INTERNET-DRAFT                                          R. Hinden, Nokia
February 18, 2005                                    B. Haberman, JHU-APL
June 15, 2007                                           G. Huston, APNIC
Intended status: Proposed Standard                        T. Narten, IBM

                           Centrally Assigned
                  Unique Local IPv6 Unicast Addresses

                  <draft-ietf-ipv6-ula-central-01.txt>

                  <draft-ietf-ipv6-ula-central-02.txt>

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 becomes
   aware will be disclosed, in accordance with
   RFC 3668. Section 6 of BCP 79.

   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/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This internet draft expires Internet-Draft will expire on August 23, 2005. December 21, 2007.

Abstract

   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.

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 Allocation of Centrally Assigned Global IDs.................................4 IDs...................5
   3.2.2 Sample Code for Pseudo-Random Global ID Algorithm.............6 Algorithm.............5
   3.3 Public Registration Services....................................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 Considerations.........................................7
   7.0 IANA Considerations.............................................8 Considerations.............................................7
   8.0 References......................................................9 References......................................................8
   8.1 Normative References............................................9 References............................................8
   8.2 Informative References..........................................9 References..........................................8
   9.0 Authors' Addresses.............................................10 Addresses..............................................9
   10.0 Change Log....................................................11 Log....................................................10
   11.0 Intellectual Property.........................................11 Full Copyright................................................10
   12.0 Disclaimer of Validity........................................12
   13.0 Copyright Statement...........................................12 Intellectual Property.........................................10

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

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

      - Globally unique prefix.
      - Well known prefix to allow for easy filtering at site
        boundaries.
      - 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.

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

   It is a highly desirable property of ULAs that they are unique, as
   ULA uniqueness would allow sites to be combined or privately
   interconnected without creating any address conflicts.

   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
      5.0 Global Routing Concerns
      6.0 Advantages and Disadvantages

   ** Note: 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",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119]. [RFC2119].

2.0 Acknowledgments

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

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

   Where:

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

      L                 Set to 1 0 if the prefix is locally centrally assigned,
                        Set to 0 if it is
                        Note: [ULA] defined L=1 for locally assigned
                        ULAs.  This document defines L=0 for centrally assigned.
                        assigned ULA addresses.  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 sequentially.  They MUST not be allocated in a
   manner where there is not any a relationship between allocations
   and that would
   make it easy to help clarify aggregate the resulting prefixes.  This is done to
   make clear that these prefixes are not intended to be routed
   globally.  Specifically, these prefixes are designed to not
   aggregate.

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

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

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

3.2.1 Allocation of 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 allocated by locality.  This is to ensure a new registry function such that there
   each allocation is no
   relationship between allocations unique 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 assignment is recorded and
   published in a public database to aggregate. verify that that allocation was
   unique.

   Global IDs should may be assigned under the authority of a single allocation
   organization because they or by multiple organizations.  If there are pseudo-random and without
   any structure.  This is easiest to accomplish if multiple
   organizations, there is MUST be an operating procedure that ensures that
   the entire allocation space maintains it property of uniqueness and
   that the allocations are recorded in a single
   authority for the assignments. public database.

   The requirements for centrally assigned Global ID allocations are:

      - Globally unique.
      - Available to anyone in an unbiased manner.
      - Permanent with no periodic fees.
      - Allocation

   The allocation function must include the ability to make an
   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  Other forms of each individual allocation should be private,
        but should be escrowed.

   The allocation authority should permit allocation,
   including periodic renewable allocations to and explicit provision for
   de-allocation may also 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. provided.

   The allocation service should include sufficient provisions to avoid
   mitigate attempts to artificially reduce the number pool through
   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 mechanism used by the registration authority.

   The ownership of the allocations is
   authority should not needed to be public since include onerous provisions that reduce the
   resulting addresses are intended to
   intent that these allocations should be used for local communication.
   It is escrowed available to ensure there are no duplicate allocations and in
   case it is needed anyone in the future (e.g., an
   unbiased manner, and should not attempt to resolve duplicate
   allocation disputes, perform rationing or
   impose quotas upon allocations.

   The registration authority may covers its costs through registration
   fees and may also use registration agreements to support a change of clearly set forth
   the central allocation
   authority).

   Note, there are many possible ways of terms conditions and liabilities associated with registration of creating an allocation
   authority.  It is important to keep in mind when reviewing
   alternatives that the goal is to pick one that can do the job.  It
   doesn't have to
   such allocations.  The payments and conditions associated with this
   function should not be perfect, only good enough unreasonably onerous to do the job at hand. extent that the
   availability of allocations is impaired.

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. already assigned.  If
        it is, discard the value and rerun the algorithm.
     6)
     7) 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.

3.3 Public Registration Services

   The registration of centrally assigned ULAs should be available in a
   public database.  This function should support a query of a specific
   ULA prefix and then return the registrant's provided detail.
   Information should be provided in a robust fashion, consistent with
   the current state of similar registration services provided by
   address and domain name registration authorities.

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

5.0 Global Routing Considerations

   Section 4.1 of

   Since [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
   unadvisable.

5.1 From the Standpoint of was first published, the Regional 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 Address
   Registries (RIR) created a very significant
   operational penalty for attempting new policy to use allocate IPv6 local address prefixes
   generically with currently known wide area routing technology.

5.2  From Provider
   Independent Addresses [RIR-PI].  Given the Standpoint of a Site

   There are a number availability of design factors in IPv6 local addresses that
   reduce the likelihood that IPv6 local RIR
   allocated provider-independent addresses the authors believe that
   there is considerably less concern that ULAs of either type will be
   used as
   arbitrary global unicast IPv6 provider-independent addresses.  These include:

      -

   The default rules to filter packets and routes make it very
        difficult to use IPv6 operational guidelines regarding routing of centrally assigned
   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 is that the default rules
        were not being used by all other sites and intermediate ISPs
        used for their current and future communication.

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

      - The addresses are allocated randomly.  If such address prefixes should be readily
   routed within a site had multiple or comparable administrative routing domain.

   By default, such prefixes that they wanted to be used globally the cost of
        advertising them would be very high as they could should not be
        aggregated.

      - They have a long prefix (i.e, /48) so announced beyond such a single local address
        prefix doesn't provide enough address
   scope, due to the non-aggregateability of these prefixes within the
   routing system and the potential negative impact on the total size of
   the routing space in large scale internet environments.

   Entities wishing to be used
        exclusively by use IPv6 Provider Independent Addresses (PI
   Space) in such larger routing contexts should consult the largest organizations. Regional
   Internet Registries policies relating to the allocation of PI Space
   [RIR-PI].

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, authority 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 Regional Internet Address registries are expected to be the
   allocation authority for centrally assigned Unique Local IPv6
   addresses.

   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.

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, S. Crocker, "Randomness
             Recommendations for Security", RFC 1750, December 1994. 4086, June 2005.

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

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

   [DHCP6]   Droms, 3174, September 2001.

   [ULA]     Hinden, R., et. al., "Dynamic Host Configuration Protocol
             for B. Haberman, "Unique Local 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. Unicast
             Addresses", RFC-4193, October 2005.

8.2 Informative References

   [RIR-PI]  O. DeLong, K. Loch, A. Dul, "Policy Proposal 2005-1:
             Provider-independent IPv6 Assignments for End Sites",
             http://www.arin.net/policy/proposals/2005_1.html, May 2006.

9.0 Authors' Addresses

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

   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
   USA

   phone:

   Geoff Huston
   APNIC

   Thomas Narten
   IBM Corporation
   3039 Cornwallis Ave.
   PO Box 12195 - BRQA/502
   Research Triangle Park, NC 27709-2195

   Phone: +1 443 778 1319 919 254 7798
   email: brian@innovationslab.net narten@us.ibm.com

10.0 Change Log

   Draft <draft-hinden-ipv6-global-local-addr-02.txt>
      o Major revision based on experience to date with [ULA] and later
        input from the RIR community

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

11. Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

12. 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
   http://www.ietf.org/ipr.

   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-
   ipr@ietf.org.

12.0 Disclaimer of Validity

   This document and

   Acknowledgment

   Funding for the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

13.0 Copyright Statement

   Copyright (C) The Internet Society (2004).  This document RFC Editor function is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, provided by the authors retain all their rights. IETF
   Administrative Support Activity (IASA).