draft-ietf-ipngwg-unicast-aggr-04.txt   rfc2374.txt 
INTERNET-DRAFT R. Hinden, Nokia Network Working Group R. Hinden
March 13, 1998 M. O'Dell, UUNET Request for Comments: 2374 Nokia
S. Deering, Cisco Obsoletes: 2073 M. O'Dell
Category: Standards Track UUNET
S. Deering
Cisco
July 1998
An IPv6 Aggregatable Global Unicast Address Format An IPv6 Aggregatable Global Unicast Address Format
<draft-ietf-ipngwg-unicast-aggr-04.txt>
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document specifies an Internet standards track protocol for the
documents of the Internet Engineering Task Force (IETF), its Areas, Internet community, and requests discussion and suggestions for
and its Working Groups. Note that other groups may also distribute improvements. Please refer to the current edition of the "Internet
working documents as Internet Drafts. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
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- Copyright Notice
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.
This internet draft expires on September 13, 1998. Copyright (C) The Internet Society (1998). All Rights Reserved.
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
Address Format''. RFC 2073 will become historic. The Aggregatable Address Format". RFC 2073 will become historic. The Aggregatable
Global Unicast Address Format is an improvement over RFC 2073 in a Global Unicast Address Format is an improvement over RFC 2073 in a
number of areas. The major changes include removal of the registry number of areas. The major changes include removal of the registry
bits because they are not needed for route aggregation, support of bits because they are not needed for route aggregation, support of
EUI-64 based interface identifiers, support of provider and exchange EUI-64 based interface identifiers, support of provider and exchange
based aggregation, separation of public and site topology, and new based aggregation, separation of public and site topology, and new
aggregation based terminology. aggregation based terminology.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119]. document are to be interpreted as described in [RFC 2119].
skipping to change at page 4, line 18 skipping to change at page 4, line 16
their organization. They can also be multihomed via the exchange to their organization. They can also be multihomed via the exchange to
more than one long-haul provider without having to have address more than one long-haul provider without having to have address
prefixes from each long-haul provider. Note that the mechanisms used prefixes from each long-haul provider. Note that the mechanisms used
for this type of provider selection and portability are not discussed for this type of provider selection and portability are not discussed
in the document. in the document.
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 | 8 | 24 | 16 | 64 bits | | 3| 13 | 8 | 24 | 16 | 64 bits |
+--+-----+---+--------+--------+--------------------------------+ +--+-----+---+--------+--------+--------------------------------+
|FP| TLA |RES| NLA | SLA | Interface ID | |FP| TLA |RES| NLA | SLA | Interface ID |
| | ID | | ID | ID | | | | ID | | ID | ID | |
+--+-----+---+--------+--------+--------------------------------+ +--+-----+---+--------+--------+--------------------------------+
<--Public Topology---> Site <--Public Topology---> Site
<--------> <-------->
Topology Topology
<------Interface Identifier-----> <------Interface Identifier----->
Where Where
FP Format Prefix (001) FP Format Prefix (001)
TLA ID Top-Level Aggregation Identifier TLA ID Top-Level Aggregation Identifier
RES Reserved for future use RES Reserved for future use
NLA ID Next-Level Aggregation Identifier NLA ID Next-Level Aggregation Identifier
SLA ID Site-Level Aggregation Identifier SLA ID Site-Level Aggregation Identifier
INTERFACE ID Interface Identifier INTERFACE ID Interface Identifier
skipping to change at page 5, line 31 skipping to change at page 5, line 30
3.4 Next-Level Aggregation Identifier 3.4 Next-Level Aggregation Identifier
Next-Level Aggregation Identifier's are used by organizations Next-Level Aggregation Identifier's are used by organizations
assigned a TLA ID to create an addressing hierarchy and to identify assigned a TLA ID to create an addressing hierarchy and to identify
sites. The organization can assign the top part of the NLA ID in a sites. The organization can assign the top part of the NLA ID in a
manner to create an addressing hierarchy appropriate to its network. manner to create an addressing hierarchy appropriate to its network.
It can use the remainder of the bits in the field to identify sites It can use the remainder of the bits in the field to identify sites
it wishes to serve. This is shown as follows: it wishes to serve. This is shown as follows:
| n | 24-n bits | 16 | 64 bits | | n | 24-n bits | 16 | 64 bits |
+-----+--------------------+--------+-----------------+ +-----+--------------------+--------+-----------------+
|NLA1 | Site ID | SLA ID | Interface ID | |NLA1 | Site ID | SLA ID | Interface ID |
+-----+--------------------+--------+-----------------+ +-----+--------------------+--------+-----------------+
Each organization assigned a TLA ID receives 24 bits of NLA ID space. Each organization assigned a TLA ID receives 24 bits of NLA ID space.
This NLA ID space allows each organization to provide service to This NLA ID space allows each organization to provide service to
approximately as many organizations as the current IPv4 Internet can approximately as many organizations as the current IPv4 Internet can
support total networks. support total networks.
Organizations assigned TLA ID's may also support NLA ID's in their Organizations assigned TLA ID's may also support NLA ID's in their
own Site ID space. This allows the organization assigned a TLA ID to own Site ID space. This allows the organization assigned a TLA ID to
provide service to organizations providing public transit service and provide service to organizations providing public transit service and
to organizations who do not provide public transit service. These to organizations who do not provide public transit service. These
organizations receiving an NLA ID may also choose to use their Site organizations receiving an NLA ID may also choose to use their Site
ID space to support other NLA ID's. This is shown as follows: ID space to support other NLA ID's. This is shown as follows:
| n | 24-n bits | 16 | 64 bits | | n | 24-n bits | 16 | 64 bits |
+-----+--------------------+--------+-----------------+ +-----+--------------------+--------+-----------------+
|NLA1 | Site ID | SLA ID | Interface ID | |NLA1 | Site ID | SLA ID | Interface ID |
+-----+--------------------+--------+-----------------+ +-----+--------------------+--------+-----------------+
| m | 24-n-m | 16 | 64 bits | | m | 24-n-m | 16 | 64 bits |
+-----+--------------+--------+-----------------+ +-----+--------------+--------+-----------------+
|NLA2 | Site ID | SLA ID | Interface ID | |NLA2 | Site ID | SLA ID | Interface ID |
+-----+--------------+--------+-----------------+ +-----+--------------+--------+-----------------+
| o |24-n-m-o| 16 | 64 bits | | o |24-n-m-o| 16 | 64 bits |
+-----+--------+--------+-----------------+ +-----+--------+--------+-----------------+
|NLA3 | Site ID| SLA ID | Interface ID | |NLA3 | Site ID| SLA ID | Interface ID |
+-----+--------+--------+-----------------+ +-----+--------+--------+-----------------+
The design of the bit layout of the NLA ID space for a specific TLA The design of the bit layout of the NLA ID space for a specific TLA
ID is left to the organization responsible for that TLA ID. Likewise ID is left to the organization responsible for that TLA ID. Likewise
the design of the bit layout of the next level NLA ID is the the design of the bit layout of the next level NLA ID is the
responsibility of the previous level NLA ID. It is recommended that responsibility of the previous level NLA ID. It is recommended that
organizations assigning NLA address space use "slow start" allocation organizations assigning NLA address space use "slow start" allocation
procedures similar to [RFC2050]. procedures similar to [RFC2050].
The design of an NLA ID allocation plan is a tradeoff between routing The design of an NLA ID allocation plan is a tradeoff between routing
aggregation efficiency and flexibility. Creating hierarchies allows aggregation efficiency and flexibility. Creating hierarchies allows
skipping to change at page 7, line 5 skipping to change at page 7, line 5
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 ID field support 65,535 greater number of subnets. The 16 bit SLA ID field support 65,535
individual subnets. individual subnets.
Organizations may choose to either route their SLA ID "flat" (e.g., Organizations may choose to either route their SLA ID "flat" (e.g.,
not create any logical relationship between the SLA identifiers that not create any logical relationship between the SLA identifiers that
results in larger routing tables), or to create a two or more level results in larger routing tables), or to create a two or more level
hierarchy (that results in smaller routing tables) in the SLA ID hierarchy (that results in smaller routing tables) in the SLA ID
field. The latter is shown as follows: 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 |
+----+-------+-------------------------------------+ +----+-------+-------------------------------------+
The approach chosen for structuring an SLA ID field is the The approach chosen for structuring an SLA ID field is the
responsibility of the individual organization. responsibility of the individual organization.
The number of subnets supported in this address format should be The number of subnets supported in this address format should be
sufficient for all but the largest of organizations. Organizations sufficient for all but the largest of organizations. Organizations
which need additional subnets can arrange with the organization they which need additional subnets can arrange with the organization they
are obtaining Internet service from to obtain additional site are obtaining Internet service from to obtain additional site
identifiers and use this to create additional subnets. identifiers and use this to create additional subnets.
skipping to change at page 8, line 17 skipping to change at page 8, line 15
routing technology. The margin is important because default-free routing technology. The margin is important because default-free
routers will also carry a significant number of longer (i.e., more- routers will also carry a significant number of longer (i.e., more-
specific) prefixes for optimizing paths internal to a TLA and between specific) prefixes for optimizing paths internal to a TLA and between
TLAs. TLAs.
The important issue is not only the size of the default-free routing The important issue is not only the size of the default-free routing
table, but the complexity of the topology that determines the number table, but the complexity of the topology that determines the number
of copies of the default-free routes that a router must examine while of copies of the default-free routes that a router must examine while
computing a forwarding table. Current practice with IPv4 it is computing a forwarding table. Current practice with IPv4 it is
common to see a prefix announced fifteen times via different paths. common to see a prefix announced fifteen times via different paths.
The complexity of Internet topology is very likely to increase in the The complexity of Internet topology is very likely to increase in the
future. It is important that IPv6 default-free routing support future. It is important that IPv6 default-free routing support
additional complexity as well as a considerably larger internet. additional complexity as well as a considerably larger internet.
It should be noted for comparison that the current IPv4 default-free It should be noted for comparison that at the time of this writing
routing table is approximately 47,000 prefixes. While this shows (spring, 1998) the IPv4 default-free routing table contains
that it is possible to support more routes than 8,192 it is matter of approximately 50,000 prefixes. While this shows that it is possible
debate if the number of prefixes supported today in IPv4 is already to support more routes than 8,192 it is matter of debate if the
too high for current routing technology. There are serious issues of number of prefixes supported today in IPv4 is already too high for
route stability as well as cases of providers not supporting all top current routing technology. There are serious issues of route
level prefixes. The technical requirement was to pick a TLA ID size stability as well as cases of providers not supporting all top level
that was below, with a reasonable margin, what was being done with prefixes. The technical requirement was to pick a TLA ID size that
IPv4. was below, with a reasonable margin, what was being done with IPv4.
The choice of 13 bits for the TLA field was an engineering The choice of 13 bits for the TLA field was an engineering
compromise. Fewer bits would have been too small by not supporting compromise. Fewer bits would have been too small by not supporting
enough top level organizations. More bits would have exceeded what enough top level organizations. More bits would have exceeded what
can be reasonably accommodated, with a reasonable margin, with can be reasonably accommodated, with a reasonable margin, with
current routing technology in order to deal with the issues described current routing technology in order to deal with the issues described
in the previous paragraphs. in the previous paragraphs.
If in the future, routing technology improves to support a larger If in the future, routing technology improves to support a larger
number of top level routes in the default-free routing tables there number of top level routes in the default-free routing tables there
skipping to change at page 10, line 8 skipping to change at page 9, line 40
5.0 Acknowledgments 5.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,
Scott Bradner, Brian Carpenter, John Stewart, and Daniel Karrenberg Scott Bradner, Brian Carpenter, John Stewart, and Daniel Karrenberg
for their review and constructive comments. for their review and constructive comments.
6.0 References 6.0 References
[ALLOC] IAB and IESG, "IPv6 Address Allocation Management", [ALLOC] IAB and IESG, "IPv6 Address Allocation Management",
RFC1881, December 1995. RFC 1881, 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-v2-02.txt>, RFC 2373, July 1998.
July 1997.
[AUTH] Atkinson, R., "IP Authentication Header", RFC1826, August [AUTH] Atkinson, R., "IP Authentication Header", RFC 1826, August
1995. 1995.
[AUTO] Thompson, S., T. Narten., "IPv6 Stateless Address [AUTO] Thompson, S., and T. Narten., "IPv6 Stateless Address
Autoconfiguration", RFC1971, August 1996. Autoconfiguration", RFC 1971, August 1996.
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", Internet Draft, <draft-ietf-ipngwg-trans- Networks", Work in Progress.
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.
[FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
Networks", Internet Draft, <draft-ietf-ipngwg-trans-fddi- Networks", Work in Progress.
net-00.txt>, March 1997.
[IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6 [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC1883, December 1995. (IPv6) Specification", RFC 1883, December 1995.
[RFC2050] Hubbard, K., M. Kosters, D. Conrad, D. Karrenberg, J. [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D.,
Postel, "Internet Registry IP Allocation Guidelines", and J. Postel, "Internet Registry IP Allocation
RFC1466, BCP12, November 1996. Guidelines", BCP 12, RFC 1466, November 1996.
[RFC2119] Bradner, S., "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", BCP 14, RFC 2119, March 1997.
7.0 Security Considerations 7.0 Security Considerations
IPv6 addressing documents do not have any direct impact on Internet IPv6 addressing documents do not have any direct impact on Internet
infrastructure security. Authentication of IPv6 packets is defined infrastructure security. Authentication of IPv6 packets is defined
in [AUTH]. in [AUTH].
8.0 Authors' Addresses 8.0 Authors' Addresses
Robert M. Hinden phone: 1 408 990-2004 Robert M. Hinden
Nokia . email: hinden@iprg.nokia.com Nokia
232 Java Drive 232 Java Drive
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Mike O'Dell phone: 1 703 206-5890 Phone: 1 408 990-2004
UUNET Technologies, Inc. email: mo@uunet.uu.net EMail: hinden@iprg.nokia.com
Mike O'Dell
UUNET Technologies, Inc.
3060 Williams Drive 3060 Williams Drive
Fairfax, VA 22030 Fairfax, VA 22030
USA USA
Stephen E. Deering phone: 1 408 527-8213 Phone: 1 703 206-5890
Cisco Systems, Inc. email: deering@cisco.com EMail: mo@uunet.uu.net
Stephen E. Deering
Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134-1706 San Jose, CA 95134-1706
USA USA
Phone: 1 408 527-8213
EMail: deering@cisco.com
9.0 Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 30 change blocks. 
88 lines changed or deleted 86 lines changed or added

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