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/