[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02                                                      
INTERNET-DRAFT                                          R. Hinden, Nokia
February 18, 2005                                    B. Haberman, JHU-APL

                           Centrally Assigned
                  Unique Local IPv6 Unicast Addresses


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-

   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 expires on August 23, 2005.


   This document defines Centrally allocated IPv6 Unique Local
   addresses.  These addresses are globally unique and are intended for
   local communications, usually inside of a site.  They are not
   expected to be routable on the global Internet.

draft-ietf-ipv6-ula-central-01.txt                              [Page 1]

INTERNET-DRAFT   Centrally Assigned Local IPv6 Addresses   February 2005

Table of Contents

   1.0 Introduction....................................................2
   2.0 Acknowledgments.................................................3
   3.0 Local IPv6 Unicast Addresses....................................3
   3.1 Format..........................................................3
   3.2 Global ID.......................................................4
   3.2.1 Centrally Assigned Global IDs.................................4
   3.2.2 Sample Code for Pseudo-Random Global ID Algorithm.............6
   4.0 Operational Guideliens..........................................6
   5.0 Global Routing Considerations...................................7
   5.1 From the Standpoint of the Internet.............................7
   5.2 From the Standpoint of a Site...................................7
   6.0 Security Considerations.........................................8
   7.0 IANA Considerations.............................................8
   8.0 References......................................................9
   8.1 Normative References............................................9
   8.2 Informative References..........................................9
   9.0 Authors' Addresses.............................................10
   10.0 Change Log....................................................11
   11.0 Intellectual Property.........................................11
   12.0 Disclaimer of Validity........................................12
   13.0 Copyright Statement...........................................12

1.0 Introduction

   This document defines the characteristics and technical allocation
   requirements for centrally assigned Local IPv6 addresses in the
   framework defined in [ULA].  They are not expected to be routable on
   the global Internet.  They are routable inside of a more limited area
   such as a site.  They may also be routed between a limited set of

   Local IPv6 unicast addresses, as defined in [ULA], have the following

      - Globally unique prefix.
      - Well known prefix to allow for easy filtering at site
      - Allows sites to be combined or privately interconnected without
        creating any address conflicts or requiring renumbering of
        interfaces using these prefixes.
      - Internet Service Provider independent and can be used for
        communications inside of a site without having any permanent or
        intermittent Internet connectivity.
      - If accidentally leaked outside of a site via routing or DNS,
        there is no conflict with any other addresses.

draft-ietf-ipv6-ula-central-01.txt                              [Page 2]

INTERNET-DRAFT   Centrally Assigned Local IPv6 Addresses   February 2005

      - In practice, applications may treat these addresses like global
        scoped addresses.

   Topics that are general to all Local IPv6 address can be found in the
   following sections of [ULA]:

      3.3 Scope Definition
      4.0 Operational Guidelines **
      4.1 Routing
      4.2 Renumbering and Site Merging
      4.3 Site Border Router and Firewall Packet Filtering
      4.5 Application and Higher Level Protocol Issues
      4.6 Use of Local IPv6 Addresses for Local Communications
      4.7 Use of Local IPv6 Addresses with VPNs
      6.0 Advantages and Disadvantages

   ** Operational guidelines specific to centrally assigned Local IPv6
      addresses are in Section 4.0 of this document.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC 2119].

2.0 Acknowledgments

   The authors would like to thank Brian Carpenter, Charlie Perkins,
   Harald Alvestrand, Keith Moore, Margaret Wasserman, Shannon Behrens,
   Alan Beard, Hans Kruse, Geoff Huston, Pekka Savola, Christian
   Huitema, Tim Chown, Steve Bellovin, Alex Zinin, Tony Hain, Leslie
   Daigle, and Bill Fenner for their comments and suggestions on this

3.0 Centrally Assigned Local IPv6 Unicast Addresses

3.1 Format

   The Centrally assigned Local IPv6 addresses, based on Unique Local
   Addresses [ULA], have the following format:

      | 7 bits |1|  40 bits   |  16 bits  |          64 bits            |
      | Prefix |L| Global ID  | Subnet ID |        Interface ID         |

draft-ietf-ipv6-ula-central-01.txt                              [Page 3]

INTERNET-DRAFT   Centrally Assigned Local IPv6 Addresses   February 2005


      Prefix            FC00::/7 prefix to identify Local IPv6 unicast

      L                 Set to 1 if the prefix is locally assigned,
                        Set to 0 if it is centrally assigned.  See
                        Section 3.2 for additional information.

      Global ID         40-bit global identifier used to create a
                        globally unique prefix. See Section 3.2 for
                        additional information.

      Subnet ID         16-bit Subnet ID is an identifier of a subnet
                        within the site.

      Interface ID      64-bit Interface ID as defined in [ADDARCH].

3.2 Global ID

   The allocation of Global IDs should be pseudo-random [RANDOM].  They
   MUST not be assigned sequentially or with well known numbers.  This
   is to ensure that there is not any relationship between allocations
   and to help clarify that these prefixes are not intended to be routed
   globally.  Specifically, these prefixes are designed to not

   The major difference between the locally assigned Unique local
   addresses defined in [ULA] and the centrally assigned local addresses
   defined in this document is that they are uniquely assigned and the
   assignments can be escrowed to resolve any disputes regarding
   duplicate assignments.

   It is expected that large managed sites will prefer central
   assignments and small or disconnected sites will prefer local
   assignments.  It is recommended that sites planning to use Local IPv6
   addresses for extensive inter-site communication, initially or as a
   future possibility, use a centrally assigned prefix as there is no
   possibility of assignment conflicts.  Sites are free to choose either

   This document defines the allocation procedure for creating global-
   IDs for centrally assigned local IPv6 addresses (i.e., L=0).  The
   allocation procedure for locally assigned local IPv6 addresses (i.e.,
   L=1) is defined in [ULA].

draft-ietf-ipv6-ula-central-01.txt                              [Page 4]

INTERNET-DRAFT   Centrally Assigned Local IPv6 Addresses   February 2005

3.2.1 Centrally Assigned Global IDs

   Centrally assigned Global IDs MUST be generated with a pseudo-random
   algorithm consistent with [RANDOM].  They should not be assigned
   sequentially or by locality.  This is to ensure that there is no
   relationship between allocations and to help clarify that these
   prefixes are not intended to be routed globally by eliminating the
   possibility of aggregation.  Specifically, these prefixes are not
   designed to aggregate.

   Global IDs should be assigned under the authority of a single
   allocation organization because they are pseudo-random and without
   any structure.  This is easiest to accomplish if there is a single
   authority for the assignments.

   The requirements for centrally assigned Global ID allocations are:

      - Available to anyone in an unbiased manner.
      - Permanent with no periodic fees.
      - Allocation on a permanent basis, without any need for renewal
        and without any procedure for de-allocation.
      - Provide mechanisms that prevent hoarding of these allocations.
      - The ownership of each individual allocation should be private,
        but should be escrowed.

   The allocation authority should permit allocations to be obtained
   without having any sort of Internet connectivity.  For example in
   addition to web based registration they should support some methods
   like telephone, postal mail, fax, etc.

   The allocation service should include sufficient provisions to avoid
   hoarding of numbers.  This can be accomplished by various ways, for
   example, requiring an exchange of documents, a verbal contact, or a
   proof that the request is on behalf of a human rather than a machine.
   The service may charge a small fee in order to cover its costs, but
   the fee should be low enough to not create a barrier to anyone
   needing one.  The precise mechanisms should be decided by the
   registration authority.

   The ownership of the allocations is not needed to be public since the
   resulting addresses are intended to be used for local communication.
   It is escrowed to ensure there are no duplicate allocations and in
   case it is needed in the future (e.g., to resolve duplicate
   allocation disputes, or to support a change of the central allocation

   Note, there are many possible ways of of creating an allocation
   authority.  It is important to keep in mind when reviewing

draft-ietf-ipv6-ula-central-01.txt                              [Page 5]

INTERNET-DRAFT   Centrally Assigned Local IPv6 Addresses   February 2005

   alternatives that the goal is to pick one that can do the job.  It
   doesn't have to be perfect, only good enough to do the job at hand.

3.2.2  Sample Code for Pseudo-Random Global ID Algorithm

   The algorithm described below is intended to be used for centrally
   assigned Global IDs.  In each case the resulting global ID will be
   used in the appropriate prefix as defined in Section 3.2.

     1) Obtain the current time of day in 64-bit NTP format [NTP].
     2) Obtain an EUI-64 identifier from the system running this
        algorithm.  If an EUI-64 does not exist, one can be created from
        a 48-bit MAC address as specified in [ADDARCH].  If an EUI-64
        cannot be obtained or created, a suitably unique identifier,
        local to the node, should be used (e.g. system serial number).
     3) Concatenate the time of day with the system-specific identifier
        creating a key.
     4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1];
        the resulting value is 160 bits.
     5) Use the least significant 40 bits as the Global ID.
     6) Verify that the computed Global ID is not in the escrow.  If it
        is, discard the value and rerun the algorithm.
     6) Concatenate FC00::/7, the L bit set to 0, and the 40 bit Global
        ID to create a centrally assigned Local IPv6 address prefix.

   This algorithm will result in a Global ID that is unique and can be
   used to create a centrally assigned local IPv6 address prefix.

4.0 Operational Guidelines

4.1 DNS Issues

   At the present time AAAA and PTR records for centrally assigned local
   IPv6 addresses may be installed in the global DNS.  This may be
   useful if these addresses are being used for site to site or VPN
   style applications, or for sites that wish to avoid separate DNS
   systems for inside and outside traffic.

   The operational issues relating to this are beyond the scope of this

draft-ietf-ipv6-ula-central-01.txt                              [Page 6]

INTERNET-DRAFT   Centrally Assigned Local IPv6 Addresses   February 2005

5.0 Global Routing Considerations

   Section 4.1 of [ULA] provides operational guidelines that forbid
   default routing of local addresses between sites.  Concerns were
   raised to the IPv6 working group and to the IETF as a whole that
   sites may attempt to use local addresses as globally routed provider-
   independent addresses.  This section describes why using local
   addresses as globally-routed provider-independent addresses is

5.1 From the Standpoint of the Internet

   There is a mismatch between the structure of IPv6 local addresses and
   the normal IPv6 wide area routing model.  The /48 prefix of an IPv6
   local addresses fits nowhere in the normal hierarchy of IPv6 unicast
   addresses.  Normal IPv6 unicast addresses can be routed
   hierarchically down to physical subnet (link) level and only have to
   be flat-routed on the physical subnet.  IPv6 local addresses would
   have to be flat-routed even over the wide area Internet.

   Thus, packets whose destination address is an IPv6 local address
   could be routed over the wide area only if the corresponding /48
   prefix were carried by the wide area routing protocol in use, such as
   BGP.  This contravenes the operational assumption that long prefixes
   will be aggregated into many fewer short prefixes, to limit the table
   size and convergence time of the routing protocol.  If a network uses
   both normal IPv6 addresses [ADDARCH] and IPv6 local addresses, these
   types of address will certainly not aggregate with each other, since
   they differ from the most significant bit onwards.  Neither will IPv6
   local addresses aggregate with each other, due to their random bit
   patterns.  This means that there would be a very significant
   operational penalty for attempting to use IPv6 local address prefixes
   generically with currently known wide area routing technology.

5.2  From the Standpoint of a Site

   There are a number of design factors in IPv6 local addresses that
   reduce the likelihood that IPv6 local addresses will be used as
   arbitrary global unicast addresses.  These include:

      - The default rules to filter packets and routes make it very
        difficult to use IPv6 local addresses for arbitrary use across
        the Internet.  For a site to use them as general purpose unicast
        addresses, they would have to make sure that the default rules
        were not being used by all other sites and intermediate ISPs
        used for their current and future communication.

draft-ietf-ipv6-ula-central-01.txt                              [Page 7]

INTERNET-DRAFT   Centrally Assigned Local IPv6 Addresses   February 2005

      - They are not registered in public databases.  The lack of public
        registration creates operational problems.

      - The addresses are allocated randomly.  If a site had multiple
        prefixes that they wanted to be used globally the cost of
        advertising them would be very high as they could not be

      - They have a long prefix (i.e, /48) so a single local address
        prefix doesn't provide enough address space to be used
        exclusively by the largest organizations.

6.0 Security Considerations

   Local IPv6 addresses do not provide any inherent security to the
   nodes that use them.  They may be used with filters at site
   boundaries to keep Local IPv6 traffic inside of the site, but this is
   no more or less secure than filtering any other type of global IPv6
   unicast addresses.

   Local IPv6 addresses do allow for address-based security mechanisms,
   including IPSEC, across end to end VPN connections.

7.0 IANA Considerations

   The IANA is instructed to designate an allocation authority, based on
   instructions from the IAB, for centrally assigned Unique Local IPv6
   unicast addresses.  This allocation authority shall comply with the
   requirements described in Section 3.2 of this document, including in
   particular allocation on a permanent basis and with sufficient
   provisions to avoid hoarding of numbers.  If deemed appropriate, the
   authority may also consist of multiple organizations performing the
   allocation authority duties.

   The designated allocation authority is required to document how they
   will meet the requirements described in Section 3.2 of this document
   in an RFC.  This RFC will be shepherd through the IETF by the IAB.

draft-ietf-ipv6-ula-central-01.txt                              [Page 8]

INTERNET-DRAFT   Centrally Assigned Local IPv6 Addresses   February 2005

8.0 References

8.1 Normative References

   [ADDARCH] Hinden, R., S. Deering, S., "IP Version 6 Addressing
             Architecture", RFC 3515, April 2003.

   [FIPS]    "Federal Information Processing Standards Publication",
             (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.

   [GLOBAL]  Hinden, R., S. Deering, E. Nordmark, "IPv6 Global Unicast
             Address Format", RFC 3587, August 2003.

   [ICMPV6]  Conta, A., S. Deering, "Internet Control Message Protocol
             (ICMPv6) for the Internet Protocol Version 6 (IPv6)
             Specification", RFC2463, December 1998.

   [IPV6]    Deering, S., R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", RFC 2460, December 1998.

   [NTP]     Mills, David L., "Network Time Protocol (Version 3)
             Specification, Implementation and Analysis", RFC 1305,
             March 1992.

   [POPUL]   Population Reference Bureau, "World Population Data Sheet
             of the Population Reference Bureau 2002",  August 2002.

   [RANDOM]  Eastlake, D. 3rd, S. Crocker, J. Schiller, "Randomness
             Recommendations for Security", RFC 1750, December 1994.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", RFC 2119, BCP14, March 1997.

   [SHA1]    D. Eastlake 3rd, P. Jones, "US Secure Hash Algorithm 1
             (SHA1)", RFC 3174, September 2001.

   [ULA]     Hinden, R., B. Haberman, "Unique Local IPv6 Unicast
             Addresses", Internet Draft <draft-ietf-ipv6-unique-local-
             addr-08.txt>, November  2004.

8.2 Informative References

   [ADDAUTO] Thomson, S., T. Narten, "IPv6 Stateless Address
             Autoconfiguration", RFC 2462, December 1998.

draft-ietf-ipv6-ula-central-01.txt                              [Page 9]

INTERNET-DRAFT   Centrally Assigned Local IPv6 Addresses   February 2005

   [ADDSEL]  Draves, R., "Default Address Selection for Internet
             Protocol version 6 (IPv6)", RFC 3484, February 2003.

   [DHCP6]   Droms, R., et. al., "Dynamic Host Configuration Protocol
             for IPv6 (DHCPv6)", RFC3315, July 2003.

   [RTP]     Schulzrinne, H., S. Casner, R. Frederick, V. Jacobson,
             "RTP: A Transport Protocol for Real-Time Applications"
             RFC3550, July 2003.

9.0 Authors' Addresses

   Robert M. Hinden
   313 Fairchild Drive
   Mountain View, CA 94043

   phone: +1 650 625-2004
   email: bob.hinden@nokia.com

   Brian Haberman
   Johns Hopkins University
   Applied Physics Lab
   11100 Johns Hopkins Road
   Laurel, MD 20723

   phone: +1 443 778 1319
   email: brian@innovationslab.net

draft-ietf-ipv6-ula-central-01.txt                             [Page 10]

INTERNET-DRAFT   Centrally Assigned Local IPv6 Addresses   February 2005

10.0 Change Log

   Draft <draft-hinden-ipv6-global-local-addr-01.txt>

      o Revised to keep consistent with [ULA].  This includes single
        prefix, L bit, change to SHA-1 algorithm, and clarifications to
        suggested algorithm.
      o Revised IANA considerations section based on feedback from the
      o Added new DNS operational guidelines sections specific to
        centrally assigned local IPv6 addresses.
      o Editorial changes.

   Draft <draft-hinden-ipv6-global-local-addr-00.txt>

      o Initial Draft created from [ULA].  This draft defines the
        centrally assigned Local IPv6 addresses.

11.0  Intellectual Property

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

draft-ietf-ipv6-ula-central-01.txt                             [Page 11]

INTERNET-DRAFT   Centrally Assigned Local IPv6 Addresses   February 2005

12.0 Disclaimer of Validity

   This document and the information contained herein are provided on an

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

draft-ietf-ipv6-ula-central-01.txt                             [Page 12]