One document matched: draft-mrw-6man-ulac-analysis-01.txt
Differences from draft-mrw-6man-ulac-analysis-00.txt
Network Working Group M. Wasserman
Internet-Draft ThingMagic
Expires: May 22, 2008 November 19, 2007
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.
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 22, 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. Wrong Way to Influence Registry Policy . . . . . . . . . . 6
4.3. Architecturally Flawed . . . . . . . . . . . . . . . . . . 6
4.4. Use as Globally Routed Provider Independent Addresses . . . 7
4.5. Enabling IPv6 NAT . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Wasserman Expires May 22, 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 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
Wasserman Expires May 22, 2008 [Page 3]
Internet-Draft ULA-C Analysis November 2007
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.
Wasserman Expires May 22, 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 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, 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 22, 2008 [Page 5]
Internet-Draft ULA-C Analysis November 2007
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), 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.
Wasserman Expires May 22, 2008 [Page 6]
Internet-Draft ULA-C Analysis November 2007
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], 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 22, 2008 [Page 7]
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 22, 2008 [Page 8]
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 22, 2008 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 03:05:45 |