INTERNET-DRAFT                                          R. Hinden, Nokia
June 23, 2004
February 18, 2005                                    B. Haberman, Caspian JHU-APL

                           Centrally Assigned
                  Unique Local IPv6 Unicast Addresses

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

                  <draft-ietf-ipv6-ula-central-01.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, we certify each
   author represents that any applicable patent or other IPR claims of
   which I am he or she is aware have been or will be disclosed, and any of
   which I 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.

   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 a as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html
   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
   http://www.ietf.org/shadow.html.

   This internet draft expires on November 28, 2004. August 23, 2005.

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 Centrally Assigned Global IDs.................................4
   3.2.2 Sample Code for Pseudo-Random Global ID Algorithm.............6
   4.0 Security Considerations.........................................6 Operational Guideliens..........................................6
   5.0 IANA Considerations.............................................6 Global Routing Considerations...................................7
   5.1 From the Standpoint of the Internet.............................7
   5.2 From the Standpoint of a Site...................................7
   6.0 References......................................................7
   6.1 Security Considerations.........................................8
   7.0 IANA Considerations.............................................8
   8.0 References......................................................9
   8.1 Normative References............................................7
   6.2 References............................................9
   8.2 Informative References..........................................8
   7.0 References..........................................9
   9.0 Authors' Addresses..............................................8
   8.0 Addresses.............................................10
   10.0 Change Log......................................................9 Log....................................................11
   11.0 Intellectual Property.........................................11
   12.0 Disclaimer of Validity........................................12
   13.0 Copyright Statement...........................................12

1.0 Introduction

   This document defines an Centrally allocated IPv6 unicast address
   format that is globally unique the characteristics and is intended technical allocation
   requirements for local
   communications [IPV6].  These addresses are called Unique centrally assigned Local IPv6
   Unicast Addresses and are abbreviated addresses in this document as Local IPv6
   addresses. 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.

   This document defines the characteristics and technical allocation
   requirements for centrally assigned Local IPv6 addresses in the
   framework defined in [ULA].

   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.

   This document defines the the characteristics and technical
   allocation requirements for centrally assigned Local IPv6 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
      5.0
      4.2 Renumbering and Site Merging
      6.0
      4.3 Site Border Router and Firewall Packet Filtering
      7.0  DNS Issues
      8.0
      4.5 Application and Higher Level Protocol Issues
      9.0
      4.6 Use of Local IPv6 Addresses for Local Communications
      10.0
      4.7 Use of Local IPv6 Addresses with VPNs
      11.0
      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",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].

2.0 Acknowledgments

   The underlying idea of creating Local IPv6 addresses described in
   this document been proposed a number of times by a variety of people.
   The authors of this draft do not claim exclusive credit.  Credit goes
   to Brian Carpenter, Christian Huitema, Aidan Williams, Andrew White,
   Charlie Perkins, and many others.  The authors would also 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, and Tim Chown Chown, Steve Bellovin, Alex Zinin, Tony Hain, Leslie
   Daigle, and Bill Fenner 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 are created using a
   pseudo-random global ID.  They addresses, based on Unique Local
   Addresses [ULA], have the following format:

      | 8 7 bits | |1|  40 bits   |  16 bits  |          64 bits            |
      +--------+------------+-----------+-----------------------------+
      | prefix
      +--------+-+------------+-----------+-----------------------------+
      | global Prefix |L| Global ID  | subnet Subnet ID |        interface        Interface ID         |
      +--------+------------+-----------+-----------------------------+
      +--------+-+------------+-----------+-----------------------------+
   Where:

      prefix            FC00::/8

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

      global

      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 Section 3.2 for
                        additional information.

      subnet

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

      interface

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

3.2 Global ID

   The allocation of global Global IDs should be pseudo-random [RANDOM].  They
   should
   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
   aggregate.

   The major difference between the locally assigned Unique local
   addresses as 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
   approach.

3.2.1 Centrally Assigned Global

   This document defines the allocation procedure for creating global-
   IDs

   Centrally for centrally assigned global IDs MUST be generated 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 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 not 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 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
   authority).

   Note, there are many possible ways of 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 be perfect, only good enough to do the job at hand.

   This document directs the IANA, in section 5.0, to delegate the
   FC00::/8 prefix to an allocation authority to allocate centrally
   assigned /48 prefixes consistent with the requirements defined in
   this section.

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 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 MD5 SHA-1 digest on the key as specified in [MD5DIG]. [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 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 Global ID that is unique and can be
   used as to create a Global ID. centrally assigned local IPv6 address prefix.

4.0 Security Considerations

   Local Operational Guidelines

4.1 DNS Issues

   At the present time AAAA and PTR records for centrally assigned local
   IPv6 addresses do not provide any inherent security to may be installed in the
   nodes that use them.  They global DNS.  This may be
   useful if these addresses are being used with filters at for site
   boundaries to keep Local IPv6 traffic inside of the site, but this is
   no more site or VPN
   style applications, 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 sites that wish to end VPN connections. avoid separate DNS
   systems for inside and outside traffic.

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

5.0 IANA Global Routing Considerations

   The IANA is instructed

   Section 4.1 of [ULA] provides operational guidelines that forbid
   default routing of local addresses between sites.  Concerns were
   raised to assign the FC00::/8 prefix for Centrally
   assigned Unique Local IPv6 unicast addresses.

   The IANA is instructed working group and to delegate, within a reasonable time, the
   prefix FC00::/8 IETF as a whole that
   sites may attempt to an allocation authority for Unique Local IPv6
   Unicast prefixes of length /48. use local addresses as globally routed provider-
   independent addresses.  This allocation authority shall
   comply with the requirements described section describes why using local
   addresses as globally-routed provider-independent addresses is
   unadvisable.

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.

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

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

6.0

   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

6.1

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.

   [MD5DIG]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
             April 1992.

   [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-05.txt>, June
             addr-08.txt>, November  2004.

6.2

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)", 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.

7.0

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
   Caspian Networks
   1 Park Drive, Suite 300
   Research Triangle Park, NC  27709
   Johns Hopkins University
   Applied Physics Lab
   11100 Johns Hopkins Road
   Laurel, MD 20723
   USA

   phone: +1-929-949-4828 +1 443 778 1319
   email: brian@innovationslab.net

8.0

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
        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  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 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 is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.