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

Versions: 00 01 02 draft-ietf-intarea-shared-addressing-issues

Internet Engineering Task Force                                A. Durand
Internet-Draft                                                   Comcast
Intended status: Informational                                   M. Ford
Expires: September 4, 2009                                    P. Roberts
                                                        Internet Society
                                                           March 3, 2009


          Issues with ISP Responses to IPv4 Address Exhaustion
                 draft-ford-shared-addressing-issues-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 September 4, 2009.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   The looming completion of IPv4 address allocations from IANA and the



Durand, et al.          Expires September 4, 2009               [Page 1]


Internet-Draft      ISP Responses to IPv4 Exhaustion          March 2009


   RIRs is already causing ISPs around the world to start to question
   how they will continue providing IPv4 service to IPv4-speaking
   customers when there are no longer sufficient IPv4 addresses to
   allocate them one per customer.  Several possible solutions to this
   problem are now emerging and this memo identifies important criteria
   to be borne in mind when evaluating these solutions.  We also seek to
   identify serious issues that remain even when mechanisms meeting our
   criteria are adopted.  We wish to stress that these solutions have a
   number of common, and potentially serious, issues.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Guiding principles . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  IPv6 is the goal . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Criteria for judging ISP responses . . . . . . . . . . . .  4
     2.3.  Potential responses  . . . . . . . . . . . . . . . . . . .  4
       2.3.1.  Obtaining previously-allocated addresses . . . . . . .  5
       2.3.2.  Deploy CGN, allocate private addresses . . . . . . . .  5
       2.3.3.  Shared address solutions . . . . . . . . . . . . . . .  6
   3.  Issues with shared address solutions . . . . . . . . . . . . .  6
     3.1.  Port Distribution, Port Reservation, Port Negotiation  . .  7
     3.2.  Connection to a Well-Known Port Number . . . . . . . . . .  8
     3.3.  Universal Plug and Play  . . . . . . . . . . . . . . . . .  8
     3.4.  Security and Subscriber Identification with IPv4 . . . . .  8
   4.  Concluding remarks . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11



















Durand, et al.          Expires September 4, 2009               [Page 2]


Internet-Draft      ISP Responses to IPv4 Exhaustion          March 2009


1.  Introduction

   Allocations of IPv4 addresses from the Internet Assigned Numbers
   Authority (IANA) are currently forecast to be complete during the
   first half of 2011 [IPv4_Report].  Allocations from the Regional
   Internet Registries (RIRs) are anticipated to be complete around a
   year later, although the exact date will vary from registry to
   registry.  This is already causing ISPs around the world to start to
   question how they will continue providing IPv4 service to IPv4-
   speaking customers when there are no longer sufficient IPv4 addresses
   to allocate them one per customer.  Several possible solutions to
   this problem are now emerging and the following discussion identifies
   important criteria to be borne in mind when evaluating the merits and
   demerits of these solutions.  These criteria are derived from the
   development and acceptance of a modern understanding and consistent
   implementation of the end-to-end principle of the Internet.

   This memo is divided into two principal sections.  The first deals
   with what we consider to be guiding principles that it is important
   to bear in mind when evaluating address-sharing proposals.  The
   second section is concerned with identifying and discussing the
   operational implications of adopting any address-sharing mechanism.
   We wish to stress that these solutions have a number of common, and
   potentially serious, issues.  Address sharing amongst multiple
   subscribers will inevitably result in a degraded experience of the
   network for many users, and increased operating costs for ISPs.
   Content providers are encouraged to consider carefully the potential
   impact of shared-addressing on their business and operational
   practices.


2.  Guiding principles

   "The end-to-end principle is the core architectural guideline of the
   Internet."  Section 2 of RFC 3724 [RFC3724] provides a concise
   history of the end-to-end principle.  While the original articulation
   was concerned with where best to place functionality in a
   communication system, the growth and development of the Internet has
   resulted in an expansion of the scope of the end-to-end principle so
   that it now encompasses the question of where best to locate the
   state associated with Internet applications.  This expanded principle
   is well-articulated in RFC 1958 [RFC1958],

             "An end-to-end protocol design should not rely on the
             maintenance of state (i.e., information about the state of
             the end-to-end communication) inside the network.  Such
             state should be maintained only in the endpoints, in such a
             way that the state can only be destroyed when the endpoint



Durand, et al.          Expires September 4, 2009               [Page 3]


Internet-Draft      ISP Responses to IPv4 Exhaustion          March 2009


             itself breaks (known as fate-sharing)."

   The end-to-end principle is arguably the fundamental principle of the
   Internet architecture.  In a sense the Internet is the embodiment of
   the principle.  By allowing either tacit or explicit erosion of the
   principle as we apply our understanding to the construction and
   operation of the global network, we allow the dismantling of the
   utility itself.  Unfortunately the approaches being proposed to
   address the looming IPv4 address shortage threaten just such erosion.

2.1.  IPv6 is the goal

   While we are discussing solutions to allow continued operation of the
   IPv4 Internet and the continued provision of services to IPv4-
   speaking customers, it is absolutely not the intention of this
   discussion to in any way advocate the prolongation of the life of
   IPv4 or to (further) delay the widespread adoption of IPv6.  Rather,
   the discussion herein is intended to guide reactions to proposals
   that are being made as a pragmatic response to some very real
   problems looming for operators who need to be able to continue
   providing service to customers who do not have any IPv6 capable
   equipment and/or who want to access services that are only available
   via IPv4.

2.2.  Criteria for judging ISP responses

   On that basis, we believe that solutions to the problem of continuing
   to provide IPv4 service post-IPv4-address-completion should be judged
   on two primary criteria:

           1) The proximity of the end user to control over the impact
           of the solution on the end-to-end communication, and;

           2) The extent to which the solution affords a natural
           progression to widespread IPv6 deployment.

2.3.  Potential responses

   Assuming ISPs wish to continue growing their businesses post-IPv4-
   address-completion there are a number of possible responses they can
   take:

           o Obtain previously-allocated IPv4 addresses through some
           unspecified means







Durand, et al.          Expires September 4, 2009               [Page 4]


Internet-Draft      ISP Responses to IPv4 Exhaustion          March 2009


           o Deploy CGN and allocate customers with private addresses

           o Deploy a shared-address solution - customers get public
           addresses with fewer available ports

   Let's deal with each of these in turn.

2.3.1.  Obtaining previously-allocated addresses

   Acquisition of previously-allocated IPv4 addresses by whatever means
   is a strategy with currently unknown (but definitely limited)
   viability.  It is also impossible to estimate in advance the cost of
   such an approach, so it does nothing to minimise business risk.
   Acquiring previously-allocated addresses may provide a short-term
   tactical solution where a relatively small number of addresses are
   required urgently to address a specific need.  It cannot be a
   solution for long-term network business growth.  It is likely that
   previously-allocated blocks acquired by whatever means will be small
   and obtaining lots of contiguous small blocks may be impossible.
   This would inevitably lead to operational complexity and associated
   cost for the network taking this approach.  It is operationally
   unsustainable in anything but the short term.

2.3.2.  Deploy CGN, allocate private addresses

   In light of the two criteria for judging solutions to the address
   allocation completion problem that we identified above, so-called
   'carrier-grade' NAT (CGN) proposals [I-D.nishitani-cgn] raise several
   issues.  Centralisation of NAT functionality in the network core will
   reduce the ability of end-users to deploy applications as they wish
   without reference to the network operator.  This means that unadorned
   CGN solutions will struggle to meet the first criterion.  Providing
   mechanisms for end-users to control their treatment by the CGN may go
   some way to mitigate this concern, however those mechanisms would
   need to be very carefully engineered to avoid raising additional
   scalability and resilience concerns of their own.  CGNs may create a
   single point of failure for all their clients and decrease the
   resilience of the network from an end-user's perspective.  CGN
   implementations may also struggle when considering our second
   criterion as there is no requirement to make use of IPv6 technology
   as part of the solution.  For these reasons there is a real risk that
   CGNs will do nothing to progress the state of IPv6 deployment and
   will only serve to degrade the utility of the current network.

   While the subject of CGN deployment has arisen recently in the
   context of IPv4 address depletion, some operators, particularly
   mobile network operators, have a long history of allocating private
   addresses to their subscribers.  Recent discussions have indicated



Durand, et al.          Expires September 4, 2009               [Page 5]


Internet-Draft      ISP Responses to IPv4 Exhaustion          March 2009


   that the increasing sophistication of both mobile handsets and the
   applications that run on them is driving operators of mobile networks
   towards public addressing solutions, including IPv6 deployment, to
   improve scalability and minimise operating expenses.  This suggests
   that those operators with real-world experience of CGN technology are
   already choosing to migrate away from it as a solution to their
   addressing needs.

2.3.3.  Shared address solutions

   How could we do better?  There are proposals currently in the IETF
   that address one or both of the criteria we identify as critical.
   These alternative proposals are simplified by using IPv6 as a
   transport substrate for the legacy traffic
   [I-D.durand-softwire-dual-stack-lite], thereby motivating IPv6
   deployment, and may also ensure that control over the fate of end-
   user applications is kept as close to the end-user as possible by
   distributing the NAT functionality towards the CPE [I-D.ymbk-aplusp].

   However, some reduction of utility for IPv4-speaking Internet users
   is unavoidable in the future.  It is inevitable that a reduced number
   of ports will be available for individual end-user applications.
   Running servers on well-known ports will most probably be an activity
   that is restricted to users willing to pay a premium for a higher
   tier of service contract.  These may turn out to be good incentives
   for end-users to migrate to IPv6.

   The remainder of this memo deals with issues that arise when shared
   address solutions are deployed by ISPs.


3.  Issues with shared address solutions

   A number of proposals currently under consideration for
   standardization or contribution to some future standard rely upon the
   concept of address sharing across multiple subscribers to achieve
   their goals.  These proposals include Carrier Grade NAT
   [I-D.nishitani-cgn], Dual-Stack-Lite
   [I-D.durand-softwire-dual-stack-lite], NAT64
   [I-D.bagnulo-behave-nat64], IVI [I-D.baker-behave-ivi], Address+Port
   proposals [I-D.ymbk-aplusp], and SAM [I-D.despres-sam].

   In many operator networks today a subscriber receives a single public
   IPv4 address at their home or small business.  Within that home or
   small business there is a NAT function that issues private addresses
   (RFC1918 addresses) to devices within the home.  All of those devices
   share the single public IPv4 address and they are all associated with
   a single small set of users, and a single operator subscriber



Durand, et al.          Expires September 4, 2009               [Page 6]


Internet-Draft      ISP Responses to IPv4 Exhaustion          March 2009


   account.

   With these new proposals a single public IPv4 address would be shared
   by a number of homes or small businesses (i.e. multiple subscribers)
   so the operational paradigm described above would no longer apply.

   All the proposals listed above share a number of technical or
   operational issues and these are addressed in the subsections that
   follow.

3.1.  Port Distribution, Port Reservation, Port Negotiation

   When we talk about port numbers we need to make a distinction between
   outgoing connections and incoming connections.  For outgoing
   connections, the actual source port number used is usually
   irrelevant.  But for incoming connections, the specific port numbers
   allocated to customers matter because they are part of external
   referrals (used by third parties to contact services run by the
   customers).  It is desirable to make sure those incoming ports remain
   stable over time.  This is challenging as the network doesn't know
   anything in particular about the applications which it is supporting
   and therefore has no real notion of how long an application/service
   session is still ongoing and therefore requiring port stability.

   According to actual measurements the average number of outgoing ports
   per customer is much, much smaller than the maximum number of ports a
   customer can use at any given time.  However, the distribution is
   heavy-tailed, so there are typically a small number of subscribers
   who use a very high number of ports [CGN_Viability].  This means that
   an algorithm that dynamically allocates outgoing port numbers from a
   central pool is much more efficient than algorithms that statically
   divide the resource by pre-allocating a fixed number of ports to each
   subscriber.  Similarly, such an algorithm should be more able to
   accommodate users wishing to use a relatively high number of ports.

   Early measurements also seem to indicate that, on average, only very
   few ports are used by customers for incoming connections.  However, a
   majority of subscribers accept at least one inbound connection.

   This means that it is not necessary to pre-allocate a large number of
   ports to each subscriber, but that it is possible to either pre-
   allocate a small number of ports for incoming connections or do port
   allocation on demand when the application wishing to receive a
   connection is initiated and reserve the bulk of ports as a
   centralized resource shared by all subscribers using a given public
   IPv4 address.

   A potential problem with this approach occurs when one of the



Durand, et al.          Expires September 4, 2009               [Page 7]


Internet-Draft      ISP Responses to IPv4 Exhaustion          March 2009


   subscriber devices behind such a port-shared IPv4 address becomes
   infected with a worm, which then quickly sets about opening many
   outbound connections in order to propagate itself.  Such an infection
   could rapidly exhaust the shared resource of the single IPv4 address
   for all connected subscribers.  Poor network hygiene of one
   subscriber now threatens the connectivity for all immediate network
   neighbors.

3.2.  Connection to a Well-Known Port Number

   Once a port address-mapping scheme is in place, connections to well-
   known port numbers will not work in the general case.  Some
   workaround (e.g. redirects to a port-specific URL) could always be
   deployed given sufficient incentives.  There exist several proposals
   for 'application service location' protocols which would provide a
   means of addressing this problem, but historically these proposals
   have not gained much deployment traction.

3.3.  Universal Plug and Play

   Using the UPnP semantic, a client is asking "I want to use port
   number X, is that ok?" and the answer is yes or no.  If the answer is
   no, the client will typically try the next port, until it either
   finds one that works or gives up after a limited number of attempts.
   UPnP has, currently, no way to redirect the client to use another
   port number.

   NAT-PMP has a better semantic here, enabling the NAT to redirect the
   client to an available port number.

3.4.  Security and Subscriber Identification with IPv4

   When an abuse is reported today, it is usually done in the form: IPv4
   address X has done something bad at time T0.  This is not enough
   information to uniquely identify the subscriber responsible for the
   abuse when that IPv4 address is shared by more than one subscriber.
   This particular issue can be fixed by logging port numbers.

   A number of application servers on the network today log IPv4
   addresses in connection attempts to protect themselves from certain
   attacks.  For example, if a server sees too many login attempts from
   the same IPv4 address, it may decide to put that address in a penalty
   box for a certain time.  If an IPv4 address is shared by multiple
   subscribers, this would have unintended consequences in a couple of
   ways.  First it may become the natural behavior to see many login
   attempts from the same address because it is now shared across a
   potentially large number of users.  Second and more likely is that
   one user who fails a number of login attempts may block out other



Durand, et al.          Expires September 4, 2009               [Page 8]


Internet-Draft      ISP Responses to IPv4 Exhaustion          March 2009


   users who have not made any previous attempts but who will now fail
   on their first attempt.

   Moreover, the assumption that a single IPv4 address maps to a single
   user may be used for other purposes like geolocation, counting the
   number of individual users of a service, etc.  All those things may
   become more complicated when an IPv4 address is shared by several
   subscribers at the same time.

   To some extent these problems of shared addressing are already with
   us due to the prevalence of dyamically assigned addresses to domestic
   broadband subscribers and the use of CPE NAT, but the point we wish
   to make here is that the widespread adoption of port-shared addresses
   by service providers will make these complications considerably more
   widespread and severe.


4.  Concluding remarks

   Of the various options that are now available to service providers as
   we approach the completion of IPv4 address allocations from the IANA,
   there are some shared-address solutions that seem to offer an
   approach consistent with a long-term goal of IPv6 deployment and
   maximal preservation of the end-to-end principle.  Nevertheless, it
   must be stressed that these solutions have a number of common, and
   potentially serious, issues.  Address sharing amongst multiple
   subscribers will inevitably result in a degraded experience of the
   network for many users, and increased operating costs for ISPs.
   Content providers are encouraged to consider carefully the potential
   impact of shared-addressing on their business and operational
   practices.


5.  Acknowledgements

   This memo was largely inspired by conversations that took place as
   part of an Internet Society hosted roundtable event for operators
   deploying IPv6.  Participants in that discussion included John
   Brzozowski, Leslie Daigle, Tom Klieber, Yiu Lee, Kurtis Lindqvist,
   Wes George, and Christian Jacquenet.


6.  IANA Considerations

   This memo includes no request to IANA.






Durand, et al.          Expires September 4, 2009               [Page 9]


Internet-Draft      ISP Responses to IPv4 Exhaustion          March 2009


7.  Security Considerations

   Section 3.4 discusses some of the security and identity-related
   implications of address sharing.


8.  Informative References

   [CGN_Viability]
              Alcock, S., "Research into the Viability of Service-
              Provider NAT", 2008.

   [I-D.bagnulo-behave-nat64]
              Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
              Address and Protocol Translation from IPv6 Clients to IPv4
              Servers", draft-bagnulo-behave-nat64-02 (work in
              progress), November 2008.

   [I-D.baker-behave-ivi]
              Li, X., Bao, C., Baker, F., and K. Yin, "IVI Update to
              SIIT and NAT-PT", draft-baker-behave-ivi-01 (work in
              progress), September 2008.

   [I-D.despres-sam]
              Despres, R., "Stateless Address Mappings (SAMs) IPv6 &
              extended IPv4 via local routing  domains - possibly
              multihomed", draft-despres-sam-01 (work in progress),
              November 2008.

   [I-D.durand-softwire-dual-stack-lite]
              Durand, A., Droms, R., Haberman, B., and J. Woodyatt,
              "Dual-stack lite broadband deployments post IPv4
              exhaustion", draft-durand-softwire-dual-stack-lite-01
              (work in progress), November 2008.

   [I-D.nishitani-cgn]
              Nishitani, T., Miyakawa, S., Nakagawa, A., and H. Ashida,
              "Common Functions of Large Scale NAT (LSN)",
              draft-nishitani-cgn-01 (work in progress), November 2008.

   [I-D.ymbk-aplusp]
              Maennel, O., Bush, R., Cittadini, L., and S. Bellovin,
              "The A+P Approach to the IPv4 Address Shortage",
              draft-ymbk-aplusp-02 (work in progress), January 2009.

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



Durand, et al.          Expires September 4, 2009              [Page 10]


Internet-Draft      ISP Responses to IPv4 Exhaustion          March 2009


   [RFC1958]  Carpenter, B., "Architectural Principles of the Internet",
              RFC 1958, June 1996.

   [RFC3724]  Kempf, J., Austein, R., and IAB, "The Rise of the Middle
              and the Future of End-to-End: Reflections on the Evolution
              of the Internet Architecture", RFC 3724, March 2004.


Authors' Addresses

   Alain Durand
   Comcast

   Email: Alain_Durand@cable.comcast.com


   Mat Ford
   Internet Society
   Geneva
   Switzerland

   Email: ford@isoc.org


   Phil Roberts
   Internet Society
   Reston, VA
   USA

   Email: roberts@isoc.org





















Durand, et al.          Expires September 4, 2009              [Page 11]


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