One document matched: draft-mrw-6man-ulac-analysis-00.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2629 PUBLIC '' 
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
    <!ENTITY rfc4193 PUBLIC '' 
        'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml'>
    <!ENTITY ulac PUBLIC ''
        'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ipv6-ula-central.xml'>
]>

<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc ipr="full3978" docName="draft-mrw-6man-ulac-analysis-00.txt">

    <front>
        <title abbrev="ULA-C Analysis">
            An Analysis of Centrally Assigned Unique Local Addresses
        </title>
        <author initials="M." surname="Wasserman" fullname="Margaret Wasserman">
            <organization>ThingMagic</organization>
            <address>
                <postal>
                    <street>One Broadway, 5th Floor</street>
                    <city>Cambridge</city> <region>MA</region>
                    <code>02142</code>
                    <country>USA</country>
                </postal>
                <phone>+1 781 405-7464</phone>
                <email>margaret@thingmagic.com</email>
                <uri>http://www.thingmagic.com</uri>
            </address>
        </author>
        <date month="November" year="2007"/>
        <area>Internet</area>
        <workgroup>Network Working Group</workgroup>

        <abstract>
<t>
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.
</t>
        </abstract>
    </front>

    <middle>
        <section title="Introduction">
<t>
Unique Local Addresses (ULAs) are defined in RFC 4193 <xref
target="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.  
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section> <section anchor="benefits" title="The Benefits of ULA-Cs">
<t>
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 accountable
nature of the registration, and the ability for ULA-Cs to be
registered in the reverse DNS.
</t>
            <section title="Greater Assurance of Uniqueness">
<t>
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.
</t>
<t>
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.
</t>
            </section>
            <section title="Accountability">
<t>
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.
</t>
<t>
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.
</t>
             </section>
             <section title="Reverse DNS">
<t>
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.
</t>
             </section>
        </section>
        <section title="The Costs of ULA-Cs">
<t>
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.
</t>
            <section title="Address Space Consumption">
<t>
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. 
</t>
            </section>
            <section title="New Registration Method">
<t>
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.
</t>
            </section>
        </section> 
        <section title="Other Concerns about ULA-Cs">
<t>
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.
</t>
            <section title="Lack of Value">
<t>
Although there are some benefits of ULA-Cs listed in section <xref
target="benefits"/>, 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.
</t>
            </section>
            <section title="Use as Globally Routed Provider Independent Addresses">
<t>
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.
</t>
            </section>
            <section title="Enabling IPv6 NAT">
<t>
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.
</t>
            </section>
        </section>
        <section title="Security Considerations">
<t>
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 <xref target="RFC4193"/>, and security considerations
regarding Centrally Assigned ULAs, in particular, can be found in the
ULA-C draft <xref target="I-D.ietf-ipv6-ula-central"/>.
</t>
        </section>
        <section title="Acknowledgements">
<t>
This document was written using the xml2rfc tool described in RFC 2629
<xref target="RFC2629"/>.
</t>
        </section> 
    </middle>
        
    <back>
        <references title="Normative References">
            &ulac;
	    &rfc4193;
        </references>

        <references title="Informative References">
            &rfc2629;
        </references>
    </back>
</rfc>