One document matched: draft-azinger-additional-private-ipv4-space-issues-02.xml

<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc ipr="trust200902"
     docName="draft-azinger-additional-private-ipv4-space-issues-02"
     category="info">

<?rfc toc="yes"?> 
<?rfc symrefs="yes"?> 
<?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<front>

<title abbrev="Additional Private IPv4">Additional Private IPv4 Space Issues</title>

<author initials="M" surname="Azinger" fullname="Marla Azinger">
   <organization>Frontier Communications Corporation</organization>
   <address>
      <postal>
         <street/>
         <city>Vancouver</city>
         <country>United States of America</country>
      </postal>
      <email>marla.azinger@frontiercorp.com</email>
      <uri>
      http://www.frontiercorp.com/
   </uri>
   </address>
</author>

        <author initials="L." surname="Vegoda" fullname="Leo Vegoda">
                <organization abbrev="ICANN">
                        Internet Corporation for Assigned Names and Numbers
                </organization>
                <address>
                        <postal>
                                <street>4676 Admiralty Way, Suite 330</street>
                                <code>90292</code> <city>Marina del Rey</city>
                                <country>United States of America</country>
                        </postal>
                        <phone>+310-823-9358</phone>
                        <email>leo.vegoda@icann.org</email>
                        <uri>
                                http://www.iana.org/
                        </uri>
                </address>
        </author>

<date month="February" year="2010" />

<keyword>private addresses</keyword>
<keyword>IPv4</keyword>

<abstract>

<t>
   
When a private network or internetwork grows very large it is sometimes
not possible to address all interfaces using private IPv4 address space
because there are not enough addresses. This document describes the problems 
faced by those networks, the available options and the issues involved in 
assigning a new block of private IPv4 address space.

</t>

<t>

While this informational document does not make a recommendation for action, it 
documents the issues surrounding the various options that have been considered.
 
</t>
   
</abstract>

</front>

<middle>

<section anchor="intro" title="Introduction">

<t>
      
<xref target="RFC1918"/> sets aside three blocks of IPv4 address space for
use in private networks: 192.168.0.0/16, 172.16.0.0/12 and 10.0.0.0/8. These
blocks can be used simultaneously in multiple, separately managed networks without
registration or coordination with IANA or any Internet registry. Very large 
networks can find that they need to connect more interfaces than the
number of addresses available in these three ranges.

It has occasionally been suggested that additional private IPv4 address space
should be reserved for use by these networks. Although such an action might address 
some of the needs for these very large network operators it is not without
consequences, particularly as we near the date when the IANA free pool
will be fully allocated.
   
</t>

</section>

<section title="Large Networks">

<t>
      
The main categories of very large networks using private address space are:  
cable operators, wireless (cell phone) operators, private internets and VPN 
service providers. In the case of the first two categories, the complete
address space reserved in <xref target="RFC1918"/> tends to be used by a single 
organization. In the case of private internets and VPN service providers there 
are multiple independently managed and operated networks and the difficulty is 
in avoiding address clashes.
      
</t>
   
</section>

<section title="Network Address Translation">

<t> 
   
The address space set aside in <xref target="RFC1918"/> is a finite resource which 
can be used to provide limited Internet access via Network Address 
Translation (NAT). A discussion of the advantages and disadvantages 
of NATs is outside the scope of this document. Nonetheless, it must 
be acknowledged that NAT is adequate in some situations and not in 
others. For instance, it is often technically feasible to use NAT 
or even multiple layers of NAT within the networks operated by 
residential users or corporations where peer to peer communication 
is not needed. Where peer to peer communication is needed or where 
services or applications do not work properly behind NAT, globally 
unique address space is required.

</t>
   
<t>
   
In many cases it is possible to use multiple layers of NAT to re-use
parts of the address space defined in <xref target="RFC1918"/>. In
particular, the tendency for low-cost CPEs to use 192.168.0.0/16 as
the default address range for the LAN allows providers to make 
full use of 172.16.0.0/12 and 10.0.0.0/8.
   
</t>   

</section>

<section title="Available Options">

<t>
   
When a network operator has exhausted the private address space set aside in <xref target="RFC1918"/>
but needs to continue operating a single routing domain a number of options are available.
These include:

</t>

<section title="Unique Globally Scoped IPv6 Unicast Addresses">
      
<t>

Using unique, globally scoped IPv6 unicast addresses is the preferred option
as it removes any concerns about address scarcity. In some cases implementing 
a new network protocol on a very large network takes more time than is available, 
based on network growth and the proportion of private space that has 
already been used. In these cases, there is a call for additional
private address space that can be shared by all network operators. 
<xref target="I-D.davies-reusable-ipv4-address-block"/> makes one such case.
      
</t>

</section>

<section title="Unique Locally Scoped IPv6 Unicast Addresses">

   <t>
      
Using the unique, locally scoped IPv6 unicast addresses defined in <xref target="RFC4193"/>
is another approach and does not require coordination with an Internet
registry. Although the addresses defined in <xref target="RFC4193"/> are probabilistically
unique, network operators on private internets and those providing VPN 
services might not want to use them because there is a very low 
probability of non-unique locally assigned global IDs being generated 
by the algorithm. Also, in the case of private internets, it can be
very challenging to coordinate the introduction of a new network
protocol to support the internet's continued growth.

   </t>

</section>

<section title="Address Transfers or Leases From Organizations with Available Address Space">
      
<t>

The Regional Internet Registry (RIR) communities have recently been developing
policies to allow organizations with available address space to transfer 
such designated space to other organizations <xref target="RIR-POLICY"/>.  In other cases,
leases might be arranged.  This approach is only viable for operators
of very large networks if enough address space is made available for
transfer or lease and if the very large networks are able to pay the costs of
these transfers.  It is not possible to know how much address space
will become available in this way, when it will be available and how
much it will cost.  For these reasons, address transfers will not be
an attractive proposition to many large network operators. Leases 
might not be attractive to some organizations if both parties 
cannot agree a suitable length of time. Also, the leasor might worry
about its own unanticipated needs for additional IPv4 address space.

</t>
      
</section>
   
<section title="Using Unannounced Address Space Allocated to Another Organization">
      
   <t>
         
Some network operators have considered using IP address space
which is allocated to another organizatiobn but is not publicly 
visible in BGP routing tables. This option is very strongly 
discouraged as the fact that an address block is not visible from 
one view does not mean that it is not visible from another. It 
is also possible that the registrant of the address block might 
want to increase its visibility to other networks in the future, 
causing problems for anyone using it unofficially. In some cases 
there might also be legal risks involved in using address space 
officially allocated to another organization.
         
   </t>
      
</section>

<section title="Unique IPv4 Space Registered by an RIR">
      
<t>
      
The policy framework shared by the RIRs does not discriminate based
on what an address is used to do, just on how efficiently the assigned
addresses are used. Unique IPv4 addresses registered by an RIR are
potentially available to organizations whose networks have used all
the addresses set aside in <xref target="RFC1918"/>. Nonetheless, 
network operators are naturally disinclined to request unique IPv4
addresses for a purpose that could be met with private addresses were
it not for the size of the network. Addresses assigned in this way are 
not available for anyone else to use and so their registration denies
them to new entrants, including potential customers.
      
</t>

</section>

</section>


<section title="Options and Consequences for Defining New Private Use Space">

<section title="Redefining Additional Unicast Space as Private Address Space">

<t>

It would be possible to re-designate a portion of the current global 
unicast IPv4 address space as private unicast address space. Doing 
this could benefit a number of operators of large network for the 
short period before they complete their IPv6 roll-out. However, this
benefit incurs a cost by reducing the pool of global unicast 
addresses available to end users.

</t>

<t>

When considering re-designating a portion of the current global 
unicast IPv4 address space as private unicast address space it is
important to consider how much space would be used and for how
long it would be sufficient. Not all of the large networks making
full use of the space defined in <xref target="RFC1918"/> would have their needs
met with a single /8. In 2005, <xref target="I-D.hain-1918bis"/> suggested 
reserving three /8s for this purpose while in 2009 <xref target="I-D.davies-reusable-ipv4-address-block"/> 
suggested a single /10 would be sufficient. There does not seem to be a 
consensus for a particular prefix length nor an agreed basis for 
deciding what is sufficient. The problem is exacerbated by the 
continually changing needs of ever expanding networks.
   
</t>

<t>
   
A further consideration is which of the currently unallocated
IPv4 unicast /8 blocks should be used for this purpose. Using
address space which is known to be used unofficially is tempting.
For instance, 1.0.0.0/8, which was unallocated until January 2010, was 
proposed in <xref target="I-D.hain-1918bis"/> and is known to be used by a 
number of different users. These include networks making use of HIP LSIs 
<xref target="RFC4423"/>, <xref target="WIANA"/>, <xref target="anoNet"/> and others. 
There is anecdotal <xref target="VEGODA"/> and research <xref target="WESSELS"/> evidence 
to suggest that several other IPv4 /8s are used in this fashion. Also there 
have been discussions <xref target="NANOG"/> about some sections of these /8's being 
carved out and filtered therefore unofficially enabling the use of these sections 
for private use.
   
</t>

<t>
      
Although new IPv4 /8s are allocated approximately once a month, they are not easy
to bring into use because network operators are slow to change their filter
configurations. This is despite long-running awareness campaigns <xref target="CYMRU"/>, <xref target="LEWIS"/> 
and active work <xref target="ripe-351"/> to notify people whose filters are not
changed in a timely fashion. Updating code that recognises private address space 
in deployed software and infrastructure systems is likely to be far more difficult 
as many systems have these ranges hard-coded and cannot be quickly changed with a
new configuration file.
      
</t>

</section>
      
<section title="Unique IPv4 Space Shared by a Group of Operators">
      
      <t>
         
         Where a group of networks find themselves in a position where they each
         need a large amount of IPv4 address space from an RIR in addition to that 
         defined in <xref target="RFC1918"/> they might cooperatively agree 
         to all use the same address space to number their networks. The
         clear benefit to this approach is that it significantly reduces the 
         potential demand on the pool of unallocated IPv4 address space.
         
      </t>
      
      <t>
         
         This approach has the potential to create an unofficial new private
         address range without proper scrutiny.
         
      </t>
      
</section>

<section title="Potential Consequences of Not Redefining Additional Unicast Space as Private Address Space">
      
<t>

If additional private address space is not defined and the large network operators
affected by this problem are not able to solve their problems with IPv6 address
space or by segmenting their networks into multiple routing domains, those networks
will need unique IPv4 addresses. It is possible and even likely that a single 
network could consume a whole IPv4 /8 in a year. At the time of writing there are
just 24 unallocated IPv4 /8s, so it would not take many such requests to make a major
dent in the available IPv4 address space. <xref target="POTAROO"/> provides an analysis of
IPv4 address consumption and projects the date on which the IANA and RIR pools will be 
fully allocated.
   
</t>      

</section>

<section title="Redefining Future Use Space as Unicast Address Space">
      
<t>

There have also been proposals to re-designate the former Class E space (240.0.0.0/4) as
unicast address space. <xref target="I-D.wilson-class-e"/> suggests that it should be 
privately scoped while <xref target="I-D.fuller-240space"/> does not propose a scope. 
Both proposals note that existing deployed equipment may not be able to use addresses 
from 240.0.0.0/4. Potential users would need to be sure of the status of the equipment 
on their network and the networks with which they intend to communicate.
      
</t>
   
<t>

It is not immediately clear how useful 240.0.0.0/4 could be in practice. While 
<xref target="I-D.fuller-240space"/> documents the status of several popular
desktop and server operating systems, the status of the most widely deployed 
routers and switches is less clear and it is possible that 240.0.0.0/4 might
only be useful in very large, new greenfield deployments where full control
of all deployed systems is available. However, in such cases it might well
be easier to deploy an IPv6 network.

</t>

</section>
   
</section>
   
<section title='Security Considerations'>

   <t>
      
This document has no security implications.
   
   </t>

</section>

<section title="IANA Considerations">

   <t>
   
This document makes no request of IANA.   
   
   </t>

</section>

</middle>
   
<back>

<references title="Normative References">

     <?rfc include="reference.RFC.1918.xml"?>
     <?rfc include="reference.RFC.2860.xml"?>
     <?rfc include="reference.RFC.4193.xml"?>

</references>

<references title="Informative References">
   
   <?rfc include="reference.RFC.4423.xml"?>
   <?rfc include="reference.I-D.davies-reusable-ipv4-address-block"?>
   <?rfc include="reference.I-D.fuller-240space"?>
   <?rfc include="reference.I-D.hain-1918bis"?>
   <?rfc include="reference.I-D.wilson-class-e"?>

   <reference anchor="anoNet" target="http://www.anonet.org/">
      <front>
         <title>anoNet: Cooperative Chaos</title>
         <author fullname="anoNET"><organization>anoNet</organization></author>
      </front>
   </reference>

   <reference anchor="CYMRU" target="http://www.team-cymru.org/Services/Bogons/">
      <front>
         <title>The Bogon Reference</title>
         <author initials='B.G.' surname='Greene' fullname='Barry Greene'/> <organization>Team Cymru, Inc.</organization>
      </front>
   </reference>

   <reference anchor="LEWIS" target="http://69box.atlantic.net/">
      <front>
         <title>This system has been setup for testing purposes for 69/8 address space</title>
         <author initials='J.L.' surname='Lewis' role='Senior Network Engineer' fullname='John Lewis'/> <organization>Atlantic.Net</organization>
      </front>
   </reference>

   <reference anchor="NANOG" target="http://mailman.nanog.org/pipermail/nanog/2010-January/017451.html">
      <front>
         <title>1/8 and 27/8 allocated to APNIC</title>
         <author initials='B.' surname='Dickson' fullname='Brian Dickson'/> <organization>Concertia Technologies Inc</organization>
      </front>
   </reference>
   
   <reference anchor="POTAROO" target="http://www.potaroo.net/tools/ipv4/index.html">
      <front>
         <title>IPv4 Address Report</title>
         <author initials='G.H.' surname='Huston' fullname='Geoff Huston'/> <organization>Geoff Huston</organization>
      </front>
   </reference>
   
   <reference anchor="ripe-351" target="http://www.ripe.net/ripe/docs/ripe-351.html">
      <front>
         <title>De-Bogonising New Address Blocks</title>
         <author initials='D.F.K.' surname='Karrenberg' role="Chief Scientist" fullname='Daniel Karrenberg'/> <organization>RIPE NCC</organization>
      </front>
   </reference>
   
   <reference anchor="RIR-POLICY" target="http://www.nro.net/documents/comp-pol-200910.html#1-3-2">
      <front>
         <title>RIR Comparative Policy Overview, October 2009, Section 1.3.2 Transfer of Custodianship</title>
         <author fullname="Number Resource Organization"><organization>Number Resource Organization</organization></author>
      </front>
   </reference>

   <reference anchor="VEGODA" target="http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_10-3/103_awkward.html">
      <front>
         <title>Awkward /8 Assignments</title>
         <author initials='L.V.' surname='Vegoda' role="Number Resources Manager" fullname='Leo Vegoda'/> <organization>ICANN</organization>
      </front>
   </reference>

   <reference anchor="WESSELS" target="https://www.dns-oarc.net/files/dnsops-2008/Wessels-Unused-space.pdf">
      <front>
         <title>Searching for Evidence of Unallocated Address Space Usage in DITL 2008 Data</title>
         <author initials='D.W.' surname='Wessels' role="" fullname='Duane Wessels'/> <organization>The Measurement Factory/CAIDA</organization>
      </front>
   </reference>

   <reference anchor="WIANA" target="http://www.wiana.org/">
      <front>
         <title>The Wireless Internet Assigned Numbers Authority</title>
         <author fullname="WIANA"><organization>WIANA</organization></author>
      </front>
   </reference>

</references>

<section title="Acknowledgments">

<t>
   
The authors would also like to thank Ron Bonica, Michelle Cotton,
Lee Howard and Barbara Roseman for their assistance in early 
discussions of this document.

</t>

</section>

</back>
</rfc>