draft-ietf-ipngwg-unicast-aggr-00.txt   draft-ietf-ipngwg-unicast-aggr-01.txt 
INTERNET-DRAFT R. Hinden, Ipsilon Networks INTERNET-DRAFT R. Hinden, Ipsilon Networks
May 16, 1997 M. O'Dell, UUNET June 12, 1997 M. O'Dell, UUNET
S. Deering, Cisco S. Deering, Cisco
An IPv6 Aggregatable Global Unicast Address Format An IPv6 Aggregatable Global Unicast Address Format
<draft-ietf-ipngwg-unicast-aggr-00.txt> <draft-ietf-ipngwg-unicast-aggr-01.txt>
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.'' ``working draft'' or ``work in progress.''
Please check the 1id-abstracts.txt listing contained in the internet- Please check the 1id-abstracts.txt listing contained in the internet-
drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft. current status of any Internet Draft.
This internet draft expires on November 17, 1997. This internet draft expires on December 13, 1997.
1.0 Introduction 1.0 Introduction
This document defines an IPv6 aggregatable global unicast address This document defines an IPv6 aggregatable global unicast address
format for use in the Internet. The address format defined in this format for use in the Internet. The address format defined in this
document is consistent with the IPv6 Protocol [IPV6] and the "IPv6 document is consistent with the IPv6 Protocol [IPV6] and the "IPv6
Addressing Architecture" [ARCH]. It is designed to facilitate Addressing Architecture" [ARCH]. It is designed to facilitate
scalable Internet routing. scalable Internet routing.
This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast
skipping to change at page 2, line 20 skipping to change at page 2, line 20
and Multicast. This document defines a specific type of Unicast and Multicast. This document defines a specific type of Unicast
address. address.
In this document, fields in addresses are given specific names, for In this document, fields in addresses are given specific names, for
example "subnet". When this name is used with the term "ID" (for example "subnet". When this name is used with the term "ID" (for
"identifier") after the name (e.g., "subnet ID"), it refers to the "identifier") after the name (e.g., "subnet ID"), it refers to the
contents of the named field. When it is used with the term "prefix" contents of the named field. When it is used with the term "prefix"
(e.g. "subnet prefix") it refers to all of the addressing bits to (e.g. "subnet prefix") it refers to all of the addressing bits to
the left of and including this field. the left of and including this field.
IPv6 unicast addresses are designed assuming that the internet
routing system makes forwarding decisions based on a "longest prefix
match" algorithm on arbitrary bit boundaries and does not have any
knowledge of the internal structure of IPv6 addresses. The structure
in IPv6 addresses is for assignment and allocation. The only
exception to this is the distinction made between unicast and
multicast addresses.
The specific type of an IPv6 address is indicated by the leading bits The specific type of an IPv6 address is indicated by the leading bits
in the address. The variable-length field comprising these leading in the address. The variable-length field comprising these leading
bits is called the Format Prefix (FP). bits is called the Format Prefix (FP).
This document defines an address format for the 001 (binary) Format This document defines an address format for the 001 (binary) Format
Prefix for Aggregatable Global Unicast addresses. The same address Prefix for Aggregatable Global Unicast addresses. The same address
format could be used for other Format Prefixes, as long as these format could be used for other Format Prefixes, as long as these
Format Prefixes also identify IPv6 unicast addresses. Only the "001" Format Prefixes also identify IPv6 unicast addresses. Only the "001"
Format Prefix is defined here. Format Prefix is defined here.
3.0 IPv6 Aggregatable Global Unicast Address Format 3.0 IPv6 Aggregatable Global Unicast Address Format
This document defines an address format for the IPv6 aggregatable This document defines an address format for the IPv6 aggregatable
global unicast address assignment. The authors believe that this global unicast address assignment. The authors believe that this
address format will be widely used for IPv6 nodes connected to the address format will be widely used for IPv6 nodes connected to the
Internet. This address format is designed to support both the Internet. This address format is designed to support both the
current provider-based aggregation and a new type of aggregation current provider-based aggregation and a new type of exchange-based
called exchanges. The combination will allow efficient routing aggregation. The combination will allow efficient routing
aggregation for both sites that connect directly to providers and aggregation for both sites that connect directly to providers and
sites that connect to exchanges. Sites will have the choice to sites that connect to exchanges. Sites will have the choice to
connect to either type of aggregation entity. connect to either type of aggregation entity.
Aggregatable addresses are organized into a three level hierarchy: Aggregatable addresses are organized into a three level hierarchy:
- Public Topology - Public Topology
- Site Topology - Site Topology
- Interface Identifier - Interface Identifier
skipping to change at page 3, line 42 skipping to change at page 3, line 51
P4), exchanges [EXCH] (shown as X1 and X2), multiple levels of P4), exchanges [EXCH] (shown as X1 and X2), multiple levels of
providers (shown at P5 and P6), and subscribers (shown as S.x) providers (shown at P5 and P6), and subscribers (shown as S.x)
Exchanges (unlike current NAPs, FIXes, etc.) will allocate IPv6 Exchanges (unlike current NAPs, FIXes, etc.) will allocate IPv6
addresses. Organizations who connect to these exchanges will also addresses. Organizations who connect to these exchanges will also
subscribe (directly, indirectly via the exchange, etc.) for long- subscribe (directly, indirectly via the exchange, etc.) for long-
haul service from one or more long-haul providers. Doing so, they haul service from one or more long-haul providers. Doing so, they
will achieve addressing independence from long-haul transit will achieve addressing independence from long-haul transit
providers. They will be able to change long-haul providers without providers. They will be able to change long-haul providers without
having to renumber their organization. They can also be multihomed having to renumber their organization. They can also be multihomed
via the exchange to more than one long-haul provider without having via the exchange to more than one long-haul provider without having
to have address prefixes from each long-haul provider. to have address prefixes from each long-haul provider. Note that the
mechanisms used for this type of provider selection and portability
IPv6 unicast addresses are designed assuming that the internet are not discussed in the document.
routing system makes forwarding decisions based on a "longest prefix
match" algorithm on arbitrary bit boundaries and does not have any
knowledge of the internal structure of IPv6 addresses. The structure
in IPv6 addresses is for assignment and allocation. The only
exception to this is the distinction made between unicast and
multicast addresses.
3.1 Aggregatable Global Unicast Address Structure 3.1 Aggregatable Global Unicast Address Structure
The aggregatable global unicast address format is as follows: The aggregatable global unicast address format is as follows:
| 3 | 13 | 32 | 16 | 64 bits | | 3 | 13 | 32 | 16 | 64 bits |
+---+-----+-----------+--------+--------------------------------+ +---+-----+-----------+--------+--------------------------------+
|FP | TLA | NLA* | SLA* | Interface ID | |FP | TLA | NLA* | SLA* | Interface ID |
+---+-----+-----------+--------+--------------------------------+ +---+-----+-----------+--------+--------------------------------+
<--Public Topology---> Site <--Public Topology---> Site
<--------> <-------->
Topology Topology
<------Interface Identifier-----> <------Interface Identifier----->
Where Where
FP Format Prefix (001) FP Format Prefix (001)
TLA Top-Level Aggregator TLA Top-Level Aggregator
NLA* Next-Level Aggregator(s) NLA* Next-Level Aggregator(s)
SLA* Site-Local Aggregator(s) SLA* Site-Level Aggregator(s)
INTERFACE ID Interface Identifier INTERFACE ID Interface Identifier
The following sections specify each part of the IPv6 Aggregatable The following sections specify each part of the IPv6 Aggregatable
Global Unicast address format. Global Unicast address format.
3.2 Top-Level Aggregator 3.2 Top-Level Aggregator
Top-Level Aggregators (TLA) are the top level in the routing Top-Level Aggregators (TLA) are the top level in the routing
hierarchy. Default-free routers will, at a minimum, have a routing hierarchy. Default-free routers must have a routing table entry for
table entry for every active TLA. every active TLA. They may have additional entries, but the routing
topology at all levels must be designed to minimize the number of
additional entries fed into the default free routing tables.
This addressing format supports 8,192 (2^^13) TLA's. Additional TLA This addressing format supports 8,192 (2^^13) TLA's. Additional TLA
may be added by using this format for additional format prefixes. may be added by using this format for additional format prefixes.
The addition of another FP will add another 8,192 TLA's. The addition of another FP will add another 8,192 TLA's.
3.2.1 Assignment of TLAs 3.2.1 Assignment of TLAs
TLAs are assigned to organizations providing public transit topology. TLAs are assigned to organizations providing public transit topology.
They are specifically not assigned to organizations only providing They are specifically not assigned to organizations only providing
leaf or private transit topology. TLA assignment does not imply leaf or private transit topology. TLA assignment does not imply
ownership. It does imply stewardship over valuable internet ownership. It does imply stewardship over valuable Internet
property. property.
The IAB and IESG have authorized the Internet Assigned Numbers The IAB and IESG have authorized the Internet Assigned Numbers
Authority (IANA) as the appropriate entity to have the responsibility Authority (IANA) as the appropriate entity to have the responsibility
for the management of the IPv6 address space as defined in [ALLOC]. for the management of the IPv6 address space as defined in [ALLOC].
The IANA will assign small blocks of TLAs to IPv6 registries. The The IANA will assign small blocks of TLAs to IPv6 registries. The
registries will assign the TLAs to organizations meeting the registries will assign the TLAs to organizations meeting the
requirements for TLAs. When the registries have assigned all of requirements for TLAs. When the registries have assigned all of
their TLAs they can request that the IANA to give them another block. their TLAs they can request that the IANA give them another block.
The blocks do not have to be contiguous. The IANA may also assign The blocks do not have to be contiguous. The IANA may also assign
TLAs to organizations directly. TLAs to organizations directly.
TLA assignment requirements are as follows: Organizations assigned TLAs are required to meet the following
requirements:
- Must have a plan to offer public native IPv6 service within 6 - Must have a plan to offer public native IPv6 service within 6
months from assignment. Plan must include plan for NLA months from assignment. Plan must include plan for NLA
allocation. allocation.
- Plan or track record providing public internet transit service to - Plan or track record providing public internet transit service on
other providers. TLAs should not be assigned to organization that fair, reasonable, and non-discriminatory terms, to other
are only providing leaf service even if multihomed. providers. TLAs must not be assigned to organizations that are
only providing leaf service even if multihomed.
- Must provide registry services for the NLA address space it is - Must provide registry services on fair, reasonable, and non-
responsible for under its TLA. This must include both sites and discriminatory terms, for the NLA address space it is responsible
next level providers. for under its TLA. This must include both sites and next level
providers.
- Must provide transit routing and forwarding to all assigned TLAs. - Must provide transit routing and forwarding to all assigned TLAs
Organization is not allowed to filter out any specific TLA's on fair, reasonable, and non-discriminatory terms. Organizations
(except temporarily for diagnostic purposes). are not allowed to filter out any specific TLA's (except
temporarily for diagnostic purposes or emergency repair purposed).
- Periodically (interval set by registry) provide to registry - Periodically (interval set by registry) provide to registry
utilization statistics of the TLA it has custody of. The utilization statistics of the TLA it has custody of. The
organization must also provide traffic statistics on amounts of organization must also show evidence of carrying TLA routing and
traffic for transit TLA traffic. transit traffic. This can be in the form of traffic statistics,
traceroutes, routing table dumps, or similar means.
Organizations which are given custody of a TLA and fail to continue Organizations which are given custody of a TLA and fail to continue
to meet these (or other future requirements defined by the IANA) may to meet these may have the TLA custody revoked.
have the TLA custody revoked.
3.3 Next-Level Aggregator(s) 3.3 Next-Level Aggregator(s)
Next-Level Aggregator(s) are used by TLA's to create an addressing Next-Level Aggregator(s) are used by TLA's to create an addressing
hierarchy and to identify sites. The TLA can assign the top part of hierarchy and to identify sites. The TLA can assign the top part of
the NLA in a manner to create an addressing hierarchy appropriate to the NLA in a manner to create an addressing hierarchy appropriate to
its network. It can use the remainder of the bits in the field to its network. It can use the remainder of the bits in the field to
identify sites it wishes to serve. This is shown as follows: identify sites it wishes to serve. This is shown as follows:
| n | 32-n bits | 16 | 64 bits | | n | 32-n bits | 16 | 64 bits |
skipping to change at page 6, line 30 skipping to change at page 6, line 47
| m | 32-n-m | 16 | 64 bits | | m | 32-n-m | 16 | 64 bits |
+-----+--------------+--------+-----------------+ +-----+--------------+--------+-----------------+
|NLA2 | Site | SLA* | Interface ID | |NLA2 | Site | SLA* | Interface ID |
+-----+--------------+--------+-----------------+ +-----+--------------+--------+-----------------+
| o |32-n-m-o| 16 | 64 bits | | o |32-n-m-o| 16 | 64 bits |
+-----+--------+--------+-----------------+ +-----+--------+--------+-----------------+
|NLA3 | Site | SLA* | Interface ID | |NLA3 | Site | SLA* | Interface ID |
+-----+--------+--------+-----------------+ +-----+--------+--------+-----------------+
The NLA delegation works the the same manner as CIDR delegation in The NLA delegation works in the same manner as CIDR delegation in
IPv4 [CIDR]. TLAs are required to assume registry duties for the IPv4 [CIDR]. TLAs are required to assume registry duties for the
NLAs. Each level of NLA is required to assume registry duties for NLAs. Each level of NLA is required to assume registry duties for
the next level NLA. the next level NLA.
The design of the bit layout of the NLA space for a specific TLA is The design of the bit layout of the NLA space for a specific TLA is
left to the organization responsible for that TLA. Likewise the left to the organization responsible for that TLA. Likewise the
design of the bit layout of the next level NLA is the responsibility design of the bit layout of the next level NLA is the responsibility
of the previous level NLA. It is recommended that organizations of the previous level NLA. It is recommended that organizations
assigning NLA address space use "slow start" allocation procedures as assigning NLA address space use "slow start" allocation procedures as
is currently done with IPV4 CIDR blocks. is currently done with IPV4 CIDR blocks.
The design of an NLA allocation plan is a tradeoff between routing
aggregation efficiency and flexibility. Creating hierarchies allows
for greater amount of aggregation and results in smaller routing
tables. Flat NLA assignment provides for easier allocation and
attachment flexibility but results in larger routing tables.
3.4 Site-Level Aggregator(s) 3.4 Site-Level Aggregator(s)
The SLA* field is used by an individual organization to create its The SLA* field is used by an individual organization to create its
own local addressing hierarchy and to identify subnets. This is own local addressing hierarchy and to identify subnets. This is
analogous to subnets in IPv4 except that each organization has a much analogous to subnets in IPv4 except that each organization has a much
greater number of subnets. The 16 bit SLA* field support 65,535 greater number of subnets. The 16 bit SLA* field support 65,535
individual subnets. individual subnets.
Organizations may choose to either route their SLA* "flat" (e.g., not Organizations may choose to either route their SLA* "flat" (e.g., not
create any logical relationship between the SLA identifiers), or to create any logical relationship between the SLA identifiers which
create a two or more level hierarchy in the SLA* field. The latter results in larger routing tables), or to create a two or more level
is shown as follows: hierarchy (which results in smaller routing tables) in the SLA*
field. The latter is shown as follows:
| n | 16-n | 64 bits | | n | 16-n | 64 bits |
+-----+------------+-------------------------------------+ +-----+------------+-------------------------------------+
|SLA1 | Subnet | Interface ID | |SLA1 | Subnet | Interface ID |
+-----+------------+-------------------------------------+ +-----+------------+-------------------------------------+
| m |16-n-m | 64 bits | | m |16-n-m | 64 bits |
+----+-------+-------------------------------------+ +----+-------+-------------------------------------+
|SLA2|Subnet | Interface ID | |SLA2|Subnet | Interface ID |
+----+-------+-------------------------------------+ +----+-------+-------------------------------------+
skipping to change at page 7, line 32 skipping to change at page 8, line 10
largest of organizations. Organizations which need additional largest of organizations. Organizations which need additional
subnets can arrange with the organization they are obtaining internet subnets can arrange with the organization they are obtaining internet
service from to obtain additional site identifiers and use this to service from to obtain additional site identifiers and use this to
create additional subnets. create additional subnets.
3.5 Interface ID 3.5 Interface ID
Interface identifiers are used to identify interfaces on a link. Interface identifiers are used to identify interfaces on a link.
They are required to be unique on that link. They may also be unique They are required to be unique on that link. They may also be unique
over a broader scope. In many cases an interface's identifier will over a broader scope. In many cases an interface's identifier will
be the same as that interface's link-layer address. be the same as that interface's link-layer address. Interface IDs
used in the aggregatable global unicast address format are required
Interface IDs used in the aggregatable global unicast address format to be 64 bits long and to be constructed in IEEE EUI-64 format
are required to be 64 bits long and to be constructed in IEEE EUI-64 [EUI-64]. These identifiers may have global scope when a global
format [EUI-64]. Interface identifiers formed using EUI-64 token (e.g., IEEE 48bit MAC) is available or may have local scope
identifiers may have global scope when a global token is available or where a global token is not available (e.g., serial links, tunnel
may have local scope where a global token is not available (e.g., end-points, etc.). The "u" bit (universal/local bit in IEEE EUI-64
serial links, tunnel end-points, etc.). Where EUI-64 identifiers are terminology) in the EUI-64 identifier must be set correctly, as
used it is required that the "u" bit (universal/local bit in IEEE defined in [ARCH], to indicate global or local scope.
EUI-64 terminology) be set correctly.
The construction of Interface Identifiers constructed in EUI-64 The procedures for creating EUI-64 based Interface Identifiers is
format is defined in [ARCH]. The details on forming interface defined in [ARCH]. The details on forming interface identifiers is
identifiers is defined in the appropriate "IPv6 over <link>" defined in the appropriate "IPv6 over <link>" specification such as
specification such as "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
[FDDI], etc.
4.0 Acknowledgments 4.0 Acknowledgments
The authors would like to express our thanks to Thomas Narten, Bob The authors would like to express our thanks to Thomas Narten, Bob
Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema, Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema,
and Scott Bradner for their review and constructive comments. Scott Bradner, Brian Carpenter, and John Stewart. for their review
and constructive comments.
5.0 References 5.0 References
[ALLOC] IAB and IESG, "IPv6 Address Allocation Management", [ALLOC] IAB and IESG, "IPv6 Address Allocation Management",
RFC1881, December 1995. RFC1881, December 1995.
[ARCH] Hinden, R., "IP Version 6 Addressing Architecture", [ARCH] Hinden, R., "IP Version 6 Addressing Architecture",
Internet Draft, <draft-ietf-ipngwg-addr-arch-00.txt>, May Internet Draft, <draft-ietf-ipngwg-addr-arch-00.txt>, May
1997. 1997.
[AUTO] Thompson, S., Narten T., "IPv6 Stateless Address [AUTO] Thompson, S., Narten T., "IPv6 Stateless Address
Autoconfiguration", RFC1971, August 1996. Autoconfiguration", RFC1971, August 1996.
[CIDR] V. Fuller, T. Li, K. Varadhan, J. Yu, "Supernetting: an [CIDR] Fuller, V., T. Li, K. Varadhan, J. Yu, "Supernetting: an
Address Assignment and Aggregation Strategy", RFC1338. Address Assignment and Aggregation Strategy", RFC1338.
[ETHER] M. Crawford, "Transmission of IPv6 Packets over Ethernet [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", Internet Draft, <draft-ietf-ipngwg-trans- Networks", Internet Draft, <draft-ietf-ipngwg-trans-
ethernet-00.txt>, March 1997. ethernet-00.txt>, March 1997.
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority", Registration Authority",
http://standards.ieee.org/db/oui/tutorials/EUI64.html, http://standards.ieee.org/db/oui/tutorials/EUI64.html,
March 1997. March 1997.
[EXCH] Hinden, R., Huitema, C. "Internet Exchanges", document [EXCH] Hinden, R., Huitema, C. "Internet Exchanges", document
under preparation. under preparation.
[FDDI] M. Crawford, "Transmission of IPv6 Packets over FDDI [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
Networks", Internet Draft, <draft-ietf-ipngwg-trans- Networks", Internet Draft, <draft-ietf-ipngwg-trans-fddi-
fddi-00.txt>, March 1997. net-00.txt>, March 1997.
[IPV6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version [IPV6] Deering, S., Hinden, R., Editors, "Internet Protocol,
6 (IPv6) Specification", RFC1883, December 1995. Version 6 (IPv6) Specification", RFC1883, December 1995.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC2119, BCP14, March 1997. Requirement Levels", RFC2119, BCP14, March 1997.
6.0 Security Considerations 6.0 Security Considerations
Documents of this type do not directly impact the security of the Documents of this type do not directly impact the security of the
Internet infrastructure or its applications. Internet infrastructure or its applications.
7.0 Authors' Addresses 7.0 Authors' Addresses
Robert M. Hinden phone: 1 408 990-2004 Robert M. Hinden phone: 1 408 990-2004
 End of changes. 27 change blocks. 
61 lines changed or deleted 75 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/