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