Network Working Group T. Hain
Internet-Draft Cisco Systems
Intended status: Standards Track R. Hinden
Expires: December 31, 2009 Nokia
G. Huston
APnic
T. Narten
IBM Corporation
June 29, 2009
Centrally Assigned IPv6 Unicast Unique Local Address Prefixes
draft-hain-ipv6-ulac-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. 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.
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 31, 2009.
Copyright Notice
Hain, et al. Expires December 31, 2009 [Page 1]
Internet-Draft IPv6 ULA-C June 2009
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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.
Hain, et al. Expires December 31, 2009 [Page 2]
Internet-Draft IPv6 ULA-C June 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Centrally Assigned Local IPv6 Unicast Address prefixes . . . . 6
3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Global ID . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Sample Code for Pseudo-Random Global ID Algorithm . . . . 8
4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 8
4.1. DNS Issues . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Routing Considerations . . . . . . . . . . . . . . . . . . 9
4.2.1. From the standpoint of the Internet . . . . . . . . . 9
4.2.2. From the Standpoint of a local network
administrator . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Hain, et al. Expires December 31, 2009 [Page 3]
Internet-Draft IPv6 ULA-C June 2009
1. Introduction
This document defines the characteristics, technical allocation and
registration requirements for Centrally Assigned Local IPv6 addresses
in the framework defined in [ULA]. 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 allocation policy, it is time
to resurrect the definition for the lower half of the ULA prefix
range. The requirements to register a ULA-C prefix should be much
less stringent than the requirements to acquire a PI prefix, but for
the sake of policy continuity it makes sense for the RIR's to
collectively manage this registry under IANA's authority.[NUMBERS]
In any case, the prefixes defined here are not expected to appear in
the routing system for the global Internet. The appropriate use of
these prefixes is within a single network administration, or between
privately interconnected networks.
Centrally registered Local IPv6 unicast addresses have the following
characteristics:
- Globally unique 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]:
Hain, et al. Expires December 31, 2009 [Page 4]
Internet-Draft IPv6 ULA-C June 2009
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
allocation, with the registrations escrowed to resolve any disputes
regarding duplicate allocations.
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
allocations, while most small or disconnected organizations will
prefer local allocations. 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 allocation 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 ...
Hain, et al. Expires December 31, 2009 [Page 5]
Internet-Draft IPv6 ULA-C June 2009
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] .
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 |
+--------+-+------------+-----------+-----------------------------+
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 allocation and registration
procedure for creating global- IDs for Centrally Allocated local IPv6
address prefixes (L=0 ; FC00::/8). The allocation procedure for
locally allocated local IPv6 address prefixes (L=1 ; FD00::/8) is
defined in [ULA].
3.2. Global ID
The allocation of Global IDs should be pseudo-random [RANDOM]. They
MUST NOT be allocated sequentially, or with well known numbers as a
vanity prefix, or by locality. This is to ensure that there is not
Hain, et al. Expires December 31, 2009 [Page 6]
Internet-Draft IPv6 ULA-C June 2009
any relationship between allocations and to help clarify that these
prefixes are not intended to be routed globally in the public
Internet. Specifically, these prefixes are designed to not aggregate
between customers of a service provider, but for the sake of internal
routing management and subnet alignment with PI or PA prefix, a
single organization may be allocated a single aggregated set (single
prefix between ::/44 & ::/48), but this ULA-C set is still not
routable across the public Internet.
Global IDs should be allocated under a single allocation and
registration authority because they are pseudo-random and without any
structure. This is easiest to accomplish if there is a single
authority, though there may be multiple organizations handling the
actual registration of allocations through a common procedure. It
also makes sense from a policy consistency perspective for the single
authority to be the same as the one for managing public IPv6
prefixes.
The requirements for ULA-C allocation and registrations are:
- Available to anyone in an unbiased manner.
- Globally Unique.
- When justified, available as a single prefix between /44 - /48.
The allocation and registration authority should permit allocations
to be obtained without having any sort of Internet connectivity and
must include the ability to make an allocation on a permanent basis,
without any need for renewal. 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.
The allocation and registration authority should include sufficient
provisions to mitigate attempts to artificially reduce the number
pool through hoarding of prefixes. The actual mechanisms are beyond
the scope of this document, but can be accomplished in various ways.
These mechanisms 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 individual allocations, but may restrict the
allocation of an aggregated set based on demonstrated need to align
with other PI or PA allocations.
The registration of centrally assigned ULAs should be available in a
public database. This function should support a query of a specific
Hain, et al. Expires December 31, 2009 [Page 7]
Internet-Draft IPv6 ULA-C June 2009
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.
3.3. Sample Code for Pseudo-Random Global ID Algorithm
The algorithm described below is essentially the same as that for
locally assigned [ULA], with the L bit set to 0, and the additional
step of verifying global uniqueness before allocation.
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 (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) Concatenate FC00::/7, the L bit set to 0, and the 40 bit
Global ID to create a centrally assigned Local IPv6 address
prefix.
7) Verify that the computed prefix is not in the escrow. If it is,
discard the value and rerun the algorithm.
[note: in the case where a prefix shorter than /48 is required, at
step 5 zero the low order bits as needed (up to 4 bits), at step 7
verify all of the contained Global IDs are available, then register
all of the contained /48 values to the same administrative
organization.]
This algorithm will result in a Global ID that is unique, and after
verification that it is not already registered it can be used as a
centrally assigned local IPv6 address prefix.
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.
Hain, et al. Expires December 31, 2009 [Page 8]
Internet-Draft IPv6 ULA-C June 2009
Any operational issues relating to this are beyond the scope of this
document.
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
globally routed, provider-independent (PI) prefixes. Subsequent
policy changes have mitigated these concerns by allowing for PI
allocations. 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 allocation 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
Hain, et al. Expires December 31, 2009 [Page 9]
Internet-Draft IPv6 ULA-C June 2009
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. IANA Considerations
The IANA is instructed to designate an allocation authority, based on
instructions from the IAB, for centrally assigned Unique Local IPv6
unicast address prefixes. 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. The IAB MAY
instruct IANA to designate itself as the allocation 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 allocation policies.
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, which will be shepherd through the IETF by the IAB.
6. 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.
Hain, et al. Expires December 31, 2009 [Page 10]
Internet-Draft IPv6 ULA-C June 2009
7. IANA Considerations
The IAB is expected to instruct IANA to designate an allocation
authority for Centrally Allocated Unique Local IPv6 unicast address
prefixes. 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. The IAB MAY instruct IANA
to designate itself as the allocation 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 allocation policies.
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, which will be shepherd through the IETF by the IAB.
8. References
8.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
Hash Standard", FIPS PUB 180-1, April 1995,
<http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[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.
Hain, et al. Expires December 31, 2009 [Page 11]
Internet-Draft IPv6 ULA-C June 2009
[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.
8.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
USA
Phone: +1 425 468-1061
Email: alh-ietf@tndh.net
Robert Hinden
Nokia
313 Fairchild Drive
Mountain View, Ca 94043
USA
Phone: +1 650 625 2400
Email: bob.hinden@nokia.com
Geoff Huston
APnic
AU
Phone:
Email: gih@apnic.net
Hain, et al. Expires December 31, 2009 [Page 12]
Internet-Draft IPv6 ULA-C June 2009
Thomas Narten
IBM Corporation
3039 Cornwallis Ave.
PO Box 12195 - BRQA/502
Research Triangle Park, NC 27709
USA
Phone: +1 919 254 7798
Email: narten@us.ibm.com
Hain, et al. Expires December 31, 2009 [Page 13]