Internet Engineering Task Force                                 A. Ripke
Internet-Draft                                                J. Quittek
Intended status: Informational                                M. Brunner
Expires: September 9, 2010                       NEC Laboratories Europe
                                                           March 8, 2010


         Dynamic Port Range Re-Assignments for Address Sharing
                    draft-rqb-dynamic-port-ranges-02

Abstract

   This document describes and extension of the port range assignment
   mechanisms used for the IPv4 address sharing framework (SHARA) that
   is based on port range routing.  The extension provides means for
   dynamically changes port range assignments by allowing clients to
   smoothly migrate to a new port range before releasing the range that
   is currently in use.  This way, the number of ports per client can be
   adjusted to actual usage patterns.

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 9, 2010.

Copyright Notice

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




Ripke, et al.           Expires September 9, 2010               [Page 1]


Internet-Draft             Dynamic Port Ranges                March 2010


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (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 BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Dynamic port range re-assignments  . . . . . . . . . . . . . .  4
     2.1.  Detecting the change point . . . . . . . . . . . . . . . .  5
   3.  Usage scenario . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Initialization . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Detecting the change point . . . . . . . . . . . . . . . .  7
     3.3.  Assigning a new port range . . . . . . . . . . . . . . . .  7
     3.4.  Ongoing port consumption . . . . . . . . . . . . . . . . .  7
     3.5.  Final de-allocation of a port range  . . . . . . . . . . .  7
   4.  Signaling  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Fragmentation  . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Port Range Swapping  . . . . . . . . . . . . . . . . . . . . .  8
   7.  Service Management . . . . . . . . . . . . . . . . . . . . . .  8
     7.1.  Server policy  . . . . . . . . . . . . . . . . . . . . . .  8
     7.2.  Client policy  . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Open issues  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   12. Informative References . . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

















Ripke, et al.           Expires September 9, 2010               [Page 2]


Internet-Draft             Dynamic Port Ranges                March 2010


1.  Introduction

   The IETF is discussing a scheme for enlarging the usable IP address
   space in [I-D.ymbk-aplusp] or [I-D.boucadair-port-range] using parts
   of the port numbers, similar to what Network Address Translators
   (NAT) do.  This allows to assign the same IP address to several
   customers or hosts.  The IP address together with the port bits
   extension differentiate the routing and forwarding of that
   communication.

   A port range router (PRR) manages one or several IPv4 addresses that
   are to be shared among several port range clients (PRC).  Each PRC
   gets a portion of one IPv4 address whereas this portion is defined by
   one or several port ranges that are assigned exclusively to a PRC.
   The PRR and the PRC can, for example, be a Broadband Remote Access
   Server (BRAS) and a Home Gateway (HGW), respectively.  Alternatively,
   the client can be a home router, a single host, or the gateway of a
   large enterprise, A schematic sketch of sharing two non-overlapping
   port ranges is illustrated by the following figure:


                                      +-------+
       [o..p]            assign PR    |       |
       +---------+--------------------+ PRAS  |
       |         |                    |       |
       |         |                    +-------+
       |         |[m..n]                  |
       |         |                        | configure PRR
       |         v                        v
       |     +-------+                +-------+
       |     |       |                |       |
       |     |  PRC  +----------------+       |
       |     |       |  A.B.C.D:m..n  |       |          |
       |     +-------+                |       |  A.B.C.D |
       v                              |  PRR  +----------+ IPv4 Internet
   +-------+                          |       |          |
   |       |            A.B.C.D:o..p  |       |          |
   |  PRC  +--------------------------+       |
   |       |                          |       |
   +-------+                          +-------+

    A PRAS assigns two different non-overlapping port ranges [m..n] and
              [o..p] of an IPv4 address A.B.C.D to two PRCs.

                                 Figure 1

   DHCP extensions [I-D.boucadair-dhc-port-range] and PPP extensions
   [I-D.boucadair-pppext-portrange-option] that can be used by a Port



Ripke, et al.           Expires September 9, 2010               [Page 3]


Internet-Draft             Dynamic Port Ranges                March 2010


   Range Assignment Server (PRAS) to assign IP addresses and port ranges
   to a PRC have already been proposed.  However, since the deployments
   are very different for different users, customers with several users
   etc., further means for managing port assignments appear to be
   required.  Measurements showed that different clients need different
   range sizes at different times [flow-counting].

   This implies that dynamic port range assignment is needed for

   o  assigning clients larger port ranges when the current one becomes
      too small,

   o  assigning clients smaller port ranges, when the current ones are
      underused,

   o  changing clients port ranges for reducing fragmentation of the
      port space,

   o  balancing port consumption for a shared IPv4 address.

   The existing means are sufficient to assign and re-assign port ranges
   (both contiguous and non-contiguous ones).  However, a PRC cannot
   immediately switch from one port range to another one, because most
   applications cannot change port numbers while using them.  Without
   interrupting existing connections, a PRC can only start allocating
   new ports in a new range and wait until ports in an old range are not
   used anymore.  Consequently, a PRC needs to wait until applications
   have closed all ports in the old port range.  Existing means allow to
   assign more than one port ranges to a PRC
   ([I-D.boucadair-port-range]), but not to identify one or more ranges
   that should not be used anymore by the PRC.


2.  Dynamic port range re-assignments

   This draft proposal provides a way for a Port Range Assignment Server
   (PRAS) to tag a port range with an attribute that signals the PRC not
   to allocate any more ports in this range.  Such a signal can be sent
   when a server signals more than one port range to a PRC.  A most
   simple implementation would be adding a flag to one or more port
   ranges during the (re-)assignment process that marks these ranges as
   not to be used anymore.  A PRC receiving the signal would then stop
   allocating port numbers in the marked ranges.  When the PRC does not
   use an address range anymore, it signals back that the port range is
   not in use anymore and can be re-assigned.  This can be done
   individually for each range as soon as it is not used anymore or at
   once when all marked ranges are not used anymore.




Ripke, et al.           Expires September 9, 2010               [Page 4]


Internet-Draft             Dynamic Port Ranges                March 2010


   The method can also be used for reducing (trimming) already assigned
   port ranges.  For this purpose, the PRAS divides the single port
   range into two or more consecutive port ranges and re-assigns the
   single port range as a set of port ranges to the PRC with one or more
   of the port ranges marked as not to be used anymore.  Again, the PRC
   would signal back that one or more ranges are not used anymore.

   This new technique allows to postpone the de-allocation of port
   ranges until the respective ports are closed (lazy de-allocation).
   The PRC has the possibility to actively confirm the release of port
   ranges.

2.1.  Detecting the change point

   While the PRC is using the port range, several reasons may occur that
   make it desirable to change the port assignment.

   o  The PRC may observe that there are only few unused numbers left in
      the used range and that it may soon happen that no further ports
      would be available for requesting applications.  In order to avoid
      this situation, the PRC requests an assignment of more port
      numbers at the PRAS.

   o  A user can actively close all ports in anticipation of an
      exceeding demand of ports from new applications to be started.
      All ports are released voluntarily in expectation of goodwill to
      get a larger port range assigned.

   o  The PRAS may monitor usage of port numbers by the PRCs and detect
      that there are only a few unused port numbers left in the range
      assigned to the PRC.  It decides to assign a wider range to the
      PRC before port numbers run out.

   o  The PRAS may detect that the PRC is only using a small part of the
      port range assigned to him and decide to assign the PRC a smaller
      port range.

   o  The PRAS may identify a need to re-assign the port range of the
      PRC in order to reduce fragmentation of the port space.

   The port range change request could be both PRC and PRAS initiated.


3.  Usage scenario

   The following usage scenario describes the impact of the proposed
   method from the initialization phase till final de-allocation of port
   ranges.



Ripke, et al.           Expires September 9, 2010               [Page 5]


Internet-Draft             Dynamic Port Ranges                March 2010


   In this scenario, a broadband provider's PRAS and PRR operates on a
   BRAS, which then manages IP addresses, according port ranges, and
   broadband access.  The PRC is a home router, allocating port numbers
   when acting as NAT for the home devices.

   Alternative scenarios have PRAS and PRR located at an MSAN (Multi
   Service Access Node), DSLAM (Digital Subscriber Line Access
   Multiplexer), an SGSN (Serving GPRS (General Packet Radio Service))
   or GGSN (Gateway GPRS Support Node).  The PRC can alternatively be
   located at various devices ranging from an enterprise gateway to a
   mobile terminal or a sensor.  The message flow between PRAS, PRR, and
   PRC is illustrated by Figure 2:


                   PRC                  PRR                PRAS
                   -+-                  -+-                -+-
                    |   req addr+PR      |                  |
              (3.1) +------------------->|      req PR      |
                    |                    +----------------->|
                    |                    |      assign PR1  |
                    |   assign addr:PR1  |<-----------------+
                    |<-------------------+                  |
                    |   ...traffic...    |                  |
              (3.2) |                    |      req new PR  |
                    |                    +----------------->|
                    |                    |      assign PR2  |
                    |   PR1->PR2         |<-----------------+
              (3.3) |<-------------------+                  |
              (3.4) |   ...traffic...    |                  |
                    |                    |                  |
                    |   free PR1         |                  |
              (3.5) +------------------->|      free PR1    |
                    |                    +----------------->|
                    |                    |                  |

   A PRAS initially assigns port range PR1 to the PRC.  Later, PR1 gets
                             replaced by PR2.

                                 Figure 2

3.1.  Initialization

   A home router requests an IPv4 address with optionally requesting a
   certain number of port numbers, a specific port range, or a specific
   set of not consecutive port numbers.  The BRAS replies in his role as
   PRAS by assigning an IP address and a set of port numbers to the home
   router.




Ripke, et al.           Expires September 9, 2010               [Page 6]


Internet-Draft             Dynamic Port Ranges                March 2010


3.2.  Detecting the change point

   After some time the BRAS identifies a very high port consumption with
   one of its home routers.  A certain threshold has been exceeded and
   still new connections are initiated from the home router side.

   Alternatively: The home router identifies an upcoming shortage of
   available ports and sends a request for more ports to the server.

3.3.  Assigning a new port range

   The BRAS sends a message to the home router.  The message contains
   two port ranges, the originally assigned one with a mark not to use
   it anymore and a new range to be used from now on.  Optionally, the
   old port range may be tagged with a time stamp that indicates when
   this port range will definitely expire and cannot be used anymore by
   the home router.

3.4.  Ongoing port consumption

   The home router only allocates new port numbers of the new range and
   releases port numbers in the old port range.

3.5.  Final de-allocation of a port range

   The BRAS detects that no port number of the initial port range is not
   in use anymore (through monitoring) and signals to the home router
   that the assignment of the old range is expired.

   Alternatively: The home router explicitly confirms the release by
   sending a signal to the BRAS that it is not using the initial range
   anymore and the BRAS can assign it to other PRCs.  A more complicated
   option is a partial release of the old range agreed between BRAS and
   home router.  This requires splitting the old port range into two
   sub-ranges, one to be released and one to be further used.


4.  Signaling

   The signaling between client and server can be done through different
   protocols including DHCP extensions, PPP extensions, Web Services,
   TR-069, or a novel protocol for address and port pool management.


5.  Fragmentation

   According to [I-D.boucadair-pppext-portrange-option] and
   [I-D.boucadair-dhc-port-range], it is possible to assign more than



Ripke, et al.           Expires September 9, 2010               [Page 7]


Internet-Draft             Dynamic Port Ranges                March 2010


   one port range to a customer (using a port mask and a port locator).
   It is expected that contiguous port range allocation will be the
   preferred procedure.  However, together with the introduced technique
   to enlarge or to reduce individual port ranges the port range manager
   might have to deal with heavily fragmented port mapping tables.
   Besides administration overhead this may lead to problems if new
   contiguous port ranges are requested.  Dynamic port range re-
   assignment provides a technique that can both amplify and rectify
   this problem.


6.  Port Range Swapping

   Port randomization [I-D.ietf-tsvwg-port-randomization] is a mechanism
   to make it harder for "blind" attacks to spoof a system.  However,
   having a smaller port range to choose from produces more port
   collisions.  Local collisions can be easily detected by comparing a
   port against open connections.  Remote collisions on the other hand
   are harder to detect unless recently closed connections are tracked
   like suggested in [I-D.ananth-tsvwg-timewait].  The problem is that
   an active closer of a TCP connection lingers in state TIME-WAIT for
   four minutes for the respective connection's five-tuple (local
   address, local port, remote address, remote port, protocol).
   Frequent connections to the same server might induce a situation
   where the client's ports are in said state on the server and no more
   connections are possible for a while.  Clearly, the smaller the
   client's port range the more often this undesired effect may occur.
   One solution with dynamic port range management might be the
   possibility to exchange a used port range for a recently unused port
   range with the port range manager.


7.  Service Management

   As already mentioned in [I-D.levis-behave-ipv4-shortage-framework], a
   PRAS assigns the number of ports to the customer upon pre-configured
   policies which might depend on the individual contract with the
   customer or on the customer's usage profile.

7.1.  Server policy

   The process on the PRAS for deciding on how many ports to give away
   is based on policies configured into the PRAS from a management
   station.  That might depend on the customer status.  Premium
   customers paying a certain fee might request higher numbers.  It can
   also depend on the current level of free addresses and ports.  When
   there are only a few ports left the IP address and port range manager
   might be more restrictive with port allocations.  In general, the



Ripke, et al.           Expires September 9, 2010               [Page 8]


Internet-Draft             Dynamic Port Ranges                March 2010


   mechanisms described above in the usage scenario requires
   configuration on the PRAS to behave in one or the other way, also
   including the configuration of the client.

7.2.  Client policy

   The policies will also be configured into the client and can provide
   information about

   o  the amount of available space that can be requested.

   o  and what port consumption level triggers the dynamic mechanism of
      expanding or reducing the client's port range.

   For example, the threshold for expanding the port range could be a
   port utilization of 80%.  If the client exceeds this threshold a
   request for more ports is sent to the PRAS.  Alternatively, the
   client only requests for more if its port range is entirely depleted.


8.  Open issues

   Dynamic port range re-assignment has several open issues to be solved
   or clarified:

   o  Modifications are required to both the DHCP and the PPP protocol
      in addition to the extensions described in
      [I-D.boucadair-dhc-port-range] and
      [I-D.boucadair-pppext-portrange-option] respectively.

   o  What strategy should be chosen to solve a potential port mapping
      table fragmentation?

   o  The constant port monitoring which the port range manager has to
      carry out might impose problems.

   o  How to handle expiration timers when requesting port ranges to be
      cleared?

   o  The processing of port overflow caused by exceeding port number
      requests might become a delicate problem.  If available port
      numbers for a specific IPv4 address do not match a client's
      request it would be necessary to assign a new IPv4 address.

   Eventually, the price to be paid for dynamic port range management is
   complexity.





Ripke, et al.           Expires September 9, 2010               [Page 9]


Internet-Draft             Dynamic Port Ranges                March 2010


9.  Acknowledgements

   The authors are supported by Trilogy
   (http://www.trilogy-project.org), a research project (ICT-216372)
   partially funded by the European Community under its Seventh
   Framework Program.  The views expressed here are those of the
   author(s) only.  The European Commission is not liable for any use
   that may be made of the information in this document.

   Thanks to Mohamed Boucadair for his comments.


10.  IANA Considerations

   This document includes no request to IANA.


11.  Security Considerations

   TBD.


12.  Informative References

   [I-D.ananth-tsvwg-timewait]
              Ramaiah, A. and P. Tate, "Effects of port randomization
              with TCP TIME-WAIT state.", draft-ananth-tsvwg-timewait-00
              (work in progress), July 2008.

   [I-D.boucadair-dhc-port-range]
              Boucadair, M., Grimault, J., Levis, P., and A.
              Villefranque, "DHCP Options for Conveying Port Mask and
              Port Range Router IP Address",
              draft-boucadair-dhc-port-range-01 (work in progress),
              October 2008.

   [I-D.boucadair-port-range]
              Boucadair, M., Levis, P., Bajko, G., and T. Savolainen,
              "IPv4 Connectivity Access in the Context of IPv4 Address
              Exhaustion: Port Range based IP Architecture",
              draft-boucadair-port-range-02 (work in progress),
              July 2009.

   [I-D.boucadair-pppext-portrange-option]
              Boucadair, M., Levis, P., Grimault, J., and A.
              Villefranque, "Port Range Configuration Options for PPP
              IPCP", draft-boucadair-pppext-portrange-option-01 (work in
              progress), July 2009.



Ripke, et al.           Expires September 9, 2010              [Page 10]


Internet-Draft             Dynamic Port Ranges                March 2010


   [I-D.ietf-tsvwg-port-randomization]
              Larsen, M. and F. Gont, "Transport Protocol Port
              Randomization Recommendations",
              draft-ietf-tsvwg-port-randomization-06 (work in progress),
              February 2010.

   [I-D.levis-behave-ipv4-shortage-framework]
              Levis, P., Boucadair, M., Grimault, J., and A.
              Villefranque, "IPv4 Address Shortage: Needs and Open
              Issues", draft-levis-behave-ipv4-shortage-framework-02
              (work in progress), June 2009.

   [I-D.ymbk-aplusp]
              Bush, R., "The A+P Approach to the IPv4 Address Shortage",
              draft-ymbk-aplusp-05 (work in progress), October 2009.

   [flow-counting]
              WAND, Network Research Group, "Flow Counting", <http://
              www.wand.net.nz/~salcock/someisp/flow_counting/
              result_page.html>.


Authors' Addresses

   Andreas Ripke
   NEC Laboratories Europe
   Kurfuersten-Anlage 36
   69115 Heidelberg,
   Germany

   Phone: +49 6221 4342 252
   Email: andreas.ripke@nw.neclab.eu


   Juergen Quittek
   NEC Laboratories Europe
   Kurfuersten-Anlage 36
   69115 Heidelberg,
   Germany

   Phone: +49 6221 4342 115
   Email: juergen.quittek@nw.neclab.eu









Ripke, et al.           Expires September 9, 2010              [Page 11]


Internet-Draft             Dynamic Port Ranges                March 2010


   Marcus Brunner
   NEC Laboratories Europe
   Kurfuersten-Anlage 36
   69115 Heidelberg,
   Germany

   Phone: +49 6221 4342 129
   Email: marcus.brunner@nw.neclab.eu











































Ripke, et al.           Expires September 9, 2010              [Page 12]