idnits 2.17.1 draft-rqb-dynamic-port-ranges-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2010) is 5163 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-boucadair-pppext-portrange-option-01 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-port-randomization-06 == Outdated reference: A later version (-10) exists of draft-ymbk-aplusp-05 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Ripke 3 Internet-Draft J. Quittek 4 Intended status: Informational M. Brunner 5 Expires: September 9, 2010 NEC Laboratories Europe 6 March 8, 2010 8 Dynamic Port Range Re-Assignments for Address Sharing 9 draft-rqb-dynamic-port-ranges-02 11 Abstract 13 This document describes and extension of the port range assignment 14 mechanisms used for the IPv4 address sharing framework (SHARA) that 15 is based on port range routing. The extension provides means for 16 dynamically changes port range assignments by allowing clients to 17 smoothly migrate to a new port range before releasing the range that 18 is currently in use. This way, the number of ports per client can be 19 adjusted to actual usage patterns. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 9, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Dynamic port range re-assignments . . . . . . . . . . . . . . 4 63 2.1. Detecting the change point . . . . . . . . . . . . . . . . 5 64 3. Usage scenario . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Initialization . . . . . . . . . . . . . . . . . . . . . . 6 66 3.2. Detecting the change point . . . . . . . . . . . . . . . . 7 67 3.3. Assigning a new port range . . . . . . . . . . . . . . . . 7 68 3.4. Ongoing port consumption . . . . . . . . . . . . . . . . . 7 69 3.5. Final de-allocation of a port range . . . . . . . . . . . 7 70 4. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 7 72 6. Port Range Swapping . . . . . . . . . . . . . . . . . . . . . 8 73 7. Service Management . . . . . . . . . . . . . . . . . . . . . . 8 74 7.1. Server policy . . . . . . . . . . . . . . . . . . . . . . 8 75 7.2. Client policy . . . . . . . . . . . . . . . . . . . . . . 9 76 8. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 12. Informative References . . . . . . . . . . . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 The IETF is discussing a scheme for enlarging the usable IP address 86 space in [I-D.ymbk-aplusp] or [I-D.boucadair-port-range] using parts 87 of the port numbers, similar to what Network Address Translators 88 (NAT) do. This allows to assign the same IP address to several 89 customers or hosts. The IP address together with the port bits 90 extension differentiate the routing and forwarding of that 91 communication. 93 A port range router (PRR) manages one or several IPv4 addresses that 94 are to be shared among several port range clients (PRC). Each PRC 95 gets a portion of one IPv4 address whereas this portion is defined by 96 one or several port ranges that are assigned exclusively to a PRC. 97 The PRR and the PRC can, for example, be a Broadband Remote Access 98 Server (BRAS) and a Home Gateway (HGW), respectively. Alternatively, 99 the client can be a home router, a single host, or the gateway of a 100 large enterprise, A schematic sketch of sharing two non-overlapping 101 port ranges is illustrated by the following figure: 103 +-------+ 104 [o..p] assign PR | | 105 +---------+--------------------+ PRAS | 106 | | | | 107 | | +-------+ 108 | |[m..n] | 109 | | | configure PRR 110 | v v 111 | +-------+ +-------+ 112 | | | | | 113 | | PRC +----------------+ | 114 | | | A.B.C.D:m..n | | | 115 | +-------+ | | A.B.C.D | 116 v | PRR +----------+ IPv4 Internet 117 +-------+ | | | 118 | | A.B.C.D:o..p | | | 119 | PRC +--------------------------+ | 120 | | | | 121 +-------+ +-------+ 123 A PRAS assigns two different non-overlapping port ranges [m..n] and 124 [o..p] of an IPv4 address A.B.C.D to two PRCs. 126 Figure 1 128 DHCP extensions [I-D.boucadair-dhc-port-range] and PPP extensions 129 [I-D.boucadair-pppext-portrange-option] that can be used by a Port 130 Range Assignment Server (PRAS) to assign IP addresses and port ranges 131 to a PRC have already been proposed. However, since the deployments 132 are very different for different users, customers with several users 133 etc., further means for managing port assignments appear to be 134 required. Measurements showed that different clients need different 135 range sizes at different times [flow-counting]. 137 This implies that dynamic port range assignment is needed for 139 o assigning clients larger port ranges when the current one becomes 140 too small, 142 o assigning clients smaller port ranges, when the current ones are 143 underused, 145 o changing clients port ranges for reducing fragmentation of the 146 port space, 148 o balancing port consumption for a shared IPv4 address. 150 The existing means are sufficient to assign and re-assign port ranges 151 (both contiguous and non-contiguous ones). However, a PRC cannot 152 immediately switch from one port range to another one, because most 153 applications cannot change port numbers while using them. Without 154 interrupting existing connections, a PRC can only start allocating 155 new ports in a new range and wait until ports in an old range are not 156 used anymore. Consequently, a PRC needs to wait until applications 157 have closed all ports in the old port range. Existing means allow to 158 assign more than one port ranges to a PRC 159 ([I-D.boucadair-port-range]), but not to identify one or more ranges 160 that should not be used anymore by the PRC. 162 2. Dynamic port range re-assignments 164 This draft proposal provides a way for a Port Range Assignment Server 165 (PRAS) to tag a port range with an attribute that signals the PRC not 166 to allocate any more ports in this range. Such a signal can be sent 167 when a server signals more than one port range to a PRC. A most 168 simple implementation would be adding a flag to one or more port 169 ranges during the (re-)assignment process that marks these ranges as 170 not to be used anymore. A PRC receiving the signal would then stop 171 allocating port numbers in the marked ranges. When the PRC does not 172 use an address range anymore, it signals back that the port range is 173 not in use anymore and can be re-assigned. This can be done 174 individually for each range as soon as it is not used anymore or at 175 once when all marked ranges are not used anymore. 177 The method can also be used for reducing (trimming) already assigned 178 port ranges. For this purpose, the PRAS divides the single port 179 range into two or more consecutive port ranges and re-assigns the 180 single port range as a set of port ranges to the PRC with one or more 181 of the port ranges marked as not to be used anymore. Again, the PRC 182 would signal back that one or more ranges are not used anymore. 184 This new technique allows to postpone the de-allocation of port 185 ranges until the respective ports are closed (lazy de-allocation). 186 The PRC has the possibility to actively confirm the release of port 187 ranges. 189 2.1. Detecting the change point 191 While the PRC is using the port range, several reasons may occur that 192 make it desirable to change the port assignment. 194 o The PRC may observe that there are only few unused numbers left in 195 the used range and that it may soon happen that no further ports 196 would be available for requesting applications. In order to avoid 197 this situation, the PRC requests an assignment of more port 198 numbers at the PRAS. 200 o A user can actively close all ports in anticipation of an 201 exceeding demand of ports from new applications to be started. 202 All ports are released voluntarily in expectation of goodwill to 203 get a larger port range assigned. 205 o The PRAS may monitor usage of port numbers by the PRCs and detect 206 that there are only a few unused port numbers left in the range 207 assigned to the PRC. It decides to assign a wider range to the 208 PRC before port numbers run out. 210 o The PRAS may detect that the PRC is only using a small part of the 211 port range assigned to him and decide to assign the PRC a smaller 212 port range. 214 o The PRAS may identify a need to re-assign the port range of the 215 PRC in order to reduce fragmentation of the port space. 217 The port range change request could be both PRC and PRAS initiated. 219 3. Usage scenario 221 The following usage scenario describes the impact of the proposed 222 method from the initialization phase till final de-allocation of port 223 ranges. 225 In this scenario, a broadband provider's PRAS and PRR operates on a 226 BRAS, which then manages IP addresses, according port ranges, and 227 broadband access. The PRC is a home router, allocating port numbers 228 when acting as NAT for the home devices. 230 Alternative scenarios have PRAS and PRR located at an MSAN (Multi 231 Service Access Node), DSLAM (Digital Subscriber Line Access 232 Multiplexer), an SGSN (Serving GPRS (General Packet Radio Service)) 233 or GGSN (Gateway GPRS Support Node). The PRC can alternatively be 234 located at various devices ranging from an enterprise gateway to a 235 mobile terminal or a sensor. The message flow between PRAS, PRR, and 236 PRC is illustrated by Figure 2: 238 PRC PRR PRAS 239 -+- -+- -+- 240 | req addr+PR | | 241 (3.1) +------------------->| req PR | 242 | +----------------->| 243 | | assign PR1 | 244 | assign addr:PR1 |<-----------------+ 245 |<-------------------+ | 246 | ...traffic... | | 247 (3.2) | | req new PR | 248 | +----------------->| 249 | | assign PR2 | 250 | PR1->PR2 |<-----------------+ 251 (3.3) |<-------------------+ | 252 (3.4) | ...traffic... | | 253 | | | 254 | free PR1 | | 255 (3.5) +------------------->| free PR1 | 256 | +----------------->| 257 | | | 259 A PRAS initially assigns port range PR1 to the PRC. Later, PR1 gets 260 replaced by PR2. 262 Figure 2 264 3.1. Initialization 266 A home router requests an IPv4 address with optionally requesting a 267 certain number of port numbers, a specific port range, or a specific 268 set of not consecutive port numbers. The BRAS replies in his role as 269 PRAS by assigning an IP address and a set of port numbers to the home 270 router. 272 3.2. Detecting the change point 274 After some time the BRAS identifies a very high port consumption with 275 one of its home routers. A certain threshold has been exceeded and 276 still new connections are initiated from the home router side. 278 Alternatively: The home router identifies an upcoming shortage of 279 available ports and sends a request for more ports to the server. 281 3.3. Assigning a new port range 283 The BRAS sends a message to the home router. The message contains 284 two port ranges, the originally assigned one with a mark not to use 285 it anymore and a new range to be used from now on. Optionally, the 286 old port range may be tagged with a time stamp that indicates when 287 this port range will definitely expire and cannot be used anymore by 288 the home router. 290 3.4. Ongoing port consumption 292 The home router only allocates new port numbers of the new range and 293 releases port numbers in the old port range. 295 3.5. Final de-allocation of a port range 297 The BRAS detects that no port number of the initial port range is not 298 in use anymore (through monitoring) and signals to the home router 299 that the assignment of the old range is expired. 301 Alternatively: The home router explicitly confirms the release by 302 sending a signal to the BRAS that it is not using the initial range 303 anymore and the BRAS can assign it to other PRCs. A more complicated 304 option is a partial release of the old range agreed between BRAS and 305 home router. This requires splitting the old port range into two 306 sub-ranges, one to be released and one to be further used. 308 4. Signaling 310 The signaling between client and server can be done through different 311 protocols including DHCP extensions, PPP extensions, Web Services, 312 TR-069, or a novel protocol for address and port pool management. 314 5. Fragmentation 316 According to [I-D.boucadair-pppext-portrange-option] and 317 [I-D.boucadair-dhc-port-range], it is possible to assign more than 318 one port range to a customer (using a port mask and a port locator). 319 It is expected that contiguous port range allocation will be the 320 preferred procedure. However, together with the introduced technique 321 to enlarge or to reduce individual port ranges the port range manager 322 might have to deal with heavily fragmented port mapping tables. 323 Besides administration overhead this may lead to problems if new 324 contiguous port ranges are requested. Dynamic port range re- 325 assignment provides a technique that can both amplify and rectify 326 this problem. 328 6. Port Range Swapping 330 Port randomization [I-D.ietf-tsvwg-port-randomization] is a mechanism 331 to make it harder for "blind" attacks to spoof a system. However, 332 having a smaller port range to choose from produces more port 333 collisions. Local collisions can be easily detected by comparing a 334 port against open connections. Remote collisions on the other hand 335 are harder to detect unless recently closed connections are tracked 336 like suggested in [I-D.ananth-tsvwg-timewait]. The problem is that 337 an active closer of a TCP connection lingers in state TIME-WAIT for 338 four minutes for the respective connection's five-tuple (local 339 address, local port, remote address, remote port, protocol). 340 Frequent connections to the same server might induce a situation 341 where the client's ports are in said state on the server and no more 342 connections are possible for a while. Clearly, the smaller the 343 client's port range the more often this undesired effect may occur. 344 One solution with dynamic port range management might be the 345 possibility to exchange a used port range for a recently unused port 346 range with the port range manager. 348 7. Service Management 350 As already mentioned in [I-D.levis-behave-ipv4-shortage-framework], a 351 PRAS assigns the number of ports to the customer upon pre-configured 352 policies which might depend on the individual contract with the 353 customer or on the customer's usage profile. 355 7.1. Server policy 357 The process on the PRAS for deciding on how many ports to give away 358 is based on policies configured into the PRAS from a management 359 station. That might depend on the customer status. Premium 360 customers paying a certain fee might request higher numbers. It can 361 also depend on the current level of free addresses and ports. When 362 there are only a few ports left the IP address and port range manager 363 might be more restrictive with port allocations. In general, the 364 mechanisms described above in the usage scenario requires 365 configuration on the PRAS to behave in one or the other way, also 366 including the configuration of the client. 368 7.2. Client policy 370 The policies will also be configured into the client and can provide 371 information about 373 o the amount of available space that can be requested. 375 o and what port consumption level triggers the dynamic mechanism of 376 expanding or reducing the client's port range. 378 For example, the threshold for expanding the port range could be a 379 port utilization of 80%. If the client exceeds this threshold a 380 request for more ports is sent to the PRAS. Alternatively, the 381 client only requests for more if its port range is entirely depleted. 383 8. Open issues 385 Dynamic port range re-assignment has several open issues to be solved 386 or clarified: 388 o Modifications are required to both the DHCP and the PPP protocol 389 in addition to the extensions described in 390 [I-D.boucadair-dhc-port-range] and 391 [I-D.boucadair-pppext-portrange-option] respectively. 393 o What strategy should be chosen to solve a potential port mapping 394 table fragmentation? 396 o The constant port monitoring which the port range manager has to 397 carry out might impose problems. 399 o How to handle expiration timers when requesting port ranges to be 400 cleared? 402 o The processing of port overflow caused by exceeding port number 403 requests might become a delicate problem. If available port 404 numbers for a specific IPv4 address do not match a client's 405 request it would be necessary to assign a new IPv4 address. 407 Eventually, the price to be paid for dynamic port range management is 408 complexity. 410 9. Acknowledgements 412 The authors are supported by Trilogy 413 (http://www.trilogy-project.org), a research project (ICT-216372) 414 partially funded by the European Community under its Seventh 415 Framework Program. The views expressed here are those of the 416 author(s) only. The European Commission is not liable for any use 417 that may be made of the information in this document. 419 Thanks to Mohamed Boucadair for his comments. 421 10. IANA Considerations 423 This document includes no request to IANA. 425 11. Security Considerations 427 TBD. 429 12. Informative References 431 [I-D.ananth-tsvwg-timewait] 432 Ramaiah, A. and P. Tate, "Effects of port randomization 433 with TCP TIME-WAIT state.", draft-ananth-tsvwg-timewait-00 434 (work in progress), July 2008. 436 [I-D.boucadair-dhc-port-range] 437 Boucadair, M., Grimault, J., Levis, P., and A. 438 Villefranque, "DHCP Options for Conveying Port Mask and 439 Port Range Router IP Address", 440 draft-boucadair-dhc-port-range-01 (work in progress), 441 October 2008. 443 [I-D.boucadair-port-range] 444 Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, 445 "IPv4 Connectivity Access in the Context of IPv4 Address 446 Exhaustion: Port Range based IP Architecture", 447 draft-boucadair-port-range-02 (work in progress), 448 July 2009. 450 [I-D.boucadair-pppext-portrange-option] 451 Boucadair, M., Levis, P., Grimault, J., and A. 452 Villefranque, "Port Range Configuration Options for PPP 453 IPCP", draft-boucadair-pppext-portrange-option-01 (work in 454 progress), July 2009. 456 [I-D.ietf-tsvwg-port-randomization] 457 Larsen, M. and F. Gont, "Transport Protocol Port 458 Randomization Recommendations", 459 draft-ietf-tsvwg-port-randomization-06 (work in progress), 460 February 2010. 462 [I-D.levis-behave-ipv4-shortage-framework] 463 Levis, P., Boucadair, M., Grimault, J., and A. 464 Villefranque, "IPv4 Address Shortage: Needs and Open 465 Issues", draft-levis-behave-ipv4-shortage-framework-02 466 (work in progress), June 2009. 468 [I-D.ymbk-aplusp] 469 Bush, R., "The A+P Approach to the IPv4 Address Shortage", 470 draft-ymbk-aplusp-05 (work in progress), October 2009. 472 [flow-counting] 473 WAND, Network Research Group, "Flow Counting", . 477 Authors' Addresses 479 Andreas Ripke 480 NEC Laboratories Europe 481 Kurfuersten-Anlage 36 482 69115 Heidelberg, 483 Germany 485 Phone: +49 6221 4342 252 486 Email: andreas.ripke@nw.neclab.eu 488 Juergen Quittek 489 NEC Laboratories Europe 490 Kurfuersten-Anlage 36 491 69115 Heidelberg, 492 Germany 494 Phone: +49 6221 4342 115 495 Email: juergen.quittek@nw.neclab.eu 496 Marcus Brunner 497 NEC Laboratories Europe 498 Kurfuersten-Anlage 36 499 69115 Heidelberg, 500 Germany 502 Phone: +49 6221 4342 129 503 Email: marcus.brunner@nw.neclab.eu