One document matched: draft-rekhter-IPv6-address-format-00.txt
- 1 -
Network Working Group Y. Rekhter
INTERNET DRAFT T.J. Watson Research Center, IBM Corp.
P. Lothberg
STUPI.AB
Editors
November 1994
IPv6 Preferred Unicast Address Format
<draft-rekhter-IPv6-address-format-00.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 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 Introduction
This document defines a preferred IPv6 unicast address format for use
in the Internet. The address format defined in this document is
consistent with the IPv6 address allocation architecture [1].
The format defined in this document doesn't preclude the use of other
of other address formats.
2 Overview of the IPv6 Address
This section recapitulates essential information from the IPv6
protocol specifications [2] concerning the basic structure of the
IPv6 addresses.
The IPv6 protocol [2] defines an IPv6 address as a sequence of 16
Expiration Date May 1995 [Page 1]
- 2 -
octets. The high-order bits of an IPv6 address are used to indicate
a particular type of the address. The variable-length prefix field
comprising these bits is called the Format Prefix (FP). This
document defines an address format for the 01 (binary) Format Prefix.
In the context of this document we treat FP as a fixed length (2
bits) field.
3 Preferred IPv6 Unicast Address Format for Use in the Internet
This document defines an address format for the IPv6 unicast address
assignment. It is expected that the defined format would be widely
used for systems connected (at the Network Layer) to the Internet.
The address format defined in this document conforms to the
architecture for IPv6 address allocation [1]. Specifically, the
format is designed to support aggregation of network layer
reachability information at multiple levels of routing hierarchy, as
described in [1].
This document assumes that address administration is organized into a
three level hierarchy -- registry, provider, and subscriber. The
address format defined in this document 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.
The address format defined in this document does not preclude the use
of other address formats in the Internet. The Internet routing
system, and especially its inter-domain component is expected to
assume as little as possible about specific structure and semantics
of an IPv6 address, except for the structure and semantics of the
Format Prefix part of the address.
3.1 Global IPv6 Unicast Addresses 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
Component, and Subscriber-Specific Component.
Expiration Date May 1995 [Page 2]
- 3 -
+-------------------------------+
| Format Prefix |
+-------------------------------+
| Registry Identifier Component |
+-------------------------------+
| Registry-Specific Component |
+-------------------------------+
| Provider-Specific Component |
+-------------------------------+
| Subscriber-Specific Component |
+-------------------------------+
The following sections suggest some of the alternatives in forming
each part of the address. The suggestions are only a small number of
the technically possible addressing formats and simultaneously
demonstrate different alternatives at different levels in the
hierarchy. It is the joint responsibility of the registry, the
provider and the subscriber to agree on their local addressing
structure.
3.2 Registry Identifiers Component (Registry 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.
Internet Registry (IR) acts as the principal registry for the IPv6
address space; however, the IR may allocate blocks of IPv6 addresses
and the assignment of those addresses to qualified Regional
Registries. The IR will serve as the default registry in cases where
no delegated registration authority has been identified.
The Registry Identifier (Registry ID) Component of the IPv6 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 part of an IPv6
Expiration Date May 1995 [Page 3]
- 4 -
address.
At present there are four major areas of address allocation: Europe,
North America, Pacific Rim, and South & Central America. In addition
address allocation could be done by the IR. Corresponding to this
division of address allocation, this document defines the following
values for the Registry ID Component:
- 0xFC (6 bits long) - Multi-regional
- 0xF4 (6 bits long) - Europe
- 0xE8 (6 bits long) - North America
- 0xE4 (6 bits long) - Central/South America
- 0xC8 (6 bits long) - Pacific Rim
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 be responsible for
managing address space registration under the Multi-regional Registry
ID.
It is expected that the IR, 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.
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 block of addresses, medium number of providers that
would request medium block of addresses, and relatively small number
of providers that would request relatively large block of addresses.
To accommodate a potentially wide range of demands for address space
allocation by individual providers a registry should allow RSC to be
of variable length. The length of the RSC associated with the address
block a registry allocates to a provider determines the size of the
address block granted to that provider by the registry.
The value of the RSC associated with an address block a registry
Expiration Date May 1995 [Page 4]
- 5 -
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
should be equal to each other or should exhibit a substring (subset)
relationship.
We suggest that within a registry the range of RSC length be limited
between 1 and 3 octets. Combined with FP and Registry ID, that leaves
12 to 14 octets for the 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)
This document assumes that some subscribers may decide to acquire
their addresses space directly out of a registry, thus making their
addresses independent of the provider(s) they directly attached to.
To accommodate such subscribers we suggest within each registry to
reserve the portion of the address space that begins with 0xFF for
address allocation to subscribers that elect to use provider-
independent addressing (as described in Section 3.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 block of addresses, medium number of subscribers that would
request medium block of addresses, relatively small number of
subscribers that would request relatively large block of addresses
and very few subscribers that would require very large block of
addresses.
To accommodate a potentially wide range of demands for address space
allocation by individual subscribers a provider should allow PSC to
be of variable length. The length of the PSC associated with the
address block a provider allocates to a subscriber determines size of
Expiration Date May 1995 [Page 5]
- 6 -
the address block granted to that subscriber by the provider.
The value of PSC associated with an address block a provider
allocates to a particular subscriber uniquely identifies this
subscriber within the provider. Since 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 provider may decide to group its subscribers into regions. This
grouping may be useful when the (direct) provider is attached to
other (indirect) provider at multiple points, as it allows the direct
provider to exert a certain degree of control over the coupling
between the attachment points and flow of the traffic destined to a
particular subscriber (see Section 5.3.1 of [1]). To accommodate such
a grouping we suggest to use high-order 4 bits of PSC as a Region
Identifier. The purpose of a Region 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 Region Identifier is present, we suggest that
the total length of 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.
Expiration Date May 1995 [Page 6]
- 7 -
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.
It is suggested 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 as the low order 6 octets of an IPv6 address (stored in
IEEE 802 canonical bit order).
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
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.
The value 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 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 a substring
(subset) relationship.
We suggest that within a registry the range of S-ID length be limited
from 12 to 24 bits. We further suggest that at the minimum a registry
should allow address allocation with S-ID of the length of 12 and 24
bits. This would leaves from 12 to 13.5 octets for allocation within
individual sites (for the SSC).
Expiration Date May 1995 [Page 7]
- 8 -
One possible use of provider-independent addresses is for multihomed
sites (as described in Section 5.4.1 of [1]).
Allocation and use of provider-independent addresses requires careful
judgement. It is crucial to understand that use of such addresses for
the purpose of Internet-wide connectivity has negative impact on the
overall routing system, as the only possible routing information
abstraction above the subscriber level could occur at the continental
level (see Section 5.7 of [1]).
4 National Registry
As a various of the proposed format, a Regional Registry may allocate
blocks of address space to several National Registries. A National
Registry then becomes the entity that allocates address space to
individual organizations (e.g. providers) within the country served
by the Registry.
To support address allocation by National Registries this document
allows to include the National Registry Id Component as part of the
address format (see below). The Component is immediately follows the
Registry Identifier Component and precedes the Registry-Specific
Component.
+-------------------------------+
| Format Prefix |
+-------------------------------+
| Registry Identifier Component |
+-------------------------------+
| National Registry ID Component|
+-------------------------------+
| Registry-Specific Component |
+-------------------------------+
| Provider-Specific Component |
+-------------------------------+
| Subscriber-Specific Component |
+-------------------------------+
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 block of addresses,
medium number of providers that would request medium block of
addresses, and relatively small number of providers that would
Expiration Date May 1995 [Page 8]
- 9 -
request relatively large block of addresses.
To accommodate a potentially wide range of demands for address space
allocation by individual national registries a regional registry
should allow National Registry ID to be of variable length. The
length of the National Registry ID associated with the address block
a regional registry allocates to a national registry determines the
size of the address block granted to that provider 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 National Registry
ID is of variable length, the uniqueness implies that no two National
Registry ID values assigned within a given regional registry should
be equal to each other or should exhibit a substring (subset)
relationship.
We suggest that within a regional registry the range of the National
Registry ID length be limited between 1 and 2 octets. We further
suggest that within a national registry the range of RSC length be
limited between 1 and 2 octets. Combined with FP, Regional Registry
ID, and National Registry ID, that leaves 12 to 14 octets for the
Provider Specific and Subscriber Specific components.
We further suggest that at the minimum a national registry would
allow address allocation with RSC of the following length:
RSC Length Fraction of Registry's Address Space
(in bits) (per provider)
---------- ------------------------------------
16 1/(2^16)
8 1/(2^8)
5 Conclusions
[TBD]
6 Acknowledgements
We would like to express our thanks to Jim Bound (DEC), Brian
Carpenter (CERN), Steve Deering (XEROX), Geoff Huston (AANET), and
Tony Li (cisco) for their review and constructive comments.
Expiration Date May 1995 [Page 9]
- 10 -
7 References
[1] Rekhter, Y., Li, T., "An Architecture for IPv6 Unicast Address
Allocation", Internet Draft, September 1994
[2] Hinden, B., "IP Next Generation Addressing Architecture",
Internet Draft, October 1994
8 Security Considerations
Security issues are not discussed in this memo.
9 Authors' Addresses
Yakov Rekhter
T.J. Watson Research Center, IBM Corporation
P.O. Box 704
Yorktown Heights, NY 10598
Phone: (914) 784-7361
email: yakov@watson.ibm.com
Peter Lothberg
STUPI.AB
Box 9129
S-102 72 Stockholm
Sweden
Phone:+46 8 6699720
email:roll@Stupi.SE
Expiration Date May 1995 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-21 19:13:08 |