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.