[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 RFC 6319

Network Working Group                                         M. Azinger
Internet-Draft                                   Frontier Communications
Intended status: Informational                               Corporation
Expires: October 19, 2010                                      L. Vegoda
                                                                   ICANN
                                                          April 17, 2010


                  Additional Private IPv4 Space Issues
         draft-azinger-additional-private-ipv4-space-issues-04

Abstract

   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.

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

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on October 19, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Azinger & Vegoda        Expires October 19, 2010                [Page 1]


Internet-Draft           Additional Private IPv4              April 2010


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Large Networks . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Network Address Translation  . . . . . . . . . . . . . . . . .  3
   4.  Available Options  . . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  Unique Globally Scoped IPv6 Unicast Addresses  . . . . . .  4
     4.2.  Unique Local IPv6 Unicast Addresses  . . . . . . . . . . .  4
     4.3.  Address Transfers or Leases From Organizations with
           Available Address Space  . . . . . . . . . . . . . . . . .  4
     4.4.  Using Unannounced Address Space Allocated to Another
           Organization . . . . . . . . . . . . . . . . . . . . . . .  5
     4.5.  Unique IPv4 Space Registered by an RIR . . . . . . . . . .  5
   5.  Options and Consequences for Defining New Private Use Space  .  6
     5.1.  Redefining Existing Unicast Space as Private Address
           Space  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.2.  Unique IPv4 Space Shared by a Group of Operators . . . . .  7
     5.3.  Potential Consequences of Not Redefining Existing
           Unicast Space as Private Address Space . . . . . . . . . .  7
     5.4.  Redefining Future Use Space as Unicast Address Space . . .  7
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  8
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11















Azinger & Vegoda        Expires October 19, 2010                [Page 2]


Internet-Draft           Additional Private IPv4              April 2010


1.  Introduction

   [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.


2.  Large Networks

   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 [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.


3.  Network Address Translation

   The address space set aside in [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 true peer to peer communication is needed or where
   services or applications do not work properly behind NAT, globally
   unique address space is required.  In other cases, NAT traversal
   techniques facilitate peer-to-peer like communication for devices
   behind NATs.

   In many cases it is possible to use multiple layers of NAT to re-use
   parts of the address space defined in [RFC1918].  It is not always
   possible to rely on CPE devices using any particular range, however.
   In some cases this means that CPE devices can use unallocated address



Azinger & Vegoda        Expires October 19, 2010                [Page 3]


Internet-Draft           Additional Private IPv4              April 2010


   space or address space allocated to other network operators.  In
   other cases, organizations choose to operate multiple separate
   routing domains to allow them to re-use the same private address
   ranges in multiple contexts.  One consequence of this is the added
   complexity involved in identifying which system is referred to when
   an IP address is identified in a log or management systems.

   Another option is to share one address across multiple interfaces and
   in some cases, subscribers.  This model breaks the classical model
   used for logging address assignments and creates some risks
   [CLAYTON].  This concept is more fully explored in [FORD].


4.  Available Options

   When a network operator has exhausted the private address space set
   aside in [RFC1918] but needs to continue operating a single routing
   domain a number of options are available.  These include:

4.1.  Unique Globally Scoped IPv6 Unicast Addresses

   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.  [DAVIES] makes one such case.

4.2.  Unique Local IPv6 Unicast Addresses

   Using the unique, local IPv6 unicast addresses defined in [RFC4193]
   is another approach and does not require coordination with an
   Internet registry.  Although the addresses defined in [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.

4.3.  Address Transfers or Leases From Organizations with Available
      Address Space

   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
   [Section 1.3.2 Transfer of Custodianship"">RIR-POLICY].  In other cases, leases might be arranged.  This



Azinger & Vegoda        Expires October 19, 2010                [Page 4]


Internet-Draft           Additional Private IPv4              April 2010


   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.  However, it is unlikely to become available in large
   contiguous blocks and this would add to the network managment burden
   for the operator.  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 lessor might worry about
   its own unanticipated needs for additional IPv4 address space.

4.4.  Using Unannounced Address Space Allocated to Another Organization

   Some network operators have considered using IP address space which
   is allocated to another organization 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.  Furthermore, address usage
   tends to leak beyond private network borders in e-mail headers, DNS
   queries, traceroute output and other ways.  The ambiguity this causes
   is problematic for multiple organizations.  This issue is addressed
   in [RFC3879], section 2.3.

   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.

   Where this has happened in the past it has caused operational
   problems [FASTWEB].

4.5.  Unique IPv4 Space Registered by an RIR

   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 [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 because 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.

   It is likely to become more difficult for network operators to obtain



Azinger & Vegoda        Expires October 19, 2010                [Page 5]


Internet-Draft           Additional Private IPv4              April 2010


   large blocks of unique address space as we approach the point where
   all IPv4 unicast /8s have been allocated.  Several RIRs already have
   policies how to allocate from their last /8 [RIR-POLICY-FINAL-8] and
   there have been policy discussions that would reduce the maximum
   allocation size available to network operators [MAX-ALLOC] or would
   reduce the period of need for which the RIR can allocate
   [SHORTER-PERIODS].


5.  Options and Consequences for Defining New Private Use Space

5.1.  Redefining Existing Unicast Space as Private Address Space

   It is 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 users in general.

   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 [RFC1918] would have their needs met with
   a single /8.  In 2005, [HAIN] suggested reserving three /8s for this
   purpose while in 2009 [DAVIES] 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.

   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 [HAIN] and is known to be used by a number of different
   users.  These include networks making use of HIP LSIs [RFC4423],
   [WIANA], [anoNet] and others.  There is anecdotal [VEGODA] and
   research [WESSELS] evidence to suggest that several other IPv4 /8s
   are used in this fashion.  Also there have been discussions [NANOG]
   about some sections of these /8's being carved out and filtered
   therefore unofficially enabling the use of these sections for private
   use.

   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



Azinger & Vegoda        Expires October 19, 2010                [Page 6]


Internet-Draft           Additional Private IPv4              April 2010


   awareness campaigns [CYMRU], [LEWIS] and active work [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.

   Another consideration when redefining existing unicast space as
   private address space is that no single class of user can expect the
   space to stay unique to them.  This means that an ISP using a new
   private address range cannot expect its customers not to already be
   using that address range within their own networks.

5.2.  Unique IPv4 Space Shared by a Group of Operators

   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 [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.
   However, the issues discussed in 4.4 could also be of concern here,
   particularly the possibility that one operator might decide to use
   the address space to number customer connections, rather than private
   infrastructure.

   Nonetheless, this approach has the potential to create an unofficial
   new private address range without proper scrutiny.

5.3.  Potential Consequences of Not Redefining Existing Unicast Space as
      Private Address Space

   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.  [POTAROO] provides an analysis of IPv4 address consumption
   and projects the date on which the IANA and RIR pools will be fully
   allocated.

5.4.  Redefining Future Use Space as Unicast Address Space

   There have also been proposals to re-designate the former Class E
   space (240.0.0.0/4) as unicast address space.  [WILSON] suggests that



Azinger & Vegoda        Expires October 19, 2010                [Page 7]


Internet-Draft           Additional Private IPv4              April 2010


   it should be privately scoped while [FULLER] 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.

   It is not immediately clear how useful 240.0.0.0/4 could be in
   practice.  While [FULLER] 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 green field
   deployments where full control of all deployed systems is available.
   However, in such cases it might well be easier to deploy an IPv6
   network.


6.  Security Considerations

   This document has no security implications.


7.  IANA Considerations

   This document makes no request of IANA.


8.  References

8.1.  Normative References

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC2860]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
              Understanding Concerning the Technical Work of the
              Internet Assigned Numbers Authority", RFC 2860, June 2000.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

8.2.  Informative References

   [RFC3879]  Huitema, C. and B. Carpenter, "Deprecating Site Local
              Addresses", RFC 3879, September 2004.

   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", RFC 4423, May 2006.



Azinger & Vegoda        Expires October 19, 2010                [Page 8]


Internet-Draft           Additional Private IPv4              April 2010


   [anoNet]   anoNet, "anoNet: Cooperative Chaos",
              <http://www.anonet.org/>.

   [CLAYTON]  Clayton, R., "Practical mobile Internet access
              traceability", January 2010, <http://
              www.lightbluetouchpaper.org/2010/01/13/
              practical-mobile-internet-access-traceability/>.

   [CYMRU]    Greene, B., "The Bogon Reference",
              <http://www.team-cymru.org/Services/Bogons/>.

   [DAVIES]   Davies, G. and C. Liljenstolpe, "Transitional non-
              conflicting reusable IPv4 address block", November 2009, <
              http://tools.ietf.org/html/
              draft-davies-reusable-ipv4-address-block-00>.

   [FASTWEB]  Aina, A., "41/8 announcement", May 2006,
              <http://www.afnog.org/archives/2006-May/002117.html>.

   [FORD]     Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing", March 2010, <ht
              tp://tools.ietf.org/html/
              draft-ford-shared-addressing-issues-02>.

   [FULLER]   Fuller, V., Lear, E., and D. Meyer, "Reclassifying 240/4
              as usable unicast address space", March 2008,
              <http://tools.ietf.org/html/draft-fuller-240space-02>.

   [HAIN]     Hain, T., "Expanded Address Allocation for Private
              Internets", January 2005,
              <http://tools.ietf.org/html/draft-hain-1918bis-01>.

   [LEWIS]    Lewis, J., "This system has been setup for testing
              purposes for 69/8 address space", March 2003,
              <http://69box.atlantic.net/>.

   [MAX-ALLOC]
              Spenceley, J. and J. Martin, "prop-070: Maximum IPv4
              allocation size", January 2009,
              <http://www.apnic.net/policy/proposals/prop-070>.

   [NANOG]    Dickson, B., "1/8 and 27/8 allocated to APNIC",
              January 2010, <http://mailman.nanog.org/pipermail/nanog/
              2010-January/017451.html>.

   [POTAROO]  Huston, G., "IPv4 Address Report",
              <http://www.potaroo.net/tools/ipv4/index.html>.




Azinger & Vegoda        Expires October 19, 2010                [Page 9]


Internet-Draft           Additional Private IPv4              April 2010


   [ripe-351]
              Karrenberg, D., "De-Bogonising New Address Blocks",
              October 2005,
              <http://www.ripe.net/ripe/docs/ripe-351.html>.

   [RIR-POLICY]
              Number Resource Organization, "RIR Comparative Policy
              Overview, October 2009, Section 1.3.2 Transfer of
              Custodianship",
              <http://www.nro.net/documents/comp-pol-200910.html#1-3-2>.

   [RIR-POLICY-FINAL-8]
              Number Resource Organization, "RIR Comparative Policy
              Overview, October 2009, 2.6. Use of Final Unallocated IPv4
              Address Space", October 2009,
              <http://www.nro.net/documents/comp-pol-200910.html#2-6>.

   [SHORTER-PERIODS]
              Karrenberg, D., O'Reilly, N., Titley, N., and R. Bush,
              "RIPE Policy Proposal 2009-03", April 2009,
              <http://www.ripe.net/ripe/policies/proposals/
              2009-03.html>.

   [VEGODA]   Vegoda, L., "Awkward /8 Assignments", September 2007, <htt
              p://www.cisco.com/web/about/ac123/ac147/archived_issues/
              ipj_10-3/103_awkward.html>.

   [WESSELS]  Wessels, D., "Searching for Evidence of Unallocated
              Address Space Usage in DITL 2008 Data", June 2008, <https:
              //www.dns-oarc.net/files/dnsops-2008/
              Wessels-Unused-space.pdf>.

   [WIANA]    WIANA, "The Wireless Internet Assigned Numbers Authority",
              <http://www.wiana.org/>.

   [WILSON]   Wilson, P., Michaelson, G., and G. Huston, "Redesignation
              of 240/4 from "Future Use" to "Private Use"",
              <http://tools.ietf.org/html/draft-wilson-class-e-02>.


Appendix A.  Acknowledgments

   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 and to Alex Bligh, Maria Blackmore, Ricardo Patara
   and Mat Ford for improvement suggestions.





Azinger & Vegoda        Expires October 19, 2010               [Page 10]


Internet-Draft           Additional Private IPv4              April 2010


Authors' Addresses

   Marla Azinger
   Frontier Communications Corporation
   Vancouver, WA
   United States of America

   Email: marla.azinger@frontiercorp.com
   URI:   http://www.frontiercorp.com/


   Leo Vegoda
   Internet Corporation for Assigned Names and Numbers
   4676 Admiralty Way, Suite 330
   Marina del Rey, CA  90292
   United States of America

   Phone: +1-310-823-9358
   Email: leo.vegoda@icann.org
   URI:   http://www.iana.org/































Azinger & Vegoda        Expires October 19, 2010               [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/