idnits 2.17.00 (12 Aug 2021) /tmp/idnits50879/draft-levis-behave-ipv4-shortage-framework-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1064 has weird spacing: '...-to-end model...' -- The document date (June 22, 2009) is 4709 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1024' on line 726 -- Looks like a reference, but probably isn't: '65535' on line 726 == Outdated reference: A later version (-04) exists of draft-bajko-pripaddrassign-01 == Outdated reference: A later version (-01) exists of draft-boucadair-dhcpv6-shared-address-option-00 == Outdated reference: A later version (-02) exists of draft-boucadair-port-range-01 == Outdated reference: A later version (-03) exists of draft-despres-sam-02 == Outdated reference: A later version (-02) exists of draft-ford-shared-addressing-issues-00 == Outdated reference: draft-ietf-softwire-dual-stack-lite has been published as RFC 6333 == Outdated reference: draft-ietf-tsvwg-port-randomization has been published as RFC 6056 == Outdated reference: A later version (-05) exists of draft-nishitani-cgn-02 == Outdated reference: A later version (-08) exists of draft-shirasaki-isp-shared-addr-02 == Outdated reference: draft-ymbk-aplusp has been published as RFC 6346 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Levis, Ed. 3 Internet-Draft M. Boucadair 4 Intended status: Informational JL. Grimault 5 Expires: December 24, 2009 A. Villefranque 6 France Telecom 7 June 22, 2009 9 IPv4 Address Shortage: Needs and Open Issues 10 draft-levis-behave-ipv4-shortage-framework-02.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 24, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document analyses the main issues related to IPv4 Internet 49 access in the context of public IPv4 address exhaustion. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Shared IPv4 Addresses . . . . . . . . . . . . . . . . . . . . 3 55 3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. CGN-based Solutions . . . . . . . . . . . . . . . . . . . 4 57 3.2. A+P Solutions . . . . . . . . . . . . . . . . . . . . . . 5 58 3.3. Common Architecture . . . . . . . . . . . . . . . . . . . 6 59 4. Address Space Multiplicative Factor . . . . . . . . . . . . . 7 60 5. Number of Current Sessions . . . . . . . . . . . . . . . . . . 8 61 6. Service Management . . . . . . . . . . . . . . . . . . . . . . 10 62 7. IPv6 Migration and IPv4-IPv6 Coexistence . . . . . . . . . . . 10 63 8. Network Addressing Capability . . . . . . . . . . . . . . . . 11 64 9. Scarcity of Private Addressing . . . . . . . . . . . . . . . . 12 65 10. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 11. Impact on Information System . . . . . . . . . . . . . . . . . 14 67 12. Impact on Services . . . . . . . . . . . . . . . . . . . . . . 14 68 13. Port Space Boundaries . . . . . . . . . . . . . . . . . . . . 15 69 14. Flow Discrimination . . . . . . . . . . . . . . . . . . . . . 17 70 15. Impact on Intra-Domain and Inter-Domain Routing . . . . . . . 17 71 16. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 17 72 17. QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 17.1. QoS performance . . . . . . . . . . . . . . . . . . . . . 17 74 17.2. QoS mechanisms . . . . . . . . . . . . . . . . . . . . . . 18 75 17.3. Introduction of Single Point of Failure (Robustness) . . . 18 76 18. Support of Multicast . . . . . . . . . . . . . . . . . . . . . 18 77 19. Mobile-IP . . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 20. End-Users Facilities . . . . . . . . . . . . . . . . . . . . . 19 79 21. Management Tools . . . . . . . . . . . . . . . . . . . . . . . 20 80 22. Legal Obligations . . . . . . . . . . . . . . . . . . . . . . 20 81 22.1. Traceability . . . . . . . . . . . . . . . . . . . . . . . 20 82 22.2. Interception . . . . . . . . . . . . . . . . . . . . . . . 21 83 23. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 84 23.1. Port Randomization . . . . . . . . . . . . . . . . . . . . 21 85 23.2. Duplicate Effects . . . . . . . . . . . . . . . . . . . . 22 86 23.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 24. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 88 25. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 89 26. Security Considerations . . . . . . . . . . . . . . . . . . . 23 90 27. Informative References . . . . . . . . . . . . . . . . . . . . 23 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 93 1. Introduction 95 Taking into consideration the IPv4 public address pool currently 96 available at the Internet Assigned Numbers Authority (IANA), it is 97 expected that the Regional Internet Registries (RIRs) will have no 98 more public IPv4 addresses to allocate in the short term. At the 99 time of writing, this foreseen date is mid-2012. See the IPv4 100 Address Report website (available at 101 http://www.potaroo.net/tools/ipv4/index.html) for a thorough analysis 102 of this issue, and an updated prediction. 104 This exhaustion phenomenon has been anticipated for a long time by 105 the IETF, with the specification of the IPv6 protocol as the IPv4 106 successor. IPv6 increases the IPv4 addressing space by a power-of- 107 four factor. IPv6 specifications are mature and current 108 standardization effort is exclusively dedicated to operational 109 aspects. Unfortunately, IPv6 was not devised as backwards compatible 110 with IPv4; it is not possible to have IPv6-based applications 111 directly exchange IP packets with their IPv4-based counterparts. The 112 expected transition process was to assume hosts and routers will be 113 Dual-Stack, that is, will support the two distinct protocol families 114 IPv4 and IPv6, and to wait until the entire Internet supports Dual- 115 Stack connectivity to deprecate IPv4. More than a decade later, 116 IPv4-only communications are still the norm, and IPv6 is still rather 117 marginal. ISPs will need to continue to provide IPv4 Internet access 118 to their customers at the exhaustion date, if they do not want to see 119 their business completely stalled or decreasing. They will wind up 120 with public address pools that cannot grow. They will have to adapt 121 to this situation, and enter an IPv4 address shortage management 122 phase. 124 This document analyses the main issues related to IPv4 Internet 125 access in the context of public IPv4 address exhaustion. Another 126 complementary study can be find in 127 [I-D.ford-shared-addressing-issues]. 129 2. Shared IPv4 Addresses 131 So far, the current practice (particularly for fixed service 132 offering) has been to give a unique IPv4 public address to each 133 customer. A common design is to assign this global IPv4 address to 134 the Customer Premises Equipment (CPE), and to assign IPv4 private 135 addresses to the hosts connected behind the CPE. A private to public 136 (and vice versa) translation occurs in the CPE owing to the 137 activation of a Network Address and Port Translator (NAPT) function 138 [RFC3022]. In this context, the public addresses that can be seen in 139 any IP packets always refer to a unique customer. To cope with the 140 IPv4 address exhaustion, this kind of practices is no more 141 affordable. Therefore, ISPs are bound to share the same IPv4 public 142 address among several customers at the same time. 144 All IPv4 address shortage mechanisms extend the address space in 145 adding port information. We call them by the generic name of IPv4 146 shortage solutions, or shared address solutions. IPv4 shortage 147 solutions differ on the way they manage the port value. In this new 148 context, a public IPv4 address seen in an IP packet can refer to 149 several customers. The port information must be considered as well, 150 in order to be able to unambiguously identify the customer pointed by 151 that shared address. In particular, the port information along with 152 the address information, must eventually be taken into account in 153 order to correctly reach the intended destination. 155 3. Solution Space 157 3.1. CGN-based Solutions 159 These solutions propose the introduction of a NAPT function in the 160 ISP network, denoted also as Carrier Grade NAT (CGN), or Large Scale 161 NAT (LSN) [I-D.nishitani-cgn], or Provider NAT. The CGN is 162 responsible for translating private addresses to publicly routable 163 addresses. Private addresses are assigned to customers, a pool of 164 public addresses is assigned to the CGN, the number of public 165 addresses is much smaller than the number of customers. A public 166 address of the CGN pool will therefore be shared by several customers 167 at the same time. 169 Packet processing is as follows (for port-based communications): 171 o Outgoing packets from an internal host to an Internet host: the 172 internal host sends a packet with a private IPv4 source address. 173 This packet goes up to the CGN, possibly after a first private to 174 private address translation in the CPE, the CGN dynamically 175 replaces the private source address by a public source address and 176 modifies the source port value. The CGN creates an entry in its 177 NAT mapping (or binding) table for each new mapping. Dynamic 178 mappings can only be created by outgoing packets. 180 o Incoming packets from an Internet host to an internal host: the 181 remote host sends a packet with a destination address within the 182 CGN public address pool. If, and only if, a mapping already 183 exists for the (destination address, destination port, protocol) 184 tuple, the CGN can reverse the mapping and forward the packet 185 towards the internal side. However, even if this mapping exists, 186 the CGN may discard the packet due to a particular filtering 187 policy. If no mapping exists for the (destination address, 188 destination port, protocol), the CGN discards the packet. 190 CGN-based solutions can be deployed in different network 191 configurations. One outstanding flavor is the DS-lite CGN 192 [I-D.ietf-softwire-dual-stack-lite]: there is no NAT in the CPEs, 193 IPv6 addresses (or prefixes) are assigned to CPEs, no IPv4 addresses 194 are assigned to CPEs, traffic is tunnelled between CPEs and the DS- 195 lite CGN into IPv6. 197 3.2. A+P Solutions 199 These solutions avoid the presence of a CGN function. They assign 200 the same IP public address to several customers at the same time 201 (shared address). They also assign a restricted port range to each 202 customer so that two customers with the same IP address have two 203 different port ranges that do not overlap. These solutions are 204 called A+P (Address+Port) [I-D.ymbk-aplusp], or Port Range 205 [I-D.boucadair-port-range], or SAM (Stateless Address Mapping) 206 [I-D.despres-sam]. These solutions introduce a new function in the 207 ISP network called Port Range Router (PRR). 209 Packet processing is as follows (for port-based communications): 211 o Outgoing packets from an internal host to an Internet host: the 212 internal host sends a packet with its public shared address as the 213 source address and a source port within his dedicated port range 214 (the internal host may also send a packet with a private address, 215 and then a NAPT in the CPE forces the source port to be within the 216 port range and translates the private source address into the 217 shared public address allocated). No specific handling is 218 necessary in the ISP network, apart from the traditional IP 219 routing process. In order to allow internal communications 220 (within the same ISP realm), the outgoing packets have however to 221 go up to the device that embeds the PRR function, but the packet 222 will be processed by this PRR, if and only if, the PRR handles the 223 destination subnet. 225 o Incoming packets from an Internet host to an internal host: the 226 remote host sends a packet with a shared destination public 227 address. Owing to routing protocol advertisements, this packet is 228 routed up to the PRR that handles this address subnet. The PRR is 229 in charge to find a route towards the actual internal 230 correspondent -for instance, CPEs have setup PPP sessions with the 231 PRR, the PRR maintains a binding table between (IPv4 address, Port 232 Range) couples and PPP session IDs-. The PRR that handles the 233 shared address of a user must be in the data path of any packet 234 intended to that user. 236 Port range solutions are sometimes described as a CGN function that 237 would have been distributed among the CPEs. This is not false, but 238 may be a rather misleading view, in the sense that it would assume 239 CGN has not disappeared but simply melt into the CPEs, and that, to 240 some extent, it is still CGN. Actually, the very purpose of A+P 241 solutions is to completely get rid of any CGN function. One main 242 interest of A+P solutions is that PRR devices are simple equipment 243 which, unlike CGN devices, have no per-user session processing, and 244 do not modify packet headers. Thus, PRR performance should not be an 245 issue. 247 3.3. Common Architecture 249 To provide a common architecture, we introduce the SHared Ip 250 Processor (SHIP) function embedded in a SHIP device. A SHIP device 251 can host either a CGN function or a PRR function, or both. In the 252 latter case, some traffic is CGN-processed (outgoing and incoming 253 packets), some is PRR-processed (incoming packets). There can be 254 several SHIP devices in the same ISP network. 255 (3) 256 (1) +----------+ 257 +---------+ | | 258 | | (2) | | +-----------------+ 259 |Host/CPE |-------------| SHIP |--------------|THE IPv4 INTERNET| 260 | | | | +-----------------+ 261 +---------+ | | 262 +----------+ 264 Shared Address Architecture 266 This architecture is composed of the following elements: 268 (1) The hosts are directly connected (e.g. mobile terminal), or 269 connected through a CPE. For PRR-based solutions, packets are sent 270 with source ports within their allocated Port Ranges. A Host/CPE 271 must know a SHIP device to which it can send its traffic. 273 (2) The network infrastructure between CPEs and PRR: 275 o Ensures outgoing packets are routed up to the SHIP device; 277 o Ensures incoming packets are routed up to the intended Host/CPE. 279 (3) The SHIP device may: 281 o Translate (NAPT) outgoing and incoming packets for CGN-processed 282 traffic (CGN function only); 284 o Find a route to incoming packets for PRR-processed traffic (PRR 285 function only). 287 Many architectural issues are common to all IPv4 shortage solutions, 288 whether they rely on the presence of a CGN or a PRR. Including, for 289 instance, means to ensure proper routing between customers and SHIP 290 devices, and SHIP devices location. Therefore, it does make sense to 291 describe and specify all solutions on a concerted basis, and not in 292 completely separate ways. 294 4. Address Space Multiplicative Factor 296 The purpose of sharing public IPv4 addresses is to potentially 297 increase the addressing space. A key parameter is the factor by 298 which ISPs want or need to multiply their IPv4 public address space; 299 and the consequence is the number of customers sharing the same 300 public IPv4 address. This parameter is called the address space 301 multiplicative factor, the inverse is called the compression ratio. 303 It is expected that IPv6 traffic will take an increasing part during 304 the next years to come, at the expense of IPv4 traffic. We should 305 reach a safety point in the future, where the number of IPv4 public 306 addresses, in use at the same time, begins decreasing. From an ISP 307 point of view, the multiplicative factor must be enough to survive 308 until this event occurs for its own customers. 310 The multiplicative factor can only be applied to the part of 311 customers that is eligible to shared address. The reasons a customer 312 cannot have a shared address can be: 314 o It would not be compatible with the service he has currently 315 subscribed to (for example: business customer). 317 o His CPE does not allow the solution selected by the ISP (for 318 example it does not handle port restriction for PRR-based 319 solutions or it does not allow IPv4 in IPv6 encapsulation for DS- 320 lite solution), and its replacement is not easy. 322 Different ISPs may have very different needs. A long-lived ISP, 323 whose number of customers is rather stable, will have an existing 324 address pool that will only need a small extension to cope with the 325 next years to come (small multiplicative factor, less than 10). A 326 new comer will need a much bigger multiplicative factor (e.g. 1000). 327 A mobile operator may see its address need explode if the IP mobile 328 handset market dramatically grows, with Internet 3G access and 329 Internet wireless (Wi-Fi/WiMAX) hotspot access. 331 The multiplicative factor is an important criterion in order to 332 select a solution. When the multiplicative factor is large, the 333 average number of ports per customer is small; in that case, it is 334 essential to manage port attribution the closest to the need as 335 possible, and to avoid to dedicate ports to people who do not use 336 them, when other people are running out of ports. Then, the larger 337 the multiplicative factor is, the more dynamic the port assignment 338 has to be. 340 CGN solutions provide the most dynamic port assignment scheme, hence 341 the best possible ratio. However, CGNs can also be produced with 342 functionalities that reduce their dynamicity; for instance, a port 343 range can be attributed to each user, the CGN mapping is constrained 344 into this range, in order, for example, to ease legal storage. As 345 for A+P solutions, their dynamicity can vary a lot, depending on the 346 Port Range assignment policy. Port Ranges can be assigned in a 347 complete static way; one Port Range is assigned once and for all to 348 each customer, no port can be added in, or removed from, the 349 attributed Range. On the opposite, Port Range assignment can be 350 fully dynamic; small Port Ranges (possibly up to one port) are 351 dynamically assigned and removed. 353 Whatever the multiplicative factor selected, one must keep in mind 354 that trying to deploy solutions that increase the IPv4 space by a big 355 factor, might be seen as an incentive to postpone again and again 356 IPv6 deployment. 358 5. Number of Current Sessions 360 In any kind of solutions, the number of current sessions per customer 361 has, de facto, to be limited in some way. Therefore, the number of 362 current sessions per customer is a limit to take into account in any 363 architectural dimensioning. According to [RFC2663] terminology: "A 364 session is defined as the set of traffic that is managed as a unit 365 for translation. TCP/UDP sessions are uniquely identified by the 366 tuple of (source IP address, source TCP/UDP port, target IP address, 367 target TCP/UDP port)". 369 A CGN must sustain the traffic that will occur in its location point 370 at the most loaded time, in terms of number of current sessions, and 371 number of new sessions per second (i.e. when these parameter values 372 are the highest). A Port Range solution should be less sensitive 373 than a CGN to session rate and number, because a PRR is a per-user, 374 and not a per-session, process. 376 UDP sessions and TCP sessions are separately handled in a CGN (a CGN 377 mapping incorporates the protocol value); it is as if the same public 378 IPv4 address pool was allocated twice: once for the TCP 379 communications and once for the UDP communications (of course other 380 Transport protocols may be taken into account such as SCTP or DCCP). 381 Therefore, the number of public addresses needed in a CGN will be 382 driven by the type of communications -TCP or UDP- which consumes the 383 highest number of public addresses. This consumption depends on the 384 number of current sessions. Actually, for a Full Cone CGN (Endpoint- 385 Independent Mapping and End point-Independent Filtering [RFC4787]), 386 the address consumption should directly depend on the number of 387 current couples (customer source address, customer source port) 388 rather than on the number of current sessions. 390 For the same traffic conditions, a Port Range solution should need 391 more addresses than a CGN. Let's assume, for the sake of simplicity, 392 that port range allocation is a static one-size fits all. The range 393 size should not only cover the average number of current sessions per 394 user at peak time, but should also take into account the distribution 395 of sessions, and should be significantly larger than the average if 396 the standard deviation is large. So, where a CGN consumes no more 397 ports than the number of current sessions, a Port Range solution, due 398 to the attribution of ports by blocks, consumes more ports, and thus 399 more addresses. 401 The IPv6 increasing deployment should have a decreasing effect on the 402 number of current IPv4 sessions per customer. If the percentage of 403 end-to-end IPv6 traffic significantly increases, so that the volume 404 of IPv4 traffic begins decreasing, then the number of IPv4 sessions 405 will be decreasing. The smaller the number of current IPv4 sessions 406 per customer is, the higher the number of customers under the same 407 IPv4 public address can be (better compression ratio), and 408 consequently, the lower the number of IPv4 public addresses is 409 needed. Hence, the pressure on IPv4 address shortage would be 410 relaxed, because one IPv4 public address would be able to potentially 411 serve more customers. However, this effect will only occur for 412 customers who have both an IPv6 access and a shared IPv4 access. 413 This advocates the strategy to systematically bound a shared IPv4 414 access to any IPv6 access. It is difficult to foresee to what extent 415 the IPv6 traffic will decrease the number of current IPv4 sessions, 416 but in any case, IPv6 activation should increase the potential IPv4 417 multiplicative factor. If it does not, that means IPv6 does not take 418 over IPv4. 420 As for the current usage of ports, several hundreds as peak numbers 421 per customer, seems current practice, although several thousands may 422 be not unusual with some P2P applications (e.g. BitTorrent). The 423 degree of fairness -balanced distribution of sessions between 424 customers-, traffic loss due to the limitation in number of sessions, 425 may vary according to the traffic conditions, and the policy 426 enforced. The knowledge of the distribution of sessions among a set 427 of users, makes it possible to know how many users might be adversely 428 affected if/when system limits are reached. However, it is surely 429 not that straightforward to really assess the degradation the 430 customers should experience, from the knowledge of their session 431 number limitations. 433 6. Service Management 435 At the time of IPv4 address exhaustion in the RIRs, ISPs will have to 436 manage public address pools that cannot grow (at least from the 437 RIRs). Concretely, they will have to decide to whom they allocate 438 shared addresses and to whom they allocate unique public addresses, 439 to the extent of the availability of addresses. Many policies can be 440 envisaged, taking into account parameters such as: old vs. new 441 customers, user profile, access type, geographic considerations, 442 unique address as the privileged choice, shared address as the 443 privileged choice, etc. 445 Care must be taken when considering the ratio that reflects the 446 number of customers who will share a given global IPv4 address, not 447 only to preserve some flexibility on the global address space that is 448 left, but also to make sure that the ISP can adequately serve 449 customer's requirements, without degrading the services they have 450 subscribed to. ISPs can adjust the volume of IPv4 public addresses 451 available playing on the balance between shared and unique 452 allocations. 454 o To increase the public IPv4 address pool: increase the number of 455 customers with shared address; increase the ratio of customers per 456 shared address. 458 o To decrease the public IPv4 address pool: decrease the number of 459 customers with shared address; decrease the ratio of customers per 460 shared address. 462 7. IPv6 Migration and IPv4-IPv6 Coexistence 464 IPv6 is the only solution to solve the IPv4 public address 465 exhaustion, that is, to actually get rid of the limitation on the 466 number of IP addresses. IPv4 shared addresses are not candidate to 467 IPv6 replacement. However, we should be very careful; whatever the 468 network model deployed, applications and business will run on top of 469 it. If we do not want to see IPv4 address shortage mechanisms 470 postpone IPv6 deployment, all Internet actors must adopt a voluntary 471 position towards IPv6. 473 Any IPv4 address shortage solution should make use, as much as 474 possible, of the IPv6 transport capabilities available, in order to 475 increase the IPv6 traffic and to move forward from an IPv4-enabled 476 ISP network towards an almost IPv6-only ISP network. If it is not 477 the case, the risk is to delay IPv6 operational deployments, in 478 staying on a pure Dual-Stack attitude for ever, similar to the ships 479 in the night routing approach, where the protocols independently live 480 their own lives. IPv4 in IPv6 tunnels, and/or NAT64 and NAT46 481 translations should be favored. However, increasing the number of 482 IPv6 packets does not automatically mean IPv6 is being generalized, 483 if the main purpose of these packets is to carry IPv4 information. 484 This is very similar to what occurred with ATM, especially in 485 European countries, where ATM cells have heavily been used to convey 486 IPv4 packets in the backhaul networks, but have never been used for 487 end-to-end communications! 489 Some public IPv4 addresses will be required to connect IPv4 and IPv6 490 realms, through IPv4-IPv6 translators, for the sake of global 491 reachability. 493 IPv4 shortage solutions may interfere with exiting IPv4 to IPv6 494 transition mechanisms, which were not designed with IPv4 shortage 495 considerations. With A+P for instance, incoming 6to4 packets should 496 be able to find their way from a 6to4 Relay up to the appropriate 497 6to4 CPE router, despite the lack of direct port range information 498 (UDP/TCP initial source port did not pass through the CPE Port Range 499 NAT translation process). One solution would be that a 6to4 IPv6 500 address embeds not only an IPv4 address but also a Port Range value. 502 8. Network Addressing Capability 504 The network addressing capability is the level of flexibility the 505 network has to configure customers' devices, either with a unique 506 public IPv4 address, or with a shared public IPv4 address. It may be 507 assessed through the following considerations: 509 o Is it possible to configure any customer's device with a shared 510 address, regardless his location and his history? 512 o Is it possible to configure any customer's device with a unique 513 public address, regardless his location and his history? 515 o Is it straightforward to switch, for any customer, from a shared 516 address to a unique public address, and vice versa? 518 What is considered here is not the policy decision to allocate a 519 unique or a shared address, but the network capability to enforce 520 such address management schemes. 522 9. Scarcity of Private Addressing 524 In several IPv4 shortage scenarios, private addresses, (as defined in 525 [RFC1918]), can be assigned to CPEs, and to SHIP devices. This can 526 be applied, for instance, to CGN double NAT architecture. In this 527 case, if there are intermediate routers between CPEs and CGN, the 528 outgoing packets are encapsulated into IPv4 packets addressed to a 529 CGN private address (tunneling), and the incoming packets are 530 natively routed towards the CPEs -the routing infrastructure must be 531 able to route the CPEs' private addresses-. If there are no 532 intermediate routers, no tunnel is necessary. However, private 533 addresses are already in use in many ISPs' networks, they belong to a 534 finite space which may rapidly raise overlapping issues as both the 535 number of customers and the number of services that can be subscribed 536 by these customers increase. As a consequence, some ISPs use Virtual 537 Private Networks (VPNs) such as [RFC4364] to allow reusing the same 538 private addresses several times with no routing overlaps. This 539 brings a lot of complexity in network configuration and management. 541 It has been suggested to make the 240/4 block available for private 542 addressing [I-D.wilson-class-e]. This address block, formerly 543 designated as "Class E", is still noted as being reserved in the IANA 544 IPv4 address registry. If it were reassigned for private addressing 545 that would yield around 268 millions extra private addresses. 546 However, many current implementations of the TCP/IP protocol stack do 547 not allow the use of the 240/4 block. This is a severe blocking 548 point for a lot of existing devices: CPE, NAT or routers. This issue 549 will only be solved when the vendors' implementations accept the 550 (240/4) addresses. 552 Another suggestion [I-D.shirasaki-isp-shared-addr] is to reserve some 553 public blocks (typically three or four /8) only for internal usage. 554 So far, there has been no consensus upon this proposal. 556 10. Scalability 558 The number of state entries in the ISP equipment (mainly the SHIP 559 devices) can have a significant impact on performance, scalability, 560 and solution cost. CGNs need to store many highly dynamic user 561 session states. Basically, PRRs will keep information about Port 562 Range attribution; they will not need to store a lot of states, the 563 states dynamicity will depend on the assignment policy enforced by 564 ISPs. 566 IPv4 shortage solutions must be able to adapt to the different ISP 567 needs and be flexible enough to cover their evolutions. Customers 568 under shared addresses can be geographically disseminated in very 569 different ways: scattered vs. localised, sparse vs. dense. In term 570 of architecture two types of responses are possible for the placement 571 of the SHIP devices: close to the users (many devices that federate 572 few customers) vs. close to the core (few devices that federate many 573 customers). 575 A+P solutions should be rather flexible and scalable. A PRR 576 treatment is a light process and should be straightforward to 577 implement, a PRR function could then be implemented in almost any 578 router devices. From this viewpoint, it will be rather comfortable 579 for a network manager to activate the PRR functions he wants, when he 580 needs and where he needs, with no big extra CAPEX (CAPital 581 EXpenditure) increase. For the same number of customers federated, a 582 CGN device should be more expensive than a PRR device. That could 583 make CGN solutions less flexible and scalable than A+P solutions. 585 Another important scalability parameter is the impact on the CPEs. 586 Some IPv4 shortage mechanisms require specific features in the CPEs. 587 In that case, IPv4 shared addresses will not be able to spread to 588 current CPEs that lack these appropriate features. Some CPEs are ISP 589 branded which makes them, on the one hand, easier to control and to 590 enhance, but which can be, on the other hand, very expensive for ISPs 591 if a lot of legacy CPEs need to be replaced (if a software update is 592 not enough). 594 A+P solutions require that CPEs receive specific Port Ranges (e.g. 595 through DHCP), and that they control and restrict the source port of 596 outgoing packets, according to the assigned Port Ranges. 597 Supplementary CPE resources (hardware and software) to run these two 598 features should be tiny (if not null) because, for example, in Linux 599 OS the port range restriction is already part of the OS (Netfilter/ 600 Iptables) and the DHCP process is already in the CPE, and would only 601 need to be complemented with port range negotiation as proposed in 602 [I-D.bajko-pripaddrassign] for DHCPv4, and in 603 [I-D.boucadair-dhcpv6-shared-address-option] for DHCPv6. 605 Some CGN solutions can be used with no specific features in the CPEs, 606 just adding a second NAT level in the ISP network, to the extent that 607 routing is correctly achieved between CPEs and CGN. The DS-lite CGN 608 flavor requires CPEs to be NATless and to have a tunnel interface 609 IPv4 into IPv6 (with several possible encapsulation types) to 610 communicate with the DS-lite CGN device. A+P IPv6 variant also 611 requires the same kind of IPv4 into IPv6 encapsulation. 613 11. Impact on Information System 615 IPv4 shortage solutions will have an impact on the Information System 616 platforms and applications handling the administrative and technical 617 information to control the activation of services (service ordering 618 and service handling functions), and to manage the customer profiles. 619 The possibility to give either a unique or a shared address, coupled 620 or not with an IPv6 address, could yield several types of customers 621 to deal with: IPv4 unique only, IPv4 shared only, IPv4 unique + IPv6, 622 IPv4 shared + IPv6, IPv6 only. 624 Common practice used to rely upon the global IPv4 address assigned to 625 a CPE device for customer identification purposes. The forthcoming 626 address depletion therefore encourages ISPs to revisit their customer 627 identification schemes since global IPv4 addresses will be shared 628 amongst several customers. This clearly advocates for an IPv6-based 629 customer identification scheme and thus impacts the way customer- 630 specific management policies are enforced. 632 Additionally, "Service and Network Assurance" functions may be 633 impacted by the introduction of SHIP function. Impacts should be 634 assessed. Moreover, dedicated interface to access the CPE when no 635 IPv4 address is assigned (e.g. DS-lite) should be defined and 636 implemented (preferably such access should migrate towards IPv6). 638 12. Impact on Services 640 There is a potential danger for the following types of applications: 642 o Applications that establish inbound communications; 644 o Applications that carry address information in their payload; 646 o Applications that carry port information in their payload; 648 o Applications that use fixed ports (e.g. well known); 650 o Applications that do not use any port (e.g. ICMP); 652 o Applications that assume the uniqueness of customers' addresses 653 (e.g. IP address as identifier); 655 o Applications that explicitly prohibit twice the same address to 656 access to a resource at the same time. 658 Current applications already implement some mechanisms in order to 659 circumvent the presence of NATs (typically CPE NATs): 661 o ALGs; 663 o Port Forwarding; 665 o UPnP IGD; 667 o NAT-PMP; 669 o NAT Traversal techniques: ICE, STUN, TURN, etc. 671 It should be considered to what extent these mechanisms can still be 672 used with IPv4 shortage mechanisms. 674 Impact on existing services: 676 o Will this service work as usual? 678 o Will this service work but with a degradation? 680 o What level of degradation? 682 o Will this service not work at all? 684 o What modifications are needed if any? 686 Impact on future services: 688 o What new constraints are to be taken into account to devise new 689 services? 691 CGN solutions should have more impact on applications than A+P 692 solutions. Basically, from an end-to-end perspective, A+P solutions 693 should not be perceived by applications, to the extent of the port 694 range limitation, whereas a CGN should be perceived as a 695 supplementary blocking mechanism that must be circumvent by specific 696 techniques and protocols. This is particular sensitive for P2P 697 applications, even if Full Cone CGN behavior should alleviate some 698 problems. 700 13. Port Space Boundaries 702 Most of the time the source port issued by a client application will 703 be translated, apart from a direct knowledge of a Port Range 704 restriction by the client's stack (A+P), either by a NAT in the 705 user's device (A+P), or by a CPE NAT (A+P), or by a CPE NAT and/or a 706 CGN NAT (CGN). 708 IANA has classified the whole port space in three categories (as 709 defined in http://www.iana.org/assignments/port-numbers): 711 o The Well Known Ports are those from 0 through 1023. 713 o The Registered Ports are those from 1024 through 49151. 715 o The Dynamic and/or Private Ports are those from 49152 through 716 65535. 718 [RFC4787] notices that current NATs have different policies with 719 regard to this classification; some NATs restrict their translations 720 to the use of dynamic ports, some also include registered ports, some 721 preserve the port range if it is in the well-known range. [RFC4787] 722 makes it clear that the use of port space [1024, 65535] is safe: 723 "mapping a source port to a source port that is already registered is 724 unlikely to have any bad effects". Therefore, for both A+P and CGN 725 solutions, there is no reason to only consider a subset of the port 726 space [1024, 65535] for outgoing source ports. In any case, limiting 727 the number of ports available will limit the compression ratio. 729 The problem is trickier for Well Known Ports. For outgoing source 730 ports, [RFC4787] points out that "certain applications expect the 731 source UDP port to be in the well-known range", hence, it can be safe 732 to keep the source port in the Well Known Ports in that case. This 733 is possible for a CGN, to the extent that this port is still 734 available; this is not possible for A+P if the well known port value 735 is not in the attributed Port Range. Apart from port preservation, 736 the use of Well Known Ports should be prohibited for outgoing source 737 ports, because some applications will not work (for instance MSN 738 messenger cannot sign in). 740 For inbound communications, it is interesting to be able to use a 741 destination port within the Well Known Ports, in order to reach a 742 server hosted by a customer (however, this constraint can be 743 alleviated with the use of SRV records [RFC2782]). This possibility 744 is limited. It is unlikely, for example, to satisfy all customers 745 who may request port 80. For a CGN, a given customer will get port 746 80 if there is still one address of the CGN public pool where port 80 747 is currently not used, with the restriction that if this customer 748 already uses an external public address, it can be harmful to give 749 him a second current external public address (this is referenced in 750 behave WG documents as "IP address pooling behavior" of "arbitrary" 751 vs. "paired"). For A+P, a given customer will only get port 80 if 752 port 80 is within his Port Range. 754 14. Flow Discrimination 756 ISPs can offer walled garden services along with Internet services. 757 ISPs may want these flows not to traverse the IPv4 shortage 758 facilities put in place. For instance, all the IPv4 traffic does not 759 have to be processed by a CGN facility, for various reasons that are 760 mostly ISP policy-specific and which include -but are not necessarily 761 limited to- performance considerations, service-specific forwarding 762 policies. It should be clear how these IPv4 flows can bypass the 763 IPv4 shortage facilities and how they can be handled by the 764 corresponding service platform/gateway. However, the best practice 765 seems to rapidly migrate these services from IPv4 to IPv6. 767 15. Impact on Intra-Domain and Inter-Domain Routing 769 The introduction of port consideration to route packets to their 770 final destinations may have an impact on the current routing 771 infrastructure: on the architecture, the IGP and EGP configuration, 772 the addressing configuration, and on routers performances. 774 The introduction of new nodes that cannot be circumvent could also 775 yield non optimized paths, especially for communications between 776 customers attached to the same ISP realm. 778 Centralized SHIP devices could also strongly modify the current flow 779 distribution scheme among the different links and nodes, and then 780 lead to non optimal paths. 782 16. Fragmentation 784 When a packet is fragmented, the port information (either UDP or TCP) 785 will only be present in the first fragment. The other fragments will 786 not bear the port information which is necessary to a correct 787 treatment up to the destination. Dedicated means to ease fragmented 788 packets routing should be activated. 790 17. QoS 792 17.1. QoS performance 794 The possible degradation of end-to-end performances (e.g. delay) 795 experienced in the context of IPv4 shortage solutions should be 796 evaluated. 798 17.2. QoS mechanisms 800 The impact on QoS mechanisms should be investigated. In particular 801 the ability to classify traffic in order to apply differentiated 802 treatments could be hindered by the fact that an IPv4 address is 803 shared among several users, possibly in a dynamic way. In 804 particular, transparent DSCP handling should be supported by SHIP 805 devices. 807 17.3. Introduction of Single Point of Failure (Robustness) 809 The introduction of new nodes/functions, specifically where the port 810 information is managed, can create single points of failure. Any 811 IPv4 shortage solution should consider the opportunity to add 812 redundancy features in order to alleviate the impact on the 813 robustness of the offered IP connectivity service. 815 Additionally, load balancing and load sharing means should be 816 evaluated. The ability of the solution to allow hot swapping from a 817 machine to another, in minimizing the perturbations, should be 818 considered. 820 For CGN solutions, the ability to switch from a CGN node to another 821 one without losing active sessions, might be rather complex to 822 achieve due to the need to keep the two devices synchronized with the 823 same active session states. For the A+P solutions such hot swapping 824 is clearly achievable because an A+P node in the network does not 825 maintain any session-based states; thus, fail-over means would be 826 lightweight. 828 18. Support of Multicast 830 It should be assessed if a customer with a shared address can receive 831 multicast packets and source multicast packets. 833 Particularly, impact on IGMP should be identified and solutions 834 proposed. Because of the presence of several end-user devices with 835 the same IP address, membership to multicast groups should be 836 evaluated and enhancement should be proposed if required. Besides 837 the membership issue, building multicast trees may be impacted. This 838 impact should be assessed and alternatives proposed. 840 19. Mobile-IP 842 Owing to the deployment of a Mobile-IP architecture, a mobile 843 terminal continues to access its connectivity service when visiting a 844 Foreign Network. In order to avoid traffic loss, it is recommended 845 to use the home address (HoA), and not the care-of address (CoA), to 846 reach that mobile terminal. A dedicated entity called HA (Home 847 Agent) is responsible for routing the traffic according to the 848 binding table it maintains. This table includes in particular the 849 association between the HoA and CoA. A Foreign Agent (FA) can 850 optionally be deployed in the visited network. If an IP address is 851 shared (in the home network or/and in the visited network), HA or FA 852 must be updated so as to take into account the port information to 853 achieve its operations (i.e. relay traffic destined to HoA to the 854 current CoA). 856 20. End-Users Facilities 858 In the current deployments, end-users are used to configuring their 859 CPEs in order to control the traffic entering/exiting their home LAN. 861 One important and very used feature is the ability to open ports 862 (port forwarding) either manually, or with a protocol such as UPnP 863 IGD. If a CGN is present, the port must also be open in the CGN. 864 However, ISPs may not be very incline to see their customers 865 configure some specific parameters in a device inside their networks. 866 Furthermore, any supplementary treatment in the NAPT process is also 867 prone to decrease the overall CGN performances. The situation may be 868 alleviated if the CGN architecture is composed of only one NAT level 869 (no NAT in the CPE) as for DS-lite. If all NATs are Full Cone the 870 need for port forwarding may be less critical, especially to allow 871 P2P communications. For A+P the port forwarding capability may still 872 be used at CPE level, with the limitation that the port open must be 873 within the Port Range (for instance no possibility to open port 80, 874 if port 80 is not in the allocated Port Range). UPnP IGD version 2 875 should, on this matter, facilitate the Port Range working, in 876 allowing CPEs to allocate another port number than the one first 877 requested by the terminals. 879 The use of the DNS SRV records [RFC2782] could be the solution to 880 host servers in customers' premises under shared addresses. SRV 881 records give the possibility to specify a port value related to a 882 service, and then allow services to be accessible on ports which are 883 not Well Known ports (e.g. a web server accessible on a port 884 different from 80). 886 Another widely used feature is the ability to store specific ALGs on 887 the CPE to allow applications to correctly behave despite the 888 presence of the NAT CPE (even if it is harmful and should be avoided, 889 to the extent possible, according to behave WG recommendations). 890 When the CPE belongs to the customer, the customer has all 891 flexibility to tailor the device to his needs, if the CPE belongs to 892 the ISP, the customer depends on the ISP good will to satisfy his 893 request. For CGNs, it would be difficult to customize the CGN with 894 specific ALGs coming from specific customers' requirements, the 895 customers should wind up with only a limited set of possibilities if 896 any. For A+P, ALGs should work as usual, and have the same 897 possibilities as today, possibly taking into account the limited port 898 choice. Like current deployment, and in the context of A+P, the 899 resources required to run ALGs concern the CPE and no network nodes. 901 21. Management Tools 903 ISPs deploy a set of tools and applications for the management of 904 their infrastructure, especially for supervision purposes. Impact on 905 these tools should be evaluated and solutions proposed when required. 906 Particularly, means to assign IP connectivity information, means to 907 monitor the overall network, to assess the reachability of devices 908 should be specified. In this context, impact on tools (e.g. ICMP- 909 based) to check the reachability of network nodes should be 910 evaluated. 912 22. Legal Obligations 914 ISPs can be required by governmental and/or regulation authorities to 915 provide customer-specific information upon request. 917 22.1. Traceability 919 Legal obligations require an ISP to provide the identity of a 920 customer upon request of the authorities. Because one public IPv4 921 address may be shared between several customers, the knowledge of the 922 IP address is not enough to have a chance to find the appropriate 923 customer. The legal request should include the information: [IP 924 address - Port - Protocol- Begin_Timestamp - End_Timestamp]. 926 A CGN must record and store all mappings (typically during 6 months 927 to one year, depending on the legislation) that it creates. The 928 piece of information to store by mapping is two-part: Index, and 929 Customer_Discriminator. 931 o Index: is the information that will match legal request input. It 932 is composed of: [Public IP address - Public port - Protocol - Date 933 of mapping creation - Date of mapping deletion]. 935 o Customer_Discriminator: is the Information that will identify the 936 customer for a given index value. The customer discriminator 937 depends on the kind of CGN solution put in place. For a DS-lite 938 CGN the customer discriminator is his IPv6 prefix, for other CGN 939 architectures it can be, for instance and among other 940 possibilities, an IPv4 private address, a PPP session ID. 942 The complete DS-lite storage tuple is: [IPv6 prefix - Public IP 943 address - Public port - Protocol - Date of mapping creation - Date of 944 mapping deletion] per mapping. It should not be necessary to store 945 the private address and private port. The ISP should be responsible 946 for resolving the customer identity: who the ISP has an agreement 947 with, but not the identity of who in the customer's house was 948 actually connected (which is of the customer responsibility). 950 If we consider one mapping per session (in fact it should be less for 951 a Full Cone, one mapping per couple as seen in Section 5) an ISP 952 should record and retain traces of all sessions created by all 953 customers during one year (if the legal storage duration is one 954 year). This can be a problem not only as a big volume of data to 955 store, but also as a big volume of data to constantly transfer from 956 the CGN to the storage place. 958 A PRR has only to keep one entry [Public IP address - Port Range 959 -Date of beginning of Port Range assignment-Date of end of Port Range 960 assignment] per customer. Legal storage should not be a main issue 961 for A+P solutions, especially if Port Range assignment remains rather 962 static. 964 22.2. Interception 966 This process is proactive, a given group of communications is 967 replicated in real time towards a law enforcement agency. Typically, 968 the point of replication is the first IP hop in the ISP network. 969 Wiretapping techniques need to be transparent to the customer, so 970 that the targeted customer cannot be aware of the interception, owing 971 to tools such as traceroute that would make appear modification on 972 the path. They even need to be transparent to network administration 973 team, and need special login with special privileges only accessible 974 to authorized members. 976 23. Security 978 23.1. Port Randomization 980 A kind of blind attacks that can be performed against TCP relies on 981 the attacker's ability to guess the 5-tuple (Protocol, Source 982 Address, Destination Address, Source Port, Destination Port) that 983 identifies the transport protocol instance to be attacked. Document 985 [I-D.ietf-tsvwg-port-randomization] describes a number of methods for 986 the random selection of the client port number, such that the 987 possibility of an attacker guessing the exact value is reduced. With 988 shared IPv4 addresses, the port selection space is reduced. This 989 issue seems more severe for A+P solutions than for CGN; Intuitively, 990 assuming the port range is known, the smaller the port range is, the 991 more predictable the port choice is. 993 It should be noted that to guess the port information may not be 994 sufficient to carry out a successful blind attack. The exact TCP 995 Sequence Number (SN) should also be known, a TCP segment is processed 996 only if all previous segments have been received, except for some 997 Reset Segment implementations which immediately process the Reset as 998 long as it is within the Window. If SN is randomly chosen it will be 999 difficult to guess it (SN is 32 bits long); port randomization is one 1000 protection among others against blind attacks. 1002 23.2. Duplicate Effects 1004 Some types of attacks that have an impact on a targeted IPv4 public 1005 address, could see their effects increased by the number of customers 1006 who share this address. For example, if a given address that has, 1007 deliberately or not misbehaved, is consequently forbidden to access 1008 some resources, the whole set of customers who share this address 1009 will be impacted. Application developers should find alternative 1010 information to uniquely identify connected users. 1012 23.3. IPsec 1014 Even if IPSec is not deployed for mass market (e.g. residential), 1015 impacts of solutions based on shared IP addresses should be evaluated 1016 and assessed. [RFC3947] proposes a solution to solve issues 1017 documented in [RFC3715]. The applicability of [RFC3947] in the 1018 context of shared IP address should be evaluated. 1020 24. Acknowledgements 1022 We are grateful to Christian Jacquenet, Iain Calder, and Marcelo 1023 Bagnulo, for their helpful comments and suggestions for improving 1024 this document. 1026 This document has also been deeply improved by the fruitful exchanges 1027 with all people who have actively participated in the proposal of 1028 IPv4 shortage solutions. 1030 25. IANA Considerations 1032 There are no IANA considerations. 1034 Note to RFC Editor: this section may be removed on publication as an 1035 RFC. 1037 26. Security Considerations 1039 Security considerations are discussed in the Security section 1041 27. Informative References 1043 [I-D.bajko-pripaddrassign] 1044 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 1045 "Port Restricted IP Address Assignment", 1046 draft-bajko-pripaddrassign-01 (work in progress), 1047 March 2009. 1049 [I-D.boucadair-dhcpv6-shared-address-option] 1050 Boucadair, M., Levis, P., Grimault, J., Savolainen, T., 1051 and G. Bajko, "Dynamic Host Configuration Protocol 1052 (DHCPv6) Options for Shared IP Addresses Solutions", 1053 draft-boucadair-dhcpv6-shared-address-option-00 (work in 1054 progress), May 2009. 1056 [I-D.boucadair-port-range] 1057 Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, 1058 "IPv4 Connectivity Access in the Context of IPv4 Address 1059 Exhaustion", draft-boucadair-port-range-01 (work in 1060 progress), January 2009. 1062 [I-D.despres-sam] 1063 Despres, R., "Stateless Address Mapping (SAM) Avoiding 1064 NATs and restoring the end-to-end model in IPv6", 1065 draft-despres-sam-02 (work in progress), March 2009. 1067 [I-D.ford-shared-addressing-issues] 1068 Durand, A., Ford, M., and P. Roberts, "Issues with ISP 1069 Responses to IPv4 Address Exhaustion", 1070 draft-ford-shared-addressing-issues-00 (work in progress), 1071 March 2009. 1073 [I-D.ietf-softwire-dual-stack-lite] 1074 Durand, A., Droms, R., Haberman, B., and J. Woodyatt, 1075 "Dual-stack lite broadband deployments post IPv4 1076 exhaustion", draft-ietf-softwire-dual-stack-lite-00 (work 1077 in progress), March 2009. 1079 [I-D.ietf-tsvwg-port-randomization] 1080 Larsen, M. and F. Gont, "Port Randomization", 1081 draft-ietf-tsvwg-port-randomization-03 (work in progress), 1082 March 2009. 1084 [I-D.nishitani-cgn] 1085 Nishitani, T., Miyakawa, S., Nakagawa, A., and H. Ashida, 1086 "Common Functions of Large Scale NAT (LSN)", 1087 draft-nishitani-cgn-02 (work in progress), June 2009. 1089 [I-D.shirasaki-isp-shared-addr] 1090 Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J., 1091 and H. Ashida, "ISP Shared Address", 1092 draft-shirasaki-isp-shared-addr-02 (work in progress), 1093 March 2009. 1095 [I-D.wilson-class-e] 1096 Wilson, P., Michaelson, G., and G. Huston, "Redesignation 1097 of 240/4 from "Future Use" to "Private Use"", 1098 draft-wilson-class-e-02 (work in progress), 1099 September 2008. 1101 [I-D.ymbk-aplusp] 1102 Bush, R., Maennel, O., Zorz, J., Bellovin, S., and L. 1103 Cittadini, "The A+P Approach to the IPv4 Address 1104 Shortage", draft-ymbk-aplusp-03 (work in progress), 1105 March 2009. 1107 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1108 E. Lear, "Address Allocation for Private Internets", 1109 BCP 5, RFC 1918, February 1996. 1111 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1112 Translator (NAT) Terminology and Considerations", 1113 RFC 2663, August 1999. 1115 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1116 specifying the location of services (DNS SRV)", RFC 2782, 1117 February 2000. 1119 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1120 Address Translator (Traditional NAT)", RFC 3022, 1121 January 2001. 1123 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 1124 (NAT) Compatibility Requirements", RFC 3715, March 2004. 1126 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1127 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1128 January 2005. 1130 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1131 Networks (VPNs)", RFC 4364, February 2006. 1133 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1134 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1135 RFC 4787, January 2007. 1137 Authors' Addresses 1139 Pierre Levis (editor) 1140 France Telecom 1141 42 rue des Coutures 1142 BP 6243 1143 Caen Cedex 4 14066 1144 France 1146 Email: pierre.levis@orange-ftgroup.com 1148 Mohamed Boucadair 1149 France Telecom 1151 Email: mohamed.boucadair@orange-ftgroup.com 1153 Jean-Luc Grimault 1154 France Telecom 1156 Email: jeanluc.grimault@orange-ftgroup.com 1158 Alain Villefranque 1159 France Telecom 1161 Email: alain.villefranque@orange-ftgroup.com