view Side-By-Side changes
- 1 -
Network Working Group
INTERNET-DRAFT Y. Rekhter
INTERNET DRAFT T.J. Watson Research Center, IBM Corp. Rekhter, Cisco
August 30, 1995 P. Lothberg Lothberg, STUPI.AB
Expires in six months R. Hinden, Ipsilon Networks
S. Deering, Xerox PARC
J. Postel, ISI
Editors
February 1995
An IPv6 Global Provider-Based Unicast Address Format
<draft-ietf-ipngwg-unicast-addr-fmt-01.txt>
<draft-ietf-ipngwg-unicast-addr-fmt-02.txt>
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working
documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts as
reference material or to cite them other than as a ``working draft'' or
``work in progress.''
Please check the 1id-abstracts.txt listing contained in the
internet-drafts internet-
drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net,
ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any
Internet Draft.
1
1.0 Introduction
This document defines an IPv6 global provider-based unicast address format for
use in the Internet. The address format defined in this document is
consistent with the "IPv6 Addressing Architecture" [ARCH] and the "An
Architecture for IPv6 address allocation architecture [1], Unicast Address Allocation" [ALLOC], and is
intended to facilitate scalable Internet routing.
The unicast address format defined in this document doesn't preclude the
use of other unicast address formats.
2
draft-ietf-ipngwg-unicast-addr-fmt-02.txt [Page 1]
INTERNET-DRAFT Provider-Based Unicast Address Format August 30, 1995
2.0 Overview of the IPv6 Address
IPv6 addresses are 128-bit identifiers for interfaces and sets of
interfaces. There are three types of addresses: Unicast, Anycast, and
Multicast. This section recapitulates essential information from document defines a specific type of Unicast address.
In this document, fields in addresses are given specific names, for
example "subscriber". When this name is used with the IPv6
protocol specifications [2] concerning term "ID" (for
"identifier") after the basic structure name (e.g., "subscriber ID"), it refers to the
contents of the named field. When it is used with the term "prefix"
(e.g. "subscriber prefix") it refers to all of the
IPv6 addresses.
Expiration Date July 1995 [Page 1]
- 2 -
The IPv6 protocol [2] defines an IPv6 address as a 16 octets object. up to and
including this field.
The high-order bits specific type of an IPv6 address are used to indicate a
particular type of is indicated by the leading bits in
the address. The variable-length prefix field comprising these leading bits is
called the Format Prefix (FP).
This document defines an address format for the 010 (binary) Format
Prefix.
Prefix for Provider-Based Unicast addresses. The same address format can
could be used for other FPs, Format Prefixes, as long as these FPs Format
Prefixes also identify IPv6 unicast addresses.
3 Only the "010" Format
Prefix is defined here.
3.0 IPv6 Global Provider-Based Unicast Address Format for Use in the Internet
This document defines an address format for the IPv6 provider-based
unicast address assignment. It is expected that the defined this address format would
will be widely used for systems IPv6 nodes connected (at IP) to the Internet.
The address format defined in this document conforms to the
architecture
"Architecture for IPv6 address allocation [1]. Unicast Address Allocation" [ALLOC].
Specifically, the format is designed to support aggregation of network
layer reachability information at multiple levels of routing hierarchy, as
described in [1]. hierarchy.
For addresses of the format described in this document the address
administration is organized into a three level hierarchy -- registry,
provider, and subscriber. The address format defined here allows
flexible address allocation at each level of the address administration
hierarchy in such a way as to support a wide spectrum of demands for
address allocation.
This document assumes that the Internet routing system doesn't make any
assumptions about the specific structure and semantics of an IPv6
address, except for the structure and semantics of the Format Prefix
part of the address, and the use of the "longest prefix match" algorithm
(on arbitrary bit boundaries) for making a forwarding decision.
draft-ietf-ipngwg-unicast-addr-fmt-02.txt [Page 2]
INTERNET-DRAFT Provider-Based Unicast Address Format August 30, 1995
The address format defined in this document is intended to facilitate
scalable Internet-wide routing that doesn't does not impose any constraints on
connectivity among the providers, as well as among the providers and
subscribers.
The address format defined in this document does not preclude the use
of other address formats in the Internet.
3.1 Global IPv6 Provider-Based Unicast Addresses Address Structure
For the purpose of address allocation, the address format defined in
this document consists of the following parts: Format Prefix, Registry Identifier, Registry-Specific Component, Provider-Specific
Expiration Date July 1995 [Page 2]
- 3 -
Component,
ID, Provider ID, Subscriber ID, and Subscriber-Specific Component.
+-------------------------------+
| Format Prefix |
+-------------------------------+ an Intra-Subscriber part. The
Intra-Subscriber part definition is the responsibility of the subscriber
and is not defined in this document. The provider-based unicast address
format is as follows:
| Registry Identifier Component 3 |
+-------------------------------+ 5 bits | Registry-Specific Component 16 bits |
+-------------------------------+ 8 | Provider-Specific Component 24 bits |
+-------------------------------+ 8 | Subscriber-Specific Component 64 bits |
+-------------------------------+
+---+----------+----------+---+------------+---+----------------+
|010|RegistryID|ProviderID|RES|SubscriberID|RES|Intra-Subscriber|
+---+----------+----------+---+------------+---+----------------+
The following sections suggest some of the alternatives in forming specify each part of the address. The suggestions IPv6 Provider-Based
Unicast address format. In general other allocation strategies are only a small number of
the technically
possible addressing formats and simultaneously
demonstrate different alternatives at different levels in the
hierarchy. RFC1219 provides useful information for allocating values within individual components. Ultimately it is the joint
responsibility of the registry, this framework, but the provider ones described in this document
will be used to assign IPv6 provider-based addresses.
The fields identified as "RES" are reserved and the subscriber must be set to zero (0).
They are intended to
agree allow for the fields on their local addressing structure. either side to grow into
that space if needed for future growth.
3.2 Registry Identifiers Component (Registry ID) ID
With the growth of the Internet and its increasing globalization, much
thought has been given to the evolution of the Network Layer address
space allocation and assignment process. RFC 1466, "Guidelines for
Management of IP Address Space", proposes a plan that defines
distributed allocation and assignment of the IPv4 address space.
As the Internet transitions to IPv6, the plan for distributed allocation
and assignment of the IPv4 address space established in RFC1466 forms a
base for the distributed allocation and assignment of the IPv6 address
space.
The Internet Registry (IR) acts as Assigned Number Authority (IANA) is the principal registry
for the
Expiration Date July 1995 [Page 3]
- 4 - IPv6 address space; however, the IR space. The IANA may allocate blocks of IPv6
addresses and delegate the assignment of those addresses blocks to qualified
Regional Registries. The IR IANA will serve as the default registry in
cases where no delegated registration authority has been identified. It is
expected that the IANA will act as the IR.
draft-ietf-ipngwg-unicast-addr-fmt-02.txt [Page 3]
INTERNET-DRAFT Provider-Based Unicast Address Format August 30, 1995
The Registry Identifier (Registry ID) Component ID of the IPv6 provider-based unicast address format defined in this document is
intended to facilitate a broad geographic address allocation and
facilitate the operations of the distributed Regional Registries.
The Registry ID Component immediately follows the FP format prefix part of an IPv6
address.
At present there are three Regional Registries: INTERNIC, RIPE NCC, and
APNIC. In addition, address allocation could be done directly by the Internet Registry.
IANA. Corresponding to this division of address allocation, this
document defines the following Registry IDs (and
associated with them address blocks):
- 0xF8 (5 bits long) - multi-regional (IR)
- 0xE8 (5 bits long) - IDs:
Regional Registry Value (binary)
-------------------- --------------
Multi-Regional (IANA) 10000
RIPE NCC
- 0xD0 (5 bits long) - 01000
INTERNIC
- 0x90 (5 bits long) - 11000
APNIC 10100
All other values of the Registry ID Component are reserved by the IANA.
Use of the Multi-regional Registry ID permits flexibility in address
assignments which are outside of the geographical regions already
allocated. It is expected that the IR would The IANA will be responsible for managing address space
registration under the Multi-regional Multi-Regional Registry ID.
It is expected that the IR, IANA, and any designated Regional Registries,
allocate addresses in conformance with this overall scheme. Where there
are qualifying Regional Registries established, primary responsibility
for allocation from within that block will be delegated to that
registry.
A Regional Registry may have more than one block of addresses allocated
to it (as a result the Registry would have multiple Registry IDs
associated with it).
Expiration Date July 1995 [Page 4]
- 5 -
3.3 Registry-Specific Component (RSC)
This document assumes that within each Regional Registry there will
be a relatively large number of providers that would request
relatively small blocks of addresses, medium number of providers that
would request medium blocks of addresses, and relatively small number
of providers that would request relatively large blocks of addresses.
To accommodate a potentially wide range of demands for address space
allocation by individual providers a registry should allow Provider ID
The Provider ID is initially assigned 16 bits. At some time in the RSC to
future it may be of variable length. The length of allowed to grow (to the RSC associated with right) into the
address block a registry allocates to "RES" field if
additional providers are needed in a provider determines the size particular registry. The 16-bit
Provider ID provides for 65,535 providers per Registry ID without any
expansion of the address block granted to that provider by the registry. Provider ID, or 2,031,585 providers within this format
prefix.
The value of the RSC Provider ID associated with an address block a registry
draft-ietf-ipngwg-unicast-addr-fmt-02.txt [Page 4]
INTERNET-DRAFT Provider-Based Unicast Address Format August 30, 1995
allocates to a particular provider uniquely identifies this provider
within the registry. Since RSC is of variable length, the uniqueness
implies that no two RSC values assigned within a given registry
Provider ID's should be equal allocated from right to each other or should exhibit a substring (subset)
relationship.
We suggest that within a registry the range of RSC length be limited
between left as shown in
following table:
Provider Provider ID Value (binary)
--------- --------------------------
Provider 1 and 0000 0000 0000 0001
Provider 2 0000 0000 0000 0010
Provider 3 octets. Combined with FP and Registry ID, that leaves
12 to 14 octets for the 0000 0000 0000 0011
Provider Specific and Subscriber Specific
components.
We further suggest that at the minimum a registry would allow address
allocation with RSC of the following length:
RSC Length Fraction of Registry's Address Space
(in bits) (per provider)
---------- ------------------------------------
24 1/(2^24)
16 1/(2^16)
8 1/(2^8) 4 0000 0000 0000 0100
Provider 5 0000 0000 0000 0101
: : : :
Provider 65,535 1111 1111 1111 1111
This document assumes that some subscribers may decide to acquire their
addresses space directly out of from a registry, thus making their addresses
independent of the provider(s) they are directly attached to.
To accommodate such subscribers we suggest within each registry attached.
3.4 Subscriber ID
The Subscriber ID is initially assigned 24 bits. At some time in the
future it may be allowed to
reserve grow (to the portion of left) into the address space that begins with 0xFF for
address allocation to "RES" field if
additional subscribers that elect to use provider-
independent addressing (as described are needed in Section 3.6).
Expiration Date July 1995 [Page 5]
- 6 -
3.4 Provider-Specific Component (PSC)
This document assumes that within each provider there will be a
relatively large number of subscribers that would request relatively
small blocks of addresses, medium number of particular provider. The 24-bit
Subscriber ID provides for 16,777,215 subscribers that would
request medium blocks of addresses, relatively small number per Provider ID
without any expansion of the Provider ID, or approximately 34 trillion
subscribers that would request relatively large blocks of addresses within this format prefix.
The structure and very few subscribers that would require very large block of
addresses.
To accommodate a potentially wide range assignment strategy of demands for address space
allocation Subscriber ID's is specified by individual subscribers a
each provider.
A (direct) provider should allow the PSC may decide to group its subscribers into regions.
This grouping may be of variable length. The length of useful when the PSC associated with (direct) provider is attached to
another (indirect) provider at multiple points, as it allows the
address block a direct
provider allocates to exert a subscriber determines the
size certain degree of control over the address block granted to that subscriber by the provider.
The value of the PSC associated with an address block a provider
allocates to a particular subscriber uniquely identifies this
subscriber within the provider. Since the PSC is of variable length,
the uniqueness implies no two PSC values assigned within a given
provider should be equal to each other or should exhibit a substring
(subset) relationship.
We suggest that within a provider the range of PSC length be limited
between 1 and 4 octets.
We further suggest that at the minimum a provider would allow address
allocation with PSC of the following length:
PSC Length Fraction of Provider's Address Space
(in bits) (per subscriber)
---------- ------------------------------------
32 1/(2^32)
24 1/(2^24)
16 1/(2^16)
8 1/(2^8)
A (direct) provider may decide to group its subscribers into regions.
This grouping may be useful when the (direct) provider is attached to
another (indirect) provider at multiple points, as it allows the
direct provider to exert a certain degree of control over the
coupling between coupling between
the attachment points and flow of the traffic destined to a particular
subscriber (see Section 5.3.1 of [1]). [ALLOC]).
To accommodate such a grouping we suggest that the (direct) provider
should may allocate some
small number of high-order bits (e.g. between 2
and 4 bits) of PSC as a Region Identifier. The purpose of a Region
Expiration Date July 1995 [Page 6]
- 7 -
Identifier is to identify a group of subscribers that are within a
close topological proximity to each other (from the provider's point
of view), and thus could be reachable through a particular attachment
point between the (direct) provider and other (indirect) provider(s).
Regardless of whether the Region Identifier is present, we suggest
that the total length of the PSC varies from 1 to 4 octets. Combined
with FP, Registry ID, and PSC that leaves 8 to 13 octets for the Subscriber Specific Component.
3.5 Subscriber-Specific Component (SSC)
This document leaves the organization of SSC up to individual
subscribers. However, this document assumes that for all but
relatively small subscribers, there will be sufficient number of bits
within the SSC to allow address assignment in such a way as to
provide hierarchical routing (at least two levels) within a
subscriber.
Regardless of how other components are organized, this document
suggests that for the subscribers that use IPv6 autoconfiguration
capabilities the minimum number of octets allocated to the SSC should
be 7. This would allow to embed IEEE 802 MAC addresses ID as the low
order 6 octets of an IPv6 address (stored in IEEE 802 canonical bit
order). Observe, that if allocation of all the other components
follows recommendations presented in this document, the SSC component
would have at least 8 octets.
3.6 Provider-independent Address Format
This section describes one possible address format for subscribers
that elect to use provider-independent addresses. The format of these
addresses is similar to the one described in the previous sections,
but it doesn't include the PSC.
This document assumes that within each registry there will be a
medium number of subscribers that would request medium block of
provider-independent addresses and relatively small number of
subscribers that would request relatively large block of provider-
independent addresses.
Each registry is expected to reserve an address block that begins
with 0xFF (8 bits) for allocation to subscribers that elect
provider-independent addresses. Following this is a variable length
Subscriber Identifier (S-ID) field. The length of the S-ID field
Expiration Date July 1995 [Page 7]
- 8 -
associated with the address block a registry allocates to a
subscriber determines the size of the address block granted to that
subscriber by the registry. Subscriber-
Region ID. The value purpose of the S-ID associated with an address block a registry
allocates to a particular subscriber uniquely identifies this
subscriber within the registry. Since S-ID Subscriber-Region ID is of variable length, the
uniqueness implies that no two S-ID values assigned within a given
registry should be equal to each other or should exhibit to identify a substring
(subset) relationship.
We suggest group
of subscribers that are within a registry close topological proximity to each
other (from the range providers point of S-ID length view), and thus could be limited
from 12 to 24 bits. We further suggest that at the minimum reachable
through a registry
should allow address allocation with S-ID of particular attachment point between the length of 12 (direct) provider and 24
bits.
other (indirect) provider(s).
draft-ietf-ipngwg-unicast-addr-fmt-02.txt [Page 5]
INTERNET-DRAFT Provider-Based Unicast Address Format August 30, 1995
3.5 Intra-Subscriber Part
This would document leaves from 12 the organization of Intra-Subscriber portion of the
address up to 13.5 octets for allocation within individual sites (for subscribers.
The provider-based unicast address format described in this document
leaves 64 bits for the SSC).
One possible use local portion of the address. The editors of provider-independent
this document recommended that subscribers use IPv6 auto-configuration
capabilities [AUTO] to generate addresses using 48 bit IEEE-802 MAC
addresses as Interface IDs. In this case 16 bits is left for multihomed
sites (as described in Section 5.4.1 of [1]).
Allocation and use the Subnet
ID. This should sufficient (e.g., 65,535 subnets) for all but the
largest of provider-independent addresses requires careful
judgement. It subscribers. This is crucial shown as follows:
| 64 bits | 16 bits | 48 bits |
+--------------------------------+-----------+------------------+
| Subscriber Prefix | Subnet ID | Interface ID |
+--------------------------------+-----------+------------------+
Subscribers who need additional subnets (and who desire to continue to understand that
use of such 48 bit IEEE-802 MAC addresses for Interface ID's) can be
accommodated by allowing the purpose of Internet-wide connectivity has negative impact on the
overall routing system, as Subnet ID can grow to the only possible routing information
abstraction above left into the
"RES" field. Alternatively, an extremely large subscriber level could occur at the continental
level (see Section 5.7 be
assigned its own Provider ID which would give it 48 bits of [1]).
4 address
space to create its own local address hierarchy.
4.0 National Registry
As a variation of the proposed format, a Registries
A Regional Registry may allocate blocks of address space to several
National Registries. A The National Registry then becomes the entity that
allocates address space to individual organizations (e.g. providers) providers within the country
served by the National Registry.
To support address allocation by create National Registries this document
allows to include the National Regional Registry Id Component as part may add a layer of
hierarchy in the
address format (see below). Provider ID field to create National Registries. The Component
resulting Provider Prefix is immediately follows the
Registry Identifier Component and precedes the Registry-Specific
Component.
+-------------------------------+ a follows:
| Format Prefix |
+-------------------------------+ | Registry Identifier Component 16 bits |
+-------------------------------+
| National Registry ID Component|
Expiration Date July 1995 [Page 8]
- 9 -
+-------------------------------+ 3 | Registry-Specific Component 5 bits |
+-------------------------------+ n bits | Provider-Specific Component 16-n bits |
+-------------------------------+
+---+----------+---------------------+-------------+
|010|RegistryID|National-Registry ID | Subscriber-Specific Component Provider ID |
+-------------------------------+
+---+----------+---------------------+-------------+
This document assumes that within each regional registry there will be a
relatively small number of national registries. However, within
each national registry there will be a relatively large number of
providers that would request relatively small blocks of addresses,
medium number of providers that would request medium blocks of
addresses, and relatively small number of providers that would
request relatively large blocks of addresses.
To accommodate a potentially wide range of demands for address space
allocation by individual national registries a regional registry
should allow the National Registry ID to be of variable length. The
length size of the National Registry
National-Registry ID associated with the address block
a regional registry allocates should be related to a national registry determines the
size number of countries in the address block granted to that provider
region administrated by the registry.
The value of the National Registry ID associated with an address
block a regional registry allocates to a particular national registry
uniquely identifies this national registry. Since the National
Registry ID is of variable length, and the uniqueness implies that no two
National Registry ID values assigned within a given regional registry
should be equal number providers
draft-ietf-ipngwg-unicast-addr-fmt-02.txt [Page 6]
INTERNET-DRAFT Provider-Based Unicast Address Format August 30, 1995
expected to be in each other or should exhibit a substring (subset)
relationship.
We suggest that within a regional registry the range of the country. National
Registry ID length be limited between 1 and 2 octets. We further
suggest that within a national registry the range of the RSC length Registries who need additional
providers can be limited between 1 and 2 octets. Combined with FP, Regional
Registry ID, and National Registry ID, that leaves 12 to 14 octets
for supported by allowing the Provider Specific and Subscriber Specific components.
We further suggest that at ID to grow to the minimum a national registry would
allow address allocation with RSC of
right into the following length:
RSC Length Fraction of Registry's "RES" field.
draft-ietf-ipngwg-unicast-addr-fmt-02.txt [Page 7]
INTERNET-DRAFT Provider-Based Unicast Address Space
(in bits) (per provider)
---------- ------------------------------------
16 1/(2^16)
8 1/(2^8)
Expiration Date July Format August 30, 1995 [Page 9]
- 10 -
5 Conclusions
[TBD]
6 Acknowledgements
We
6.0 Acknowledgments
The editors would like to express our thanks to Jim Bound (DEC), Scott
Bradner (Harvard), Brian Carpenter (CERN), Steve Deering (XEROX), Geoff Huston (AANET), and
Tony Li (cisco) for their review and constructive comments.
7
6.0 References
[1]
[ALLOC] Rekhter, Y., Li, T., "An Architecture for IPv6 Unicast Address
Allocation", Internet Draft
[2] Draft.
[ARCH] Hinden, B., R., "IP Next Generation Version 6 Addressing Architecture", Architecture" Internet Draft
8
Draft.
[AUTO] Thompson, S., "IPv6 Stateless Address Autoconfiguration",
Internet Draft.
7.0 Security Considerations
Security issues are not discussed in this memo.
9 Authors'
8.0 Editors' Addresses
Yakov Rekhter
T.J. Watson Research Center, IBM Corporation
P.O. Box 704
Yorktown Heights, NY 10598
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Phone: (914) 784-7361 +1 914 528-0090
email: yakov@watson.ibm.com yakov@cisco.com
Peter Lothberg
STUPI.AB
Box 9129
S-102 72 Stockholm
Sweden
Phone:+46 8 6699720
email:roll@Stupi.SE
Expiration Date
email: roll@Stupi.SE
draft-ietf-ipngwg-unicast-addr-fmt-02.txt [Page 8]
INTERNET-DRAFT Provider-Based Unicast Address Format August 30, 1995
Robert M. Hinden
Ipsilon Networks, Inc.
2465 Latham Street, Suite 100
Mt. View, CA 94040
USA
phone: +1 415 528 4604
email: hinden@ipsilon.com
Stephen E. Deering
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304
USA
phone: +1 415 812 4839
fax: +1 415 812 4471
email: deering@parc.xerox.com
Jon Postel
Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292-6695
USA
phone: +1 310 822 1511
fax: +1 310 823 6714
email: postel@isi.edu
draft-ietf-ipngwg-unicast-addr-fmt-02.txt [Page 10] 9]
----