One document matched: draft-mrw-6man-ulac-analysis-00.txt
Network Working Group M. Wasserman
Internet-Draft ThingMagic
Expires: May 15, 2008 November 12, 2007
An Analysis of Centrally Assigned Unique Local Addresses
draft-mrw-6man-ulac-analysis-00.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 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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.
Wasserman Expires May 15, 2008 [Page 1]
Internet-Draft ULA-C Analysis November 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Benefits of ULA-Cs . . . . . . . . . . . . . . . . . . . . 3
2.1. Greater Assurance of Uniqueness . . . . . . . . . . . . . . 4
2.2. Accountability . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Costs of ULA-Cs . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Address Space Consumption . . . . . . . . . . . . . . . . . 5
3.2. New Registration Method . . . . . . . . . . . . . . . . . . 5
4. Other Concerns about ULA-Cs . . . . . . . . . . . . . . . . . . 5
4.1. Lack of Value . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Use as Globally Routed Provider Independent Addresses . . . 6
4.3. Enabling IPv6 NAT . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Wasserman Expires May 15, 2008 [Page 2]
Internet-Draft ULA-C Analysis November 2007
1. Introduction
Unique Local Addresses (ULAs) are defined in RFC 4193 [RFC4193],
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 that would be.
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 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 reasonable 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, 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 Centrally Allocated ULAs 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
benefits 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
Wasserman Expires May 15, 2008 [Page 3]
Internet-Draft ULA-C Analysis November 2007
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 will be used for these large, private,
inter-enterprise networks, it may be 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 Allocated 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 them 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-allocated nature.
Wasserman Expires May 15, 2008 [Page 4]
Internet-Draft ULA-C Analysis November 2007
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 followign 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
Section 2, 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.
Wasserman Expires May 15, 2008 [Page 5]
Internet-Draft ULA-C Analysis November 2007
4.2. 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 teh 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.3. 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], and security considerations regarding
Centrally Assigned ULAs, in particular, can be found in the ULA-C
draft [I-D.ietf-ipv6-ula-central].
6. Acknowledgements
This document was written using the xml2rfc tool described in RFC
2629 [RFC2629].
7. References
7.1. Normative References
[I-D.ietf-ipv6-ula-central]
Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast
Addresses", draft-ietf-ipv6-ula-central-02 (work in
progress), June 2007.
Wasserman Expires May 15, 2008 [Page 6]
Internet-Draft ULA-C Analysis November 2007
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
7.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
Author's Address
Margaret Wasserman
ThingMagic
One Broadway, 5th Floor
Cambridge, MA 02142
USA
Phone: +1 781 405-7464
Email: margaret@thingmagic.com
URI: http://www.thingmagic.com
Wasserman Expires May 15, 2008 [Page 7]
Internet-Draft ULA-C Analysis November 2007
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.
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Wasserman Expires May 15, 2008 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 03:07:09 |