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

Versions: 00 01 02

Network Working Group                                            T. Hain
Internet-Draft                                             Cisco Systems
Intended status:  Standards Track                              R. Hinden
Expires:  January 11, 2011
                                                               G. Huston
                                                           July 10, 2010

     Centrally Assigned IPv6 Unicast Unique Local Address Prefixes


   This document defines Centrally Allocated IPv6 Unique Local address
   prefixes.  These prefixes are globally unique and are intended for
   local communications, usually within a single network administration.
   They are not intended to be used in place of Provider Independent
   (PI) address prefixes available from the Regional Internet Registries
   (RIR) <ref:  http://www.iana.org/numbers/ > , and should not appear
   in the global routing table for the Internet.

   The draft is being discussed on the ipv6@ietf.org list.


   This documents and the information contained therein are provided on

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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

Hain, et al.            Expires January 11, 2011                [Page 1]

Internet-Draft                 IPv6 ULA-C                      July 2010

   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 11, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Hain, et al.            Expires January 11, 2011                [Page 2]

Internet-Draft                 IPv6 ULA-C                      July 2010

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Acknowledgements . . . . . . . . . . . . . . . . . . . . .  6
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Centrally Assigned Local IPv6 Unicast Address prefixes . . . .  6
     3.1.  Format . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Registration process . . . . . . . . . . . . . . . . . . .  7
   4.  Operational Guidelines . . . . . . . . . . . . . . . . . . . .  7
     4.1.  DNS Issues . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Routing Considerations . . . . . . . . . . . . . . . . . .  7
       4.2.1.  From the standpoint of the Internet  . . . . . . . . .  8
       4.2.2.  From the Standpoint of a local network
               administrator  . . . . . . . . . . . . . . . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

Hain, et al.            Expires January 11, 2011                [Page 3]

Internet-Draft                 IPv6 ULA-C                      July 2010

1.  Introduction

   This document defines the characteristics, technical assignment and
   registration requirements for Centrally Assigned Local IPv6 addresses
   in the framework defined in [ULA].  There are organizations looking
   for address space that is independent of the ranges used for public
   Internet routing, yet they also need the uniqueness of central
   assignment which the locally assigned ULA block cannot provide.  A
   stumbling block in earlier attempts at defining the Centrally
   Allocated portion of the ULA prefix range (ULA-C) was the lack of
   public policy at the RIR's for organizations to acquire PI address
   prefixes, so the ULA-C effort was seen as an end-run around the
   public policy process.  As the ability to acquire PI space is now
   resolved by assignment policy, it is time to resurrect the definition
   for the lower half of the ULA prefix range.  At the same time, this
   document will defer as much policy as possible, and focus on
   technical definition.  To make the range useful to a wide range of
   organizations, the requirements to register a ULA-C prefix should be
   less stringent than the requirements to acquire a PI prefix, but non-
   trivial and sufficient to keep them from becoming an attractive
   nuisance to bypass PI policy.  For the sake of policy continuity the
   IAB should strongly consider organizatoinal alignment for the
   managemnet of the ULA-C prefix with that for globally routable

   In any case, the prefixes defined here are not expected to appear in
   the routing system for the global Internet.  A frequent question is
   how this prefix differs from a PI assignment.  The simple answer is
   in expectation of global public routability.  A PI assignment has the
   expectation that it could appear in the global DFZ, where a ULA-C
   registration is expected to be limited reach as service providers are
   free to, and expected to filter the entire FC00::/7 prefix as bogon
   space.  Recognizing that this is a policy statement; the appropriate
   use of these prefixes is within a single network administration, or
   between privately interconnected networks that want to ensure that
   private communications do not accidentally get routed over the public
   Internet as might happen with PI.

   Centrally registered Local IPv6 unicast addresses have the following

Hain, et al.            Expires January 11, 2011                [Page 4]

Internet-Draft                 IPv6 ULA-C                      July 2010

   - Globally unique registration for each prefix.
   - Well known designator prefix to allow for easy filtering at
     administrative boundaries.
   - Allows sites to be combined or privately interconnected without
     creating any address conflicts or requiring renumbering of
   - Internet Service Provider independent and can be used for
     communications inside of a private network where public Internet
     connectivity is intermittent or not available.
   - If accidentally leaked outside of a private network via routing
     or DNS, there is no conflict with any other addresses.
   - 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.

   Where the Unique Local Address prefixes defined in [ULA]were
   probabilistically unique, the major difference between those and the
   Centrally Allocated local address prefixes defined in this document
   is that the ULA-C prefixes are registered and verified unique before
   assignment, with the registrations escrowed to resolve any disputes
   regarding duplicate assignments.

   It is expected that network administrators of larger organizations,
   or those with business practice or governmental requirements to avoid
   conflict in future mergers or acquisitions will prefer central
   assignments, while most small or disconnected organizations will
   prefer local assignments.  It is recommended that network
   administrations which are planning to use Local IPv6 address
   prefixes, for extensive inter-site communication over a long period
   of time, use a Centrally Allocated prefix as there is no possibility
   of assignment conflicts when interconnecting or merging networks.
   Individual administrations are free to choose either approach, and in
   fact may choose both, with a Centrally Allocated prefix for their
   production networks while using locally allocated prefixes in their

Hain, et al.            Expires January 11, 2011                [Page 5]

Internet-Draft                 IPv6 ULA-C                      July 2010

   experimental or lab networks.

1.1.  Acknowledgements

   Robert Hinden and Brian Haberman attempted a version of this
   specification between 2002 & 2005, followed by another attempt by
   Geoff Huston and Thomas Narten in 2007.  Both of those drafts were
   significant resources for much of the text used in developing this
   document, as those included comments from Alan Beard, Alex Zinin,
   Brian Carpenter, Charlie Perkins, Christian Huitema, Hans Kruse,
   Harald Alvestrand, Keith Moore, Leslie Daigle, Margaret Wasserman,
   Pekka Savola, Shannon Behrens, Steve Bellovin, Tim Chown, and Bill
   Fenner.  Additional comments to this document were provided by ...

2.  Terminology

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

3.  Centrally Assigned Local IPv6 Unicast Address prefixes

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         |


         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.

         Global ID      40-bit global identifier used to create a
                        globally unique prefix.

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

Hain, et al.            Expires January 11, 2011                [Page 6]

Internet-Draft                 IPv6 ULA-C                      July 2010

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

   NOTE:  This document defines the assignment and registration
   procedure for creating global- IDs for Centrally Allocated local IPv6
   address prefixes (L=0 ; FC00::/8).  The assignment procedure for
   locally allocated local IPv6 address prefixes (L=1 ; FD00::/8) is
   defined in [ULA].

3.2.  Registration process

   Global IDs MUST be allocated under a single assignment and
   registration authority.  The IAB SHOULD designate IANA as the
   registration authority.  As policies differ around the world, IANA
   SHOULD delegate to the RIRs in a manner similar to the /12 approach
   used for the 2000::/3 prefix.  The RIRs SHOULD establish registration
   policies which recognize that ULA-C prefixes are not a threat to the
   global DFZ, and therefore easier to justify.  Organizations that
   don't want an ongoing relationship with the RIRs SHOULD be directed
   to RFC 4193.

   The requirements for ULA-C assignment and registrations are:

   - Available to anyone in an unbiased manner.
   - Globally Unique.
   - When justified, available as a single prefix between /44 - /48.

4.  Operational Guidelines

4.1.  DNS Issues

   Given their inherent uniqueness, AAAA and PTR records for centrally
   assigned local IPv6 addresses may be installed and appear 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 or split-DNS systems for inside and outside traffic.
   Any operational issues relating to this are beyond the scope of this

4.2.  Routing Considerations

   Section 4.1 of [ULA]provides operational guidelines that inhibit
   default routing of local addresses between sites.  During the initial
   attempts at defining the ULA-C space, concerns were raised to the
   IPv6 working group and to the IETF as a whole that lacking an
   alternative, sites would attempt to use local address prefixes as

Hain, et al.            Expires January 11, 2011                [Page 7]

Internet-Draft                 IPv6 ULA-C                      July 2010

   globally routed, provider-independent (PI) prefixes.  Subsequent
   policy changes have mitigated these concerns by allowing for PI
   assignments.  This section describes why using local addresses in
   place of PI prefixes is unadvisable, and why existing RIR mechanisms
   for acquiring PI prefix blocks should be used instead.

4.2.1.  From the standpoint of the Internet

   IPv6 unicast addresses are designed to be routed hierarchically down
   to physical subnet (link) level and only have to be flat-routed
   within the physical subnet prefix.  Attempting to use IPv6 local
   address prefixes publicly would result in them being flat-routed over
   the wide area Internet, and thus a larger routing table.  This
   contravenes the operational assumption that for global public
   routing, long prefixes will be aggregated into fewer short prefixes
   to limit the table size and convergence time of the routing protocol.

   Collecting all local-use prefixes under one short designator prefix
   (FC00::/7) simplifies the development and maintenance of bogon route
   filters.  Given that everything registered under the procedures
   defined in this document are intended for local, non-public use only,
   it is expected to be common practice for all public service providers
   to filter any prefixes within the entire ULA range (both centrally
   registered and locally defined), and remove them from the public
   global routing table.  The alternative would be to enumerate every
   prefix that should not be publicly routed, and then hope that there
   are no operational errors that inadvertently allow a private prefix
   to be propagated publically.

   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 assignment of PI Space

4.2.2.  From the Standpoint of a local network administrator

   The operational guidelines regarding routing of centrally allocated
   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
   global routing system and the potential negative impact on the total
   size of the routing space in large scale Internet environments.

Hain, et al.            Expires January 11, 2011                [Page 8]

Internet-Draft                 IPv6 ULA-C                      July 2010

5.  Security Considerations

   Local IPv6 address prefixes 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 address prefixes.

   They should be filtered by public network operators to ensure that
   publicly routed prefixes are publicly documented, but beyond
   accountability there is no security aspect related to propagating the
   route.  On the other hand, the lack of a public routing entry is
   considered by many to be one layer in a defense-in-depth strategy, so
   widespread practice of filtering the entire ULA prefix range would
   automatically provide that layer even for sites that don't implement
   an explicit filter of their own.

   Local IPv6 address prefixes do allow for address-based security
   mechanisms, including IPSEC, across end to end VPN connections or
   other private interconnects.

6.  IANA Considerations

   The IAB is expected to instruct IANA to designate an assignment
   authority for Centrally Allocated Unique Local IPv6 unicast address
   prefixes.  This assignment authority shall comply with the
   requirements described in Section 3.2 of this document, including in
   particular assignment on a permanent basis and with sufficient
   provisions to avoid hoarding of numbers.  The IAB MAY instruct IANA
   to designate itself as the assignment and registration authority, and
   IANA in turn MAY choose to delegate the day-to-day operational
   functions to the same organizations that handle publicly routed
   prefixes to maintain consistency between assignment policies.

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

7.  References

7.1.  Normative References

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

   [FIPS]     National Institute of Standards and Technology, "Secure

Hain, et al.            Expires January 11, 2011                [Page 9]

Internet-Draft                 IPv6 ULA-C                      July 2010

              Hash Standard", FIPS PUB 180-1, April 1995,

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

   [ICMPv6]   Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

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

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

   [RANDOM]   Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

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

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

   [ULA]      Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

7.2.  Informative References

   [NUMBERS]  "IANA Numbers Authority", <http://www.iana.org/numbers/>.

Authors' Addresses

   Tony Hain
   Cisco Systems
   500 108th Ave NE
   Bellevue, WA  98004

   Phone:  +1 425 468-1061
   Email:  alh-ietf@tndh.net

Hain, et al.            Expires January 11, 2011               [Page 10]

Internet-Draft                 IPv6 ULA-C                      July 2010

   Robert Hinden
   313 Fairchild Drive
   Mountain View, Ca  94043

   Phone:  +1 650 625 2400
   Email:  bob.hinden@nokia.com

   Geoff Huston

   Email:  gih@apnic.net

Hain, et al.            Expires January 11, 2011               [Page 11]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/