idnits 2.17.1 draft-ymbk-aplusp-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (May 31, 2011) is 4712 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC5737' is mentioned on line 501, but not defined == Outdated reference: A later version (-04) exists of draft-bajko-pripaddrassign-03 == Outdated reference: A later version (-09) exists of draft-boucadair-pppext-portrange-option-04 == Outdated reference: A later version (-04) exists of draft-dec-stateless-4v6-01 == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-08 == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-07 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush, Ed. 3 Internet-Draft Internet Initiative Japan 4 Intended status: Experimental May 31, 2011 5 Expires: December 2, 2011 7 The A+P Approach to the IPv4 Address Shortage 8 draft-ymbk-aplusp-10 10 Abstract 12 We are facing the exhaustion of the IANA IPv4 free IP address pool. 13 Unfortunately, IPv6 is not yet deployed widely enough to fully 14 replace IPv4, and it is unrealistic to expect that this is going to 15 change before the depletion of IPv4 addresses. Letting hosts 16 seamlessly communicate in an IPv4-world without assigning a unique 17 globally routable IPv4 address to each of them is a challenging 18 problem. 20 This draft proposes an IPv4 address sharing scheme, treating some of 21 the port number bits as part of an extended IPv4 address (Address 22 plus Port, or A+P). Instead of assigning a single IPv4 address to a 23 single customer device, we propose to extend the address field by 24 using bits from the port number range in the TCP/UDP header as 25 additional end point identifiers, thus leaving a reduced range of 26 ports available to applications. This means assigning the same IPv4 27 address to multiple clients (e.g., CPE, mobile phones), each with its 28 assigned port-range. In the face of IPv4 address exhaustion, the 29 need for addresses is stronger than the need to be able to address 30 thousands of applications on a single host. If address translation 31 is needed, the end-user should be in control of the translation 32 process - not some smart boxes in the core. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in RFC 2119 [RFC2119]. 40 Status of this Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on December 2, 2011. 57 Copyright Notice 59 Copyright (c) 2011 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.1. Problems with Carrier Grade NATs . . . . . . . . . . . . . 4 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3. Design Constraints and Functions . . . . . . . . . . . . . . . 6 78 3.1. Design Constraints . . . . . . . . . . . . . . . . . . . . 6 79 3.2. A+P Functions . . . . . . . . . . . . . . . . . . . . . . 7 80 3.3. Overview of the A+P Solution . . . . . . . . . . . . . . . 8 81 3.3.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 9 82 3.3.2. Address Realm . . . . . . . . . . . . . . . . . . . . 11 83 3.3.3. Reasons for Allowing Multiple A+P Gateways . . . . . . 15 84 3.3.4. Overall A+P Architecture . . . . . . . . . . . . . . . 17 85 3.4. A+P experiments . . . . . . . . . . . . . . . . . . . . . 17 86 4. Stateless A+P Mapping Function . . . . . . . . . . . . . . . . 18 87 4.1. Stateless A+P Mapping gateway (SMAP) Function 88 description . . . . . . . . . . . . . . . . . . . . . . . 18 89 4.2. Implementation Mode . . . . . . . . . . . . . . . . . . . 20 90 4.3. Towards IPv6-only Networks . . . . . . . . . . . . . . . . 22 91 4.4. PRR: On Stateless and Binding Table Modes . . . . . . . . 22 92 4.5. General recommendations on SMAP . . . . . . . . . . . . . 23 93 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 24 94 5.1. A+P Deployment Models . . . . . . . . . . . . . . . . . . 24 95 5.1.1. A+P for Broadband Providers . . . . . . . . . . . . . 24 96 5.1.2. A+P for Mobile Providers . . . . . . . . . . . . . . . 24 97 5.1.3. A+P from the Provider Network Perspective . . . . . . 25 98 5.2. Dynamic Allocation of Port Ranges . . . . . . . . . . . . 27 99 5.3. Example of A+P-forwarded Packets . . . . . . . . . . . . . 28 100 5.3.1. Forwarding of Standard Packets . . . . . . . . . . . . 33 101 5.3.2. Handling ICMP . . . . . . . . . . . . . . . . . . . . 33 102 5.3.3. Fragmentation . . . . . . . . . . . . . . . . . . . . 34 103 5.3.4. Limitations of the A+P approach . . . . . . . . . . . 34 104 5.3.5. Port allocation strategy agnostic . . . . . . . . . . 35 105 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 106 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 107 8. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 108 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 109 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 110 10.1. Normative References . . . . . . . . . . . . . . . . . . . 38 111 10.2. Informative References . . . . . . . . . . . . . . . . . . 38 112 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 40 114 1. Introduction 116 This document describes a technique to deal with the imminent IPv4 117 address space exhaustion. Many large Internet Service Providers 118 (ISPs) face the problem that their networks' customer edges are so 119 large that it will soon not be possible to provide each customer with 120 a unique public IPv4 address. Therefore, although undesirable, 121 address sharing, in the same molds as NAT, is inevitable. 123 To allow end-to-end connectivity between IPv4 speaking applications 124 we propose to extend the semantics of the IPv4 address with bits from 125 the UDP/TCP header. Assuming we could limit the applications' port 126 addressing to any number of bits lower than 16, we can increase the 127 effective size of an IPv4 address by remaining additional bits of up 128 to 16. In this scenario, 1 to 65536 customers could be multiplexed 129 on the same IPv4 address, while allowing them a fixed or dynamic 130 range of 1 to 65536 ports. Customers could for example receive 131 initial fixed port range, defined by operator and dynamically request 132 additional blocks, depending on their contract. We call this 133 "extended addressing" or "A+P" (Address plus Port) addressing. The 134 main advantage of A+P is that it preserves the Internet "end-to-end" 135 paradigm by not requiring translation (at least for some ports) of an 136 IP address. 138 1.1. Problems with Carrier Grade NATs 140 Various forms of NATs will be installed at various levels and places 141 in the IPv4-Internet to achieve address compression. This document 142 argues for mechanisms where this happens as close to the edge of the 143 network as possible, thereby minimizing damage to the End-to-End 144 Principle and allowing end-customers to retain control over the 145 address and port translation. Therefore it is essential to create 146 mechanisms to "bypass" NATs in the core when applicable and keep the 147 control at the end-user. 149 With Carrier Grade NATs in the core of the network the user is 150 trapped behind unchangeable application policies, and the deployment 151 of new applications is hindered by the need to implement the 152 corresponding Application Level Gateways (ALGs) on the CGNs. This is 153 the opposite of the "end-to-end" model of the Internet. 155 With the smarts at the edges, one can easily deploy new applications 156 between consenting end-points by merely tweaking the NATs at the 157 corresponding Customer Premises Equipment (CPE), or even upgrading 158 them to a new version that supports a specific ALG. 160 Today's NATs are typically mitigated by offering the customers 161 limited control over them, e.g. port forwarding or UPnP/NAT-PMP. 163 However, this is not expected to work with CGNs. CGN proposals - 164 other than DS-Lite [I-D.ietf-softwire-dual-stack-lite] with A+P or 165 PCP [I-D.ietf-pcp-base]- admit that it is not expected that 166 applications that require specific port assignment or port mapping 167 from the NAT box will keep working. 169 Another issue with CGN is the trade-off between session state and 170 network placement. The furthest from the edge the CGN placed, the 171 more session state needs to be kept due to larger subscriber 172 aggregation, and more disruption in the case of a failure. In order 173 to reduce the state, CGNs would end up somewhere closer to the edge. 174 The CGN hence trades scalability for the amount of state that needs 175 to be kept, which makes optimally placing a CGN a hard engineering 176 problem 178 In some deployment scenarios, CGN can be seen as single point of 179 failure and therefore the availability of delivered services are 180 impacted by the ones of CGN s devices. Means to ensure state 181 synchronisation and failover would be required to allow for service 182 continuity whenever a failure occurs. 184 Intra-domain paths may not be optimal for communications between two 185 nodes connected to the same domain deploying CGNs, hence leading to 186 path stretches. 188 2. Terminology 190 This document makes use of the following terms: 192 Public Realm: This realm contains only public routable IPv4 193 addresses. Packets in this realm are forwarded based on the 194 destination IPv4 address 196 A+P Realm: This realm contains both public routable IPv4 and also 197 A+P addresses. 199 A+P Packet: A regular IPv4 packet is forwarded based on the 200 destination IPv4 address and the TCP/UDP port numbers. 202 Private Realm: This realm contains IPv4 addresses that are not 203 globally routed. They may be taken from the [RFC1918] range. 204 However, this document does not make such an assumption. We 205 regard as private address space any IPv4 address, which needs to 206 be translated in order to gain global connectivity, irrespective 207 of whether it falls in [RFC1918] space or not. 209 Port Range Router (PRR): A device that forwards A+P packets. 211 Customer Premises Equipment (CPE): cable/DSL modem. 213 Provider Edge Router (PE): Customer aggregation router 215 Provider Border Router (BR): Providers edge to other providers 217 Network Core Routers (Core): Provider routers which are not at the 218 edges. 220 3. Design Constraints and Functions 222 The problem of address space shortage is first felt by providers with 223 a very large end-user customer base, such as broadband providers and 224 mobile service providers. Though the cases and requirements are 225 slightly different, they share many commonalities. In the following 226 we develop a set of overall design constraints for solutions 227 addressing the IPv4 address shortage problem. 229 3.1. Design Constraints 231 We regard several constraints as important for our design: 233 1) End-to-End is under customer control: Customers shall have 234 the ability to deploy new application protocols at will. 235 IPv4 address shortage should not be a license to break the 236 Internet's end-to-end paradigm. 238 2) Backward compatibility: Approaches should be transparent to 239 unaware users. Devices or existing applications should be 240 able to work without modification. Emergence of new 241 applications should not be limited. 243 3) Highly-scalable and minimal state core: Minimal state should 244 be kept inside the ISP's network. If the operator is rolling 245 out A+P incrementally, it is understood there may be state in 246 the core in the non-A+P part of such a roll-out. 248 4) Efficiency vs. complexity: Operators should have the 249 flexibility to trade off port multiplexing efficiency and 250 scalability and end-to-end transparency. 252 5) "Double-NAT" should be avoided: Multiple gateway devices 253 might be present in a path, and once one has done some 254 translation, those packets should not be re-translated. 256 6) Legal traceability: ISPs must be able to provide the identity 257 of a customer from the knowledge of the IPv4 public address 258 and the port. This should have as low an impact as is 259 reasonable on storage by the ISP. We assume that NATs on 260 customer premises do not pose much of a problem, while 261 provider NATs need to keep additional logs. 263 7) IPv6 deployment should be encouraged. NAT444 strongly biases 264 the users to the deployment of RFC 1918 addressing. 266 Constraint 5 is important: while many techniques have been deployed 267 to allow applications to work through a NAT, traversing cascaded NATs 268 is crucial if NATs are being deployed in the core of a provider 269 network. 271 3.2. A+P Functions 273 The A+P architecture can be split into three distinct functions: 274 encaps/decaps, NAT, and signaling. 276 Encaps/decaps function: is used to forward port-restricted A+P- 277 packets over intermediate legacy devices. The encapsulation function 278 takes an IPv4 packet, looks up the IP and TCP/UDP headers, and puts 279 the packet into the appropriate tunnel. The state needed to perform 280 this action is comparable to a forwarding table. The decapsulation 281 device SHOULD check if the source address and port of packets coming 282 out of the tunnel are legitimate (e.g., see [BCP38]). Based on the 283 result of such a check, the packet MAY be forwarded untranslated, it 284 MAY be discarded or MAY be NATed. In this document we refer to a 285 device that provides this encaps/decaps functionality as Port-Range- 286 Router (PRR). 288 Network Address Translation (NAT) function: is used to connect legacy 289 end-hosts. Unless upgraded, end-hosts or end-systems are not aware 290 of A+P restrictions and therefore assume a full IP address. The NAT 291 function performs any address or port translation, including 292 Application Level Gateways (ALGs) whenever required. The state that 293 has to be kept to implement this function is the mapping for which 294 external addresses and ports have been mapped to which internal 295 addresses and ports, just as in CPEs embedding NAT today. A subtle, 296 but very important, difference should be noted here: the customer has 297 control over the NATing process or might choose to "bypass" the NAT. 298 If this is done, we call the NAT a large scale NAT (LSN). However, 299 if the NAT that does NOT allow the customer to control the 300 translation process, we refer to as a CGN. 302 Signaling function: is used in order to allow A+P-aware devices get 303 to know which ports are assigned to be passed through untranslated 304 and what will happen to packets outside the assigned port-range 305 (e.g., could be NATed or discarded). Signaling may also be used to 306 learn the encapsulation method and any endpoint information needed. 307 In addition, the signaling function may be used to dynamically assign 308 the requested port-range. 310 3.3. Overview of the A+P Solution 312 As mentioned above, the core architectural elements of the A+P 313 solution are three separated and independent functions: the NAT 314 function, the encaps/decaps function, and the signaling function. 315 The NAT function is similar to a NAT as we know it today: it performs 316 a translation between two different address realms. When the 317 external realm is public IPv4 address space, we assume that the 318 translation is many-to-one, in order to multiplex many customers on a 319 single public IPv4 address. The only difference with a traditional 320 NAT (Figure 1) is that the translator might only be able to use a 321 restricted range of ports when mapping multiple internal addresses 322 onto an external one, e.g., the external address realm might be port- 323 restricted. 325 "internal-side" "external-side" 326 +-----+ 327 internal | N | external 328 address <---| A |---> address 329 realm | T | realm 330 +-----+ 332 Traditional NAT 334 Figure 1 336 The encaps/decaps function, on the other hand, is the ability to 337 establish a tunnel with another end-point providing the same 338 function. This implies some form of signaling to establish a tunnel. 339 Such signaling can be viewed as integrated with DHCP or as a separate 340 service. Section 3.3.1 discusses the constraints of this signaling 341 function. The tunnel can be an IPv6 or IPv4 encapsulation, a layer-2 342 tunnel, or some other form of softwire. Note that the presence of a 343 tunnel allows unmodified, naive, or even legacy devices between the 344 two endpoints. 346 Two or more devices which provide the encaps/decaps function and are 347 linked by tunnels to form an A+P subsystem. The function of each 348 gateway is to encapsulate and decapsulate respectively. Figure 2 349 depicts the simplest possible A+P subsystem, that is, two devices 350 providing the encaps/decaps function. 352 +------------------------------------+ 353 Private | +----------+ tunnel +----------+ | Public 354 address --|-| gateway |==========| gateway |-|-- address 355 realm | +----------+ +----------+ | realm 356 +------------------------------------+ 357 A+P subsystem 359 A simple A+P subsystem 361 Figure 2 363 Within an A+P subsystem, the public address realm is extended by 364 using bits from the port number when forwarding packets. Each device 365 is assigned one address from the external realm and a range of port 366 numbers. Hence, devices which are part of an A+P subsystem can 367 communicate with the public realm without the need for address 368 translation (i.e., preserving end-to-end packet integrity): an A+P 369 packet originated from within the A+P subsystem can be simply 370 forwarded over tunnels up to the endpoint, where it gets decapsulated 371 and routed in the external realm. 373 3.3.1. Signaling 375 The following information needs to be available on all the gateways 376 in the A+P subsystem. It is expected that there will be a signaling 377 protocols such as [I-D.bajko-pripaddrassign], 378 [I-D.boucadair-dhcpv6-shared-address-option], 379 [I-D.boucadair-pppext-portrange-option], or [I-D.ietf-pcp-base]. 381 The information that needs to be shared is the following: 383 o a set of public IPv4 addresses, 385 o for each IPv4 address a starting point for the allocated port- 386 range, 388 o number of delegated ports, 390 o optional key that enables partial or full preservation of entropy 391 in port randomization - see [I-D.bajko-pripaddrassign], 393 o lifetime for each IPv4 address and allocated port-set, 394 o the tunneling technology to be used (e.g., "IPv6-encapsulation") 396 o addresses of the tunnel endpoints (e.g., IPv6 address of tunnel 397 endpoints) 399 o whether or not NAT function is provided by the gateway 401 o a device identification number and some authentication mechanisms 403 o a version number and some reserved bits for future use. 405 Note that the functions of encapsulation and decapsulation have been 406 separated from the NAT function. However, to accommodate legacy 407 hosts, NATing is likely to be provided at some point in the path; 408 therefore the availability or absence of NATing MUST be communicated 409 in signaling, as A+P is agnostic about NAT placement. 411 The port-ranges can be allocated in two different ways: 413 o If applications or end-hosts behind the CPE are not UPnPv2/NAT-PMP 414 aware, then the CPE SHOULD request ports via mechanisms, e.g. as 415 described in [I-D.bajko-pripaddrassign] and 416 [I-D.boucadair-pppext-portrange-option]. Note that different 417 port-ranges can have different lifetimes, and the CPE is not 418 entitled to use them after they expire - unless it refreshes those 419 ranges. It is up to the ISP to put mechanisms in place, that 420 determine what percentage of already allocated port-ranges should 421 be exhausted before a CPE may requests additional ranges, how 422 often the CPE can request additional ranges, and so on. (To 423 prevent Denial of Service attacks.) 425 o If applications behind the CPE are UPnPv2/NAT-PMP aware additional 426 ports MAY be requested through that mechanism. In this case the 427 CPE should forward those requests to the LSN and the LSN should 428 reply reporting if the requested ports are available or not (and 429 if they are not available some alternatives should be offered). 430 Here again, to prevent potential denial of service attacks, 431 mechanism should be in place to prevent UPnPv2/NAT-PMP packet 432 storms and fast port allocation. Detailed description of this 433 mechanism, called PCP is described in [I-D.ietf-pcp-base]. 435 Whatever signaling mechanism is used inside the tunnels, DHCP, IPCP, 436 or PCP-based, synchronization between signaling server and PRR must 437 be established in both directions. For example, if we use DHCP as 438 signaling mechanism, the PRR must communicate to DHCP server at least 439 its IP range. The DHCP server then starts to allocate IPs and port- 440 ranges to CPEs and communicates back to the PRR which IP and port 441 range have been allocated to which CPE, so the PRR knows to which 442 tunnel redirect incoming traffic. In addition, DHCP MUST also 443 communicate lifetimes of port-ranges assigned to CPE via the PRR. 444 DHCP server may be co-located with the PRR function to ease address 445 management and also to avoid the need to introduce a communication 446 protocol between the PRR and DHCP. 448 If UPnPv2/NAT-PMP is used as dynamic port allocation mechanism, the 449 PRR must also communicate to the DHCP (or IPCP) server to avoid those 450 ports. The PRR must somehow (DHCP or IPCP options) communicate back 451 to CPE that allocation of ports was successful, so CPE adds those 452 ports to existing port ranges. 454 Note that operation can be even simplified if a fixed length of port 455 ranges are assigned to all customers and no differentiation is 456 implemented based on port range length. In such case, the binding 457 table maintained by the PRR can be dynamically built upon the receipt 458 of a first packet form a port-restricted device. 460 3.3.2. Address Realm 462 Each gateway within the A+P subsystem manages a certain portion of 463 A+P address space, that is, a portion of IPv4 space which is extended 464 by borrowing bits from the port number. This address space may be a 465 single, port-restricted IPv4 address. The gateway MAY use its 466 managed A+P address space for several purposes: 468 o Allocation of a sub-portion of the A+P address space to other 469 authenticated A+P gateways in the A+P subsystem (referred to as 470 delegation). We call the allocated sub-portion delegated address 471 space. 473 o Exchange of (untranslated) packets with the external address 474 realm. For this to work, such packets MUST use source address and 475 port belonging to the non-delegated address space. 477 If the gateway is also capable of performing the NAT function, it MAY 478 translate packets arriving on an internal interface which are outside 479 of its managed A+P address space into non-delegated address space. 481 Hence, a provider may have 'islands' of A+P as they slowly deploy 482 over time. The provider does not have to replace CPE until they want 483 to provide the A+P function to an island of users or even to one 484 particular user in a sea of non-A+P users. 486 An A+P gateway ("A"), accepts incoming connections from other A+P 487 gateways ("B"). Upon connection establishment (provided appropriate 488 authentication), B would "ask" A for delegation of an A+P address. 489 In turn, A will inform B about its public IPv4 address, and will 490 delegate a portion of its port-range to B. In addition, A will also 491 negotiate the encaps/decaps function with B (e.g., let B know the 492 address of the decaps device/other-end-point of the tunnel). 494 This could be implemented for example via a NAT-PMP or DHCP-like 495 solution. In general the following rule applies: A sub-portion of 496 the managed A+P address space is delegated as long as devices below 497 ask for it, otherwise private IPv4 is provided to support legacy 498 hosts. 500 In the following example, IPv4 address reserved for documentation 501 blocks defined in [RFC5737] are used. 503 private +-----+ +-----+ public 504 address ---| B |==========| A |--- Internet 505 realm +-----+ +-----+ 507 Address space realm of A: 508 public IPv4 address = 192.0.2.1 509 port range = 0-65535 511 Address space realm of B: 512 public IPv4 address = 192.0.2.1 513 port range = 2560-3071 515 Configuration example 517 Figure 3 519 Figure 3 illustrates a sample configuration. Note that A might 520 actually consist of three different devices: one that handles 521 signaling requests from B; one device that performs encapsulation and 522 decapsulation; and, if provided, one device that performs NATing 523 function (e.g., LSN). Packet forwarding is assumed to be as follows: 524 In the "out-bound" case, a packet arrives from the private address 525 realm to B. As stated above, B has two options: it can either apply 526 or not apply the NAT function. The decision depends upon the 527 specific configuration and/or the capabilities of A and B. Note that 528 NAT functionality is required to support legacy hosts, however, this 529 can be done at either of the two devices A or B. The term NAT refers 530 to translating the packet into the managed A+P address (B has address 531 192.0.2.1 and ports 2560-3071 in the example above). We then have 532 two options: 534 1) B NATs the packet. The translated packet is then tunneled to A. 535 A recognizes that the packet has already been translated, because 536 the source address and port match the delegated space. A 537 decapsulates the packet and releases it in the public Internet. 539 2) B does not NAT the packet. The untranslated packet is then 540 tunneled to A. A recognizes that the packet has not been 541 translated, so A forwards the packet to a co-located NATing 542 device, which translates the packet and routes it in the public 543 Internet. This device, e.g. - an LSN, has to store the mapping 544 between the source port used to NAT and the tunnel where the 545 packet came from, in order to correctly route the reply. Note 546 that A cannot use a port number from the range that has been 547 delegated to B. As a consequence A has to assign a part of its 548 non-delegated address space to the NATing function. 550 "Inbound" packets are handled in the following way: a packet from the 551 public realm arrives at A. A analyzes the destination port number to 552 understand whether the packet needs to be NATed or not. 554 1) If the destination port number belongs to the range that A 555 delegated to B, then A tunnels the packet to B. B NATs the packet 556 using its stored mapping and forwards the translated packet to 557 the private domain. 559 2) If the destination port number is from the address space of the 560 LSN, then A passes the packet on to the co-located LSN which uses 561 its stored mapping to NAT the packet into the private address 562 realm of B. The appropriate tunnel is stored as well in the 563 mapping of the initial NAT. The LSN then encapsulates the packet 564 to B, which decapsulates it and normally routes it within its 565 private realm. 567 3) Finally, if the destination port number neither falls in a 568 delegated range, nor into the address range of the LSN, A 569 discards the packet. If the packet is passed to the LSN, but no 570 mapping can be found, the LSN discards the packet. 572 Observe that A must be able to receive all IPv4 packets destined to 573 the public IPv4 address (192.0.2.1 in the example), so that it can 574 make routing decisions according to the port number. On the other 575 hand, B receives IPv4 packets destined to the public IPv4 address 576 only via the established tunnel with A. In other words, B uses the 577 public IPv4 address just for translation purposes, but it is not used 578 to make routing decisions. This allows us to keep the routing logic 579 at B as simple as described above, while enabling seamless 580 communication between A+P devices sharing the same public IPv4 581 address. 583 private +-----+ +-----+ public 584 address ---| B |==========| A |--- Internet 585 realm 1 +-----+ +-----+ 586 | 587 private +-----+ | 588 address ---| C |============/ 589 realm 2 +-----+ 591 Address space realm of A: 592 public IPv4 address = 192.0.2.1 593 port range = 0-65535 595 Address space realm of B: 596 public IPv4 address = 192.0.2.1 597 port range = 2560-3071 599 Address space realm of C: 600 public IPv4 address = 192.0.2.1 601 port range = 0-2559 603 Hierarchical A+P 605 Figure 4 607 Consider the example shown in Figure 4. Here both B and C use the 608 encaps/decaps function to establish a tunnel with A, and they are 609 assigned the same public IPv4 address with different, non-overlapping 610 port-ranges. Assume that a host in B's private realm sends a packet 611 destined to address 192.0.2.1 and port 2000, and that B has been 612 instructed to NAT all packets destined to 192.0.2.1. Under these 613 assumptions, B receives the packet and NATs it using its own public 614 IPv4 address (192.0.2.1) and a port selected from its configured 615 port-range (e.g., 3000). B then tunnels the translated packet to A. 616 When A receives the packet via the tunnel, it looks at the 617 destination address and port, recognizes C's delegated range, and 618 then tunnels the packet to C. Observe that, apart from stripping the 619 tunnel header, A handles the packet as if it came from the public 620 Internet. When C receives the packet, it NATs the destination 621 address into one address chosen from its private address realm, while 622 keeping the source address (192.0.2.1) and port (3000) untranslated. 623 Return traffic is handled the same way. Such a mechanism allows 624 hosts behind A+P devices to communicate seamlessly even when they 625 share the same public IPv4 address. 627 Please refer to Section 4 for a discussion of an alternative A+P 628 mechanism that does not incur in path stretches penalties for intra- 629 domain communication. 631 3.3.3. Reasons for Allowing Multiple A+P Gateways 633 Since each device in an A+P subsystem provides the encaps/decaps 634 function, new devices can establish tunnels and become in turn part 635 of an A+P subsystem. As noted above, being part of an A+P subsystem 636 implies the capability of talking to the external address realm 637 without any translation. In particular, as described in the previous 638 section, a device X in an A+P subsystem can be reached from the 639 external domain by simply using the public IPv4 address and a port 640 which has been delegated to X. Figure 5 shows an example where three 641 devices are connected in a chain. In other words, A+P signaling can 642 be used to extend end-to-end connectivity to the devices which are in 643 an A+P subsystem. This allows A+P-aware applications (or OSes) 644 running on end hosts to enter an A+P subsystem and exploit 645 untranslated connectivity. 647 There are two modes for end-hosts to gain fine-grained control of 648 end-to-end connectivity. The first is where actual end-hosts perform 649 the NAT function and the encaps/decaps function which is required to 650 join the A+P subsystem. This option works in a similar way to the 651 NAT-in-the-host trick employed by virtualization software such as 652 VMware, where the guest operating system is connected via a NAT to 653 the host operating system. The second mode is applications which 654 autonomously ask for an A+P address and use it to join the A+P 655 subsystem. This capability is necessary for some applications that 656 require end-to-end connectivity (e.g., applications that need to be 657 contacted from outside). 659 +---------+ +---------+ +---------+ 660 internal | gateway | | gateway | | gateway | external 661 realm --| 1 |======| 2 |======| 3 |-- realm 662 +---------+ +---------+ +---------+ 664 An A+P subsystem with multiple devices 666 Figure 5 668 Whatever the reasons might be, the Internet was built on a paradigm 669 that end-to-end connectivity is important. A+P makes this still 670 possible in a time where address shortage forces ISPs to use NATs at 671 various levels. In such sense, A+P can be regarded as a way to 672 bypass NATs. 674 +---+ (customer2) 675 |A+P|-. +---+ 676 +---+ \ NAT|A+P|-. 677 \ +---+ | 678 \ | forward if in-range 679 +---+ \+---+ +---+ / 680 |A+P|------|A+P|----|A+P|---- 681 +---+ /+---+ +---+ \ 682 / NAT if necessary 683 / (cust1) (prov. (e.g., provider NAT) 684 +---+ / router) 685 |A+P|-' 686 +---+ 688 A complex A+P subsystem 690 Figure 6 692 Figure 6 depicts a complex scenario, where the A+P subsystem is 693 composed by multiple devices organized in a hierarchy. Each A+P 694 gateway decapsulates the packet and then re-encapsulates it again to 695 the next tunnel. 697 A packet can either be NATed when it enters the A+P subsystem, or at 698 intermediate devices, or when it exits the A+P subsystem. This could 699 be for example a gateway installed within the provider's network, 700 together with a LSN. Then each customer operates its own CPE. 701 However, behind the CPE applications might also be A+P-aware and run 702 their own A+P-gateways, which enables them to have end-to-end 703 connectivity. 705 One limitation applies, if "delayed translation" is used (e.g., 706 translation at the LSN instead of the CPE). If devices using 707 "delayed translation" want to talk to each other they SHOULD use A+P 708 addresses or out-of-band addressing. 710 3.3.4. Overall A+P Architecture 712 A+P architecture 714 IPv4 Full-A+P AFTR CGN 715 | | | | 716 <-- Full IPv4 ---- Port range ---- Port range ---- Provider ---> 717 allocated & dynamic & LSN NAT ONLY 718 allocation (NAT on CPE (No mechanism) 719 (no NAT) (NAT on CPE) and on LSN) for customer to 720 bypass CGN) 722 Figure 7: A+P overall architecture 724 The A+P architecture defines various deployment options within an 725 ISP. Figure 7 shows the spectrum of deployment options. On the far 726 left is the common deployment method for broadband subscribers today, 727 an IPv4 address unrestricted with full port-range. Full-A+P refers 728 to a port-range allocation from the ISP. The customer must operate 729 an A+P-aware CPE device and no NATing functionality is provided by 730 the ISP. AFTR, such as DS-Lite [I-D.ietf-softwire-dual-stack-lite], 731 is a hybrid. There is NAT present in the core (in this document 732 referred to as LSN), but the user has the option to "bypass" that NAT 733 in one form or an other, for example via A+P, NAT-PMP, etc... 734 Finally, a service provider which only deploys CGN, will place a NAT 735 in the providers core and does not allow the customer to "bypass" the 736 translation process or modify ALGs on the NAT. The customer is 737 provider-locked. Notice that all options (besides full IPv4) require 738 some form of tunneling mechanism (e.g., 4in6) and a signaling 739 mechanism (see Section 3.3.1). 741 3.4. A+P experiments 743 There are implementations of A+P as well as documented experiments. 744 France Telecom did experiments, that are described in 745 [I-D.deng-aplusp-experiment-results]. As seen in that experiment, 746 most tested applications are unaffected. There are problems with 747 torrent protocol and applications, as listening port is out of A+P 748 port range and some UPnP may be required to make it work with A+P 750 Problems with BitTorrent have already been experienced in the wild by 751 users trapped behind a non-UPnP-capable CPE. The current workaround 752 for the end user is to statically map ports, which can be done in the 753 A+P scenario as well. 755 Bittorrent tests and experiments in shared IP and port range 756 environments are well described in 757 [I-D.boucadair-behave-bittorrent-portrange]. Conclusions in that 758 document tell us that two limitations were experienced. The first 759 occurred when two clients sharing the same IP address tried to 760 simultaneously retrieve the SAME file located in a SINGLE remote 761 peer. The second limitation occured when a client tried to download 762 a file located on several seeders, when those seeders shared the same 763 IP address. Mutual file sharing between hosts having the same IP 764 address has been checked. Indeed, machines having the same IP 765 address can share files with no alteration compared to current IP 766 architectures. 768 Working implementations of A+P can be found in ISC AFTR 769 (http://www.isc.org/software/aftr), FT Orange opensource A+P 770 (http://opensourceaplusp.weebly.com/) and 4RD from ipinfusion.com 771 (stateless A+P). 773 4. Stateless A+P Mapping Function 775 4.1. Stateless A+P Mapping gateway (SMAP) Function description 777 SMAP stands for Stateless A+P Mapping. This function is responsible 778 to encapsulate (Resp., decapsulate), in a stateless scheme, IPv4 779 packets in (Resp. from) IPv6 ones. A SMAP function may be hosted in 780 a PRR, end-user device, etc. 782 As mentioned in Section 4.1 of [RFC6052], the suffix part may enclose 783 the port. 785 Stateless A+P Mapping gateway (SMAP) consists in two basic functions 786 as described in Figure 8. 788 1. SMAP encapsulates an IPv4 packet, destined to a shared IPv4 789 address, in IPv6 one. The IPv6 source address is constructed using 790 an IPv4-Embedded IPv6 address [RFC6052] from the IPv4 source address 791 and port number plus the IPv6 prefix which has been provisioned to 792 the node performing the SMAP function. The destination IPv6 address 793 is constructed using the shared IPv4 destination address and port 794 number plus the IPv6 prefix which has been provisioned to the SMAP 795 function and which is dedicated to IPv4 destination addresses. 797 2. SMAP extracts IPv4 incoming packets from IPv6 incoming ones which 798 have IPv6 source addresses belonging to the prefix of the node 799 performing the SMAP function. Extracted IPv4 packets are then 800 forwarded to the point identified by the IPv4 destination address and 801 port number. 803 +-------------------+ 804 | |----IPv6---\ 805 ----IPv4---\| |----IPv4---\\ 806 -----------/| |-----------// 807 | |-----------/ 808 | SMAP | 809 | | /--IPv6----- 810 /---IPv4----| |//---IPv4---- 811 \-----------| |\\----------- 812 | | \----------- 813 +-------------------+ 815 Figure 8: Stateless A+P Mapping Gateway Function 817 A SMAP-enabled node will perform the stateless 6/4 mapping function 818 for all public shared IPv4 addresses for which it was designated as a 819 stateless 6/4 mapping gateway. 821 To perform stateless 6/4 mapping function a SMAP gateway must: 823 o be provided with an IPv6 prefix (i.e., Pref6). The SMAP gateway 824 uses this prefix to construct IPv6 source addresses for all IPv4 825 shared addresses for which it was designated as a SMAP gateway. The 826 IPv6 prefix may be provisioned statically or dynamically (e.g., DHCP) 828 o be able to know the IPv6 prefix of the node serving as another SMAP 829 gateway for IPv4 destination addresses. This prefix may be known in 830 various ways: 832 * Default or Well Known Prefix (i.e., 64:ff9b::/96) which was 833 provisioned statically or dynamically; 835 * Retained at the reception of incoming IPv4-in-IPv6 encapsulated 836 packets; 838 * Discovered at the communication starting thanks to mechanisms as 839 DNS resolution for example. 841 When the SMAP-enabled node receives IPv4 packets with IPv4 source 842 addresses for which it was not designated as a SMAP gateway, it will 843 not perform stateless 6/4 mapping function for those packets. Those 844 packets will be handled in a classical way (i.e., forwarded, dropped 845 or locally processed). 847 When the SMAP-enabled node receives IPv6 packets with IPv6 addresses 848 which do not match with its IPv6 prefix, it will not perform the 849 stateless 6/4 mapping function for those packets. Those packets will 850 be handled in a classical way (i.e., forwarded, dropped or locally 851 processed). 853 4.2. Implementation Mode 855 In this configuration, the node A performs the stateless mapping 856 function on the received IPv4 traffic (encapsulated in IPv6 packets) 857 before forwarding to the node B. The node B performs the stateless 858 mapping function on the received IPv6 traffics (extracting IPv4 859 packets) before forwarding the IPv4 traffic to the destination 860 identified by the IPv4 destination address and port number. In the 861 opposite direction and as previously, the node B performs the 862 stateless mapping function on the received IPv4 traffics 863 (encapsulating in IPv6 packets) before forwarding to the node A. The 864 node A performs the stateless mapping function on the received IPv6 865 traffic (extracting IPv4 packets) before forwarding the IPv4 traffic 866 to the point identified by the IPv4 destination address and port 867 number. In this case, only IPv6 traffic is managed in the network 868 segment between the nodes A and B. 870 +------+ +------+ 871 | |----IPv6---\ | | 872 ----IPv4---\| |----IPv4---\\| |----IPv4---\ 873 -----------/| |-----------//| |-----------/ 874 | |-----------/ | | 875 | SMAP | | SMAP | 876 | | /----IPv6---| | 877 /---IPv4----| |//---IPv4----| |/---IPv4---- 878 \-----------| |\\-----------| |\----------- 879 | | \-----------| | 880 +------+ +------+ 881 node A node B 883 Figure 9 885 Several deployment scenarios of the SMAP function may be envisaged in 886 the context of Port Range based solutions: 888 o A SMAP function is embedded in a port-restricted device. Other 889 SMAP-enabled nodes are deployed in the boundaries between IPv6- 890 enabled realms and IPv4 ones. This scenario may be particularly 891 deployed for intra-domain communications so as to interconnect 892 heterogeneous realms (i.e., IPv6/IPv4) within the same AS. 894 o A SMAP function is embedded in a port-restricted device. Other 895 SMAP-enabled nodes are deployed in the interconnection segment (with 896 adjacent IPv4-only ones) of a given AS. This deployment scenario is 897 more suitable for service providers targeting the deployment of IPv6 898 since it eases the migration to full IPv6. Core nodes are not 899 required to activate anymore both IPv4 and IPv6 transfer 900 capabilities. 902 Other considerations regarding the interconnection of SMAP-enabled 903 domains should be elaborated. The following provides a non 904 exhaustive list of interconnection schemes. 906 o The interconnection of two domains implementing the SMAP function 907 may be deployed via IPv4 Internet (Figure 10): This means that IPv4 908 packets encapsulated in IPv6 one are transferred using IPv6 until 909 reaching the first SMAP-node. Then these packets are de- 910 encapsulated and are forwarded using IPv4 transfer capabilities. A 911 remote SMAP-enabled node will receive those packets and proceeds to 912 an IPv4-in-IPv6 encapsulation. These packets are then routed 913 normally until reaching the port-restricted devices which de- 914 encapsulates the packets. 916 +------+ +------+ +--------+ +------+ +------+ 917 | |--IPv6--\ | | | | | |---IPv6--\ | | 918 | |--IPv4--\\| |---|-IPv4---|--\| |---IPv4--\\| | 919 | |--------//| |---|--------|--/| |---------//| | 920 | |--------/ | | |Internet| | |---------/ | | 921 | SMAP | | SMAP | | IPv4 | | SMAP | | SMAP | 922 | | /--IPv6--| | | | | | /---IPv6--| | 923 | |//--IPv4--| |/--|-IPv4---|---| |//--IPv4---| | 924 | |\\--------| |\--|--------|---| |\\---------| | 925 | | \--------| | | | | | \---------| | 926 +------+ +------+ +--------+ +------+ +------+ 927 Source node A node B Destination 929 Figure 10: Interconnection Scenario 1 931 o A second scheme is to interconnect two realms implementing the SMAP 932 function using IPv6 (Figure 11). An IPv6 prefix (i.e., Pref6) 933 assigned by IANA is used for this service. If appropriate routing 934 configuration have been enforced, then the IPv6 encapsulated packets 935 will be routed until the final destination. In order to implement 936 this model, IPv4-inferred IPv6 prefixes are required to be injected 937 in the IPv6 inter-domain routing tables. 939 +------+ +------------+ +------+ 940 | | | | | | 941 | |----IPv6-----|----IPv6----|----IPv6----\ | | 942 | |----IPv4-----|------------|----IPv4----\\| | 943 | |-------------|------------|------------//| | 944 | |-------------|------------|------------/ | | 945 | SMAP | | Internet v6| | SMAP | 946 | | /-----IPv6--|------------|-----IPv6-----| | 947 | |//---IPv4----|------------|-------IPv4---| | 948 | |\\-----------|------------|--------------| | 949 | | \-----------|------------|--------------| | 950 | | | | | | 951 +------+ +------------+ +------+ 952 Source Destination 954 Figure 11: Interconnection Scenario 2 956 4.3. Towards IPv6-only Networks 958 The deployment of SMAP function allows for smooth migration of 959 networks to IPv6-only scheme while maintaining the delivery of IPv4 960 connectivity services to customers. The delivery of IPv4 961 connectivity services over an IPv6-only network does not require any 962 stateful function to be deployed on the core network. Owing to this 963 A+P mode, both the IPv4 service continuity and migration to an IPv6- 964 only deployment model are facilitated. 966 4.4. PRR: On Stateless and Binding Table Modes 968 SMAP section discusses two modes: the binding and the stateless 969 modes. Dynamic port allocation is not a feature of the stateless 970 mode but it is supported in the binding mode. In the binding mode, 971 distinct external IPv4 addresses may be used but this is not 972 recommended. 974 o Stateless Mode 976 Complete stateless mapping implies that the IPv4 address and the 977 significant bits coding the port range are reflected inside the IPv6 978 prefix assigned to the port-restricted device. This can be achieved 979 either by embedding the full IPv4 address and the significant bits in 980 the IPv6 prefix or by applying an algorithmic approach. Two 981 alternatives are offered when such a stateless mapping is to be 982 enabled: 984 - either using the IPv6 prefix already used for native IPv6 traffic, 985 - or provide two prefixes to the port-restricted device: one for the 986 native IPv6 traffic and one for the IPv4 traffic. 988 Note that: 990 - Providing two IPv6 prefixes has the advantages of allowing a /64 991 prefix for the port-restricted device along with another prefix 992 (e.g., a /56 or /64) for native IPv6 traffic. This alternative 993 spares the service provider to relate the native IPv6 traffic 994 addressing plan to the IPv4 addressing plan. The drawback is the 995 burden to allocate two prefixes to each port-restricted device and to 996 route them. In addition, an address selection issue may be 997 encountered. 999 - Providing one prefix for both needs (e.g., a /56 or a /64) spares 1000 the service provider to handle two types of IPv6 prefix for the port- 1001 restricted device and in routing tables. But the drawback is that it 1002 somewhat links strongly the IPv4 addressing plan to the allocated 1003 IPv6 prefixes. 1005 As mentioned in Section 4.1 of [RFC6052], the suffix part may enclose 1006 the port. 1008 o Binding Table Mode 1010 Another alternative is to assign a "normal" IPv6 prefix to the port- 1011 restricted device and to use a binding table, which can be hosted by 1012 a service node, to correlate the (shared IPv4 address, Port Range) 1013 with an IPv6 address part of the assigned IPv6 prefix. For 1014 scalability reasons, this table should be instantiated within PRR- 1015 enabled nodes which are close to the port-restricted devices. The 1016 number of required entries if hosted at interconnection segment would 1017 be equal to the amount of subscribed users (one per port-restricted 1018 device). 1020 4.5. General recommendations on SMAP 1022 If Stateless A+P Mapping (SMAP) type of implementation is deployed 1023 over intermediate IPv6-ONLY-capable devices, it is recommended that 1024 default-routes are configured and IPv4 routing table is not "leaked" 1025 into IPv6 routing table in terms to have reachability for the packets 1026 going towards the internet. 1028 One of stateless A+P variants is 4RD [I-D.despres-intarea-4rd] 1030 5. Deployment Scenarios 1032 5.1. A+P Deployment Models 1034 5.1.1. A+P for Broadband Providers 1036 Some large broadband providers will not have enough public IPv4 1037 address space to provide every customer with a single IP. The 1038 natural solution is sharing a single IP address among many customers. 1039 Multiplexing customers is usually accomplished by allocating 1040 different port numbers to different customers somewhere within the 1041 network of the provider. 1043 It is expected that, when the provider wishes to enable A+P for a 1044 customer or a range of customers, the CPE can be upgraded or replaced 1045 to support A+P encaps/decaps functionality. Ideally the CPE also 1046 provides NATing functionality. Further, it is expected that at least 1047 another component in the ISP network provides the corresponding A+P 1048 functionality, and hence is able to establish an A+P subsystem with 1049 the CPE. This device is referred to as A+P router or port-range 1050 router (PRR), and could be located close to PE routers. The core of 1051 the network MUST support the tunneling protocol (which SHOULD be 1052 IPv6, as per Constraint 7) but MAY be another tunneling technology 1053 when necessary. In addition, we do not wish to restrict any 1054 initiative of customers who might want to run an A+P-capable network 1055 on or behind their CPE. To satisfy both Constraints 1 and 2 1056 unmodified legacy hosts should keep working seamlessly, while 1057 upgraded/new end-systems should be given the opportunity to exploit 1058 enhanced features. 1060 5.1.2. A+P for Mobile Providers 1062 In the case of mobile service provider the situation is slightly 1063 different. The A+P border is assumed to be the gateway (e.g., GGSN/ 1064 PDN GW of 3GPP, or ASN GW of WiMAX). The need to extend the address 1065 is not within the provider network, but on the edge between the 1066 mobile phone devices and the gateway. While desirable, IPv6 1067 connectivity may or may not be provided. 1069 For mobile providers we use the following terms and assumptions: 1071 1. Provider Network (PN) 1073 2. Gateway (GW) 1075 3. Mobile Phone device (phone) 1076 4. Devices behind phone, e.g., laptop computer connecting via phone 1077 to Internet. 1079 We expect that the gateway has a pool of IPv4 addresses and is always 1080 in the data-path of the packets. Transport between the gateway and 1081 phone devices is assumed to be an end-to-end layer-2 tunnel. We 1082 assume that phone as well as gateway can be upgraded to support A+P. 1083 However, some applications running on the phone or devices behind the 1084 phone (such as laptop computers connecting via the phone), are not 1085 expected to be upgraded. Again, while we do not expect that devices 1086 behind the phone will be A+P aware/upgraded we also do not want to 1087 hinder their evolution. In this sense the mobile phone would be 1088 comparable to the CPE in the broadband provider case; the gateway to 1089 the PRR/LSN box in the network of the broadband provider. 1091 5.1.3. A+P from the Provider Network Perspective 1093 ISPs suffering from IPv4 address space exhaustion are interested in 1094 achieving a high address space compression ratio. In this respect, 1095 an A+P subsystem allows much more flexibility than traditional NATs: 1096 the NAT can be placed at the customer, and/or in the provider 1097 network. In addition hosts or applications can request ports and 1098 thus have untranslated end-to-end connectivity. 1100 +---------------------------+ 1101 private | +------+ A+P-in +-----+ | dual-stacked 1102 (RFC1918) --|-| CPE |==-IPv6-==| PRR |-|-- network 1103 space | +------+ tunnel +-----+ | (public addresses) 1104 | ^ +-----+ | 1105 | | IPv6-only | LSN | | 1106 | | network +-----+ | 1107 +----+----------------- ^ --+ 1108 | | 1109 on customer within provider 1110 premises and control network 1112 A simple A+P subsystem example 1114 Figure 12 1116 Consider the deployment scenario in Figure 12, where an A+P subsystem 1117 is formed by the CPE and a PRR within the ISP core network, 1118 preferably close to the customer edge, and represents the border from 1119 where on packets are forwarded based on address and port. The 1120 provider MAY deploy a LSN co-located with the PRR to handle packets 1121 that have not been translated by the CPE. In such a configuration, 1122 the ISP allows the customer to freely decide whether the translation 1123 is done at the CPE or at the LSN. In order to establish the A+P 1124 subsystem, the CPE will be configured automatically (e.g. via a 1125 signaling protocol, that conforms to the requirements stated above). 1127 Note that the CPE in the example above is only provisioned with an 1128 IPv6 address on the external interface. 1130 +------------ IPv6-only transport ------------+ 1131 | +---------------+ | | | 1132 | |A+P-application| | +--------+ | +-----+ | dual-stacked 1133 | | on end-host |=|==| CPE w/ |==|==| PRR |-|-- network 1134 | +---------------+ | +--------+ | +-----+ | (public addresses) 1135 +---------------+ | +--------+ | +-----+ | 1136 private IPv4 <-*--+->| NAT | | | LSN | | 1137 address space \ | +--------+ | +-----+ | 1138 for legacy +|--------------|----------+ 1139 hosts | | 1140 | | 1141 end-host with | CPE device | provider 1142 upgraded | on customer | network 1143 application | premises | 1145 An extended A+P subsystem with end-host running A+P-aware 1146 applications 1148 Figure 13 1150 Figure 13 shows an example of how an upgraded application running on 1151 a legacy end-host can connect to another host in the public realm. 1152 The legacy host is provisioned with a private IPv4 address allocated 1153 by the CPE. Any packet sent from the legacy host will be NATed 1154 either at the CPE (if configured to do so), or at the LSN (if 1155 available). 1157 An A+P-aware application running on the end-host MAY use the 1158 signaling described in Section 3.3.1 to connect to the A+P-subsystem. 1159 In this case, the application will be delegated some space in the A+P 1160 address realm, and will be able to contact the public realm (i.e., 1161 the public Internet) without the need for translation. 1163 Note that part of A+P signaling is that the NATs are optional. 1164 However, if neither the CPE nor the PRR provides NATing 1165 functionality, then it will not be possible to connect legacy end- 1166 hosts. 1168 To enable packet forwarding with A+P, the ISP MUST install at its A+P 1169 border a PRR which encaps/decaps packets. However, to achieve a 1170 higher address space compression ratio and/or to support CPEs without 1171 NATing functionality, the ISP MAY decide to provide an LSN as well. 1172 If no LSN is installed in some part of the ISP's topology, all CPE in 1173 that part of the topology MUST support NAT functionality. For 1174 reasons of scalability, it is assumed that the PRR is located within 1175 the access-portion of the network. The CPE would be configured 1176 automatically (e.g. via an extended DHCP or NAT-PMP, which has the 1177 signaling requirements stated above) with the address of the PRR, and 1178 if a LSN is being provided or not. Figure 12 illustrates a possible 1179 deployment scenario. 1181 5.2. Dynamic Allocation of Port Ranges 1183 Allocating a fixed number of ports to all CPEs may lead to exhaustion 1184 of ports for high usage customers. This is a perfect recipe for 1185 upsetting more demanding customers. On the other hand, allocating to 1186 all customers ports sufficient to match the needs of peak users will 1187 not be very efficient. A mechanism for dynamic allocation of port 1188 ranges allows the ISP to achieve two goals; a more efficient 1189 compression ratio of number of customers on one IPv4 address and, on 1190 the other hand, not limiting the more demanding customers' 1191 communication. 1193 Additional allocation of ports, or port ranges may be made after an 1194 initial static allocation of ports. 1196 The mechanism would prefer allocations of port ranges from the same 1197 IP address as the initial allocation. If it is not possible to 1198 allocate an additional port range from the same IP, then mechanism 1199 can allocate a port range from another IP within the same subnet. 1200 With every additional port range allocation, the PRR updates its 1201 routing table. The mechanism for allocating additional port ranges 1202 may be part of normal signaling that is used to authenticate CPE to 1203 ISP. 1205 The ISP controls the dynamic allocation of port ranges by the PRR by 1206 setting the initial allocation size and maximum number of allocations 1207 per CPE, or the maximum allocations per subscription, depending on 1208 subscription level. There is a general observation that the more 1209 demanding customer uses around 1024 ports when heavily communicating. 1210 So, for example, a first suggestion might be 128 ports initially and 1211 then dynamic allocations of ranges of 128 ports up to 511 more 1212 allocations maximum. A configured maximum number of allocations 1213 could be used to prevent one customer acting in destructive manner 1214 should they become infected. The maximum number of allocations might 1215 also be more finely grained, with parameters of how many allocations 1216 a user may request per some time frame. If this is used, evasive 1217 applications may need to be limited in their bad behavior, for 1218 example one additional allocation per minute would considerably slow 1219 a port request storm. 1221 There is likely no minimum request size. This is because A+P-aware 1222 applications running on end-hosts MAY request a single port (or a few 1223 ports) for the CPE to be contacted on (e.g., VoIP clients register a 1224 public IP and a single delegated port from the CPE, and accept 1225 incoming calls on that port). The implementation on the CPE or PRR 1226 will dictate how to handle such requests for smaller blocks: For 1227 example, half of available blocks might be used for "block- 1228 allocations", 1/6 for single port requests, and the rest for NATing. 1230 Another possible mechanism to allocate additional ports is UPnP/ 1231 NAT-PMP (as defined in Section 3.3.1), if applications behind CPE 1232 support it. In case of the LSN implementation (DS-Lite), as 1233 described in the A+P overall architecture section, signaling packets 1234 are simply forwarded by the CPE to the LSN and back to the host 1235 running the application which requested the ports, and PRR allocates 1236 requested port to appropriate CPE. The same behavior may be chosen 1237 with AFTR, if requested ports are outside of static initial port 1238 allocation. If a full A+P implementation is selected, than UPnPv2/ 1239 NAT-PMP packets are accepted by the CPE, processed, and the requested 1240 port number is communicated through normal signaling mechanism 1241 between CPE and PRR tunnel endpoints (PCP). 1243 5.3. Example of A+P-forwarded Packets 1245 This section provides a detailed example of A+P setup, configuration, 1246 and packet flow from an end-host connected to A+P Service Provider to 1247 any host in the IPv4 Internet, and how the return packets flow back. 1248 The following example discusses an A+P-unaware end-host, where the 1249 NATing is done at the CPE. Figure 14 illustrates how the CPE 1250 receives an IPv4 packet from the end-user device. We first describe 1251 the case where the CPE has been configured to provide the NAT 1252 functionality (e.g., by the customer through interaction with a 1253 website, or automatic signaling). In the following, we call a packet 1254 which is translated at the CPE an A+P-forwarded packet, an analogy 1255 with the port-forwarding function employed in today's CPEs. Upon 1256 receiving a packet from the internal interface, the CPE translates, 1257 encapsulates and forwards it to the PRR. The NAT on the CPE is 1258 assumed to have a default route to the public realm through its 1259 tunnel interface. 1261 When the PRR receives the A+P-forwarded packet, it de-capsulates the 1262 inner IPv4 packet and checks the source address. If the source 1263 address does match the range assigned to A+P enabled CPEs, then the 1264 PRR simply forwards the decapsulated packet onward. This is always 1265 the case for A+P-forwarded packets. Otherwise, the PRR assumes that 1266 the packet is not A+P-forwarded, and passes it to the LSN function, 1267 which in-turn translates and forward the packet based on the 1268 destination address. Figure 14 shows the packet flow for an outgoing 1269 A+P-forwarded packet. 1271 +-----------+ 1272 | Host | 1273 +-----+-----+ 1274 | | 198.51.100.2 1275 IPv4 datagram 1 | | 1276 | | 1277 v | 198.51.100.1 1278 +---------|---------+ 1279 |CPE | | 1280 +--------|||--------+ 1281 | ||| 2001:db8::2 1282 | ||| 192.0.2.3 (100-200) 1283 IPv6 datagram 2| ||| 1284 | |||<-IPv4-in-IPv6 1285 | ||| 1286 -----|-|||------- 1287 / | ||| \ 1288 | ISP access network | 1289 \ | ||| / 1290 -----|-|||------- 1291 | ||| 1292 v ||| 2001:db8::1 1293 +--------|||--------+ 1294 |PRR ||| | 1295 +---------|---------+ 1296 | | 192.0.2.1 1297 IPv4 datagram 3 | | 1298 -----|--|-------- 1299 / | | \ 1300 | ISP network / | 1301 \ Internet / 1302 -----|--|-------- 1303 | | 1304 v | 203.0.113.1 1305 +-----+-----+ 1306 | IPv4 Host | 1307 +-----------+ 1309 Figure 14: Forwarding of Outgoing A+P-forwarded Packets 1311 +-----------------+--------------+-----------------------------+ 1312 | Datagram | Header field | Contents | 1313 +-----------------+--------------+-----------------------------+ 1314 | IPv4 datagram 1 | IPv4 Dst | 203.0.113.1 | 1315 | | IPv4 Src | 198.51.100.2 | 1316 | | TCP Dst | 80 | 1317 | | TCP Src | 8000 | 1318 | --------------- | ------------ | --------------------------- | 1319 | IPv6 Datagram 2 | IPv6 Dst | 2001:db8::1 | 1320 | | IPv6 Src | 2001:db8::2 | 1321 | | IPv4 Dst | 203.0.113.1 | 1322 | | IPv4 Src | 192.0.2.3 | 1323 | | TCP Dst | 80 | 1324 | | TCP Src | 100 | 1325 | --------------- | ------------ | --------------------------- | 1326 | IPv4 datagram 3 | IPv4 Dst | 203.0.113.1 | 1327 | | IPv4 Src | 192.0.2.3 | 1328 | | TCP Dst | 80 | 1329 | | TCP Src | 100 | 1330 +-----------------+--------------+-----------------------------+ 1332 Datagram header contents 1334 An incoming packet undergoes the reverse process. When the PRR 1335 receives an IPv4 packet on an external interface, it first checks 1336 whether the destination address falls within the A+P CPE delegated 1337 range or not. If the address space was delegated, then PRR 1338 encapsulates the incoming packet and forwards it through the 1339 appropriate tunnel for that IP/port range. If the address space was 1340 not-delegated the packet would be handed to the LSN to check if a 1341 mapping is available. 1343 Figure 15 shows how an incoming packet is forwarded, under the 1344 assumption that the port number matches the port range which was 1345 delegated to the CPE. 1347 +-----------+ 1348 | Host | 1349 +-----+-----+ 1350 ^ | 198.51.100.2 1351 IPv4 datagram 3 | | 1352 | | 1353 | | 198.51.100.1 1354 +---------|---------+ 1355 |CPE | | 1356 +--------|||--------+ 1357 ^ ||| 2001:db8::2 1358 | ||| 192.0.2.3 (100-200) 1359 IPv6 datagram 2| ||| 1360 | |||<-IPv4-in-IPv6 1361 | ||| 1362 -----|-|||------- 1363 / | ||| \ 1364 | ISP access network | 1365 \ | ||| / 1366 -----|-|||------- 1367 | ||| 1368 | ||| 2001:db8::1 1369 +--------|||--------+ 1370 |PRR ||| | 1371 +---------|---------+ 1372 ^ | 192.0.2.1 1373 IPv4 datagram 1 | | 1374 -----|--|-------- 1375 / | | \ 1376 | ISP network / | 1377 \ Internet / 1378 -----|--|-------- 1379 | | 1380 | | 203.0.113.1 1381 +-----+-----+ 1382 | IPv4 Host | 1383 +-----------+ 1385 Figure 15: Forwarding of Incoming A+P-forwarded Packets 1387 +-----------------+--------------+-----------------------------+ 1388 | Datagram | Header field | Contents | 1389 +-----------------+--------------+-----------------------------+ 1390 | IPv4 datagram 1 | IPv4 Dst | 198.51.100.3 | 1391 | | IPv4 Src | 203.0.113.1 | 1392 | | TCP Dst | 100 | 1393 | | TCP Src | 80 | 1394 | --------------- | ------------ | --------------------------- | 1395 | IPv6 Datagram 2 | IPv6 Dst | 2001:db8::2 | 1396 | | IPv6 Src | 2001:db8::1 | 1397 | | IPv4 Dst | 198.51.100.3 | 1398 | | IP Src | 203.0.113.1 | 1399 | | TCP Dst | 100 | 1400 | | TCP Src | 80 | 1401 | --------------- | ------------ | --------------------------- | 1402 | IPv4 datagram 3 | IPv4 Dst | 198.51.100.2 | 1403 | | IPv4 Src | 203.0.113.1 | 1404 | | TCP Dst | 8000 | 1405 | | TCP Src | 80 | 1406 +-----------------+--------------+-----------------------------+ 1408 Datagram header contents 1410 Note that datagram 1 travels untranslated up to the CPE, thus the 1411 customer has the same control over the translation as it has today 1412 where s/he has an home gateway with customizable port-forwarding. 1414 5.3.1. Forwarding of Standard Packets 1416 Packets for which the CPE does not have a corresponding port 1417 forwarding rule are tunneled to the PRR which provides the LSN 1418 function. We underline that the LSN MUST NOT use the delegated space 1419 for NATting. See [I-D.ietf-softwire-dual-stack-lite] for network 1420 diagrams which illustrate the packet flow in this case. 1422 5.3.2. Handling ICMP 1424 ICMP is problematic for all NATs, because it lacks port numbers. A+P 1425 routing exacerbates the problem. 1427 Most ICMP messages fall into one of two categories: error reports, or 1428 ECHO/ECHO reply (commonly known as "ping"). For error reports, the 1429 offending packet header is embedded within the ICMP packet; NAT 1430 devices can then rewrite that portion and route the packet to the 1431 actual destination host. This functionality will remain the same 1432 with A+P; however, the PRR will need to examine the embedded header 1433 to extract the port number, while the A+P gateway will do the 1434 necessary rewriting. 1436 ECHO and ECHO reply are more problematic. For ECHO, the A+P gateway 1437 device must rewrite the "Identifier" and perhaps "Sequence Number" 1438 fields in the ICMP request, treating them as if they were port 1439 numbers. This way, the PRR can build the correct A+P address for the 1440 returning ECHO replies, so they can be correctly routed back to the 1441 appropriate host in the same way as TCP/UDP packets. Pings 1442 originated from the Public Realm (Internet) towards an A+P device are 1443 not supported. 1445 5.3.3. Fragmentation 1447 In order to deliver a fragmented IP packet to its final destination 1448 (among those having the same IP address), the PRR should activate a 1449 dedicated procedure similar to the one used by 1450 [I-D.ietf-behave-v6v4-xlate-stateful], section 3.5 in a sense that it 1451 should reassemble the fragments in order to look at the destination 1452 port number. 1454 Note that it is recommended to use a PMTUD path discovery mechanism 1455 (e.g., [RFC1191]). 1457 Security issues related to fragmentation are out of scope of this 1458 document. For more details, refer to [RFC1858]. 1460 5.3.4. Limitations of the A+P approach 1462 One limitation that A+P shares with any other IP address-sharing 1463 mechanism is the availability of well-known ports. In fact, services 1464 run by customers that share the same IP address will be distinguished 1465 by the port number. As a consequence, it will be impossible for two 1466 customers who share the same IP address to run services on the same 1467 port (e.g., port 80). Unfortunately, working around this limitation 1468 usually implies application-specific hacks (e.g., HTTP and HTTPS 1469 redirection), discussion of which is out of the scope of this 1470 document. Of course, a provider might charge more for giving a 1471 customer the well-known port range, 0..1024, thus allowing the 1472 customer to provide externally available services. Many applications 1473 require the availability of well known ports. However, those 1474 applications are not expected to work in A+P environment unless they 1475 can adapt to work with different ports. However, such application do 1476 not work behind today's NATs either. 1478 Another problem which is common to all NATs is coexistence with 1479 IPsec. In fact, a NAT which also translates port numbers prevents AH 1480 and ESP from functioning properly, both in tunnel and in transport 1481 mode. In this respect, we stress that, since an A+P subsystem 1482 exhibits the same external behavior as a NAT, well-known workarounds 1483 (such as [RFC3715]) can be employed. 1485 A+P, as all other port sharing solutions also suffers from the issues 1486 documented in [I-D.ietf-intarea-shared-addressing-issues], but that's 1487 something we'll have to live with. 1489 For the host-based A+P, issues related to applications conflicts 1490 trying to bind to an out-of-range port are to be further assessed. 1491 Note that extensions to the host-based model have been proposed in 1492 the past (e.g., Port Enhanced ARP extension documented in 1493 http://software.merit.edu/pe-arp/). 1495 5.3.5. Port allocation strategy agnostic 1497 Issues, rised by [I-D.thaler-port-restricted-ip-issues] have been 1498 analyzed in [I-D.dec-stateless-4v6]. As seen in that document, most 1499 of the issues apply to host based port sharing solutions. A+P is not 1500 intended to be host based port sharing solution. 1502 Conclusion of [I-D.dec-stateless-4v6] document is, that the set of 1503 issues specifically attributed to A+P either do not apply to CPE- 1504 based flavours, or can be mitigated. A+P solution represents a 1505 reasonable trade off compared to alternatives in areas such as 1506 binding logging (for data storage purposes), ease as of deployment 1507 and operations, all of which are actually facilitated by such a 1508 solution. 1510 6. IANA Considerations 1512 This document makes no request of IANA. 1514 Note to RFC Editor: this section may be removed on publication as an 1515 RFC. 1517 7. Security Considerations 1519 With CGN/LSNs, tracing hackers, spammers and other criminals will be 1520 difficult, requiring logging, recording, and storing of all 1521 connection based mapping information. The need for storage implies a 1522 tradeoff. On one hand, the LSNs can manage addresses and ports as 1523 dynamically as possible in order to maximize aggregation. On the 1524 other hand, the more quickly the mapping between private and public 1525 space changes, the more information needs to be recorded. This would 1526 not only cause concern for law enforcement services, but also for 1527 privacy advocates. 1529 A+P offers a better set of tradeoffs. All that needs to be logged is 1530 the allocation of a range of port numbers to a customer. By design, 1531 this will be done rarely, improving scalability. If the NAT 1532 functionality is moved further up the tree, the logging requirement 1533 will be as well, increasing the load on one node, but giving it more 1534 resources to allocate to a busy customer, perhaps decreasing the 1535 frequency of allocation requests. 1537 The other extreme is A+P NAT on the customer premises. Such a node 1538 would be no different than today's NAT boxes, which do no such 1539 logging. We thus conclude that A+P is no worse than today's 1540 situation, while being considerably better than CGNs. 1542 8. Authors 1544 This document has 9 primary authors, which is not allowed in the 1545 header of Internet-Drafts. This is the list of actual authors of 1546 this document. 1548 Gabor Bajko 1549 Nokia 1550 Email: gabor(dot)bajko(at)nokia(dot)com 1552 Mohamed Boucadair 1553 France Telecom 1554 3, Av Francois Chateaux 1555 Rennes 35000 1556 France 1557 Email: mohamed.boucadair@orange-ftgroup.com 1559 Steven M. Bellovin 1560 Columbia University 1561 1214 Amsterdam Avenue 1562 MC 0401 1563 New York, NY 10027 1564 US 1565 Phone: +1 212 939 7149 1566 Email: bellovin@acm.org 1568 Randy Bush 1569 Internet Initiative Japan 1570 5147 Crystal Springs 1571 Bainbridge Island, Washington 98110 1572 US 1573 Phone: +1 206 780 0431 x1 1574 Email: randy@psg.com 1576 Luca Cittadini 1577 Universita' Roma Tre 1578 via della Vasca Navale, 79 1579 Rome, 00146 1580 Italy 1581 Phone: +39 06 5733 3215 1582 Email: luca.cittadini@gmail.com 1584 Olaf Maennel 1585 Loughborough University 1586 Department of Computer Science - N.2.03 1587 Loughborough 1588 United Kindom 1589 Phone: +44 115 714 0042 1590 Email: o@maennel.net 1592 Reinaldo Penno 1593 Juniper Networks 1594 1194 North Mathilda Avenue 1595 Sunnyvale, California 94089 1596 USA 1597 Email: rpenno@juniper.net 1599 Teemu Savolainen 1600 Nokia 1601 Hermiankatu 12 D 1602 TAMPERE, FI-33720 1603 Finland 1604 Email: teemu.savolainen@nokia.com 1606 Jan Zorz 1607 Go6 Institute Slovenia 1608 Frankovo naselje 165 1609 Skofja Loka, 4220 1610 Slovenia 1611 Email: jan@go6.si 1613 9. Acknowledgments 1615 The authors wish to especially thank Remi Despres, and Pierre Levis 1616 for their help on the development of the A+P approach. We also thank 1617 David Ward for review, constructive criticism, and interminable 1618 questions, and Dave Thaler for useful criticism on "stackable" A+P 1619 gateways. We would also like to thank the following persons for 1620 their feedback on earlier versions of this work: Rob Austein, Gert 1621 Doering, Dino Farinacci, Russ Housley, Ruediger Volk, Tina Tsou and 1622 Pasi Sarolahti. 1624 10. References 1626 10.1. Normative References 1628 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1629 Requirement Levels", BCP 14, RFC 2119, March 1997. 1631 10.2. Informative References 1633 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1634 Defeating Denial of Service Attacks which employ IP Source 1635 Address Spoofing", BCP 38, May 2000. 1637 [I-D.bajko-pripaddrassign] 1638 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 1639 "Port Restricted IP Address Assignment", 1640 draft-bajko-pripaddrassign-03 (work in progress), 1641 September 2010. 1643 [I-D.boucadair-behave-bittorrent-portrange] 1644 Boucadair, M., Grimault, J., Levis, P., and A. 1645 Villefranque, "Behaviour of BitTorrent service in an IP 1646 Shared Address Environment", 1647 draft-boucadair-behave-bittorrent-portrange-02 (work in 1648 progress), January 2009. 1650 [I-D.boucadair-dhcpv6-shared-address-option] 1651 Boucadair, M., Levis, P., Grimault, J., Savolainen, T., 1652 and G. Bajko, "Dynamic Host Configuration Protocol 1653 (DHCPv6) Options for Shared IP Addresses Solutions", 1654 draft-boucadair-dhcpv6-shared-address-option-01 (work in 1655 progress), December 2009. 1657 [I-D.boucadair-pppext-portrange-option] 1658 Boucadair, M., Levis, P., and T. Savolainen, "Port Range 1659 Configuration Options for PPP IPCP", 1660 draft-boucadair-pppext-portrange-option-04 (work in 1661 progress), September 2010. 1663 [I-D.dec-stateless-4v6] 1664 Dec, W., "Stateless 4Via6 Address Sharing", 1665 draft-dec-stateless-4v6-01 (work in progress), March 2011. 1667 [I-D.deng-aplusp-experiment-results] 1668 Deng, X., Boucadair, M., and F. Telecom, "Implementing A+P 1669 in the provider's IPv6-only network", 1670 draft-deng-aplusp-experiment-results-00 (work in 1671 progress), March 2011. 1673 [I-D.despres-intarea-4rd] 1674 Despres, R., Matsushima, S., Murakami, T., and O. Troan, 1675 "IPv4 Residual Deployment across IPv6-Service networks 1676 (4rd) ISP-NAT's made optional", 1677 draft-despres-intarea-4rd-01 (work in progress), 1678 March 2011. 1680 [I-D.ietf-behave-v6v4-xlate-stateful] 1681 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 1682 NAT64: Network Address and Protocol Translation from IPv6 1683 Clients to IPv4 Servers", 1684 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 1685 progress), July 2010. 1687 [I-D.ietf-intarea-shared-addressing-issues] 1688 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 1689 Roberts, "Issues with IP Address Sharing", 1690 draft-ietf-intarea-shared-addressing-issues-05 (work in 1691 progress), March 2011. 1693 [I-D.ietf-pcp-base] 1694 Wing, D., Cheshire, S., Boucadair, M., and R. Penno, "Port 1695 Control Protocol (PCP)", draft-ietf-pcp-base-08 (work in 1696 progress), April 2011. 1698 [I-D.ietf-softwire-dual-stack-lite] 1699 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1700 Stack Lite Broadband Deployments Following IPv4 1701 Exhaustion", draft-ietf-softwire-dual-stack-lite-07 (work 1702 in progress), March 2011. 1704 [I-D.thaler-port-restricted-ip-issues] 1705 Thaler, D., "Issues With Port-Restricted IP Addresses", 1706 draft-thaler-port-restricted-ip-issues-00 (work in 1707 progress), February 2010. 1709 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1710 November 1990. 1712 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1713 Considerations for IP Fragment Filtering", RFC 1858, 1714 October 1995. 1716 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1717 E. Lear, "Address Allocation for Private Internets", 1718 BCP 5, RFC 1918, February 1996. 1720 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 1721 (NAT) Compatibility Requirements", RFC 3715, March 2004. 1723 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1724 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1725 October 2010. 1727 Author's Address 1729 Randy Bush (editor) 1730 Internet Initiative Japan 1731 5147 Crystal Springs 1732 Bainbridge Island, Washington 98110 1733 US 1735 Phone: +1 206 780 0431 x1 1736 Email: randy@psg.com