< draft-ietf-ipv6-unicast-aggr-v2-01.txt		draft-ietf-ipv6-unicast-aggr-v2-02.txt >
	INTERNET-DRAFT R. Hinden, Nokia		INTERNET-DRAFT R. Hinden, Nokia
	February 4, 2003 S. Deering, Cisco		February 26, 2003 S. Deering, Cisco
			E. Nordmark, Sun
	IPv6 Global Unicast Address Format for the 2000::/3 Prefix		IPv6 Global Unicast Address Format
	<draft-ietf-ipv6-unicast-aggr-v2-01.txt>		<draft-ietf-ipv6-unicast-aggr-v2-02.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		This document is an Internet-Draft and is subject to all provisions
	of Section 10 of RFC2026.		of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 31 ¶		skipping to change at page 1, line 32 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet- Drafts as reference		time. It is inappropriate to use Internet- Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	This internet draft expires on August 4, 2003.		This internet draft expires on August 26, 2003.
	Abstract		Abstract
	This document defines the unicast address format for the 2000::/3		RFC2374 "An IPv6 Aggregatable Global Unicast Address Format" defined
	(001 binary) prefix. The address format defined in this document is		an IPv6 address allocation structure that includes TLA (Top Level
	consistent with RFC2460 "Internet Protocol, Version 6 (IPv6)		Aggregator) and NLA (Next Level Aggregator). This document replaces
	Specification" and RFCXXXX "IP Version 6 Addressing Architecture".		RFC2374, and makes RFC 2374 and the TLA/NLA structure historic.
	This documented replaces RFC2374 "An IPv6 Aggregatable Global Unicast
	Address Format". RFC2374 will become historic.
	1.0 Introduction		1.0 Introduction
	This document defines the unicast address format for the 2000::/3		RFC2374 "An IPv6 Aggregatable Global Unicast Address Format" defined
	(001 binary) prefix. The address format defined in this document is		an IPv6 address allocation structure that includes TLA (Top Level
	consistent with the IPv6 Protocol [IPV6] and the "IPv6 Addressing		Aggregator) and NLA (Next Level Aggregator). This document replaces
	Architecture" [ARCH]. It is designed to facilitate scalable Internet		RFC2374, and makes RFC 2374 and the TLA/NLA structure historic.
	routing.
	RFC2374, "An IPv6 Aggregatable Global Unicast Address Format" defined		2.0 TLA/NLA Made Historic
	a structured allocation structure of global unicast IPv6 addresses
	with named fields (e.g., TLA, NLA, etc.).
	While this approach was originally thought to be a good way to		The TLA/NLA scheme has been replaced by a coordinated allocation
	allocate IPv6 addresses, subsequent experience and discussion showed		policy defined by the Regional Internet Registries (RIRs) [IPV6RIR].
	that it would be better to leave flexibility in the definition of
	IPv6 allocation policies to the Internet Address Registries, in order
	to allow a better balance among the competing requirements. This is
	consistent with the recommendations made by the IAB and IESG in
	[RFC3177].
	This document removes the defined structure and generalizes the		Part of the motivation for obsoleting the TLA/NLA structure is
	fields in the global unicast address format.		technical; for instance, there is concern that TLA/NLA is not the
			technically best approach at this stage of the deployment of IPv6.
			Moreover, the allocation of IPv6 addresses is related to policy and
			to the stewardship of the IP address space and routing table size,
			which the RIRs have been managing for IPv4. It is likely that the
			RIRs' policy will evolve as IPv6 deployment proceeds.
	This documented replaces RFC2374, "An IPv6 Aggregatable Global		The IETF has provided technical input to the RIRs (for example,
	Unicast Address Format". RFC 2374 will become historic.		[RFC3177]), which the RIRs have taken into account when defining
			their address allocation policy.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		RFC2374 was the definition of addresses for Format Prefix 001
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		(2000::/3) which is formally made historic by this document. Even
	document are to be interpreted as described in [RFC 2119].		though currently only 2000::/3 is being delegated by the IANA,
			implementations should not make any assumptions about 2000::/3 being
			special, since the IANA might later be directed to delegate currently
			unassigned parts of the IPv6 address space to the purpose of Global
			Unicast as well.
	2.0 Address Format		The SLA (subnet local aggregator) field in RFC2374 remains in
			function but with a different name in [ARCH]. Its new name is
			"subnet ID".
			This documented replaces RFC2374, "An IPv6 Aggregatable Global
			Unicast Address Format". RFC2374 will become historic.
			3.0 Address Format
	The general format for IPv6 global unicast addresses as defined in		The general format for IPv6 global unicast addresses as defined in
	"IP Version 6 Addressing Architecture" [ARCH] is as follows:		"IP Version 6 Addressing Architecture" [ARCH] is as follows:
	| n bits | m bits | 128-n-m bits |		| n bits | m bits | 128-n-m bits |
	+------------------------+-----------+----------------------------+		+-------------------------+-----------+----------------------------+
	| global routing prefix | subnet ID | interface ID |		| global routing prefix | subnet ID | interface ID |
	+------------------------+-----------+----------------------------+		+-------------------------+-----------+----------------------------+
	where the global routing prefix is a (typically hierarchically-		where the global routing prefix is a (typically hierarchically-
	structured) value assigned to a site (a cluster of subnets/links),		structured) value assigned to a site (a cluster of subnets/links),
	the subnet ID is an identifier of a subnet within the site, and the		the subnet ID is an identifier of a subnet within the site, and the
	interface ID is as defined in section 2.5.1 of [ARCH].		interface ID is as defined in section 2.5.1 of [ARCH].
	[ARCH] also requires that all unicast addresses, except those that		[ARCH] also requires that all unicast addresses, except those that
	start with binary value 000, have Interface IDs that are 64 bits long		start with binary value 000, have Interface IDs that are 64 bits long
	and to be constructed in Modified EUI-64 format.		and to be constructed in Modified EUI-64 format. The format of
			global unicast address in this case is:
	The specific format of global unicast address under the 2000::/3
	prefix is:
	| 3 | n bits | 61-n bits | 64 bits |		| n bits | 64-n bits | 64 bits |
	+---+--------------------+-----------+----------------------------+		+-------------------------+-----------+----------------------------+
	|001| routing prefix | subnet ID | interface ID |		| global routing prefix | subnet ID | interface ID |
	+---+--------------------+-----------+----------------------------+		+-------------------------+-----------+----------------------------+
	where the routing prefix is a value assigned to a identify a site (a		where the routing prefix is a value assigned to identify a site (a
	cluster of subnets/links), the subnet ID is an identifier of a subnet		cluster of subnets/links), the subnet ID is an identifier of a subnet
	within the site, and the interface ID is in modified EUI-64 format as		within the site, and the interface ID is in modified EUI-64 format as
	defined in [ARCH].		defined in [ARCH].
	3.0 Acknowledgments		An example of the resulting format of global unicast address under
			the 2000::/3 prefix that is currently being delegated by the IANA and
			consistent with the recommendations in RFC3177 is:
	The authors would like to express our thanks to Margaret Wasserman,		| 3 | 45 bits | 16 bits | 64 bits |
	Brian Carpenter, Pekka Savola, Alain Durand, Fred Templin, Michel Py,		+---+---------------------+-----------+----------------------------+
	and Jun-ichiro itojun Hagino for their review and constructive		|001|global routing prefix| subnet ID | interface ID |
	comments.		+---+---------------------+-----------+----------------------------+
	4.0 References		4.0 Acknowledgments
			The authors would like to express our thanks to Alain Durand, Brian
			Carpenter, Fred Templin, Julian Sellers, Jun-ichiro itojun Hagino,
			Margaret Wasserman, Michel Py, Pekka Savola, Tatuya Jinmei, and
			Thomas Narten for their review and constructive comments.
			5.0 References
	Normative		Normative
	[ARCH] Hinden, R., "IP Version 6 Addressing Architecture",		[ARCH] Hinden, R., "IP Version 6 Addressing Architecture",
	Internet Draft, <draft-ietf-ipngwg-addr-arch-v3-11.txt>,		Internet Draft, <draft-ietf-ipngwg-addr-arch-v3-11.txt>,
	October 2002.		October 2002.
	[IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6		[IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC2460, December 1998.		(IPv6) Specification", RFC2460, December 1998.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		Non-Normative
	Requirement Levels", RFC2119, BCP14, March 1997.
			[IPV6RIR] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and
			Assignment Policy", Document ID: ripe-267,
			http://www.ripe.net/ripe/docs/ipv6policy.html, January 22,
			2003.
	[RFC3177] IAB/IESG, "Recommendations on IPv6 Address Allocations to		[RFC3177] IAB/IESG, "Recommendations on IPv6 Address Allocations to
	Sites" RFC3177, September 2001.		Sites" RFC3177, September 2001.
	5.0 Security Considerations		6.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.		infrastructure security.
	6.0 Authors' Addresses		7.0 Authors' Addresses
	Robert M. Hinden		Robert M. Hinden email: bob.hinden@nokia.com
	Nokia		Nokia
	313 Fairchild Drive		313 Fairchild Drive
	Mountain View, CA		Mountain View, CA
	US		US
			Stephen E. Deering email: deering@cisco.com
	email: hinden@iprg.nokia.com
	Stephen E. Deering
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, CA 95134-1706		San Jose, CA 95134-1706
	US		US
	email: deering@cisco.com		Erik Nordmark email: erik.nordmark@sun.com
			Sun Microsystems Laboratories
			180, avenue de l'Europe
			38334 SAINT ISMIER Cedex
			France
End of changes. 25 change blocks.
	62 lines changed or deleted		77 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/