An Analysis of Centrally Assigned Unique Local Addresses
draft-mrw-6man-ulac-analysis-01.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 May 22, 2008.

Abstract

There has been discussion within the IETF IPv6 community for some time regarding whether or not to define Centrally Assigned Unique Local Addresses (ULA-Cs). Although many arguments both for and against the definition of ULA-Cs have been raised and repeated, our discussions have not resulted in consensus about whether or not to define this new address type. This document will summarize the arguments for and against the allocation of ULA-Cs, in an attempt to help the IETF IPv6 community reach a decision on this issue.

Table of Contents

1.  Introduction
2.  The Benefits of ULA-Cs
    2.1.  Greater Assurance of Uniqueness
    2.2.  Accountability
    2.3.  Reverse DNS
3.  The Costs of ULA-Cs
    3.1.  Address Space Consumption
    3.2.  New Registration Method
4.  Other Concerns about ULA-Cs
    4.1.  Lack of Value
    4.2.  Wrong Way to Influence Registry Policy
    4.3.  Architecturally Flawed
    4.4.  Use as Globally Routed Provider Independent Addresses
    4.5.  Enabling IPv6 NAT
5.  Security Considerations
6.  Acknowledgements
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

Unique Local Addresses (ULAs) are defined in RFC 4193 [RFC4193] (Hinden, R. and B. Haberman, “Unique Local IPv6 Unicast Addresses,” October 2005.), which defines a local assignment method to be used for half of the ULA address space. RFC 4193 reserves the other half of the ULA space for ULAs that are assigned using another assignment method, without specifying what method would be used.

ULAs are largely targeted at fulfilling the need for local, Internet Service Provider (ISP)-independent prefixes that can be used on isolated networks, internal networks and VPNs. Enterprise administrators do not want to use Provider Assigned addresses for these purposes, because they want to avoid the need to renumber their internal, private networks when they change ISPs, or when their ISPs merge with other ISPs or restructure their address allocations.

Locally Assigned ULAs are generated within the local enterprise, either by the network administrator or by a piece of networking equipment, using a random number generator. These addresses are probabilistically unique, in the sense that it is extremely unlikely that there will be an overlap within any reasonably small number of Centrally Assigned ULA prefixes.

Locally Assigned ULAs meet most of the local addressing needs that have been expressed, and their probabilistic uniqueness represents a significant advantage over the overlapping private address space available in IPv4. However, there have been some arguments that we should also define a centrally assigned set of ULAs (ULA-Cs), to meet some needs that are not fully handled by the locally allocated ones.

The IETF IPv6 community (originally represented by the IPv6 WG, but now represented by the IPv6 Maintenance (6man) WG) has not been able to achieve consensus, over a period of several years, regarding whether or not to define ULA-Cs to inhabit the other half of the ULA address space. The document has been written in an attempt to clearly document the different sides of this issue, in the hope that we can achieve a consensus decision on how to proceed.

2.  The Benefits of ULA-Cs

To understand the benefits of Centrally Assigned ULAs in a world that already has Locally Assigned ULAs available, we need to discuss what features Centrally Assigned ULAs will provide that are not already covered by Locally Assigned ULAs. These benefits stem from the differences between Locally Assigned and Centrally Assigned ULAs: the greater certainty that ULA-Cs will be unique, the publicly accountable nature of the registration, and the ability for ULA-Cs to be registered in the reverse DNS.

2.1.  Greater Assurance of Uniqueness

In some cases, local enterprise networks extend beyond the boundaries of a single enterprise, connecting a set of trading partners, or connecting a business and its customers, to a single private network. Many of these inter-enterprise private networks exist today, and they can be quite large in some cases.

In cases where ULA prefixes are used for these large, private, inter-enterprise networks, it is important that the ULA prefix assigned to the private network does not conflict with any of the prefixes used internally by the participating enterprises, including the prefixes used by those enterprises on other private inter-enterprise networks with overlappign membership. To ensure that this requirement is met, some network administrators would prefer to use prefixes, such as ULA-Cs, that have a greater probability of uniqueness than Locally Assigned ULAs.

2.2.  Accountability

ULA-Cs are assigned by a central registry that keeps a record of the assignment. This means that if a conflict does arise where two enterprises are using the same Centrally Assigned ULA prefix, it is possible for an enterprise administrator to prove that the prefix was assigned to his/her company, and that his/her enterprise has the right to use it.

The use of Centrally Assigned ULAs also has some advantages for tracking the source of any local traffic that may leak into another enterprise network or onto the Internet. Because the prefix has been centrally assigned, it should be possible to check who owns the prefix and contact the owner about the problem.

2.3.  Reverse DNS

One of the major advantages of Centrally Assigned ULAs over Locally Assigned ULAs is that it is possible for the Centrally Assigned ULA prefixes to be populated in the global Reverse DNS. Since these addresses may be routed across private networks between enterprises, it isn't reasonable to assume that all of the nodes on a private network will be configured to use a single DNS server that can run "two-faced" DNS to reflect the internal addresses. In these cases, it may be valuable to have these addresses populated in the global Reverse DNS tree. This would be possible with ULA-Cs, because of their centrally-assigned nature.

3.  The Costs of ULA-Cs

This section attempts to summarize the costs associated with the definition of ULA-Cs. Additional concerns regarding the definition of ULA-Cs are covered in the following section.

3.1.  Address Space Consumption

From an address space perspective, there is little or no cost to defining ULA-Cs. RFC 4193 allocates the prefix FCOO::/7 to be used for Unique Local Addresses. One half of that space (the prefix FD00::/8) is allocated for Locally Assigned ULAs, while the other half of the space (the prefix FC00::/8) is reserved for ULAs that use another assignment method. The ULA-C draft proposes that remaining half of that space (the FC00::/8 prefix) should be used for Centrally Assigned ULAs.

3.2.  New Registration Method

ULA-Cs would require an additional type of address registration, which would involve some costs to the larger Internet community. However, if there is any signficant demand for ULA-Cs, it is likely that these costs could be recouped from the ULA-C registration fees.

4.  Other Concerns about ULA-Cs

In addition to the costs associated with defining ULA-Cs, a number of concerns have been raised regarding the value of ULA-C prefixes and how they might be used or abused. This section attempts to summarize those concerns.

4.1.  Lack of Value

Although there are some benefits of ULA-Cs listed in Section 2 (The Benefits of ULA-Cs), it has been argued that the benefits of ULA-Cs are not sufficient to warrant the corresponding complexity that will be added to the IPv6 standard or the effort of setting up a centralized registration mechanism. The vast majority of the benefits that can be obtained using ULA-Cs can also be obtained using Locally Assigned ULAs, which are already defined and do not require any central registration process. In most cases where enterprise administrators argue that they need a higher likelihood of uniqueness, it is not actually the case that their application will substantially benefit from the different between probabilistic uniqueness and more deterministic uniqueness.

4.2.  Wrong Way to Influence Registry Policy

It has been argued that it is inappropriate and/or ineffective for the IETF to attempt to influence address registration policies through the publication of an RFC that creates a new address space with defined registration policies.

There is no technical advantage, and there may be some architectural disadvantages (see Section 4.3 (Architecturally Flawed)), to allocating a prefix for globally unique addresses with specific registration policies. If the Internet community believes that it is both useful and wise to freely assign globally unique prefixes for local use, registry policies could be updated to make such assignments from the regular IPv6 address space. There is no guarantee that any address prefixes that are assigned by the registries will be routable on the global Internet. Routing is achieved through separate agreements with ISPs. So there is no reason to allocate a new block of IPv6 address space to remove that non-existent guarantee.

Furthermore, there is no direct connection between the publication of and RFC and the implementation of an address registration service. So, while it might be useful for the IETF to publish an RFC describing needs for a specific type of registration service, an RFC describing ULA-Cs would not directly result in the availability of a corresponding registration service.

So, publishing an RFC that assigns an address prefix for ULA-Cs is not necessary for the allocation of globally unique local addresses, nor will it be sufficient to ensure that the registration function described in the document becomes available.

4.3.  Architecturally Flawed

It has been argued that associating routing behavior with specific address prefixes is architecturally unsound and has caused problems in the past. For example, IETF statements that the IPv4 address block 240/4 would not be globally routable lead to the implementation of default routing filters that have complicated the allocation of those addresses as part of the global IPv4 address space. However, this argument only loosely applies to the definition of ULA-Cs. We will not avoid the allocation of address prefixes with associated routing behaviour by deciding not to define ULA-Cs, as the address space that would be used for ULA-Cs has already been allocated in RFC 4193.

4.4.  Use as Globally Routed Provider Independent Addresses

There is a widely-held view in the Internet operations community that ULA-Cs will end-up being routed across the Internet and will, effectively, result in the unlimited allocation of globally routed Provider Independent (PI) addresses. Since these addresses would not be allocated by ISPs in an aggregable fashion, it is expected that they would result in separate per-enterprise routes in the global routing table, as PI addresses from the IPv4 "swamp space" do today. If ULA-Cs were widely used in this fashion, the global routing tables for IPv6 could become large enough to compromise the stability of the Internet.

4.5.  Enabling IPv6 NAT

Some have argued that the definition of ULA-Cs will provide a suitable set of addresses for use behind an IPv6-to-IPv6 NAT box, and that we should not define these addresses to avoid that situation. However, ULA-Cs provide no significant benefits to NAT installations that cannot be achieved with Locally Assigned ULAs, so it is unlikely that defining ULA-Cs will have much effect, in either direction, on whether enterprises decide to use NAT for IPv6 networks.

5.  Security Considerations

This document analyzes the tradeoffs involved in whether or not to define a new IPv6 local address type called Centrally Allocated ULAs (ULA-Cs). Security considerations regarding ULAs, in general, can be found in RFC 4193 [RFC4193] (Hinden, R. and B. Haberman, “Unique Local IPv6 Unicast Addresses,” October 2005.), and security considerations regarding Centrally Assigned ULAs, in particular, can be found in the ULA-C draft [I‑D.ietf‑ipv6‑ula‑central] (Hinden, R., “Centrally Assigned Unique Local IPv6 Unicast Addresses,” June 2007.).

6.  Acknowledgements

This document was written using the xml2rfc tool described in RFC 2629 [RFC2629] (Rose, M., “Writing I-Ds and RFCs using XML,” June 1999.).

7.  References

7.1. Normative References

7.2. Informative References

Author's Address

Full Copyright Statement

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

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.