idnits 2.17.1 draft-boucadair-port-range-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 19 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 115 has weird spacing: '...Hurdles and F...' == Line 1159 has weird spacing: '...Hurdles and F...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 3, 2009) is 5410 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2026' is defined on line 1469, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1889 (Obsoleted by RFC 3550) == Outdated reference: A later version (-04) exists of draft-bajko-pripaddrassign-01 == Outdated reference: A later version (-04) exists of draft-boucadair-behave-ipv6-portrange-01 == Outdated reference: A later version (-09) exists of draft-boucadair-pppext-portrange-option-00 == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-00 -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair, Ed. 3 Internet-Draft P. Levis 4 Intended status: Informational France Telecom 5 Expires: January 4, 2010 G. Bajko 6 T. Savolainen 7 Nokia 8 July 3, 2009 10 IPv4 Connectivity Access in the Context of IPv4 Address Exhaustion: Port 11 Range based IP Architecture 12 draft-boucadair-port-range-02.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 4, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This memo proposes a solution, based on fractional addresses, to face 51 the IPv4 public address exhaustion. It details the solution and 52 presents a mock-up implementation, with the results of tests that 53 validate the concept. It also describes architectures and how 54 fractional addresses are used to overcome the IPv4 address shortage. 55 A comparison with the alternative Carrier-Grade NAT (CG-NAT) 56 solutions is also elaborated in the document. The IPv6 variant of 57 this solution is described in a companion draft. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1. Context . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.2. Tentative Solutions: Overview and Limitations . . . . . . 4 64 1.3. Contribution of this draft . . . . . . . . . . . . . . . . 6 66 2. Conventions used in this document . . . . . . . . . . . . . . 6 68 3. Port Range Architecture: Overall Procedure . . . . . . . . . . 7 69 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.2. Basic Principles . . . . . . . . . . . . . . . . . . . . . 8 71 3.3. Applicability Use Cases . . . . . . . . . . . . . . . . . 9 72 3.3.1. CPE . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.3.2. End Host . . . . . . . . . . . . . . . . . . . . . . . 9 74 3.3.3. Point-to-Point Links . . . . . . . . . . . . . . . . . 10 75 3.3.4. Point-to-Point Tunneled Links . . . . . . . . . . . . 11 77 4. Retrieving IP Configuration Data . . . . . . . . . . . . . . . 12 78 4.1. Assumption . . . . . . . . . . . . . . . . . . . . . . . . 12 79 4.2. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 12 80 4.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 12 81 4.3. An alternative to avoid DHCP Server modifications . . . . 13 83 5. Required Modifications . . . . . . . . . . . . . . . . . . . . 16 84 5.1. CPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 5.2. End-user Terminals . . . . . . . . . . . . . . . . . . . . 17 86 5.3. Service Provider Infrastructure . . . . . . . . . . . . . 17 87 5.4. DHCP Server Implementations . . . . . . . . . . . . . . . 18 89 6. Port Range Router . . . . . . . . . . . . . . . . . . . . . . 18 90 6.1. Main Function . . . . . . . . . . . . . . . . . . . . . . 18 91 6.2. Routing Considerations: Focus on IGP . . . . . . . . . . . 19 92 6.3. Binding Table . . . . . . . . . . . . . . . . . . . . . . 20 93 6.4. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 20 94 6.4.1. Needs . . . . . . . . . . . . . . . . . . . . . . . . 20 95 6.4.2. Option 1: CPE-Provisioned PRR . . . . . . . . . . . . 20 96 6.4.3. Option 2: Provider-Provisioned PRR . . . . . . . . . . 21 98 7. Localization Inside a Service Provider's Domain . . . . . . . 21 100 8. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 22 102 9. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 23 104 10. IGD 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 106 11. IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 108 12. ICMP and Other Portless Protocols . . . . . . . . . . . . . . 25 110 13. 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 112 14. Protocols not supported by PRR . . . . . . . . . . . . . . . . 26 114 15. Comparison with CG-NAT/LSN . . . . . . . . . . . . . . . . . . 26 115 15.1. Generic Hurdles and Focus on Transparency to 116 applications which enclose IPv4 address in their 117 protocol messages . . . . . . . . . . . . . . . . . . . . 26 118 15.2. Focus on Legal Storage . . . . . . . . . . . . . . . . . . 27 119 15.3. Session Handling in CG-NAT . . . . . . . . . . . . . . . . 30 120 15.4. Peer-to-Peer applications . . . . . . . . . . . . . . . . 31 122 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 124 17. Security Considerations . . . . . . . . . . . . . . . . . . . 31 126 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 128 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 130 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 131 20.1. Normative References . . . . . . . . . . . . . . . . . . . 32 132 20.2. Informative References . . . . . . . . . . . . . . . . . . 33 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 136 1. Introduction 138 1.1. Context 140 It is commonly agreed by the Internet community that the exhaustion 141 of public IPv4 addresses is an ineluctable fact. In this context, 142 the community was mobilized in the past to adopt a promising solution 143 (in particular with the definition of IPv6). Nevertheless, this 144 solution is not globally activated by Service Providers for both 145 financial and strategic reasons. In the meantime, these Service 146 Providers are not indifferent to the alarms recently emitted by the 147 IETF particularly by the reports presented within the GROW working 148 group (Global Routing Operations Working Group) meetings. 150 G. Huston introduced an extrapolation model to forecast the 151 exhaustion date of IPv4 addresses managed by IANA. This effort 152 indicates that if the current tendency of consumption continues at 153 the same pace, IPv4 addresses exhaustion of IANA's pool would occur 154 in 2011, while RIRs'pool would be exhausted in late 2012. The state 155 of the current consumption of public IPv4 addresses is daily updated 156 and is available at this URL: 157 http://www.potaroo.net/tools/ipv4/index.html. 159 1.2. Tentative Solutions: Overview and Limitations 161 In order to solve this depletion problem, Service Providers need to 162 investigate and enable means to ensure the deployment of their 163 service offerings and their delivery to end users. Two strands may 164 be followed: 166 (1) Migrate to IPv6: 168 IPv6 has been introduced for several years as the next version of the 169 IP protocol. This new version offers an abundance of IP addresses as 170 well as several enhancements compared to IPv4 especially with the 171 adoption of hierarchical routing (and therefore allows reducing the 172 routing tables size). IPv6 specifications are mature and current 173 work within the IETF is related to operational aspects. 174 Nevertheless, Service Providers have not largely activated IPv6 in 175 their networks yet. 177 However, even if a Service Provider activates IPv6, it will be 178 confronted with the problem to ensure a global connectivity towards 179 nowadays Internet v4. Mechanisms such as NAT-PT (Network Address 180 Translation Protocol Translation) were introduced to ensure the 181 interconnection between two heterogeneous realms (i.e., IPv4/IPv6) 182 and to ensure a continuity of IP communications (i.e., end-to-end). 183 It is out of scope of this document to analyze the hurdles of these 184 solutions. 186 Despite the current IPv6 deployment situation, IPv6 is the viable 187 alternative to offer IP connectivity services to a large number of 188 customers. From this perspective, Service Providers should avoid 189 introducing new functions and nodes which may be problematic when 190 envisaging migrating to IPv6. This critical requirement should not 191 be taken into account only during the technical engineering phase, 192 but also when elaborating required CAPEX (Capital Expenditure)/OPEX 193 (Operational Expenditure) estimation of activating alternative 194 schemes to solve or to reduce the impact of the IPv4 address 195 exhaustion phenomenon. 197 Note that this requires deploying interconnection mechanisms with the 198 already existent IPv4 realms. This cost overhead should be 199 considered in transition scenarios. 201 (2) Enhance current IPv4 architectures and optimize the assignment 202 of IPv4 addresses: 204 A first example of the implementation of this option is the 205 introduction of a second level of NAT, called Provider-NAT or Carrier 206 Grade NAT (CG-NAT). This node is located in the Service Provider 207 domain. In such option, only private addresses are assigned to end- 208 user home gateways, which still perform their own NAT. The CG-NAT is 209 responsible for translating IP packets issued with private addresses 210 to ones with publicly routable IPv4 addresses when exiting the domain 211 of the Service Provider. 213 The introduction of the CG-NAT will have an important impact on the 214 applications. Some services will only work in a degraded mode, some 215 will even not work at all (refer to Section 15 for more details about 216 encountered hurdles). 218 A variant of CG-NAT, called DS-lite, is proposed in 219 [I-D.ietf-softwire-dual-stack-lite]. In this mode, only one NAT 220 level is maintained but it is located in the service provider's 221 network. Unlike Provider-NAT, IPv6 is used to convey traffic isseud/ 222 destined from/to customer's device. 224 Another example of this second option is the proposal that has been 225 made to release IPv4 class E addresses [I-D.fuller-240space]: 226 concretely to reclassify 240/4 as usable unicast address space. The 227 rationale of this proposal is that since the community has not 228 concluded whether the E block should be considered public or private, 229 and given the current consumption rate, it is clear that the block 230 should not be left unused. This proposal requires updating IP- 231 enabled equipment so as to treat correctly IPv4 addresses belonging 232 to 240/4 blocks. These addresses should be routable and announced 233 for instance between adjacent Autonomous Systems (ASes) through BGP 234 (Border Gateway Protocol) for instance. An exhaustive study should 235 be undertaken to evaluate the economic and technical impact of such 236 new policy. Another alternative is to re-classify class E address as 237 private ones [I-D.savolainen-indicating-240-addresses]. 239 1.3. Contribution of this draft 241 This memo specifies an alternative solution to the Double NAT 242 architecture which aims at solving the depletion problem as 243 encountered by current ISPs. The proposed solution, called Port 244 Range based architecture is session stateless and does not alter the 245 various offered services. The solution presented in this document 246 does not require severe modifications to current engineering 247 practices as adopted by major Service Providers. Furthermore, the 248 solution is scalable and can be deployed in several variants, 249 especially to prepare the migration towards IPv6. 251 This draft describes a lightweight architecture that may be deployed 252 by Service Providers to offer IP connectivity services to their 253 already subscribed customers or to new ones. This document provides 254 an implementation scenario. Service Providers are free to enforce 255 their own engineering rules based on their internal policies and 256 available technological means as activated in their IP 257 infrastructure. The solution is flexible enough to be accommodated 258 in various contexts. 260 The scalability of this solution is similar to current deployed IP 261 architectures. No session-related states are maintained in core 262 nodes operated by a given Service Provider. 264 This solution can be activated in an end host, CPE (Customer Premises 265 Equipment), or any other device able to constraint its source port 266 numbers. 268 An IPv6 variant of this solution is described in 269 [I-D.boucadair-behave-ipv6-portrange]. 271 2. Conventions used in this document 273 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 274 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 275 interpreted as described in RFC-2119 [RFC2119]. 277 The following abbreviations are used within this document: 279 - ASN GW: Access Service Network Gateway 281 - CGN: Carrier Grade Network Address Translator 283 - CPE: Consumer Premises Equipment, a device that resides between 284 Internet service provider's network and consumers' home network. 286 - GGSN :Gateway GPRS Support Node 288 - GPRS: General Packet Radio Service 290 - PDN GW: Packet Data Network Gateway 292 - PDSN: Packet Data Serving Node 294 - PRR: Port Range Router 296 3. Port Range Architecture: Overall Procedure 298 3.1. Introduction 300 As an alternative to the Double NAT solution, which suffers from 301 several drawbacks, a second alternative is proposed within this 302 document. The motivations for introducing this second alternative 303 are as follows: 305 - Not to alter current (IPv4-based) services delivery and to not 306 impact the introduction of future services; 308 - Avoid maintaining sessions states at the core network. 309 Stateless solutions are privileged; 311 - Ease management functions (including provisioning, configuration 312 operations, etc.); 314 - Optimise CAPEX and OPEX: As shown latter in this draft, the 315 functional requirements to implement the proposed procedure are 316 lightweight. Only slight modifications are required to be 317 brought. Furthermore, the offered services are not impacted. 318 Management practices would remain as today. For example, because 319 the solution described in this memo does not handle dynamic NAT 320 mappings (contrary to the CG-NAT), the planned maintenance 321 operations (replacement of involved network equipment) would not 322 impact the delivered services as a CG-NAT-based solution would do; 324 - Minor impact on routing and addressing architectures; 325 - Transparent to end-users: The same practices as today's ones 326 will remain (e.g., Port forwarding on CPE still possible -provided 327 the port is within the allocated Port Range-); 329 - Usability easiness; 331 - Facilitate functional separation (Service and Network): For 332 instance, and unlike CG-NAT, the problem to run SIP-based services 333 above a third party IP infrastructure would not be encountered 334 with the proposed solution; 336 - Ease implementing legal requirements (optimize storage of legal 337 data); 339 - Ease migration to a long term solution such as IPv6; 341 This section focuses only on the IPv4 variant of the solution. Other 342 variants have been defined to integrate IPv6 and offer a global IP 343 connectivity services including towards IPv6 realms in a stateless 344 manner. Companion Internet Drafts will be submitted latter. 346 3.2. Basic Principles 348 The major idea is to assign the same IP address to several end-users' 349 devices (e.g., Home Gateways (HGW) embedding NAT, but that could be 350 other types of devices embedding NAT) and to constrain the (source) 351 port numbers to be used by each device. In addition to the assigned 352 IP address to access IP connectivity services, additional parameters 353 are also communicated with the customer's device. These additional 354 parameters indicate which Ports or Port Range(s) is/are assigned to 355 the customer's devices. 357 In the remaining part of this draft, the above mentioned public 358 address is denoted as Primary IP Address. 360 For outbound communications, a given HGW proceeds to its classical 361 operations except the constraint to control the source port number 362 assignment so as to be within the Port Range assigned by its IP 363 connectivity Service Provider. The traffic is then routed inside the 364 Service Provider's domain and delivered to its final destination 365 (within the service domain or to external domains). 367 For inbound communications (i.e., Towards customers attached to the 368 Service Provider which has activated the procedure detailed in this 369 memo), the traffic is trapped by a dedicated function called: Port 370 Range Router (PRR). This function may be embedded in current routers 371 or hosted by new nodes to be integrated in the IP infrastructure of 372 these Service Providers. Appropriate routing tuning policies are 373 enforced so as to drive the inbound traffic to cross a PRR (see 374 Section 6 for more details). Particularly, each PRR correlate the 375 Primary IP Address and information about the allowed port values with 376 a specific identifier called: routing identifier (e.g., secondary 377 IPv4 address, IPv6 address, point-to-point link identifier, etc). 378 This routing identifier is used to route the packets to the suitable 379 device among all those owning the same IP address (See Section 6.1). 381 Note that for some reasons (e.g., Ease implementation of port-driven 382 RPF (Reverse Path Forwarding) checking, anti-spoofing techniques, 383 etc.), outbound traffic may be constrained to invoke the PRR 384 function. This feature for outbound packets is considered as an 385 engineering option. Service Providers are free to enforce it or not. 387 3.3. Applicability Use Cases 389 The following sub-sections provide a non exhaustive list of the port 390 range solution applicability use cases. Other scenarios may be 391 envisaged. 393 3.3.1. CPE 395 For deployment considerations and reduction of impact on terminals, 396 the recommended scenario (in the context of DSL-type service 397 offerings) of the deployment of the solution is a Provider 398 provisioned CPE. This scenarios hides the connectivity solution and 399 its associated addressing architecture. Machines behind the CPE 400 continue to behave as today. No modification is required on end 401 hosts. 403 3.3.2. End Host 405 When a host, which is capable of an IP address and a port range, but 406 some of the applications on the host may have trouble using those 407 addresses (e.g., they require a specific port to operate), as an 408 implementation choice, the host may hide the port restricted nature 409 of the allocated address by implementing an internal NAT as 410 illustrated in the figure: 412 Host 413 +---------------------+ 414 + Application + 415 + | + 416 + | IPv4p +-----+ + IPv4 address and a port range 417 + |-------| NAT | +--------------------------------- 418 + +-----+ + 419 + + 420 +---------------------+ 422 Figure 1: Internal NAT in a host 424 3.3.3. Point-to-Point Links 426 In point-to-point links it can be assumed that there are only two 427 communicating parties on the link, and thus IP address collisions are 428 easy to avoid. 430 In wireless cellular networks host attached to an access router, such 431 as 3GPP PDN GW or WiMAX ASN GW , over a point-to-point link providing 432 layer 2 IPv4 transport capability. 434 In order to be able to allocate an IP address together with a port 435 range to a host, the access router needs to implement DHCP server or 436 at least act as a DHCP relay or DHCP proxy , while a DHCP server 437 exists in the backend. These setups are illustrated in the following 438 figure. 440 +--------+ | 441 3GPP ---Point to Point link--| 3GPP |------| 442 host <-IPv4 EPS bearer--> | PDN GW | | 443 +--------+ | 444 | IPv4 Internet 445 +--------+ | 446 WiMAX ---Point to Point link--| WiMAX |------| 447 host <-----IPv4 CS------> | ASN GW | | 448 +--------+ | 450 Figure 2: Point-to-point physical links 452 As each host is attaching to the access router with an individual 453 link, both modified and unmodified hosts can be supported 454 simultaneously. This enables incremental deployment of modified 455 hosts that are supporting public IPv4 address conservation by using 456 DHCP to assign IPv4 address and a port range, while continuing to 457 support the legacy hosts using DHCP as currently specified. 459 In this scenario, IPv6 addresses can be used in parallel with any 460 IPv4 address, therefore no tunneling is necessary. 462 If PPP is used, port restricted IPv4 address can also be configured 463 in PPP IPCP option as described in 464 [I-D.boucadair-pppext-portrange-option]. 466 3.3.4. Point-to-Point Tunneled Links 468 From DHCP point of view, tunneled link scenario does not differ very 469 much from L2 point-to-point links as described in the previous 470 section, although there are general concerns regarding tunnels (e.g., 471 decreased MTU). 473 The tunnel is established between a host (or a CPE) and a tunnel 474 endpoint in the host Operator's network. In different scenarios, the 475 tunnel endpoint may be placed at different locations. The tunnel 476 endpoint can be at the first hop router such as 3GPP2 PDSN or 3GPP 477 PDN-GW, or farther off in the network. In one scenario, the tunnel 478 endpoint can be the CGN of DS-Lite 479 [I-D.ietf-softwire-dual-stack-lite]. 481 These example setups are illustrated in the following figure. 482 Tunnel endpoints, 483 implementing DHCPv4 484 server/relay/proxy 486 +-------------+ 487 Host ====IPv4 over IPv6==== | 3GPP2 | | 488 <---PPP & IPv6CP ----> | PDSN |------| 489 (point-to-point) +-------------+ | 490 | 491 +-------------+ | 492 Host ====IPv4 over IPv6==== | 3GPP |------| IPv4 Internet 493 <--IPv6 PDP context--> | GGSN | | 494 (point-to-point) +-------------+ | 495 | 496 +-------------+ | 497 Host ====IPv4 over IPv6==== | IETF |------| 498 <---- IPv6-only -----> | DS-Lite CGN | | 499 network +-------------+ 501 Figure 3: Point-to-point links as IPv4 over IPv6 tunnels over three 502 different accesses 504 Having the tunnel endpoint at the first hop router can be beneficial 505 in setups where arrangement of native dual-stack transport for the 506 last mile is not feasible or cost-effective approach. This can be 507 the case e.g., in 3GPP networks, prior 3GPP Release-8, where a PDP 508 context is capable of transporting only IPv4 or IPv6 packets, and for 509 dual-stack access two parallel PDP contexts are required. 511 For networks which use IP(v6)CP to configure IPv4 and IPv6 addresses 512 to the host, allocating an IPv4 address and a port range to the host 513 to prevent running out of available IPv4 addresses, can also be a 514 feasible solution. In these deployment scenarios, IPv6CP would be 515 used to configure an IPv6 address to the host. The host would then 516 set up the tunnel and use the DHCPv4 extensions defined in this 517 document to request an IPv4 address together with a port range. 518 Examples of such networks include 3GPP2 and BRAS. 520 4. Retrieving IP Configuration Data 522 4.1. Assumption 524 In the context of this section, it is assumed that DHCP (Dynamic Host 525 Configuration Protocol, [RFC2131]) is used to convey IP connectivity 526 information. Other alternatives, such as PPP (Point-to-Point 527 Protocol, [RFC1661] and [I-D.boucadair-pppext-portrange-option]), may 528 be used. The procedure described in this section is only an 529 illustration example. It may be adapted so as to be able to apply in 530 other technological contexts. 532 4.2. Procedure 534 4.2.1. Overview 536 At a bootstrapping phase, a given HGW issues a DHCP_DISCOVER message. 537 This message is sent in broadcast. This message can be relayed by a 538 DHCP Client Relay or be received directly by a DHCP Server. Once 539 this message is received by a DHCP Server, this latter answers the 540 requester by a dedicated DHCP_OFFER message containing a 541 configuration offer. 543 The exchange which intervenes is illustrated in the following figure: 545 +-----+ +-------------+ 546 | HGW | | DHCP Server | 547 +-----+ +-------------+ 548 | | 549 | (1) DHCP DISCOVER | 550 |------------------------------>| 551 | | 552 | | 553 | (2) DHCP OFFER | 554 |<------------------------------| 555 | | 557 Figure 4: DHCP Call Flow 559 A DHCP OFFER message encloses a set of IP-related information so as 560 to access IP connectivity service. Particularly, it includes an IP 561 address together with a new DHCP option, see: 562 [I-D.bajko-pripaddrassign]. 564 Additional information may be included in the DHCP offer. 566 The use of Port Mask DHCP sub-option (similar to subnet mask) makes 567 it possible to extend the notion of Port Range with non-continuous 568 values, for the sake of flexibility. 570 A Port Range is then a set of ports that all have in common a subset 571 of pre-positioned bits. 573 Once a Port Range information is received by a HGW, it constrains its 574 NAT operations to the provisioned range. The number of customers to 575 which an ISP can assign the same IP address depends on the number of 576 allowed port numbers per user. Thus, if N bits are used to build the 577 Port Mask, 2^N customers can be provided with the same IP address. 578 For example: If N == 3, then the Service Provider multiplies by 8 its 579 capacity in term of number of customers to which the connectivity 580 service may be delivered. 582 In the remaining part, Port Mask and Port Range are used 583 interchangeably. 585 4.3. An alternative to avoid DHCP Server modifications 587 To avoid alteration of already in place DHCP servers, this section 588 presents an alternative to implement Port Range assignment procedure. 589 This alternative relies on DHCP Relay Clients or DHCP proxies and not 590 on DHCP servers. These latter are kept unchanged. Their main 591 function is to assign an available IP address. This address is 592 assumed to be routed inside the Service Provider domain. 594 DHCP proxies, in cooperation with the PRR, maintains a set of pre- 595 assignments based on a pre-provisioned Service Provider policy 596 regarding how to build Port Ranges. As an example, if the 597 implemented policy is to assign the same IP address to 4 customers, 598 then 4 Port Ranges per IP address are statically built and then 599 assigned to customers upon request. 601 In this context, DHCP proxies do not relay any IP assignment request 602 until all available Port Ranges are allocated. 604 Figure 5 and Figure 6 provide an example of this option. In this 605 example, CPE-1 and CPE-2 are two CPEs of two distinct customers. 607 CPE-1 sends first its DHCP DISCOVER message. This message is 608 received by the DHCP proxy. Upon receipt, a lookup on available IP 609 address and Port Range is achieved by the DHCP proxy. 611 Since no IP address is available, a DHCP DISCOVER message is 612 forwarded to the DHCP Server. A DHCP OFFER is then sent back. This 613 offer is trapped by the DHCP proxy. 615 The assigned IP address is retrieved and a pre-allocation of a Port 616 Range is achieved. The offer is then updated with the Port Range 617 Information and then relayed to CPE-1. 619 The remaining operations are the same operations as current DHCP 620 exchanges. 622 +-----+ +-----+ +--------+ +------+ 623 |CPE-1| |DHCP | |Binding | |DHCP | 624 | | |proxy| |Table | |Server| 625 +-----+ +-----+ +--------+ +------+ 626 | (1)DHCP DISCOVER | | | 627 |------------------->| | | 628 | |(2) Check if there| | 629 | | is an available | | 630 | | IP @ and a | | 631 | | Port Range | | 632 | |----------------->| | 633 | | | | 634 | |(3) No Available @| | 635 | | | | 636 | |<-----------------| | 637 | | | | 638 | | (4) DHCP DISCOVER| | 639 | |-------------------------------------->| 640 | | (5) DHCP OFFER(IP-Pub-1) | 641 | |<--------------------------------------| 642 | | (6) DHCP REQUEST (IP-Pub-1) | 643 | |-------------------------------------->| 644 | | (7) DHCP ACK(IP-Pub-1) | 645 | |<--------------------------------------| 646 | | | | 647 | |(8)Add IP-Pub-1 | | 648 | | to Ports Range | | 649 | | allocation, | | 650 | |and pre-assign a | 651 | | Port Range to CPE1 | 652 | |----------------->| | 653 |(9)DHCP OFFER(IP-Pub-1, PR1) | | 654 |<-------------------| | | 655 | | | | 656 |(10)DHCP REQUEST(IP-Pub-1, PR1) | | 657 |------------------->| | | 658 | |(11) Assign PR1 to| | 659 | | CPE1 | | 660 | |----------------->| | 661 |(10)DHCP ACK(IP-Pub-1, PR1) | | 662 |------------------->| | | 663 | | | | 665 Figure 5: First Example 667 If CPE-2 requests an IP address, it issues a DHCP DISCOVER message. 668 This message is not relayed to the DHCP Server. A lookup request is 669 executed by the DHCP proxy to check if an IP address and a Port Range 670 are available to be assigned. In this example, a positive answer is 671 sent to the DHCP proxy. A DHCP Offer is then sent to CPE-2 as 672 illustrated in Figure 6. 674 +-----+ +-----+ +--------+ +------+ 675 |CPE-2| |DHCP | |Binding | |DHCP | 676 | | |proxy| |Table | |Server| 677 +-----+ +-----+ +--------+ +------+ 678 | (1)DHCP DISCOVER | | | 679 |------------------->| | | 680 | |(2) Check if there| | 681 | | is an available | | 682 | | IP @ and a | | 683 | | Port Range | | 684 | |----------------->| | 685 | | | | 686 | |(3) OK (IP1) | | 687 | | | | 688 | |<-----------------| | 689 | | | | 690 | | | | 691 | |(4) Allocate IP1 | | 692 | |and Pre-assign a | | 693 | |Port Range to CPE2 | 694 | |----------------->| | 695 |(9)DHCP OFFER(IP-Pub-1, PR2) | | 696 |<-------------------| | | 697 | | | | 698 |(10)DHCP REQUEST(IP-Pub-1, PR2) | | 699 |------------------->| | | 700 | |(11) Assign PR2 to| | 701 | | CPE2 | | 702 | |----------------->| | 703 |(10)DHCP ACK(IP-Pub-1, PR2) | | 704 |------------------->| | | 705 | | | | 707 Figure 6: Second Example 709 5. Required Modifications 711 5.1. CPE 713 Above, we have quoted the case of Home Gateway but the solution can 714 fit to any kind of Customer Premises Equipment (CPE). 716 In order to activate the aforementioned solution, slight 717 modifications are required to be supported by CPEs. Concretely, CPEs 718 MUST be able to constrain their NAT operations and to use only source 719 port numbers within the allocated Port Range. If an IP packet is 720 received by a given Port Range-enabled CPE, with a destination port 721 number outside the assigned Port Range, the packet MUST be discarded. 723 Moreover, Port Range-enabled CPEs MUST be able to enforce 724 configuration data received from the Service Providers so as to 725 constrain its Port Range. More particularly, if DHCP is used to 726 convey configuration data, a particular DHCP option (to be assigned 727 by IANA) is to be supported by that CPE. 729 According to the enforced routing identifier mode, a de-encapsulation 730 function MAY be required to be supported. 732 5.2. End-user Terminals 734 In some deployment scenarios (e.g., mobile), end-hosts should be 735 updated. Concretely, end-hosts MUST be able to constrain their 736 source port numbers and to use only source port numbers within the 737 allocated Port Range. If an IP packet is received by a given Port 738 Range-enabled end-user terminal, with a destination port number 739 outside the assigned Port Range, the packet MUST be discarded. 741 Moreover, Port Range-enabled terminals MUST be able to enforce 742 configuration data received from the Service Providers so as to 743 constrain its Port Range. 745 According to the enforced routing identifier mode, a de-encapsulation 746 function MAY be required to be supported. 748 5.3. Service Provider Infrastructure 750 The IP infrastructure of a given IP Service Provider is maintained 751 slightly unchanged when deploying the Port Range architecture based 752 solution. Only, a new function is introduced. This new function is 753 denoted as PRR. This function is responsible for routing packets to 754 the appropriate end-user's device among those to which the same IP 755 address is assigned by the Service Provider. This operation is 756 denoted as Port-Driven Routing operation since the destination IP 757 address is not sufficient to handle routing operations and the 758 information related to destination port is also required. 760 Except the PRR, all classical operations and practices remain as 761 today's ones. 763 A PRR can be stand-alone server, or it can be hosted into other boxes 764 such existing routers, PDN GW, ASN GW, etc. 766 5.4. DHCP Server Implementations 768 In case DHCP is used to convey IP connectivity information to 769 customers' devices, DHCP server implementations may be modified 770 accordingly. Indeed, DHCP server implementation should be modified 771 so as to be able to support additional options such as Port Range 772 DHCP option. The DHCP server assignment policy can be tuned by the 773 Service Provider. A given Service Provider can provision its DHCP 774 server with the Port Range to be allocated to end users' devices. 776 A second alternative to assign Port Ranges is described in 777 Section 4.3. This alternative does not require any modification of 778 the DHCP Server. Nevertheless, new changes are required to be 779 supported by DHCP proxies. 781 6. Port Range Router 783 6.1. Main Function 785 As stated above, the main function implemented by a PRR is a port- 786 driven routing. In order to implement the port-driven routing, the 787 following operations are achieved by a given PRR: 789 In order to implement the port-driven routing, the following 790 operations are achieved by a given PRR: 792 1. It retrieves both destination IP address and destination port 793 number. 795 2. Based on this couple, the PRR consults its binding table and 796 retrieves the routing identifier. 798 Several modes may be envisaged to assign a routing identifier to be 799 used as a deterministic discriminator to unambiguously identify a 800 device among all those having the same IP address. 802 Hereafter are provided some implementation alternatives: 804 1. If a Secondary-IP address is used as the routing identifier: the 805 PRR consults its binding table and retrieves the corresponding 806 Secondary-IP address associated with a (Destination IP, Port 807 Mask). Once retrieved, the PRR encapsulates the original packets 808 in an IPv4 one with a destination IP address equal to 809 Secondary-IP. This packet is then routed according to 810 instantiated IGP (Interior Gateway Protocol) routes. Once 811 received by the CPE, a de-encapsulation operation is achieved. 812 The original packets is then treated and handled locally. If 813 destination port of that packet is within the Port Range of that 814 CPE, and depending on the local NAT implementation, the packet 815 may be accepted and then proceed to classical NAT operation. 816 Otherwise, the packet is dropped. Note that: 818 A. The scope of the secondary address is limited to the access 819 segment 821 B. The secondary IP address may be an IPv6 address 823 2. Instead of encapsulation, and if source routing is supported, an 824 explicit route is forced. A loose route is indicated in the 825 packets. This loose route contains at least Secondary-IP. The 826 routing of the resulting packet will be based on that address and 827 not the destination one. The packet will be then received by the 828 CPE with that Secondary-IP address. Then, the CPE will route the 829 packet based on the final destination IP address. Since that 830 address is also an IP address of that CPE, the packet is handled 831 locally. The remaining operations are similar to the ones 832 implemented by current CPEs. 834 3. If disjoint routes have been pre-installed so as to unambiguously 835 identify the targeted device among all those having the same IP 836 address, the PRR consults its binding tables and retrieves the 837 index of the route corresponding to that (Destination IP, Port 838 Mask) pair. The original packet is then sent over that route. 839 Since the routes are disjoint, the packet will be received by the 840 targeted CPE. A example is the case where the PRR and the CPEs 841 are directly linked by Ethernet, the route is then identified by 842 the Ethernet MAC address of the CPE. 844 4. The routing identifier can also be the identifier of the L2 845 point-to-point link 847 As for inbound, a new operation is introduced in the path, this 848 operation is a port-driven operation with no modification of the 849 original packet. Further evaluation should be undertaken so as to 850 assess the impact of this operation. 852 The performance experienced by outbound packets is not impacted since 853 no alteration of the issued packets is to be enforced in the path. 854 The experienced QoS (Quality of Service) is then the same as the 855 currently deployed one. 857 6.2. Routing Considerations: Focus on IGP 859 A PRR is inserted in the inbound path in order to execute a port- 860 driven routing. This constraint is translated into an IGP one. 862 Indeed, a given PRR MUST advertise in IGP the primary IP addresses it 863 handles. Doing so, all inbound packets will cross that PRR. 865 In case IPv4 Secondary-IP addresses are used to uniquely identify a 866 CPE among all those having the same Primary-IP address, IPv4 867 Secondary-IP addresses MUST NOT be routable addresses inside core 868 network. These addresses MUST NOT be reachable from the Internet. 869 An example of the scope of those addresses is up to the frontier of 870 an IP access POP (Point of Presence). 872 6.3. Binding Table 874 In order to implement port-driven routing operations, a PRR maintains 875 a binding table which is a collection of entries correlating (IP 876 address, Port Mask) with a routing identifier. 878 This table should not be confused with the NAT table as maintained by 879 a CG-NAT. 881 6.4. Provisioning 883 6.4.1. Needs 885 In order to be able to treat received packets and then to proceed to 886 port-driven routing, a PRR MUST be provisioned appropriately. 887 Concretely, and as stated above, a given PRR needs to maintain a 888 binding table which correlates a destination IP address and a Port 889 Mask with a routing identifier (such as a secondary IPv4 address, 890 IPv6 address, routing index, MAC address, PPP session identifier, 891 etc.). This binding table can be provisioned either by the Service 892 Provider (owing to an internal interface) or by the CPE itself once 893 IP connectivity information has been received from the service 894 platform. 896 These two options are described hereafter. Service Providers are 897 free to implement the option which meets its internal engineering 898 policies. 900 6.4.2. Option 1: CPE-Provisioned PRR 902 Once its IP connectivity configuration is retrieved owing to a 903 dedicated means such as DHCP, a given CPE enforces this new 904 configuration. Particularly, the new received information may 905 contain the following information: 907 {Primary-IP, Port Mask, Default_PRR, Routing Identifier} 909 In case the adopted method for the routing identifier (mentioned in 910 Section 6.1) is a Secondary-IP address, a message is issued by the 911 CPE towards its Default PRR. This message notifies that PRR about 912 the new association: i.e., (Primary-IP, Port Mask) with Secondary-IP. 913 This notification is achieved owing to a new message denoted as BIND. 914 Once received by the PRR, an ACK message must be sent as response. 915 If no ACK message is received, the CPE re-transmits its BIND message. 917 The procedure is sketched in the following figure: 919 +-----+ +-----+ 920 | HGW | | PRR | 921 +-----+ +-----+ 922 | | 923 | (1) BIND | 924 |------------------------------>| 925 | | 926 | | 927 | (2) ACK | 928 |<------------------------------| 929 | | 931 Figure 7: Example of CPE-provisioned PRR 933 Authentication means may be required to prevent creating hostile 934 bindings. 936 6.4.3. Option 2: Provider-Provisioned PRR 938 Here, the provisioning of PRR binding table is undertaken by the 939 Service Provider owing to the activation of appropriate management 940 interfaces. These interfaces are internal to Service Provider's 941 domain and are not visible to end-users. Exchanges between the PRR 942 and the management realms are operated by the Service Provider. An 943 implementation scenario of this option, is that once the DHCP server 944 has assigned an IP address together with a Port Range a dedicated 945 message is issued towards a PRR so as to instantiate a new entry in 946 the binding table of that PRR. The entry can be refreshed or dropped 947 once required. 949 In both options, the structure of the binding tables and the state 950 machine of the PRR are identical. 952 7. Localization Inside a Service Provider's Domain 954 Each service Provider is free to adopt its internal policies for the 955 deployment of PRRs. Nevertheless, we recommend deploying those nodes 956 at access segment in order not to significantly impact end-to-end 957 routing optimization. A PRR function can be embedded in an access 958 router, a DSLAM, etc. 960 Several engineering options may be enforced: 962 o A given IP address is shared between several customers located in 963 the same access POP: In this scenario, only access routers should 964 be updated to support a PRR function. Doing so, communication 965 (more precisely IGP routes) between the customers located in the 966 same POP are optimised. 968 o Re-use the same IP address in several access POP and assign the 969 same port range to all customers of the same POP: In this 970 configuration, a given IP address is assigned to a single customer 971 per POP. For intra-domain communications, and for optimisation 972 purposes, all access routers should enable a PRR function. A far 973 head router in the network should be activated to route inter POP 974 traffic. 976 8. Fragmentation 978 In order to deliver a fragmented IP packet to its final destination 979 (among those having the same IP address), the PRR should activated a 980 dedicated procedure which described hereafter: 982 1. Check if the received packet is a fragment: ((MF == 1 && Fragment 983 Offset == 0) || (Fragment Offset != 0)), else apply the classical 984 PRR routing procedure; 986 2. Check if this fragment is the first one (MF == 1 && Fragment 987 Offset == 0) 989 2.1. In addition to the information retrieved to enforce port 990 range routing, retrieve the source IP address and packet 991 identifier. A fragmentation entry is instantiated. A timer 992 (referred to as fragmentation timer) is associated with this 993 entry. A clean up procedure is achieved when the timer 994 expires. 996 2.2. Retrieve the binding entry to be used to route this 997 first fragment. A pointer to this entry is added to the 998 fragmentation entry. A fragmentation entry includes: 999 destination IP address, source IP address, Identifier, binding 1000 entry identifier and timer. 1002 3. Check if this fragment is not the first one (Fragment Offset != 1003 0) 1005 3.1. Retrieve the source IP address, destination IP address 1006 and Identifier; 1008 3.2 Check if an entry having the same source IP address, 1009 destination IP address and Identifier is instantiated in the 1010 fragmentation table 1012 3.2.1 If yes, retrieve the binding entry pointer from the 1013 fragmentation table. Use the corresponding entry to route 1014 the fragment. 1016 3.2.1 If not (fragments are not received in the order), 1017 launch a timer (which value is small than the fragmentation 1018 timer). This timer is referred to as fragmentation order 1019 timer. Upon expire of this timer, go to Step 3.2. This 1020 step is repeated two or three times. If it fails, the 1021 fragment is dropped. 1023 Note that it is recommended to use a PMTUD path discovery mechanism 1024 (e.g., [RFC1191]). 1026 Security issues related to fragmentation are out of scope of this 1027 document. For more details, refer to [RFC1858] 1029 9. Multicast 1031 In the previous sections, only unicast considerations have been 1032 elaborated. This section focuses on the impacts on multicast 1033 mechanisms and services when a Port Range based solution is 1034 activated. 1036 Since the proposed solution does not require any modification on the 1037 core network of a given service provider / IP network provider, 1038 protocols to build and maintain multicast trees (e.g., PIM-SM 1039 [RFC4601], M-OSPF [RFC1584]) can be activated without any 1040 modification. Concretely, current multicast configurations on core 1041 routers and nodes can be applied without any adaptation. 1043 As far as multicast group membership is concerned, classical 1044 procedures, e.g., IGMPv2 [RFC2236], or IGMPv3 [RFC3376], may be 1045 impacted. 1047 Concretely: 1049 1. If a secondary IP address (see Section 6.1) is used, the 1050 subscription to a multicast group can be done using this address. 1051 Thus, IGMP operations to receive traffic (i.e., IGMP requests) 1052 are not impacted and multicast traffic can be forwarded to the 1053 subscribed hosts; 1055 2. If the shared IP address is used to issue IGMP requests, 1057 A. If distinct public IP addresses are assigned to each customer 1058 which device is attached to the same multicast router: 1059 classical IGMP operations are valid. No adaptation is to be 1060 enforced. Multicast traffic can be forwarded to each 1061 subscribed users without ambiguity. 1063 B. If a same public IP address is assigned to several customers 1064 which devices are attached to the same multicast router: the 1065 attached multicast router should correlate the request source 1066 with the binding table to unambiguously forward the multicast 1067 traffic to the appropriate subscribed user. More precisely, 1068 IGMP states should be updated to include the routing 1069 identifier to be used to forward traffic to the subscribed 1070 host. Appropriate means to uniquely distinguish the source 1071 of IGMP request among those having the same IP address should 1072 be implemented. 1074 + To avoid the modification of IGMP, several virtual router 1075 instances can be instantiated into the same physical node. 1076 Each virtual router manages only distinct IP addresses. 1077 This configuration is similar to the bullet a. 1079 In addition to these considerations, a hurdle can be encountered when 1080 using IGMPv3. Indeed, IGMPv3 messages can specify specific sources 1081 to be used to be excluded. If a shared IP address is assigned to 1082 those sources, traffic issued by other sources having the same IP 1083 address can be impacted. This scenario is not viable in current 1084 multicast deployments since the source of multicast traffic is under 1085 control of a service provider (e.g., head ends in the context of IP 1086 TV service offering) and a not shared IP address would be assigned to 1087 head ends. 1089 10. IGD 2.0 1091 Version 2.0 of IGP specification recommends the usage of a new method 1092 called AddAnyPortMapping() instead of AddPortMapping(). This new 1093 specification will ease the deployment of shared IP addresses. 1095 11. IPSec 1097 Even if IPSec is not deployed for mass market, impacts of solutions 1098 based on shared IP addresses should be evaluated and assessed. 1099 [RFC3947] proposes a solution to solve complications issues 1100 documented in [RFC3715]. Below is described an analysis of the 1101 applicability of [RFC3947] in the context of this solution. 1103 Indeed,[RFC3947] (Section 4, Changing to New Ports), specifies that 1104 if an IKE peer responder is behind a port translating NAT, the 1105 initiator is allowed to use a different port than 4500 to contact it. 1106 The initiator will have to determine which ports to use by contacting 1107 another server or by out of band procedure . Once the initiator 1108 knows which ports to use to traverse the NAT, generally something 1109 like UDP (4500, Z), it initiates using these ports. 1111 In the case both IKE initiator and responder peers are behind a Port 1112 translating NAT, the changing port can be summarized as follows: 1114 Init addr CPE Pub1. addr PRR_CPE Pub. addr Resp. addr 1115 v v v v PRR v 1117 Initiator ---------->CPE-----------------> PRR ---------->CPE----------->Responder 1118 ^ NAT ^ ^ NAT ^ 1119 | | | | 1120 Init addr, PRR_CPE.Pub addr UDP(4500,Z) | | CPE Pub1 addr, Resp.addr (1234,4500) 1121 | | 1122 CPE Pub1 addr, PRR_CPE.Pub addr UDP(1234,Z) 1124 12. ICMP and Other Portless Protocols 1126 The multiplexing of IP flows in PRR is based on the port numbers used 1127 by transport layer protocols such as TCP, UDP, SCTP, and DCCP. 1128 However, the protocols not containing port numbers need special 1129 handling in order to be multiplexed correctly. 1131 As for ICMP messages, identifier field may be used as port number. 1132 The value of this field should be selected from the assigned port 1133 range value. This approach has a limit when both the source and 1134 destination are assigned with a shared IP address. 1136 13. 6to4 1138 A host utilizing 6to4 [RFC3056] with port restricted IPv4 addresses 1139 must pick the 16-bit "SLA ID" value for the 6to4 prefix(es) 1140 construction from the pool of allocated port values. The 1141 multiplexing gateway must then multiplex 6to4 traffic based on "SLA 1142 ID" value as it would multiplex plain IPv4 traffic based on port 1143 values. i.e., for incoming packets the gateway shall look at the 1144 destination IPv4 address and the "SLA ID"-field from tunneled IPv6 1145 packet's destination IPv6 address, and then select the right route as 1146 it would have picked the port number from a transport layer header. 1148 14. Protocols not supported by PRR 1150 The case where Port Range Router is not able to multiplex a protocol 1151 is similar to a case where middle box, such as firewall or NAT, 1152 blocks traffic it is not able or willing to pass trough. The 1153 application is recommended to fallback to UDP encapsulation often 1154 used for NAT traversal, for which gateway is able to perform 1155 multiplexing. 1157 15. Comparison with CG-NAT/LSN 1159 15.1. Generic Hurdles and Focus on Transparency to applications which 1160 enclose IPv4 address in their protocol messages 1162 When deploying a Double NAT scenario, several hurdles will be 1163 encountered by Service Providers. Examples of these hurdles are as 1164 follows: 1166 o End-users won't be able to configure their own port forwarding 1167 policies anymore, whilst with the Port Range solution, the user 1168 can still configure port forwarding (provided the port is within 1169 the allowed range). 1171 o Need to activate a second ALG (Application Level Gateway) at the 1172 core network for some applications (e.g., SIP (Session Initiation 1173 Protocol, [RFC3261]); 1175 o Problems to run servers behind middleboxes with private addresses; 1177 o Complication to enable inbound access; 1179 o Performance issues (e.g., maintaining NAT entries by frequent 1180 (every 30s for instance) keep-alive messages is a real killer for 1181 battery powered devices); 1183 o Interference between the service and network layers: The delivery 1184 of some services (e.g., SIP, DNS (Domain Name Service, [RFC1034]), 1185 and FTP (File Transfer Protocol, [RFC3659])) will require the 1186 knowledge of the underlying network engineering characteristics 1187 (i.e., Presence of intermediate CG-NAT boxes). If distinct 1188 administrative entities are managing the high-level services and 1189 the underlying IP infrastructure, critical problems for the 1190 current Internet business model will be raised. 1192 Besides these generic hurdles, let's consider the ones that may arise 1193 when delivering SIP-based calls in the presence of CG-NAT boxes. 1194 Concretely, the following constraints should be followed: 1196 o The SIP-based Service Provider should be aware about the 1197 underlying IP infrastructure so as to implement appropriate ALGs 1198 (Application Level Gateway). At least two modifications of SIP 1199 messages should be applied: The first one at the Home NAT and the 1200 second one at the CG-NAT. If no such ALG is enabled, no 1201 communication may be established. This constraint is heavy since 1202 it assumes that the same administrative entity administers both 1203 service and network infrastructures. 1205 o NAT mapping entries at the CG-NAT should be maintained by keep- 1206 alive packets so as to be able to deliver incoming messages to 1207 customers' devices located behind the CG-NAT. 1209 o Media flows may encounter some problems to be delivered since RTP 1210 (Real Time Transport Protocol, [RFC1889]) ports may not be opened. 1212 The introduction of CG-NAT nodes may impact heavily the delivery of 1213 SIP-based services. 1215 With a Port Range approach, nothing is changed with regard to the 1216 behavior of a today CPE with NAT: a SIP ALG can be quite easily 1217 implemented to take care of swapping the embedded IP address and port 1218 number in the messages to reflect the outbound IPv4 address and port 1219 of the CPE. On the contrary, running a SIP ALG instance inside the 1220 Carrier-Grade NAT for each SIP client may turn out to be very 1221 complex. Therefore, with the Port Range approach, SIP-based services 1222 are not altered compared to current practices when a CG-NAT is 1223 present in the path. The same mechanisms as today have to be 1224 deployed without any additional constraint nor impact. 1226 Consequently, SIP-based services are not altered and complexity not 1227 increased. 1229 15.2. Focus on Legal Storage 1231 Most National Regulatory Authorities (NRA) require that ISPs provide 1232 the identity of a customer upon request of the authorities. This 1233 requirement is usually denoted as Legal Storage. In order to 1234 implement this requirement, Service Providers have deployed 1235 appropriate infrastructures including memory storage and interface to 1236 their Information Systems. Due to the continuous increase of traffic 1237 exchanged between end users, the amount of data stored by Service 1238 Providers would be also impacted if data relevant to all the sessions 1239 were to be stored. This is considered as a critical issue by Service 1240 Providers. 1242 When deploying a new IP architecture or when modifying the currently 1243 deployed ones, Service Providers should be able to assess its impact 1244 on their Legal Storage infrastructures. Concretely, and because of 1245 the presence of NAPT function the knowledge of the source port number 1246 (simply referred to as port number), along with the source public IP 1247 address (simply referred to as public IP address), is mandatory to be 1248 able to retrieve the appropriate customer (or user) which is 1249 concerned by a given flow. This implies that all NAT mapping 1250 information is to be stored by a given ISP during the whole legal 1251 duration (one year in many countries). 1253 Concretely, and because of the presence of NAPT function (in the CG- 1254 NAT), the knowledge of the source port number (simply referred to as 1255 port number), along with the source public IP address (simply 1256 referred to as public IP address), is mandatory to be able to 1257 retrieve the appropriate customer (or user) which is concerned by a 1258 given flow. This implies that all NAT mapping information is to be 1259 stored by a given ISP during the whole legal duration (one year in 1260 many countries). 1262 When a CG-NAT is deployed, a given Service Provider must store legal 1263 information of the mapped addresses in form of the following tuple: 1265 {Public IP address - Public Port - Private IP address - Private port 1266 - protocol - date and hour of the beginning of address/port 1267 allocation - duration of this allocation (or date and hour of the 1268 allocation end)}. 1270 Note that to actually find the identity of the appropriate customer 1271 which is concerned by a given IP flow, a given ISP must also store 1272 the mapping between the private IP address and the customer 1273 identification. 1275 As for the Port Range based approach, the required information to be 1276 stored is the following tuple (called in the remaining part tuple 1277 with Port Range): 1279 {Public IP address - Port Range - protocol - customer identification 1280 - date and hour of the beginning of the Public IP address and Port 1281 Range allocation - duration of this allocation (or date and hour of 1282 the allocation end)}. 1284 The length of this tuple with Port Range is about: 1286 4 + 3 (2 for the Port Range pattern + 1 for the length) + 20 1287 (customer identification) + 8 (date/time begin) + 8 (date/time end) = 1288 43 bytes. 1290 The Port Range is expected to be allocated for the same duration as 1291 the IP address, namely for a reasonable term (e.g., more than 24 1292 hours conforming to current practices of IP address assignment). 1293 Thus, with regard to the nowadays situation, the additive information 1294 to be stored is only the Port Range. 1296 The allocation of Public IP address and Port Range is expected to be 1297 made for a reasonable term (e.g., more than 24 hours) as the current 1298 practices for the assignment of IP addresses. 1300 In order to illustrate the volume of required data to be stored by 1301 Service Providers,let's consider the following figures: 1303 o 1000 CPEs 1305 o 100 new sessions per 10 minutes per CPE (optimistic, it may be 1306 more) 1308 o each CPE traffics during 6 hour a day 1310 o the public address and Ports Range change each day (changing these 1311 parameters may be even less frequent) 1313 The amount of data to be stored per month when the Port Range 1314 approach is enabled (i.e., use of a Port Range) is around 1,3 Mbytes. 1315 The one for CG-NAT is around 3,1 Gbytes (Gbytes and not Mbytes) per 1316 month. 1318 - Port Range based architecture: 1320 Amount for 1000 CPEs per month = 1000 (CPEs) * 43 (bytes for the 1321 tuple with Port Range) * 30 (days in a month) = 1,3 Mbytes 1323 -CG-NAT: 1325 {Public IP address - Public Port - Private IP address - Private port 1326 - protocol - date and hour of the beginning of address/port 1327 allocation - duration of this allocation (or date and hour of the 1328 allocation end)} 1330 = 4 + 2 + + 4 + 2 + 1 + 8 + 8 1331 = 29 bytes. 1333 Note : Storing the customer identification attached to the private 1334 address is considered negligible in the calculation. 1336 Amount for 1000 CPEs per month 1338 = 1000 (CPEs) * 100 (number of new sessions in 10 mn) * 36 (number of 1339 10 mn durations in 6 h) * 29 (number of bytes per session) * 30 (days 1340 in a month) 1342 = 3,1 Gbytes 1344 Based on this data, a factor of more than 1000 is to be observed 1345 between the two solutions (in favor of the Port Range approach). 1347 This factor (i.e., ratio of 1000) is important to be taken into 1348 account since CAPEX and OPEX would be impacted drastically for the 1349 implementation of this legal requirement. Indeed, a large investment 1350 must be forecast(ed) for deploying a suitable infrastructure (e.g., 1351 physical nodes and storage capacity). Service Providers should 1352 carefully consider this impact on their legal storage 1353 infrastructures. 1355 This factor may be optimized if a port ranges are assigned to 1356 customers on the CG-NAT device. 1358 Moreover, as the deployment of the FTTH (Fiber To The Home) will 1359 progress it is expected that the number of sessions per user will be 1360 growing which will further increase the amount of data to be stored 1361 in CG-NAT but not in the Port Range approach. 1363 15.3. Session Handling in CG-NAT 1365 The complexity of the real-time processing is related to the number 1366 of operations to handle the TCP and UDP sessions and associated 1367 complexity. 1369 CG-NAT is a NAT and therefore has to monitor dynamically all the 1370 sessions in order to identify if a public port number is still in-use 1371 or can be released. For this purpose, a CG-NAT needs in particular 1372 to handle timeouts and to scrutinize all TCP session states. In 1373 addition the entries enclosed in the NAT table maintained by a given 1374 CG-NAT is of a much greater complexity than the table in the PRR. 1375 The CG-NAT needs to keep all the mappings [Public IP address - Public 1376 Port - protocol - Private IP address - Private Port] for each session 1377 (UDP or TCP) whilst the PRR has to keep only one entry [Public IP 1378 address - Port Range - route to the CPE] per CPE. 1380 For example, if the CPE handles 100 active sessions, the factor is 1381 100 between a CG-NAT and a PRR. For a CPE with 1000 active sessions 1382 (which may not be so rare for clients making high use of peer to peer 1383 applications) the factor raises to 1000. Again, this is not simply a 1384 matter of factor; with CG-NAT, handling a session is complex as 1385 already indicated (e.g., timeouts, scrutinizing of session states, 1386 NAT entries real time maintenance, etc.). 1388 As for the PRR, it does not handle sessions but simply routes packets 1389 (routing based on both IP address and Port Range). 1391 CG-NAT can either be used in a context where the CPE keeps its NAT 1392 (yielding a double NAT configuration) or in a configuration where the 1393 CPE is a mere router (or bridge) without any NAT. In the first case 1394 (i.e., CPE without NAT) there is only one level of NAT in the path 1395 (at the CG-NAT level). All the complexity, today distributed among 1396 the CPEs, becomes concentrated into CG-NAT equipment. The cost of 1397 the CG-NAT is not balanced by a relative simplification of the CPEs 1398 (no NAT embedded). In a double NAT configuration the relative 1399 simplification of the CPE (no NAT embedded) is not even attained. 1401 15.4. Peer-to-Peer applications 1403 P2P applications can not work at full capabilities when a CG-NAT is 1404 in the path. This is because the peers can not initiate 1405 communications toward a peer behind a CG-NAT. Consequently the 1406 communications must pass through a server which greatly reduces the 1407 throughput capabilities of the system. A palliative could be for P2P 1408 applications to use a STUN server so that they can know the public 1409 address and port allocated by the CG-NAT and to keep alive the port 1410 (by periodical short messages). 1412 There is no such problem with the Port Range approach where the user 1413 can still as today set manually the port forwarding policies onto his 1414 CPE (e.g., Through WEB page, provided the choice of the port were 1415 restricted to the allocated Port Range, etc.). 1417 16. IANA Considerations 1419 TBC. 1421 17. Security Considerations 1423 This section will be completed in the next version of this draft. 1425 18. Contributors 1427 These authors have contributed to this memo: 1429 o Jean-Luc Grimault (France Telecom, 1430 jeanluc.grimault@orange-ftgroup.com) 1432 o Alain Villefranque (France Telecom, 1433 alain.villefranque@orange-ftgroup.com ) 1435 19. Acknowledgements 1437 The authors would like to thank Dave THALER and Yoann NOISETTE, for 1438 their extensive review and technical input, and Mohammed KASSI LAHLOU 1439 for his suggestion regarding the involvement of the DHCP client 1440 relay. We would also like to thank Pierrick MORAND and Mohammed 1441 ACHEMLAL for their support and suggestions. 1443 6to4 text has been proposed by D. THALER. 1445 20. References 1447 20.1. Normative References 1449 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1450 STD 13, RFC 1034, November 1987. 1452 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1453 November 1990. 1455 [RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, 1456 March 1994. 1458 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1459 RFC 1661, July 1994. 1461 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1462 Considerations for IP Fragment Filtering", RFC 1858, 1463 October 1995. 1465 [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V. 1466 Jacobson, "RTP: A Transport Protocol for Real-Time 1467 Applications", RFC 1889, January 1996. 1469 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1470 3", BCP 9, RFC 2026, October 1996. 1472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1473 Requirement Levels", BCP 14, RFC 2119, March 1997. 1475 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1476 RFC 2131, March 1997. 1478 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1479 Thyagarajan, "Internet Group Management Protocol, Version 1480 3", RFC 3376, October 2002. 1482 20.2. Informative References 1484 [I-D.bajko-pripaddrassign] 1485 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 1486 "Port Restricted IP Address Assignment", 1487 draft-bajko-pripaddrassign-01 (work in progress), 1488 March 2009. 1490 [I-D.boucadair-behave-ipv6-portrange] 1491 Boucadair, M., Levis, P., Grimault, J., Villefranque, A., 1492 and M. Kassi-Lahlou, "Flexible IPv6 Migration Scenarios in 1493 the Context of IPv4 Address Shortage", 1494 draft-boucadair-behave-ipv6-portrange-01 (work in 1495 progress), March 2009. 1497 [I-D.boucadair-pppext-portrange-option] 1498 Boucadair, M., Levis, P., Grimault, J., and A. 1499 Villefranque, "Port Range Configuration Options for PPP 1500 IPCP", draft-boucadair-pppext-portrange-option-00 (work in 1501 progress), February 2009. 1503 [I-D.fuller-240space] 1504 Fuller, V., "Reclassifying 240/4 as usable unicast address 1505 space", draft-fuller-240space-02 (work in progress), 1506 March 2008. 1508 [I-D.ietf-softwire-dual-stack-lite] 1509 Durand, A., Droms, R., Haberman, B., and J. Woodyatt, 1510 "Dual-stack lite broadband deployments post IPv4 1511 exhaustion", draft-ietf-softwire-dual-stack-lite-00 (work 1512 in progress), March 2009. 1514 [I-D.savolainen-indicating-240-addresses] 1515 Savolainen, T., "A way for a host to indicate support for 1516 240.0.0.0/4 addresses", 1517 draft-savolainen-indicating-240-addresses-01 (work in 1518 progress), February 2009. 1520 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 1521 2", RFC 2236, November 1997. 1523 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1524 via IPv4 Clouds", RFC 3056, February 2001. 1526 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1527 A., Peterson, J., Sparks, R., Handley, M., and E. 1528 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1529 June 2002. 1531 [RFC3659] Hethmon, P., "Extensions to FTP", RFC 3659, March 2007. 1533 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 1534 (NAT) Compatibility Requirements", RFC 3715, March 2004. 1536 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1537 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1538 January 2005. 1540 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1541 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1542 Protocol Specification (Revised)", RFC 4601, August 2006. 1544 Authors' Addresses 1546 Mohamed Boucadair (editor) 1547 France Telecom 1548 3, Av Francois Chateau 1549 Rennes 35000 1550 France 1552 Email: mohamed.boucadair@orange-ftgroup.com 1554 Pierre Levis 1555 France Telecom 1556 42 rue des Coutures 1557 BP 6243 1558 Caen Cedex 4 14066 1559 France 1561 Email: pierre.levis@orange-ftgroup.com 1562 Gabor Bajko 1563 Nokia 1565 Email: gabor.bajko@nokia.com 1567 Teemu Savolainen 1568 Nokia 1569 Hermiankatu 12 D 1570 FI-33720 TAMPERE 1571 Finland 1573 Email: teemu.Savolainen@nokia.com