INTERNET-DRAFT R. Hinden, Nokia
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 validA new Request for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It Comments is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work now available 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 online RFC libraries.
RFC 3587
Title: IPv6 Aggregatable Global Unicast Address Format" defined
an IPv6 address allocation structure that includes TLA (Top Level
Aggregator) and NLA (Next Level Aggregator). 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
I-D Tag: draft-ietf-ipv6-unicast-aggr-v2-03.txt
URL: ftp://ftp.rfc-editor.org/in-notes/rfc3587.txt
This document replaces
RFC2374, and makes obsoletes RFC 2374 and the TLA/NLA structure historic.
1.0 Introduction
RFC2374 2374, "An IPv6 Aggregatable Global Unicast
Address Format" Format". It defined an IPv6 address allocation structure that
includes TLA (Top Top Level
Aggregator) Aggregator (TLA) and NLA (Next Next Level Aggregator). Aggregator (NLA).
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
This document is a coordinated allocation
policy defined by product of the Regional Internet Registries (RIRs) [IPV6RIR].
Part IP Version 6 Working Group of the motivation
IETF.
This memo provides information for obsoleting the TLA/NLA structure is
technical; for instance, there is concern that TLA/NLA is Internet community. It does
not the
technically best approach at this stage of the deployment specify an Internet standard of IPv6.
Moreover, the allocation any kind. Distribution of IPv6 addresses this
memo 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 unlimited.
This announcement is likely that sent to 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 list and 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 RFC-DIST list.
Requests to be added to or deleted from the IANA,
implementations IETF distribution list
should not make any assumptions about 2000::/3 being
special, since the IANA might later be directed sent to delegate currently
unassigned parts of the IPv6 address space IETF-REQUEST@IETF.ORG. Requests 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 be
added to a site (a cluster of subnets/links),
the subnet ID is an identifier of a subnet within the site, and or deleted from 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 RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
Details on obtaining RFCs via FTP or EMAIL may 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 obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the routing prefix is a value assigned message body
help: ways_to_get_rfcs. For example:
To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to identify a site (a
cluster of subnets/links), either the subnet ID is an identifier
author of a subnet
within the site, and the interface ID is in modified EUI-64 format as
defined RFC 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 question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
specifically noted otherwise on 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 RFC itself, all RFCs are for their review and constructive comments.
5.0 References
Normative
[ARCH] Hinden, R., "IP Version 6 Addressing Architecture",
Internet Draft, <draft-ietf-ipngwg-addr-arch-v3-11.txt>,
October 2002.
[IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC2460, December 1998.
Non-Normative
[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
unlimited distribution.echo
Submissions for Requests for Comments should be sent to
Sites" RFC3177, September 2001.
6.0 Security Considerations
IPv6 addressing documents do not have any direct impact on Internet
infrastructure security.
7.0 Authors' Addresses
Robert M. Hinden email: bob.hinden@nokia.com
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
Sun Microsystems Laboratories
180, avenue de l'Europe
38334 SAINT ISMIER Cedex
France
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
Authors, for further information.