idnits 2.17.1 draft-ietf-intarea-shared-addressing-issues-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 03, 2011) is 4797 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-cheshire-nat-pmp-03 == Outdated reference: A later version (-02) exists of draft-haddad-mext-nat64-mobility-harmful-01 == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-00 == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-06 == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-06 == Outdated reference: A later version (-06) exists of draft-shirasaki-nat444-03 == Outdated reference: A later version (-10) exists of draft-ymbk-aplusp-09 -- Obsolete informational reference (is this intentional?): RFC 1700 (Obsoleted by RFC 3232) -- Obsolete informational reference (is this intentional?): RFC 2140 (Obsoleted by RFC 9040) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Ford, Ed. 3 Internet-Draft Internet Society 4 Intended status: Informational M. Boucadair 5 Expires: September 4, 2011 France Telecom 6 A. Durand 7 Juniper Networks 8 P. Levis 9 France Telecom 10 P. Roberts 11 Internet Society 12 March 03, 2011 14 Issues with IP Address Sharing 15 draft-ietf-intarea-shared-addressing-issues-05 17 Abstract 19 The completion of IPv4 address allocations from IANA and the RIRs is 20 causing service providers around the world to question how they will 21 continue providing IPv4 connectivity service to their subscribers 22 when there are no longer sufficient IPv4 addresses to allocate them 23 one per subscriber. Several possible solutions to this problem are 24 now emerging based around the idea of shared IPv4 addressing. These 25 solutions give rise to a number of issues and this memo identifies 26 those common to all such address sharing approaches. Such issues 27 include application failures, additional service monitoring 28 complexity, new security vulnerabilities and so on. Solution- 29 specific discussions are out of scope. 31 Deploying IPv6 is the only perennial way to ease pressure on the 32 public IPv4 address pool without the need for address sharing 33 mechanisms that give rise to the issues identified herein. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on September 4, 2011. 51 Copyright Notice 53 Copyright (c) 2011 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Shared Addressing Solutions . . . . . . . . . . . . . . . . . 4 70 3. Analysis of Issues as they Relate to First and Third 71 Parties . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 4. Content Provider Example . . . . . . . . . . . . . . . . . . . 8 73 5. Port Allocation . . . . . . . . . . . . . . . . . . . . . . . 8 74 5.1. Outgoing Ports . . . . . . . . . . . . . . . . . . . . . . 9 75 5.2. Incoming Ports . . . . . . . . . . . . . . . . . . . . . . 10 76 5.2.1. Port Negotiation . . . . . . . . . . . . . . . . . . . 11 77 5.2.2. Connection to a Well-Known Port Number . . . . . . . . 12 78 5.2.3. Port Discovery Mechanisms . . . . . . . . . . . . . . 12 79 6. Impact on Applications . . . . . . . . . . . . . . . . . . . . 12 80 7. Geo-location and Geo-proximity . . . . . . . . . . . . . . . . 14 81 8. Tracking Service Usage . . . . . . . . . . . . . . . . . . . . 15 82 9. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 10. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 16 85 12. Traceability . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 13. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 13.1. Abuse Logging and Penalty Boxes . . . . . . . . . . . . . 18 88 13.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 19 89 13.3. SPAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 13.4. Port Randomisation . . . . . . . . . . . . . . . . . . . . 19 91 13.5. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 13.6. Policing Forwarding Behaviour . . . . . . . . . . . . . . 20 93 14. Transport Issues . . . . . . . . . . . . . . . . . . . . . . . 20 94 14.1. Parallel connections . . . . . . . . . . . . . . . . . . . 20 95 14.2. Serial connections . . . . . . . . . . . . . . . . . . . . 21 96 14.3. TCP Control Block Sharing . . . . . . . . . . . . . . . . 21 97 15. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 16. Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . 21 99 17. IPv6 Transition Issues . . . . . . . . . . . . . . . . . . . . 21 100 18. Introduction of Single Points of Failure . . . . . . . . . . . 22 101 19. State Maintenance Reduces Battery Life . . . . . . . . . . . . 22 102 20. Support of Multicast . . . . . . . . . . . . . . . . . . . . . 22 103 21. Support of Mobile-IP . . . . . . . . . . . . . . . . . . . . . 23 104 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 105 23. Security Considerations . . . . . . . . . . . . . . . . . . . 23 106 24. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 107 25. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 108 26. Annex . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 109 26.1. Classes of Address Sharing Solution . . . . . . . . . . . 24 110 26.2. Address Space Multiplicative Factor . . . . . . . . . . . 24 111 27. Informative References . . . . . . . . . . . . . . . . . . . . 25 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 114 1. Introduction 116 Allocations of IPv4 addresses from the Internet Assigned Numbers 117 Authority (IANA) were completed on February 3, 2011 [IPv4_Pool]. 118 Allocations from Regional Internet Registries (RIRs) are anticipated 119 to be complete around a year later, although the exact date will vary 120 from registry to registry. This is causing service providers around 121 the world to start to question how they will continue providing IPv4 122 connectivity service to their subscribers when there are no longer 123 sufficient IPv4 addresses to allocate them one per subscriber. 124 Several possible solutions to this problem are now emerging based 125 around the idea of shared IPv4 addressing. These solutions give rise 126 to a number of issues and this memo identifies those common to all 127 such address sharing approaches and collects them in a single 128 document. 130 Deploying IPv6 is the only perennial way to ease pressure on the 131 public IPv4 address pool without the need for address sharing 132 mechanisms that give rise to the issues identified herein. In the 133 short term, maintaining growth of IPv4 services in the presence of 134 IPv4 address depletion will require address sharing. Address sharing 135 will cause issues for end-users, service providers and third parties 136 such as law enforcement agencies and content providers. This memo is 137 intended to highlight and briefly discuss these issues. 139 Increased IPv6 deployment should reduce the burden being placed on an 140 address sharing solution, and should reduce the costs of operating 141 that solution. Increasing IPv6 deployment should cause a reduction 142 in the number of concurrent IPv4 sessions per subscriber. If the 143 percentage of end-to-end IPv6 traffic significantly increases, so 144 that the volume of IPv4 traffic begins decreasing, then the number of 145 IPv4 sessions will decrease. The smaller the number of concurrent 146 IPv4 sessions per subscriber, the higher the number of subscribers 147 able to share the same IPv4 public address, and consequently, the 148 lower the number of IPv4 public addresses required. However, this 149 effect will only occur for subscribers who have both an IPv6 access 150 and a shared IPv4 access. This motivates a strategy to 151 systematically bind a shared IPv4 access to an IPv6 access. It is 152 difficult to foresee to what extent growing IPv6 traffic will reduce 153 the number of concurrent IPv4 sessions, but in any event, IPv6 154 deployment and use should reduce the pressure on the available public 155 IPv4 address pool. 157 2. Shared Addressing Solutions 159 In many networks today a subscriber is provided with a single public 160 IPv4 address at their home or small business. For instance, in fixed 161 broadband access, an IPv4 public address is assigned to each CPE 162 (Customer Premises Equipment). CPEs embed a NAT function which is 163 responsible for translating private IPv4 addresses ([RFC1918] 164 addresses) assigned to hosts within the local network, to the public 165 IPv4 address assigned by the service provider (and vice versa). 166 Therefore, devices located with the LAN share the single public IPv4 167 address and they are all associated with a single subscriber account 168 and a single network operator. 170 A number of proposals currently under consideration in the IETF rely 171 upon the mechanism of multiplexing multiple subscribers' connections 172 over a smaller number of shared IPv4 addresses. This is a 173 significant change. These proposals include Carrier Grade NAT (CGN. 174 a.k.a., LSN for Large Scale NAT) [I-D.ietf-behave-lsn-requirements], 175 Dual-Stack Lite [I-D.ietf-softwire-dual-stack-lite], NAT64 176 [I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-v6v4-xlate], 177 Address+Port (A+P) proposals [I-D.ymbk-aplusp], 178 [I-D.boucadair-port-range] and SAM [I-D.despres-sam]. Section 26 179 provides a classification of these different types of solutions and 180 discusses some of the design considerations to be borne in mind when 181 deploying large-scale address sharing. Whether we're talking about 182 DS-Lite, A+P, NAT64 or CGN isn't especially important - it's the view 183 from the outside that matters, and given that, most of the issues 184 identified below apply regardless of the specific address sharing 185 scenario in question. 187 In these new proposals, a single public IPv4 address would be shared 188 by multiple homes or small businesses (i.e., multiple subscribers) so 189 the operational paradigm described above would no longer apply. In 190 this document we refer to this new paradigm as large-scale address 191 sharing. All these proposals extend the address space by adding port 192 information, they differ in the way they manage the port value. 194 Security issues associated with NAT have long been documented (see 195 [RFC2663] and [RFC2993] ). However, sharing IPv4 addresses across 196 multiple subscribers by any means, either moving the NAT 197 functionality from the home gateway to the core of the service 198 provider network, or restricting the port choice in the subscriber's 199 NAT, creates additional issues for subscribers, content providers and 200 network operators. Many of these issues are created today by public 201 Wi-Fi hotspot deployments. As such large-scale address sharing 202 solutions become more widespread in the face of IPv4 address 203 depletion, these issues will become both more severe and more 204 commonly felt. NAT issues in the past typically only applied to a 205 single legal entity; as large-scale address sharing becomes more 206 prevalent these issues will increasingly span across multiple legal 207 entities simultaneously. 209 All large-scale address sharing proposals share technical and 210 operational issues and these are addressed in the sections that 211 follow. These issues are common to any service-provider NAT, 212 enterprise NAT, and also non-NAT solutions that share individual IPv4 213 addresses across multiple subscribers. This document is intended to 214 bring all of these issues together in one place. 216 3. Analysis of Issues as they Relate to First and Third Parties 218 In this section we present an analysis of whether the issues 219 identified in the remainder of this document are applicable to the 220 organization deploying the shared addressing mechanism (and by 221 extension their subscribers) and/or whether these issues impact third 222 parties (e.g., content providers, law enforcement agencies, etc.). 223 In this analysis, issues that affect end-users are deemed to affect 224 1st parties, as end-users can be expected to complain to their 225 service provider when problems arise. Where issues can expect to be 226 foreseen and addressed by the party deploying the shared addressing 227 solution, they are not attributed. 229 In Figure 1 we have also tried to indicate (with 'xx') where issues 230 are newly created in addition to what could be expected from the 231 introduction of a traditional NAT device. Issues marked with a 232 single 'x' are already present today in the case of typical CPE NAT, 233 however they can be expected to be more severe and widespread in the 234 case of large-scale address sharing. 236 +------------------------------------------------+--------+---------+ 237 | Issue | 1st | 3rd | 238 | | party | parties | 239 +------------------------------------------------+--------+---------+ 240 | Restricted allocations of outgoing | x | | 241 | ports will impact performance for end users | | | 242 | | | | 243 | Incoming port negotiation mechanisms may fail | xx | | 244 | | | | 245 | Incoming connections to Assigned Ports will | x | | 246 | not work | | | 247 | | | | 248 | Port discovery mechanisms will not work | x | | 249 | | | | 250 | Some applications will fail to operate | x | x | 251 | | | | 252 | Assumptions about parallel/serial connections | x | x | 253 | may fail | | | 254 | | | | 255 +------------------------------------------------+--------+---------+ 256 +------------------------------------------------+--------+---------+ 257 | Issue | 1st | 3rd | 258 | | party | parties | 259 +------------------------------------------------+--------+---------+ 260 | TCP control block sharing will be affected | x | x | 261 | | | | 262 | Reverse DNS will be affected | x | x | 263 | | | | 264 | Inbound ICMP will fail in many cases | x | x | 265 | | | | 266 | Amplification of security issues | xx | xx | 267 | | | | 268 | Fragmentation will require special handling | x | | 269 | | | | 270 | Single points of failure and increased | x | | 271 | network instability | | | 272 | | | | 273 | Port randomization will be affected | x | | 274 | | | | 275 | Service usage monitoring and abuse logging | xx | xx | 276 | will be impacted for all elements in the chain | | | 277 | between service provider and content provider | | | 278 | | | | 279 | Penalty boxes will no longer work | xx | xx | 280 | | | | 281 | Spam blacklisting will be affected | xx | xx | 282 | | | | 283 | Geo-location services will be impacted | xx | xx | 284 | | | | 285 | Geo-proximity mechanisms will be impacted | xx | xx | 286 | | | | 287 | Load balancing algorithms may be impacted | | xx | 288 | | | | 289 | Authentication mechanisms may be impacted | | x | 290 | | | | 291 | Traceability of network usage and abusage will | | xx | 292 | be affected | | | 293 | | | | 294 | IPv6 transition mechanisms will be affected | xx | | 295 | | | | 296 | Frequent keep-alives reduce battery life | x | | 297 | | | | 298 +------------------------------------------------+--------+---------+ 300 Figure 1: Shared addressing issues for first and third parties 302 As can be seen from Figure 1, deployment of large-scale address 303 sharing will create almost as many problems for third parties as it 304 does for the service provider deploying the address sharing 305 mechanism. Several of these issues are specific to the introduction 306 of large-scale address sharing as well. All of these issues are 307 discussed in further detail below. 309 4. Content Provider Example 311 Taking a content provider as an example of a third-party, and 312 focusing on the issues that are created specifically by the presence 313 of large-scale address sharing, we identify the following issues as 314 being of particular concern: 316 o Degraded geolocation for targeted advertising and licensed content 317 restrictions (see Section 7). 319 o Additional latency due to indirect routing and degraded 320 geoproximity (see Section 7). 322 o Exposure to new amplification attacks (see Section 13). 324 o Service usage monitoring is made more complicated (see Section 8). 326 o Incoming port negotiation mechanisms may fail (see Section 5.2.1). 328 o IP blocking for abuse/spam will cause collateral damage (see 329 Section 13). 331 o Load balancing algorithms may be impacted (see Section 16). 333 o Traceability of network usage and abuse will be impacted (see 334 Section 12). 336 5. Port Allocation 338 When we talk about port numbers we need to make a distinction between 339 outgoing connections and incoming connections. For outgoing 340 connections, the actual source port number used is usually 341 irrelevant. (While this is true today, in a port-range solution it 342 is necessary for the source port to be within the allocated range). 343 But for incoming connections, the specific port numbers allocated to 344 subscribers matter because they are part of external referrals (used 345 by third parties to contact services run by the subscribers). 347 The total number of subscribers able to share a single IPv4 address 348 will depend upon assumptions about the average number of ports 349 required per active subscriber, and the average number of 350 simultaneously active subscribers. It is important to realize that 351 the TCP design makes it undesirable for clients to re-use ports while 352 they remain in the TIME-WAIT state (typically 4 minutes after the 353 connection has concluded). TIME-WAIT state removes the hazard of old 354 duplicates for "fast" or "long" connections, in which clock-driven 355 Initial Sequence Number selection is unable to prevent overlap of the 356 old and new sequence spaces. The TIME-WAIT delay allows all old 357 duplicate segments time enough to die in the Internet before the 358 connection is reopened [RFC1337]. Therefore ports in this state must 359 be included in calculations concerning port usage per subscriber. 361 Most of the time the source port selected by a client application 362 will be translated (unless there is direct knowledge of a port-range 363 restriction in the client's stack), either by a NAT in the 364 subscriber's device, or by a CPE NAT, or by a CPE NAT and a CGN. 366 [RFC1700] defines the Assigned Ports (both System and User). IANA 367 has further classified the whole port space into three categories, as 368 defined in [IANA_Ports] 370 o The Well-Known Ports are those from 0 through 1023. 372 o The Registered Ports are those from 1024 through 49151. 374 o The Dynamic and/or Private Ports are those from 49152 through 375 65535. 377 [RFC4787] notes that current NATs have different policies with regard 378 to this classification; some NATs restrict their translations to the 379 use of dynamic ports, some also include registered ports, some 380 preserve the port if it is in the well-known range. [RFC4787] makes 381 it clear that the use of port space (1024-65535) is safe: "mapping a 382 source port to a source port that is already registered is unlikely 383 to have any bad effects". Therefore, for all address sharing 384 solutions, there is no reason to only consider a subset of the port 385 space (1024-65535) for outgoing source ports. 387 5.1. Outgoing Ports 389 According to measurements the average number of outgoing ports 390 consumed per active subscriber is much, much smaller than the maximum 391 number of ports a subscriber can use at any given time. However, the 392 distribution is heavy-tailed, so there are typically a small number 393 of subscribers who use a very high number of ports [CGN_Viability]. 394 This means that an algorithm that dynamically allocates outgoing port 395 numbers from a central pool will typically allow more subscribers to 396 share a single IPv4 address than algorithms that statically divide 397 the resource by pre-allocating a fixed number of ports to each 398 subscriber. Similarly, such an algorithm should be more able to 399 accommodate subscribers wishing to use a relatively high number of 400 ports. 402 It is important to note here that the desire to dynamically allocate 403 outgoing port numbers will make a service provider's job of 404 maintaining records of subscriber port number allocations 405 considerably more onerous (see Section 12). The number of records 406 per subscriber will increase from 1 in a scheme where ports are 407 statically allocated, to a much larger number equivalent to the total 408 number of outgoing ports consumed by that subscriber during the time 409 period for which detailed logs must be kept. 411 A potential problem with dynamic allocation occurs when one of the 412 subscriber devices behind such a port-shared IPv4 address becomes 413 infected with a worm, which then quickly sets about opening many 414 outbound connections in order to propagate itself. Such an infection 415 could rapidly exhaust the shared resource of the single IPv4 address 416 for all connected subscribers. It is therefore necessary to impose 417 limits on the total number of ports available to an individual 418 subscriber to ensure that the shared resource (the IPv4 address) 419 remains available in some capacity to all the subscribers using it. 420 However, static schemes for ports assignment may introduce security 421 issues [RFC6056] when small contiguous port ranges are statically 422 assigned to subscribers. Another way to mitigate this issue is to 423 kill off (randomly) established connections when the port space runs 424 out. A user with many connections will be proportionally more likely 425 to get impacted. 427 Session failure due to NAT state overflow or timeout (when the NAT 428 discards session state because it's run out of resource) can be 429 experienced when the configured quota per user is reached or if the 430 NAT is out of recourses. 432 5.2. Incoming Ports 434 It is desirable to ensure that incoming ports remain stable over 435 time. This is challenging as the network doesn't know anything in 436 particular about the applications that it is supporting and therefore 437 has no real notion of how long an application/service session is 438 still ongoing and therefore requiring port stability. 440 Early measurements [CGN_Viability] also seem to indicate that, on 441 average, only very few ports are used by subscribers for incoming 442 connections. However, a majority of subscribers accept at least one 443 inbound connection. 445 This means that it is not necessary to pre-allocate a large number of 446 incoming ports to each subscriber. It is possible to either pre- 447 allocate a small number of ports for incoming connections or do port 448 allocation on demand when the application wishing to receive a 449 connection is initiated. The bulk of incoming ports can be reserved 450 as a centralized resource shared by all subscribers using a given 451 public IPv4 address. 453 5.2.1. Port Negotiation 455 In current deployments, one important and widely used feature of many 456 CPE devices is the ability to open incoming ports (port forwarding) 457 either manually, or with a protocol such as Universal Plug and Play 458 Internet Gateway Device (UPnP IGD) [UPnP-IGD]. If a CGN is present, 459 the port must also be opened in the CGN. CGN makes subscribers 460 dependent on their service provider for this functionality. 462 If the CPE and the CGN are required to co-operate in order for port 463 forwarding functionality to work, protocol development will be 464 required to provide an automated solution. If the CGN architecture 465 is composed of only one NAT level (no NAT in the CPE) as for DS-Lite, 466 the service provider will still be required to offer some means for 467 configuring incoming ports by their subscribers. This may be either 468 via a PCP [I-D.ietf-pcp-base], UPnP or NAT-PMP proxy over a tunneled 469 direct connection between the CPE and CGN, or a web interface to 470 configure the incoming port mapping on the CGN. Note, that such an 471 interface effectively makes public what was previously a private 472 management interface and this raises security concerns that must be 473 addressed. 475 For port-range solutions, port forwarding capabilities may still be 476 present at the CPE, with the limitation that the open incoming port 477 must be within the allocated port-range (for instance it is not 478 possible to open port 5002 for incoming connections if port 5002 is 479 not within the allocated port-range). 481 5.2.1.1. Universal Plug and Play (UPnP) 483 Using the UPnP semantic, an application asks "I want to use port 484 number X, is that OK?" and the answer is yes or no. If the answer is 485 no, the application will typically try the next port in sequence, 486 until it either finds one that works or gives up after a limited 487 number of attempts. UPnP IGD 1.0 has no way to redirect the 488 application to use another port number. UPnP IGD 2.0 improves this 489 situation and allows for allocation of any available port. 491 5.2.1.2. NAT Port Mapping Protocol (NAT-PMP) 493 NAT-PMP enables the NAT to redirect the requesting application to a 494 port deemed to be available for use by the NAT state mapping table. 496 5.2.2. Connection to a Well-Known Port Number 498 Once an IPv4 address sharing mechanism is in place, inbound 499 connections to well-known port numbers will not work in the general 500 case. Any application that is not port-agile cannot be expected to 501 work. Some workaround (e.g., redirects to a port-specific URI) could 502 be deployed given sufficient incentives. There exist several 503 proposals for 'application service location' protocols which would 504 provide a means of addressing this problem, but historically these 505 proposals have not gained much deployment traction. 507 For example, the use of DNS SRV records [RFC2782] provides a 508 potential solution for subscribers wishing to host services in the 509 presence of a shared-addressing scheme. SRV records make it possible 510 to specify a port value related to a service, thereby making services 511 accessible on ports other than the Well-Known ports. It is worth 512 noting that this mechanism is not applicable to HTTP and many other 513 protocols. 515 5.2.3. Port Discovery Mechanisms 517 Port discovery using a UDP port to discover a service available on a 518 corresponding TCP port, either through broadcast, multicast or 519 unicast, is a commonly deployed mechanism. Unsolicited inbound UDP 520 will be dropped by address sharing mechanisms as they have no live 521 mapping to enable them to forward the packet to the appropriate host. 522 Address sharing thereby breaks this service discovery technique. 524 6. Impact on Applications 526 Address sharing solutions will have an impact on the following types 527 of applications: 529 o Applications that establish inbound communications - these 530 applications will have to ensure that ports selected for inbound 531 communications are either within the allocated range (for port- 532 range solutions) or are forwarded appropriately by the CGN (for 533 CGN-based solutions). See Section 5.2 for more discussion of 534 this; 536 o Applications that carry address and/or port information in their 537 payload - where translation of port and/or address information is 538 performed at the IP and transport layers by the address sharing 539 solution, an ALG will also be required to ensure application layer 540 data is appropriately modified. Note that ALGs are required in 541 some cases, and in many other cases end-to-end protocol mechanisms 542 have developed to work around a lack of ALGs in address 543 translators, to the point of it being preferable to avoid any 544 support in the NAT; 546 o Applications that use fixed ports - see Section 5.2.2 for more 547 discussion of this; 549 o Applications that do not use any port (e.g., ICMP echo) - will 550 require special handling - see Section 9 for more discussion of 551 this; 553 o Applications that assume the uniqueness of source addresses (e.g., 554 IP address as identifier) - such applications will fail to operate 555 correctly in the presence of multiple, discrete, simultaneous 556 connections from the same source IP address; 558 o Applications that explicitly prohibit concurrent connections from 559 the same address - such applications will fail when multiple 560 subscribers sharing an IP address attempt to use them 561 simultaneously. 563 o Applications that do not use TCP or UDP for transport - All IP 564 address sharing mechanisms proposed to date are limited to TCP, 565 UDP, and ICMP, thereby preventing end users from fully utilizing 566 the Internet (e.g., SCTP, DCCP, RSVP, protocol 41 (IPv6-over- 567 IPv4), protocol 50 (IPsec ESP)). 569 Applications already frequently implement mechanisms in order to 570 circumvent the presence of NATs (typically CPE NATs): 572 o Application Layer Gateways (ALGs): Many CPE devices today embed 573 ALGs that allow applications to behave correctly despite the 574 presence of NAT on the CPE. When the NAT belongs to the 575 subscriber, the subscriber has flexibility to tailor the device to 576 his or her needs. For CGNs, subscribers will be dependent on the 577 set of ALGs that their service provider makes available. For 578 port-range solutions, ALGs will require modification to deal with 579 the port-range restriction, but will otherwise have the same 580 capabilities as today. Note that ALGs are required in some cases, 581 and in many other cases end-to-end protocol mechanisms have 582 developed to work around lack of ALGs, to the point of it being 583 preferable to avoid any support in the NAT. 585 o NAT Traversal Techniques: There are several commonly-deployed 586 mechanisms that support operating servers behind a NAT by 587 forwarding specific TCP or UDP ports to specific internal hosts 588 ([UPnP-IGD], [I-D.cheshire-nat-pmp], and manual configuration). 589 All of these mechanisms assume the NAT's WAN address is a 590 publicly-routable IP address, and fail to work normally when that 591 assumption is wrong. There have been attempts to avoid that 592 problem by automatically disabling the NAT function and bridging 593 traffic instead upon assignment of a private IP address to the WAN 594 interface (as is required for [Windows-Logo] certification). 595 Bridging (rather than NATting) has other side effects (DHCP 596 requests are served by an upstream DHCP server which can increase 597 complexity of in-home networking). 599 7. Geo-location and Geo-proximity 601 IP addresses are frequently used to indicate, with some level of 602 granularity and some level of confidence, where a host is physically 603 located. Using IP addresses in this fashion is a heuristic at best, 604 and is already challenged today by other deployed capabilities, e.g., 605 tunnels. Geo-location services are used by content providers to 606 allow them to conform with regional content licensing restrictions, 607 to target advertising at specific geographic areas, or to provide 608 customized content. Geo-location services are also necessary for 609 emergency services provision. In some deployment contexts (e.g., 610 centralized CGN), shared addressing will reduce the level of 611 confidence and level of location granularity that IP-based geo- 612 location services can provide. Viewed from the content provider, a 613 subscriber behind a CGN geolocates to wherever the prefix of the CGN 614 appears to be; very often that will be in a different city than the 615 subscriber. 617 IP addresses are also used as input to geolocation services that 618 resolve an IP address to a physical location using information from 619 the network infrastructure. Current systems rely on resources such 620 as RADIUS databases and DHCP lease tables. The use of address 621 sharing will prevent these systems from resolving the location of a 622 host based on IP address alone. It will be necessary for users of 623 such systems to provide more information (e.g., TCP or UDP port 624 numbers), and for the systems to use this information to query 625 additional network resources (e.g., NAT-PT binding tables). Since 626 these new data elements tend to be more ephemeral than those 627 currently used for geolocation, their use by geolocation systems may 628 require them to be cached for some period of time. 630 Other forms of geo-location will still work as usual. 632 A slightly different use of an IP address is to calculate the 633 proximity of a connecting host to a particular service delivery 634 point. This use of IP address information impacts the efficient 635 delivery of content to an end-user. If a CGN is introduced in 636 communications and it is far from an end-user connected to it, 637 application performance may be degraded insofar as IP-based geo- 638 proximity is a factor. 640 8. Tracking Service Usage 642 As large-scale address sharing becomes more commonplace, monitoring 643 the number of unique users of a service will become more complex than 644 simply counting the number of connections from unique IP addresses. 645 While this is a somewhat inexact methodology today due to the 646 widespread use of CPE NAT, it will become a much less useful approach 647 in the presence of widespread large-scale address sharing solutions. 648 In general, all elements that monitor usage or abusage in the chain 649 between a service provider that has deployed address sharing and a 650 content provider will need to be upgraded to take account of the port 651 value in addition to IP addresses. 653 9. ICMP 655 ICMP does not include a port field and is consequently problematic 656 for address sharing mechanisms. Some ICMP message types include a 657 fragment of the datagram that triggered the signal to be sent, which 658 is assumed to include port numbers. For some ICMP message types, the 659 Identifier field has to be used as a de-multiplexing token. Sourcing 660 ICMP echo messages from hosts behind an address sharing solution does 661 not pose problems, although responses to outgoing ICMP echo messages 662 will require special handling, such as making use of the ICMP 663 identifier value to route the response appropriately. 665 For inbound ICMP there are two cases. The first case is that of ICMP 666 sourced from outside the network of the address sharing solution 667 provider. Where ICMP messages include a fragment of an outgoing 668 packet including port numbers it may be possible to forward the 669 packet appropriately. In addition to these network signaling 670 messages, several applications (e.g., P2P applications) make use of 671 ICMP echo messages which include no hints that could be used to route 672 the packet correctly. Measurements derived by such applications in 673 the presence of an address sharing solution will be erroneous or fail 674 altogether. The second case is that of ICMP sourced from within the 675 network of the address sharing solution provider (e.g., for network 676 management, signaling and diagnostic purposes). In this case ICMP 677 can be routed normally for CGN-based solutions owing to the presence 678 of locally unique private IP addresses for each CPE device. For 679 port-range solutions, ICMP echo messages will not be routable without 680 special handling, e.g., placing a port number in the ICMP identifier 681 field, and having port-range routers make routing decisions based 682 upon that field. 684 Considerations related to ICMP message handling in NAT-based 685 environments are specified in [RFC5508]. 687 10. MTU 689 In applications where the end hosts are attempting to use path MTU 690 Discovery [RFC1191] to optimize transmitted packet size with 691 underlying network MTU, shared addressing has a number of items which 692 must be considered. As covered in Section 9, ICMP "Packet Too Big" 693 messages must be properly translated through the address sharing 694 solution in both directions. However, even when this is done 695 correctly, MTU can be a concern. Many end hosts cache PMTUd 696 information for a certain period of time. If the MTU behind the 697 address sharing solution is inconsistent, the public end host may 698 have the incorrect MTU value cached. This may cause it to send 699 packets that are too large, causing them to be dropped if the DF 700 (Don't Fragment) bit is set, or causing them to be fragmented by the 701 network, increasing load and overhead. Because the host eventually 702 will reduce MTU to the lowest common value for all hosts behind a 703 given public address, it may also send packets that are below optimal 704 size for the specific connection, increasing overhead and reducing 705 throughput. 707 This issue also generates a potential attack vector, that a 708 malevolent user could send an ICMP "Packet Too Big" (Type 3, Code 4) 709 message indicating a Next-Hop MTU of anything down to 68 octets. 710 This value will be cached by the off-net server for all subscribers 711 sharing the address of the malevolent user. This could lead to a DoS 712 against both the remote server and the large-scale NAT device itself 713 (as they will both have to handle many more packets per second). 715 11. Fragmentation 717 When a packet is fragmented, transport-layer port information (either 718 UDP or TCP) is only present in the first fragment. Subsequent 719 fragments will not carry the port information and so will require 720 special handling. In addition, the IP Identifier may no longer be 721 unique as required by the receiver to aid in assembling the fragments 722 of a datagram. 724 12. Traceability 726 In many jurisdictions, service providers are legally obliged to 727 provide the identity of a subscriber upon request to the appropriate 728 authorities. Such legal requests have traditionally included the 729 source IPv4 address and date (and usually the time), which is 730 sufficient information when subscribers are assigned IPv4 addresses 731 for a long duration. 733 However, where one public IPv4 address is shared between several 734 subscribers, the IPv4 address no longer uniquely identifies a 735 subscriber. There are two solutions to this problem: 737 o The first solution is for servers to additionally log the source 738 port of incoming connections and for the legal request to include 739 the source port. The legal request should include the 740 information: [Source IP address, Source Port, Timestamp] (and 741 possibly other information). Accurate time-keeping (e.g., use of 742 NTP or SNTP) is vital because port assignments are dynamic. A 743 densely populated CGN could mean even very small amounts of clock 744 skew between a third party's server and the CGN operator will 745 result in ambiguity about which customer was using a specific port 746 at a given time. 748 o The second solution considers it is unrealistic to expect all 749 servers to log the source port number of incoming connections. To 750 deal with this, service providers using IPv4 address sharing may 751 need to log IP destination addresses. 753 Destination logging is imperfect if multiple subscribers are 754 accessing the same (popular) server at nearly the same time, it can 755 be impossible to disambiguate which subscriber accessed the server, 756 especially with protocols that involve several connections (e.g., 757 HTTP). Thus, logging the destination address on the NAT is inferior 758 to logging the source port at the server. 760 If neither solution is used (that is, the server is not logging 761 source port numbers and the NAT is not logging destination IP 762 addresses), the service provider cannot trace a particular activity 763 to a specific subscriber. In this circumstance, the service provider 764 would need to disclose the identity of all subscribers who had active 765 sessions on the NAT during the time period in question. This may be 766 a large number of subscribers. 768 Address sharing solutions must record and store all mappings 769 (typically during 6-12 months, depending on the local jurisdiction) 770 that they create. If we consider one mapping per session, a service 771 provider should record and retain traces of all sessions created by 772 all subscribers during one year (if the legal storage duration is one 773 year). This may be challenging due to the volume of data requiring 774 storage, the volume of data to repeatedly transfer to the storage 775 location, and the volume of data to search in response to a query. 777 Address sharing solutions may mitigate these issues to some extent by 778 pre-allocating groups of ports. Then only the allocation of the 779 group needs to be recorded, and not the creation of every session 780 binding within that group. There are trade-offs to be made between 781 the sizes of these port groups, the ratio of public addresses to 782 subscribers, whether or not these groups timeout, the impact on 783 logging requirements and port randomization security [RFC6056]. 785 13. Security 787 Before noting some specific security-related issues caused by large- 788 scale address sharing, it is perhaps worth noting that, in general, 789 address sharing creates a vector for attack amplification in numerous 790 ways. See Section 10 for one example. 792 13.1. Abuse Logging and Penalty Boxes 794 When an abuse is reported today, it is usually done in the form: IPv4 795 address X has done something bad at time T0. This is not enough 796 information to uniquely identify the subscriber responsible for the 797 abuse when that IPv4 address is shared by more than one subscriber. 798 Law enforcement authorities may be particularly impacted because of 799 this. This particular issue can be fixed by logging port numbers, 800 although this will increase logging data storage requirements. 802 A number of services on the network today log the IPv4 source 803 addresses used in connection attempts to protect themselves from 804 certain attacks. For example, if a server sees too many requests 805 from the same IPv4 address in a short period of time, it may decide 806 to put that address in a penalty box for a certain time during which 807 requests are denied, or it may require completion of a CAPTCHA for 808 future requests. If an IPv4 address is shared by multiple 809 subscribers, this would have unintended consequences in a couple of 810 ways. First it may become the natural behavior to see many login 811 attempts from the same address because it is now shared across a 812 potentially large number of subscribers. Second and more likely is 813 that one user who fails a number of login attempts may block out 814 other users who have not made any previous attempts but who will now 815 fail on their first attempt. In the presence of widespread large- 816 scale address sharing, penalty box solutions to service abuse simply 817 will not work. 819 In addition, there are web tie-ins into different blacklists that web 820 administrators subscribe to redirect users with infected machines 821 (e.g., detect the presence of a worm) to a URL that says "Hey, your 822 machine is infected!". With address sharing, someone else's worm can 823 interfere with the ability to access the service for other 824 subscribers sharing the same IP address. 826 13.2. Authentication 828 Simple address-based identification mechanisms that are used to 829 populate access control lists will fail when an IP address is no 830 longer sufficient to identify a particular subscriber. Including 831 port numbers in access control list definitions may be possible at 832 the cost of extra complexity, and may also require the service 833 provider to make static port assignments, which conflicts with the 834 requirement for dynamic assignments discussed in Section 5.1. 836 Address or DNS-name based signatures (e.g., some X.509 signatures) 837 may also be affected by address sharing as the address itself is now 838 a shared token, and the name to address mapping may not be current. 840 13.3. SPAM 842 Another case of identifying abusers has to do with SPAM blacklisting. 843 When a spammer is behind a CGN or using a port-shared address, 844 blacklisting of their IP address will result in all other subscribers 845 sharing that address having their ability to source SMTP packets 846 restricted to some extent. 848 13.4. Port Randomisation 850 A blind attack that can be performed against TCP relies on the 851 attacker's ability to guess the 5-tuple (Protocol, Source Address, 852 Destination Address, Source Port, Destination Port) that identifies 853 the transport protocol instance to be attacked. [RFC6056] describes 854 a number of methods for the random selection of the source port 855 number, such that the ability of an attacker to correctly guess the 856 5-tuple is reduced. With shared IPv4 addresses, the port selection 857 space is reduced. Preserving port randomization is important and may 858 be more or less difficult depending on the address sharing solution 859 and the size of the port space that is being manipulated. Allocation 860 of non-contiguous port ranges could help to mitigate this issue. 862 It should be noted that guessing the port information may not be 863 sufficient to carry out a successful blind attack. An in-window TCP 864 Sequence Number (SN) should also be known or guessed. A TCP segment 865 is processed only if all previous segments have been received, except 866 for some Reset segment implementations which immediately process the 867 Reset as long as it is within the Window. If SN is randomly chosen 868 it will be difficult to guess it (SN is 32 bits long); port 869 randomization is one protection among others against blind attacks. 870 There is more detailed discussion of improving TCP's robustness to 871 Blind In-Window Attacks in [RFC5961]. 873 13.5. IPsec 875 The impact of large-scale IP address sharing for IPsec operation 876 should be evaluated and assessed. [RFC3947] proposes a solution to 877 solve issues documented in [RFC3715]. [RFC5996] specifies Internet 878 Key Exchange (IKE) Protocol Version 2 which includes NAT traversal 879 mechanisms that are now widely used to enable IPsec to work in the 880 presence of NATs in many cases. Nevertheless, service providers may 881 wish to ensure that CGN deployments do not inadvertently block NAT 882 traversal for security protocols such as IKE (refer to 883 [I-D.gont-behave-nat-security] for more information). 885 13.6. Policing Forwarding Behaviour 887 [RFC2827] motivates and discusses a simple, effective, and 888 straightforward method for using ingress traffic filtering to 889 prohibit Denial-of-Service (DoS) attacks which use forged IP 890 addresses. Following this recommendation, service providers 891 operating shared-addressing mechanisms should ensure that source 892 addresses, or source ports in the case of port-range schemes, are set 893 correctly in outgoing packets from their subscribers or they should 894 drop the packets. 896 If some form of IPv6 ingress filtering is deployed in the broadband 897 network and DS-Lite service is restricted to those subscribers, then 898 tunnels terminating at the CGN and coming from registered subscriber 899 IPv6 addresses cannot be spoofed. Thus a simple access control list 900 on the tunnel transport source address is all that is required to 901 accept traffic on the internal interface of a CGN. 903 14. Transport Issues 905 14.1. Parallel connections 907 Systems that assume that multiple simultaneous connections to a 908 single IP address implies connectivity to a single host - such 909 systems may experience unexpected results. 911 14.2. Serial connections 913 Systems that assume that returning to a given IP address means 914 returning to the same physical host, as with stateful transactions. 915 This may also affect cookie-based systems. 917 14.3. TCP Control Block Sharing 919 [RFC2140] defines a performance optimization for TCP based on sharing 920 state between TCP control blocks that pertain to connections to the 921 same host, as opposed to maintaining state for each discrete 922 connection. This optimization assumes that an address says something 923 about the properties of the path between two hosts, which is clearly 924 not the case if the address in question is shared by multiple hosts 925 at different physical network locations. While CPE NAT today causes 926 problems for sharing TCP control block state across multiple 927 connections to a given IP address, large-scale address sharing will 928 make these issues more severe and more widespread. 930 15. Reverse DNS 932 Many service providers populate forward and reverse DNS zones for the 933 public IPv4 addresses that they allocate to their subscribers. In 934 the case where public addresses are shared across multiple 935 subscribers, such strings are, by definition, no longer sufficient to 936 identify an individual subscriber without additional information. 938 16. Load Balancing 940 Algorithms used to balance traffic load for popular destinations may 941 be affected by the introduction of address sharing. Where balancing 942 is achieved by deterministically routing traffic from specific source 943 IP addresses to specific servers, imbalances in load may be 944 experienced as address sharing is enabled for some of those source IP 945 addresses. This will require re-evaluation of the algorithms used in 946 the load-balancing design. In general, as the scale of address 947 sharing grows, load-balancing designs will need to be re-evaluated 948 and any assumptions about average load per source IP address 949 revisited. 951 17. IPv6 Transition Issues 953 IPv4 address sharing solutions may interfere with existing IPv4 to 954 IPv6 transition mechanisms, which were not designed with IPv4 955 shortage considerations in mind. With port-range solutions for 956 instance, incoming 6to4 packets should be able to find their way from 957 a 6to4 relay to the appropriate 6to4 CPE router, despite the lack of 958 direct port range information (UDP/TCP initial source port did not 959 pass through the CPE port range translation process). One solution 960 would be for a 6to4 IPv6 address to embed not only an IPv4 address 961 but also a port range value. 963 Subscribers allocated with private addresses will not be able to 964 utilize 6to4 [RFC3056] to access IPv6, but may be able to utilize 965 Teredo [RFC4380]. 967 Some routers enable 6to4 on their WAN link. 6to4 requires a publicly- 968 routable IPv4 address. Enabling 6to4 when the apparently public IPv4 969 WAN address is in fact behind a NAT creates a disconnected IPv6 970 island. 972 18. Introduction of Single Points of Failure 974 In common with all deployments of new network functionality, the 975 introduction of new nodes or functions to handle the multiplexing of 976 multiple subscribers across shared IPv4 addresses could create single 977 points of failure in the network. Any IP address sharing solution 978 should consider the opportunity to add redundancy features in order 979 to alleviate the impact on the robustness of the offered IP 980 connectivity service. The ability of the solution to allow hot 981 swapping from one machine to another should be considered. This is 982 especially important where the address sharing solution in question 983 requires the creation of per-flow state in the network. 985 19. State Maintenance Reduces Battery Life 987 In order for hosts to maintain network state in the presence of NAT, 988 keep-alive messages have to be sent at frequent intervals. For 989 battery-powered devices, sending these keep-alive messages can result 990 in significantly reduced battery performance than would otherwise be 991 the case [Mobile_Energy_Consumption]. 993 20. Support of Multicast 995 [RFC5135] specifies requirements for a NAT that supports Any Source 996 IP Multicast or Source-Specific IP Multicast. Port-range routers 997 that form part of port-range solutions will need to support similar 998 requirements if multicast support is required. 1000 21. Support of Mobile-IP 1002 IP address sharing within the context of Mobile-IP deployments (in 1003 the home network and/or in the visited network), will require Home 1004 Agents and/or Foreign Agents to be updated so as to take into account 1005 the relevant port information. There may also be issues raised when 1006 an additional layer of encapsulation is required thereby causing, or 1007 increasing the need for, fragmentation and reassembly. 1009 Issues for Mobile-IP in the presence of NAT are discussed in 1010 [I-D.haddad-mext-nat64-mobility-harmful] 1012 22. IANA Considerations 1014 This memo includes no request to IANA. 1016 23. Security Considerations 1018 This memo does not define any protocol and therefore creates no new 1019 security issues. Section 13 discusses some of the security and 1020 identity-related implications of IP address sharing. 1022 24. Contributors 1024 This document is based on sources co-authored by J.L. Grimault and A. 1025 Villefranque of France Telecom. 1027 25. Acknowledgments 1029 This memo was partly inspired by conversations that took place as 1030 part of Internet Society (ISOC) hosted roundtable events for 1031 operators and content providers deploying IPv6. Participants in 1032 those discussions included John Brzozowski, Leslie Daigle, Tom 1033 Klieber, Yiu Lee, Kurtis Lindqvist, Wes George, Lorenzo Colliti, Erik 1034 Kline, Igor Gashinsky, Jason Fesler, Rick Reed, Adam Bechtel, Larry 1035 Campbell, Tom Coffeen, David Temkin, Pete Gelbman, Mark Winter, Will 1036 Charnock, Martin Levy, Greg Wood and Christian Jacquenet. 1038 The authors are also grateful to Christian Jacquenet, Iain Calder, 1039 Joel Halpern, Brian Carpenter, Gregory Lebovitz, Bob Briscoe, Marcelo 1040 Bagnulo, Dan Wing and Wes George for their helpful comments and 1041 suggestions for improving the document. 1043 This memo was created using the xml2rfc tool. 1045 26. Annex 1047 26.1. Classes of Address Sharing Solution 1049 IP address sharing solutions fall into two classes. Either a 1050 service-provider operated NAT function is introduced and subscribers 1051 are allocated addresses from [RFC1918] space, or public IPv4 1052 addresses are shared across multiple subscribers by restricting the 1053 range of ports available to each subscriber. These classes of 1054 solution are described in a bit more detail below. 1056 o CGN-based solutions: These solutions propose the introduction of a 1057 NAPT function in the service provider's network, denoted also as 1058 Carrier Grade NAT (CGN), or Large Scale NAT (LSN) 1059 [I-D.ietf-behave-lsn-requirements], or Provider NAT. The CGN is 1060 responsible for translating private addresses to publicly routable 1061 addresses. Private addresses are assigned to subscribers, a pool 1062 of public addresses is assigned to the CGN, and the number of 1063 public addresses is smaller than the number of subscribers. A 1064 public IPv4 address in the CGN pool is shared by several 1065 subscribers at the same time. Solutions making use of a service 1066 provider-based NAT include [I-D.shirasaki-nat444] (two layers of 1067 NAT) and [I-D.ietf-softwire-dual-stack-lite] (a single layer of 1068 NAT). 1070 o Port-range solutions: These solutions avoid the presence of a CGN 1071 function. A single public IPv4 address is assigned to several 1072 subscribers at the same time. A restricted port range is also 1073 assigned to each subscriber so that two subscribers with the same 1074 IPv4 address have two different port ranges that do not overlap. 1075 These solutions are called A+P (Address+Port) [I-D.ymbk-aplusp], 1076 or Port Range [I-D.boucadair-port-range], or SAM (Stateless 1077 Address Mapping) [I-D.despres-sam]. 1079 26.2. Address Space Multiplicative Factor 1081 The purpose of sharing public IPv4 addresses is to increase the 1082 addressing space. A key parameter is the factor by which service 1083 providers want or need to multiply their IPv4 public address space; 1084 and the consequence is the number of subscribers sharing the same 1085 public IPv4 address. We refer to this parameter as the address space 1086 multiplicative factor, the inverse is called the compression ratio. 1088 The multiplicative factor can only be applied to the subset of 1089 subscribers that are eligible for a shared address. The reasons a 1090 subscriber cannot have a shared address can be: 1092 o It would not be compatible with the service they are currently 1093 subscribed to (for example: business subscriber). 1095 o Subscriber CPE is not compatible with the address sharing solution 1096 selected by the service provider (for example it does not handle 1097 port restriction for port-range solutions or it does not allow 1098 IPv4 in IPv6 encapsulation for the DS-Lite solution), and its 1099 replacement is not easy. 1101 Different service providers may have very different needs. A long- 1102 lived service provider, whose number of subscribers is rather stable, 1103 may have an existing address pool that will only need a small 1104 extension to cope with the next few years, assuming that this address 1105 pool can be re-purposed for an address sharing solution (small 1106 multiplicative factor, less than 10). A new entrant or a new line of 1107 business will need a much bigger multiplicative factor (e.g., 1000). 1108 A mobile operator may see its addressing needs grow dramatically as 1109 the IP-enabled mobile handset market grows. 1111 When the multiplicative factor is large, the average number of ports 1112 per subscriber is small. Given the large measured disparity between 1113 average and peak port consumption [CGN_Viability], this will create 1114 service problems in the event that ports are allocated statically. 1115 In this case, it is essential for port allocation to map to need as 1116 closely as possible, and to avoid allocating ports for longer than 1117 necessary. Therefore, the larger the multiplicative factor, the more 1118 dynamic the port assignment has to be. 1120 27. Informative References 1122 [CGN_Viability] 1123 Alcock, S., "Research into the Viability of Service- 1124 Provider NAT", 2008, . 1127 [I-D.boucadair-port-range] 1128 Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, 1129 "IPv4 Connectivity Access in the Context of IPv4 Address 1130 Exhaustion: Port Range based IP Architecture", 1131 draft-boucadair-port-range-02 (work in progress), 1132 July 2009. 1134 [I-D.cheshire-nat-pmp] 1135 Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 1136 draft-cheshire-nat-pmp-03 (work in progress), April 2008. 1138 [I-D.despres-sam] 1139 Despres, R., "Scalable Multihoming across IPv6 Local- 1140 Address Routing Zones Global-Prefix/Local-Address 1141 Stateless Address Mapping (SAM)", draft-despres-sam-03 1142 (work in progress), July 2009. 1144 [I-D.gont-behave-nat-security] 1145 Gont, F. and P. Srisuresh, "Security implications of 1146 Network Address Translators (NATs)", 1147 draft-gont-behave-nat-security-03 (work in progress), 1148 October 2009. 1150 [I-D.haddad-mext-nat64-mobility-harmful] 1151 Haddad, W. and C. Perkins, "A Note on NAT64 Interaction 1152 with Mobile IPv6", 1153 draft-haddad-mext-nat64-mobility-harmful-01 (work in 1154 progress), April 2010. 1156 [I-D.ietf-behave-lsn-requirements] 1157 Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, 1158 "Common requirements for IP address sharing schemes", 1159 draft-ietf-behave-lsn-requirements-00 (work in progress), 1160 October 2010. 1162 [I-D.ietf-behave-v6v4-xlate] 1163 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1164 Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in 1165 progress), September 2010. 1167 [I-D.ietf-behave-v6v4-xlate-stateful] 1168 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 1169 NAT64: Network Address and Protocol Translation from IPv6 1170 Clients to IPv4 Servers", 1171 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 1172 progress), July 2010. 1174 [I-D.ietf-pcp-base] 1175 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and F. 1176 Dupont, "Port Control Protocol (PCP)", 1177 draft-ietf-pcp-base-06 (work in progress), February 2011. 1179 [I-D.ietf-softwire-dual-stack-lite] 1180 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1181 Stack Lite Broadband Deployments Following IPv4 1182 Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work 1183 in progress), August 2010. 1185 [I-D.shirasaki-nat444] 1186 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 1187 and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work 1188 in progress), January 2011. 1190 [I-D.ymbk-aplusp] 1191 Bush, R., "The A+P Approach to the IPv4 Address Shortage", 1192 draft-ymbk-aplusp-09 (work in progress), February 2011. 1194 [IANA_Ports] 1195 Geoff Huston, "IANA Port Number Assignments", 1196 February 2011, 1197 . 1199 [IPv4_Pool] 1200 Geoff Huston, "Available Pool of Unallocated IPv4 Internet 1201 Addresses Now Completely Emptied", 2011, 1202 . 1205 [Mobile_Energy_Consumption] 1206 Haverinen, H., Siren, J., and P. Eronen, "Energy 1207 Consumption of Always-On Applications in WCDMA Networks", 1208 2007, . 1210 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1211 November 1990. 1213 [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", 1214 RFC 1337, May 1992. 1216 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 1217 October 1994. 1219 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1220 E. Lear, "Address Allocation for Private Internets", 1221 BCP 5, RFC 1918, February 1996. 1223 [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, 1224 April 1997. 1226 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1227 Translator (NAT) Terminology and Considerations", 1228 RFC 2663, August 1999. 1230 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1231 specifying the location of services (DNS SRV)", RFC 2782, 1232 February 2000. 1234 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1236 Defeating Denial of Service Attacks which employ IP Source 1237 Address Spoofing", BCP 38, RFC 2827, May 2000. 1239 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 1240 November 2000. 1242 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1243 via IPv4 Clouds", RFC 3056, February 2001. 1245 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 1246 (NAT) Compatibility Requirements", RFC 3715, March 2004. 1248 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1249 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1250 January 2005. 1252 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1253 Network Address Translations (NATs)", RFC 4380, 1254 February 2006. 1256 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1257 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1258 RFC 4787, January 2007. 1260 [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a 1261 Network Address Translator (NAT) and a Network Address 1262 Port Translator (NAPT)", BCP 135, RFC 5135, February 2008. 1264 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 1265 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 1266 April 2009. 1268 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 1269 Robustness to Blind In-Window Attacks", RFC 5961, 1270 August 2010. 1272 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1273 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1274 RFC 5996, September 2010. 1276 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 1277 Protocol Port Randomization", BCP 156, RFC 6056, 1278 January 2011. 1280 [UPnP-IGD] 1281 UPnP Forum, "Universal Plug and Play (UPnP) Internet 1282 Gateway Device (IGD) V 2.0", December 2010, 1283 . 1285 [Windows-Logo] 1286 Microsoft, "Windows Logo Program Device Requirements", 1287 2006, . 1290 Authors' Addresses 1292 Mat Ford (editor) 1293 Internet Society 1294 Geneva 1295 Switzerland 1297 Email: ford@isoc.org 1299 Mohamed Boucadair 1300 France Telecom 1301 Rennes 35000 1302 France 1304 Email: mohamed.boucadair@orange-ftgroup.com 1306 Alain Durand 1307 Juniper Networks 1309 Email: adurand@juniper.net 1311 Pierre Levis 1312 France Telecom 1313 42 rue des Coutures 1314 BP 6243 1315 Caen Cedex 4 14066 1316 France 1318 Email: pierre.levis@orange-ftgroup.com 1320 Phil Roberts 1321 Internet Society 1322 Reston, VA 1323 USA 1325 Email: roberts@isoc.org