[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 RFC 4147

Individual Submission                                          G. Huston
Internet-Draft                                                     APNIC
Expires: June 14, 2005                                 December 14, 2004

        Proposed changes to the format of the IANA IPv6 Registry

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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 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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on June 14, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).


   This document proposes a revised format for the IANA IPv6 address
   registry.  The proposed format brings the address registry into
   alignment with the current IPv6 Address Architecture specification,
   as well as aligning it to the format used for the IPv4 address

Huston                   Expires June 14, 2005                  [Page 1]

Internet-Draft                  ip6.int                    December 2004

1.  Introduction

   This document proposes a revised format for the IANA IPv6 address
   registry.  The proposed format brings the address registry into
   alignment with the current IPv6 Address Architecture specification,
   as well as aligning it to the format used for the IPv4 address

   The current IPv6 registries [2][3] are based on a now-deprecated
   address architecture that used the concept of Top Level Aggregation
   Identifiers (TLAs) and sub-TLAs.  The current IPv6 Address
   Architecture [1] uses the terminology of Global Identifiers in place
   of these TLAs and sub-TLAs.

2.  IPv6 Address Registry

   The proposed registry format for IPv6 is indicated in Figure 1
   (Figure 1).  The registry explicitly notes which entity is placing a
   reservation on an address block and notes the defining RFC document
   for each allocation.



   [last updated 30 November 2004]

     IPv6 Prefix           Allocation              Reference      Note
     -----------           ----------              ---------      ----
     0::/8                 Reserved by IETF        RFC3513        [1]
     100::/8               Reserved by IETF        RFC3513
     200::/7               Reserved by IETF        RFCxxxx        [2]
     400::/6               Reserved by IETF        RFC3513
     800::/5               Reserved by IETF        RFC3513
     1000::/4              Reserved by IETF        RFC3513
     2000::/3              Global Unicast          RFC3513        [3]
     4000::/3              Reserved by IETF        RFC3513
     6000::/3              Reserved by IETF        RFC3513
     8000::/3              Reserved by IETF        RFC3513
     A000::/3              Reserved by IETF        RFC3513
     C000::/3              Reserved by IETF        RFC3513
     E000::/4              Reserved by IETF        RFC3513
     F000::/5              Reserved by IETF        RFC3513
     F800::/6              Reserved by IETF        RFC3513
     FA00::/7              Reserved by IETF        RFC3513
     FE00::/9              Reserved by IETF        RFC3513
     FE80::/10             Link Local Unicast      RFC3513

Huston                   Expires June 14, 2005                  [Page 2]

Internet-Draft                  ip6.int                    December 2004

     FEC0::/10             Reserved by IETF        RFC3879        [4]
     FF00::/8              Multicast               RFC3513


     [1] The "unspecified address", the "loopback address", and the IPv6
         Addresses with Embedded IPv4 Addresses are assigned out of the
         0::/8 address block.

     [2] 200::/7 was previously defined as an OSI NSAP-mapped prefix set
         [RFC1888]. This definition has been deprecated as of November
         2004 [RFCxxxx].

     [3] The IPv6 Unicast space encompasses the entire IPv6 address range
         with the exception of FF00::/8. IANA unicast address assignments
         are currently limited to the IPv6 unicast address range of
         2000::/3. IANA assignments from this block are registered in the
         IANA registry:

     [4] FEA0::/10 was previously defined as a Site-Local scoped address
         prefix. This definition has been deprecated as of September 2004


     [RFC1888]  J. Bound et al, "OSI NSAPs and IPv6", RFC1888, August 1996.

     [RFC3513]  R. Hinden and S. Deering, "IP Version 6 Addressing
                Architecture", RFC 3513, April 2003.

     [RFC3879]  C. Huitema and B. Carpenter, "Deprecating Site Local
                Addresses", RFC 3879, September 2004.

     [RFCxxxx]  B. Carpenter, "RFC1888 is obsolete", RFC xxxx (work
                in progress: draft-carptenter-obsolete-1888-01.txt).


                                Figure 1

2.1  Notes on Proposed Format Changes to the Registry

   o  The textual preamble at the start of the registry has been
      removed, in deference to the use of standard IPv6 prefix notation

Huston                   Expires June 14, 2005                  [Page 3]

Internet-Draft                  ip6.int                    December 2004

      in the registry.

   o  Binary prefix notation has been replaced by standard IPv6 prefix
      notation, and the fraction of address space column has been
      replaced with the reference to the relevant RFC that defines the
      disposition of the address block.  Foot note references are also
      displayed in a consistent fashion.

   o  The terminology "Unassigned" has been replaced by the more precise
      phrase "Reserved by IETF", indicating the body that has the token
      to permit reassignment of the status of this address block.

   o  The "Formerly Site-Local" entry in the body of the registry has
      been replaced with an explicit reference to deprecation.  A
      similar treatment is proposed for 200::/8, although the RFC number
      for the deprecation document has yet to be assigned.

   o  Annotations that are references to footnotes are included in the
      registry in its own column

   o  The text commentary on unicast, multicast and anycast addresses
      has been removed as there is no distinction between anycast and
      unicast addresses and multicast addresses are explicitly flagged
      in the registry.

3.  Global Unicast IPv6 Address Registry

   The proposed registry format for Global Unicast IPv6 address block
   allocations is indicated in Figure 2 (Figure 1).  The registry notes
   the current allocations, and does not include any notation of
   intended future allocations or reservations.  All address space not
   listed in this registry forms the IANA unallocated address pool, to
   be allocated by IANA as per the prevailing address allocation



   [last updated 14 December 2004]

   Global Unicast Registry

     Global Unicast Prefix Assignment     Date     Note
     --------------------- ----------     ------   ----
     2001:0000::/23        IANA           Jul 99   [1]
     2001:0200::/23        APNIC          Jul 99

Huston                   Expires June 14, 2005                  [Page 4]

Internet-Draft                  ip6.int                    December 2004

     2001:0400::/23        ARIN           Jul 99
     2001:0600::/23        RIPE NCC       Jul 99
     2001:0800::/23        RIPE NCC       May 02
     2001:0A00::/23        RIPE NCC       Nov 02
     2001:0C00::/23        APNIC          May 02   [2]
     2001:0E00::/23        APNIC          Jan 03
     2001:1200::/23        LACNIC         Nov 02
     2001:1400::/23        RIPE NCC       Feb 03
     2001:1600::/23        RIPE NCC       Jul 03
     2001:1800::/23        ARIN           Apr 03
     2001:1A00::/23        RIPE NCC       Jan 04
     2001:1C00::/22        RIPE NCC       May 04
     2001:2000::/20        RIPE NCC       May 04
     2001:3000::/21        RIPE NCC       May 04
     2001:3800::/22        RIPE NCC       May 04
     2001:4000::/23        RIPE NCC       Jun 04
     2001:4200::/23        ARIN           Jun 04
     2001:4400::/23        APNIC          Jun 04
     2001:4600::/23        RIPE NCC       Aug 04
     2001:4800::/23        ARIN           Aug 04
     2001:4A00::/23        RIPE NCC       Oct 04
     2001:5000::/20        RIPE NCC       Sep 04
     2001:8000::/19        APNIC          Nov 04
     2001:A000::/20        APNIC          Nov 04
     2002::/16             6to4           Feb 01   [3]
     3FFE::/16             6BONE          Dec 98   [4]


     The assignable Global Unicast Address space is defined in [RFC3513]
     as being the address block defined by the prefix 2000::/3.

     [1]  The prefix assigned to the IANA, 2001::/23, is for assignment for
          testing, experimental and trial usage by IANA [RFC2928].

     [2]  Per [RFC3849] "IPv6 Address Prefix Reserved for Documentation",
          the 2001:DB8::/32 prefix has been assigned as a NON-ROUTABLE
          range to be used for documentation purposes.

     [3]  2002::/16 is reserved for use in 6to4 deployments [RFC3056]

     [4]  The is an experimental allocation to the 6BONE [RFC2471]. Per
          [RFC3701] this prefix will be returned to the unassigned address
          pool on the 6th June 2006.


     [RFC2471]   Hinden, R., R. Fink, J. Postel, "IPv6 Testing Address

Huston                   Expires June 14, 2005                  [Page 5]

Internet-Draft                  ip6.int                    December 2004

                 Allocation", RFC2471, December 1998.

     [RFC2928]   Hinden, R., Deering, S., Fink, R., Hain, T., , "Initial
                 IPv6 Sub-TLA ID Assignments", RFC2928, September 2000.

     [RFC3056]   Carpenter, B., K. Moore, "Connection of IPv6 Domains via
                 IPv4 Clouds without Explicit Tunnels", RFC 3056, February

     [RFC3513]   Hinden, R., "IP Version 6 Addressing Architecture",
                 RFC3513, April 2003.

     [RFC3701]   Fink, R., "6Bone (IPv6 Testing Address Allocation)
                 Phaseout", RFC 3701, March 2004.

     [RFC3849]   Huston, G., A. Lord, P. Smith, "IPv6 Address Prefix
                 Reserved for Documentation", RFC 3849, July 2004.


                                Figure 2

3.1  Notes on Proposed Format Changes to the Registry

   o  The current registry name "iana-ipv6-tla-assignments" should be
      renamed to "iana-ipv6-unicast-address-assignments".

   o  The title of the registry has been altered to remove the reference

   o  The TLA and Sub-TLA identifier assignments have been rolled into a
      single set of address prefixes and their assignment.

   o  The text commentary at the start of the registry contents has been

   o  Binary value notation of the address prefixes has been removed.

   o  Further commentary on assignments, such as the planned phase out
      of the 6BONE is placed in a footnote.

   o  The registry continuation lines with three full stops have been

Huston                   Expires June 14, 2005                  [Page 6]

Internet-Draft                  ip6.int                    December 2004

   o  Only assigned addresses are listed.  All unassigned addresses,
      marked in the original IANA registry with the assignment note of
      "(future assignment)" have been removed, as has the entry marked
      as "reserved *)".

   o  Address assignments are listed using prefix size notation of the
      actual allocation, rather than reporting the allocation in
      sub-units of /23 prefixes.

4.  IANA Considerations

   IANA is advised to adopt this format for the IPv6 address registry
   and the IPv6 Global Unicast address registry.

5.  Security Considerations

   Security of the Internet's routing system relies on the ability to
   authenticate an assertion of unique control of an address block.
   Measures to authenticate such assertions rely on validation that the
   address block forms part of an existing allocated address block, and
   that there is a trustable reference from the IANA address registry to
   the references Regional Internet Registry (RIR), and a trustable
   reference from the RIR's registry to a Local Internet Registry or end
   user Internet Service Provider.

   The proposed format for the IANA registry is a small step towards the
   creation of a registry that can be used as a trust point for
   commencing a chain of address validation.  Consideration should be
   given to IANA registry publication formats that are machine
   parseable, and also the use of file signatures and associated
   certificate mechanisms to allow applications to confirm that the
   registry contents are current, and that they have been published by
   the IANA.

6.  Acknowledgements

   The document was prepared with the assistance of Kurt Lindqvist,
   Thomas Narten, Paul Wilson, David Kessens, Bob Hinden and Brian

7.  References

7.1  Normative References

   [1]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
        Addressing Architecture", RFC 3513, April 2003.

Huston                   Expires June 14, 2005                  [Page 7]

Internet-Draft                  ip6.int                    December 2004

7.2  Informative References

   [2]  IANA, "IPv6 Address Registry", September 2004.

   [3]  IANA, "IPv6 Top Level Aggregation Identifier Assignments",
        October 2004.

Author's Address

   Geoff Huston
   Asia Pacific Network Information Centre

   EMail: gih@apnic.net
   URI:   http://www.apnic.net

Appendix A.  Draft Notes

   [This section not for RFC publication]

   This memo has been prepared as part of the activities of an ad hoc
   advisory committee to advise the IAB on a number of matters relating
   to IPv6.  It is proposed that the note be published as an Internet
   Standards action for IPv6 as a BCP.

   As noted in the Security Considerations Section this is a step in the
   direction of updating the IANA address registry to be a seed trust
   point in the operation of validating addresses.  It is noted that
   further study is appropriate to determine what forms of additional
   information and formats should be published to allow systems to use
   this data in a trustworthy manner.

   The format provided here could be provided through the use of a base
   registry format using an XML scheme.  Such an XML scheme for IPv6
   registry specification is not considered in this document, but is a
   topic that is recommended for further study.

Huston                   Expires June 14, 2005                  [Page 8]

Internet-Draft                  ip6.int                    December 2004

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Huston                   Expires June 14, 2005                  [Page 9]

Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/