[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02
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]
Html markup produced by rfcmarkup 1.128b, available from
https://tools.ietf.org/tools/rfcmarkup/