Internet Engineering Task Force A. Ripke Internet-Draft J. Quittek Intended status: Informational M. Brunner Expires: April 29, 2010 NEC Laboratories Europe October 26, 2009 Dynamic Port Range Re-Assignments for Address Sharing draft-rqb-dynamic-port-ranges-01 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 April 29, 2010. 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 This document proposes an extension regarding dynamic port range re- assignment to an IPv4 address sharing framework (SHARA), to overcome Ripke, et al. Expires April 29, 2010 [Page 1] Internet-Draft Dynamic Port Ranges October 2009 IPv4 address shortage. It allows an entity which is responsible for IPv4 address and port distribution to apply dynamic handling of already assigned port ranges. An adjustment of number of ports per customer according to the current consumption pattern is possible with this enhancement. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Dynamic port range re-assignments . . . . . . . . . . . . . . 4 4. Usage scenario . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Initialization . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Detecting the change point . . . . . . . . . . . . . . . . 5 4.3. Assigning a new port range . . . . . . . . . . . . . . . . 5 4.4. Ongoing port consumption . . . . . . . . . . . . . . . . . 6 4.5. Final de-allocation of a port range . . . . . . . . . . . 6 5. Location of the address and port manager . . . . . . . . . . . 6 5.1. Mobile networks . . . . . . . . . . . . . . . . . . . . . 6 6. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Port Range Swapping . . . . . . . . . . . . . . . . . . . . . 7 9. Service Management . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Server policy . . . . . . . . . . . . . . . . . . . . . . 7 9.2. Client policy . . . . . . . . . . . . . . . . . . . . . . 8 10. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 13. Security Considerations . . . . . . . . . . . . . . . . . . . 9 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 14.1. Normative References . . . . . . . . . . . . . . . . . . . 9 14.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Ripke, et al. Expires April 29, 2010 [Page 2] Internet-Draft Dynamic Port Ranges October 2009 1. Introduction The IETF starts 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. So far within the IETF DHCP extensions [I-D.boucadair-dhc-port-range] and PPP extensions [I-D.boucadair-pppext-portrange-option] to assign IP addresses and port ranges to hosts and sites have been proposed. However, since the deployments are very different for different users, customers with several users etc., more 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 seems to be 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 client 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 client can only start allocating new ports in a new range and wait until ports in an old range are not used anymore. Consequently, a client 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 client ([I-D.boucadair-port-range]), but not to identify one or more ranges that should not be used anymore by the client. Ripke, et al. Expires April 29, 2010 [Page 3] Internet-Draft Dynamic Port Ranges October 2009 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Dynamic port range re-assignments This draft proposal provides a way for a port range assignment server to tag a port range with an attribute that signals the client 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 client. 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 client receiving the signal would then stop allocating port numbers in the marked ranges. When the client 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. The method can also be used for reducing (trimming) already assigned port ranges. For this purpose, the server 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 client with one or more of the port ranges marked as not to be used anymore. Again, the client 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 client has the possibility to actively confirm the release of port ranges. 4. Usage scenario The following usage scenario describes the impact of the proposed method from the initialization phase till final de-allocation of port ranges. A broadband operator manages IP address and port range manager for broadband access provisioning at a BRAS (Broadband Remote Access Server). The client would be a home router, a single host or the gateway of a large enterprise, allocating port numbers when acting as NAT for the respective devices. Ripke, et al. Expires April 29, 2010 [Page 4] Internet-Draft Dynamic Port Ranges October 2009 4.1. Initialization When a client requests an IPv4 address with a port range including the number of ports, the BRAS assigns it and signals the assigned port range to the client. The port range specified by the client could be a preferred port range indicated by a minimum value and a maximum value or just the number of ports. 4.2. Detecting the change point While the client is using the port range, several reasons may occur that make it desirable to change the port assignment. o The client 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 client requests an assignment of more port numbers at the BRAS. 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 BRAS may monitor usage of port numbers by the clients and detect that there are only a few unused port numbers left in the range assigned to the client. It decides to assign a wider range to the client before port numbers run out. o The BRAS may detect that the client is only using a small part of the port range assigned to him and decide to assign the client a smaller port range. o The BRAS may identify a need to re-assign the port range of the client in order to reduce fragmentation of the port space. Therefore, the port range change request could be both client and server initiated. 4.3. Assigning a new port range The BRAS sends a message to the client. 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, it can also give a time until when the old port range is still valid, before it will definitely expire. Ripke, et al. Expires April 29, 2010 [Page 5] Internet-Draft Dynamic Port Ranges October 2009 4.4. Ongoing port consumption The client only allocates new port numbers of the new range. 4.5. Final de-allocation of a port range Either the BRAS detects that no port number of the initial port range is in use anymore (through monitoring) and signals to the client that the initially assigned range is not anymore assigned to the client. Or the client send an explicit signal that it is not using the initial range anymore and the BRAS can assign it to other clients. Alternatively, the client can carry out a partial release of a requested port range, hence splitting the port range in used and unused ports. 5. Location of the address and port manager In the above usage scenario, it is implied that the IP address and the port range management service is supplied with a BRAS. Alternatively, the IP address and port range manager can be located at a MSAN (Multi Service Access Node), DSLAM (Digital Subscriber Line Access Multiplexer), or any other infrastructure equipment. 5.1. Mobile networks The scheme might also apply to mobile networks, where the server is located on the SGSN (Serving GPRS (General Packet Radio Service) Support Node) or GGSN (Gateway GPRS Support Node), and the client on a user equipment. 6. 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. 7. Fragmentation According to [I-D.boucadair-pppext-portrange-option] and [I-D.boucadair-dhc-port-range], it is possible to assign more than 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 Ripke, et al. Expires April 29, 2010 [Page 6] Internet-Draft Dynamic Port Ranges October 2009 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. 8. 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. 9. Service Management As already mentioned in [I-D.levis-behave-ipv4-shortage-framework], a management station 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. 9.1. Server policy The process on the BRAS for deciding on how many ports to give away is based on policies configured into the BRAS 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 mechanisms described above in the usage scenario requires configuration on the BRAS to behave in one or the other way, also including the configuration of the client. Ripke, et al. Expires April 29, 2010 [Page 7] Internet-Draft Dynamic Port Ranges October 2009 9.2. Client policy The policies will also be configured into the client. Those policies tell the client how large of a space he/she is allowed to request, and at what usage level the client should ask for more port space. For example, that can be if only 80% of the ports are used, the client asks already for more, or the client only asks for more if he fully used up his space. 10. 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. 11. 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 in the first version. Ripke, et al. Expires April 29, 2010 [Page 8] Internet-Draft Dynamic Port Ranges October 2009 12. IANA Considerations This document includes no request to IANA. 13. Security Considerations TBD. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 14.2. 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. [I-D.ietf-tsvwg-port-randomization] Larsen, M. and F. Gont, "Port Randomization", draft-ietf-tsvwg-port-randomization-04 (work in progress), July 2009. Ripke, et al. Expires April 29, 2010 [Page 9] Internet-Draft Dynamic Port Ranges October 2009 [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-04 (work in progress), July 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 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 April 29, 2010 [Page 10]