One document matched: draft-mrw-6man-ulac-analysis-01.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-01.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 would be used.  
</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 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.
</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 (ULA-Cs), 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 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.
</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
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.
</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 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.
</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 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.
</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 the owner 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-assigned 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 following 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 <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="Wrong Way to Influence Registry Policy">
<t>
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.  
</t>
<t>
There is no technical advantage, and there may be some architectural
disadvantages (see <xref target="architecture"/>), 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
            </section>
            <section anchor="architecture" title="Architecturally Flawed">
<t>
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.
</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 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.
</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>