< draft-ietf-ipv6-unicast-aggr-v2-02.txt		draft-ietf-ipv6-unicast-aggr-v2-03.txt >
			A new Request for Comments is now available in online RFC libraries.
	INTERNET-DRAFT R. Hinden, Nokia		RFC 3587
	February 26, 2003 S. Deering, Cisco
	E. Nordmark, Sun
	IPv6 Global Unicast Address Format
	<draft-ietf-ipv6-unicast-aggr-v2-02.txt>
	Status of this Memo
	This document is an Internet-Draft and is subject to all provisions
	of Section 10 of RFC2026.
	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
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet- Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html
	This internet draft expires on August 26, 2003.
	Abstract
	RFC2374 "An IPv6 Aggregatable Global Unicast Address Format" defined
	an IPv6 address allocation structure that includes TLA (Top Level
	Aggregator) and NLA (Next Level Aggregator). This document replaces
	RFC2374, and makes RFC 2374 and the TLA/NLA structure historic.
	1.0 Introduction
	RFC2374 "An IPv6 Aggregatable Global Unicast Address Format" defined
	an IPv6 address allocation structure that includes TLA (Top Level
	Aggregator) and NLA (Next Level Aggregator). This document replaces
	RFC2374, and makes RFC 2374 and the TLA/NLA structure historic.
	2.0 TLA/NLA Made Historic
	The TLA/NLA scheme has been replaced by a coordinated allocation
	policy defined by the Regional Internet Registries (RIRs) [IPV6RIR].
	Part of the motivation for obsoleting the TLA/NLA structure is
	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.
	The IETF has provided technical input to the RIRs (for example,
	[RFC3177]), which the RIRs have taken into account when defining
	their address allocation policy.
	RFC2374 was the definition of addresses for Format Prefix 001
	(2000::/3) which is formally made historic by this document. Even
	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.
	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
	"IP Version 6 Addressing Architecture" [ARCH] is as follows:
	| n bits | m bits | 128-n-m bits |
	+-------------------------+-----------+----------------------------+
	| global routing prefix | subnet ID | interface ID |
	+-------------------------+-----------+----------------------------+
	where the global routing prefix is a (typically hierarchically-
	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
	interface ID is as defined in section 2.5.1 of [ARCH].
	[ARCH] also requires that all unicast addresses, except those that
	start with binary value 000, have Interface IDs that are 64 bits long
	and to be constructed in Modified EUI-64 format. The format of
	global unicast address in this case is:
	| n bits | 64-n bits | 64 bits |
	+-------------------------+-----------+----------------------------+
	| global routing prefix | subnet ID | interface ID |
	+-------------------------+-----------+----------------------------+
	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
	within the site, and the interface ID is in modified EUI-64 format as
	defined in [ARCH].
	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:
	| 3 | 45 bits | 16 bits | 64 bits |
	+---+---------------------+-----------+----------------------------+
	|001|global routing prefix| subnet ID | interface ID |
	+---+---------------------+-----------+----------------------------+
	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		Title: IPv6 Global Unicast Address Format
			Author(s): R. Hinden, S. Deering, E. Nordmark
			Status: Informational
			Date: August 2003
			Mailbox: bob.hinden@nokia.com, erik.nordmark@sun.com
			Pages: 5
			Characters: 8783
			Obsoletes: 2374
	[ARCH] Hinden, R., "IP Version 6 Addressing Architecture",		I-D Tag: draft-ietf-ipv6-unicast-aggr-v2-03.txt
	Internet Draft, <draft-ietf-ipngwg-addr-arch-v3-11.txt>,
	October 2002.
	[IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3587.txt
	(IPv6) Specification", RFC2460, December 1998.
	Non-Normative		This document obsoletes RFC 2374, "An IPv6 Aggregatable Global Unicast
			Address Format". It defined an IPv6 address allocation structure that
			includes Top Level Aggregator (TLA) and Next Level Aggregator (NLA).
			This document makes RFC 2374 and the TLA/NLA structure historic.
	[IPV6RIR] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and		This document is a product of the IP Version 6 Working Group of the
	Assignment Policy", Document ID: ripe-267,		IETF.
	http://www.ripe.net/ripe/docs/ipv6policy.html, January 22,
	2003.
	[RFC3177] IAB/IESG, "Recommendations on IPv6 Address Allocations to		This memo provides information for the Internet community. It does
	Sites" RFC3177, September 2001.		not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	6.0 Security Considerations		This announcement is sent to the IETF list and the RFC-DIST list.
			Requests to be added to or deleted from the IETF distribution list
			should be sent to IETF-REQUEST@IETF.ORG. Requests to be
			added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	IPv6 addressing documents do not have any direct impact on Internet		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
	infrastructure security.		an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	7.0 Authors' Addresses		To: rfc-info@RFC-EDITOR.ORG
			Subject: getting rfcs
	Robert M. Hinden email: bob.hinden@nokia.com		help: ways_to_get_rfcs
	Nokia
	313 Fairchild Drive
	Mountain View, CA
	US
	Stephen E. Deering email: deering@cisco.com
	Cisco Systems, Inc.
	170 West Tasman Drive
	San Jose, CA 95134-1706
	US
	Erik Nordmark email: erik.nordmark@sun.com		Requests for special distribution should be addressed to either the
	Sun Microsystems Laboratories		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
	180, avenue de l'Europe		specifically noted otherwise on the RFC itself, all RFCs are for
	38334 SAINT ISMIER Cedex		unlimited distribution.echo
	France		Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 13 change blocks.
	151 lines changed or deleted		32 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/