INTERNET-DRAFT                                          R. Hinden, Nokia
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-02.txt>


Status of this Memo

   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 becomes
   aware will be disclosed, in accordance with 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 will expire on 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.






Hinden, et. al.         Expires December 21, 2007               [Page 1]


INTERNET-DRAFT   Centrally Assigned Local IPv6 Addresses       June 2007


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...................5
   3.2.2 Sample Code for Pseudo-Random Global ID Algorithm.............5
   3.3 Public Registration Services....................................6
   4.0 Operational Guideliens..........................................6
   5.0 Global Routing Considerations...................................7
   6.0 Security Considerations.........................................7
   7.0 IANA Considerations.............................................7
   8.0 References......................................................8
   8.1 Normative References............................................8
   8.2 Informative References..........................................8
   9.0 Authors' Addresses..............................................9
   10.0 Change Log....................................................10
   11.0 Full Copyright................................................10
   12.0 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.
      - Internet Service Provider independent and can be used for
        communications inside of a site without having any permanent or
        intermittent Internet connectivity.
      - 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.




Hinden, et. al.         Expires December 21, 2007               [Page 2]


INTERNET-DRAFT   Centrally Assigned Local IPv6 Addresses       June 2007


   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 [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, Pekka Savola, Shannon Behrens, Steve Bellovin, Tim Chown,
   and 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.




Hinden, et. al.         Expires December 21, 2007               [Page 3]


INTERNET-DRAFT   Centrally Assigned Local IPv6 Addresses       June 2007


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

   The major difference between the locally assigned Unique Local
   Addresses defined in [ULA] and the centrally assigned Unique Local
   Addresses, as defined in this document, is that they are uniquely
   assigned and the 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

   Global IDs should be allocated by a new registry function such that
   each allocation is unique and that the assignment is recorded and



Hinden, et. al.         Expires December 21, 2007               [Page 4]


INTERNET-DRAFT   Centrally Assigned Local IPv6 Addresses       June 2007


   published in a public database to verify that that allocation was
   unique.

   Global IDs may be assigned under the authority of a single allocation
   organization or by multiple organizations.  If there are multiple
   organizations, there 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 public database.

   The requirements for centrally assigned Global ID allocations are:

      - Globally unique.
      - Available to anyone in an unbiased manner.

   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.  Other forms of allocation,
   including periodic renewable allocations and explicit provision for
   de-allocation may also be provided.

   The allocation service should include sufficient provisions to
   mitigate attempts to artificially reduce the number pool through
   hoarding of numbers.  The mechanism used by the registration
   authority should not include onerous provisions that reduce the
   intent that these allocations should be available to anyone in an
   unbiased manner, and should not attempt to perform rationing or
   impose quotas upon allocations.

   The registration authority may covers its costs through registration
   fees and may also use registration agreements to clearly set forth
   the terms conditions and liabilities associated with registration of
   such allocations.  The payments and conditions associated with this
   function should not be unreasonably onerous to the 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).



Hinden, et. al.         Expires December 21, 2007               [Page 5]


INTERNET-DRAFT   Centrally Assigned Local IPv6 Addresses       June 2007


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

   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

   Since [ULA] was first published, the Regional Internet Address
   Registries (RIR) created a new policy to allocate IPv6 Provider
   Independent Addresses [RIR-PI].  Given the availability of RIR
   allocated provider-independent addresses the authors believe that
   there is considerably less concern that ULAs of either type will be
   used as IPv6 provider-independent addresses.




Hinden, et. al.         Expires December 21, 2007               [Page 6]


INTERNET-DRAFT   Centrally Assigned Local IPv6 Addresses       June 2007


   The operational guidelines regarding routing of centrally assigned
   local addresses is that such address prefixes should be readily
   routed within a site or comparable administrative routing domain.

   By default, such prefixes should not be announced beyond such a local
   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 use IPv6 Provider Independent Addresses (PI
   Space) in such larger routing contexts should consult the 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 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.







Hinden, et. al.         Expires December 21, 2007               [Page 7]


INTERNET-DRAFT   Centrally Assigned Local IPv6 Addresses       June 2007


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.

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

   [RANDOM]  Eastlake, D. 3rd, J. Schiller, S. Crocker, "Randomness
             Recommendations for Security", RFC 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", 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


   Geoff Huston



Hinden, et. al.         Expires December 21, 2007               [Page 8]


INTERNET-DRAFT   Centrally Assigned Local IPv6 Addresses       June 2007


   APNIC


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

   Phone: +1 919 254 7798
   email: narten@us.ibm.com








































Hinden, et. al.         Expires December 21, 2007               [Page 9]


INTERNET-DRAFT   Centrally Assigned Local IPv6 Addresses       June 2007


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



Hinden, et. al.         Expires December 21, 2007              [Page 10]


INTERNET-DRAFT   Centrally Assigned Local IPv6 Addresses       June 2007


   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.

   Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).































Hinden, et. al.         Expires December 21, 2007              [Page 11]