Centrally Assigned IPv6 Unicast Unique Local Address Prefixes
draft-hain-ipv6-ulac-02

Abstract

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.

Legal

This documents and the information contained therein 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

Table of Contents

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

1.  Introduction

This document defines the characteristics, technical assignment and registration requirements for Centrally Assigned Local IPv6 addresses in the framework defined in [ULA] (Hinden, R. and B. Haberman, “Unique Local IPv6 Unicast Addresses,” October 2005.). 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 prefixes.[NUMBERS] (, “IANA Numbers Authority,” .)

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 characteristics:

- 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
  interfaces.
- 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] (Hinden, R. and B. Haberman, “Unique Local IPv6 Unicast Addresses,” October 2005.):

      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] (Hinden, R. and B. Haberman, “Unique Local IPv6 Unicast Addresses,” October 2005.)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 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) .

3.  Centrally Assigned Local IPv6 Unicast Address prefixes

3.1.  Format

The Centrally assigned Local IPv6 addresses, based on Unique Local Addresses [ULA] (Hinden, R. and B. Haberman, “Unique Local IPv6 Unicast Addresses,” October 2005.), 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 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.

      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] (Hinden, R. and B. Haberman, “Unique Local IPv6 Unicast Addresses,” October 2005.).

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

4.2.  Routing Considerations

Section 4.1 of [ULA] (Hinden, R. and B. Haberman, “Unique Local IPv6 Unicast Addresses,” October 2005.)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 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 [RIR-PI].

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.

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

7.2. Informative References

Authors' Addresses