idnits 2.17.1 draft-ford-shared-addressing-issues-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2010) is 5163 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-haddad-mext-nat64-mobility-harmful-00 == Outdated reference: A later version (-23) exists of draft-ietf-behave-v6v4-xlate-10 == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-09 == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-03 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-port-randomization-06 == Outdated reference: A later version (-05) exists of draft-nishitani-cgn-03 == Outdated reference: A later version (-06) exists of draft-shirasaki-nat444-00 == Outdated reference: A later version (-10) exists of draft-ymbk-aplusp-05 -- Obsolete informational reference (is this intentional?): RFC 2140 (Obsoleted by RFC 9040) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 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 9, 2010 France Telecom 6 A. Durand 7 Comcast 8 P. Levis 9 France Telecom 10 P. Roberts 11 Internet Society 12 March 8, 2010 14 Issues with IP Address Sharing 15 draft-ford-shared-addressing-issues-02 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. Solution- 27 specific discussions are out of scope. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on September 9, 2010. 52 Copyright Notice 54 Copyright (c) 2010 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Shared Addressing Solutions . . . . . . . . . . . . . . . . . 4 71 3. Analysis of Issues as they Relate to First and Third 72 parties . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4. Port Allocation . . . . . . . . . . . . . . . . . . . . . . . 7 74 4.1. Outgoing Ports . . . . . . . . . . . . . . . . . . . . . . 8 75 4.2. Incoming Ports . . . . . . . . . . . . . . . . . . . . . . 9 76 4.2.1. Port Negotiation . . . . . . . . . . . . . . . . . . . 10 77 4.2.2. Connection to a Well-Known Port Number . . . . . . . . 10 78 5. Impact on Applications . . . . . . . . . . . . . . . . . . . . 11 79 6. Geo-location and Geo-proximity . . . . . . . . . . . . . . . . 12 80 7. Tracking Service Usage . . . . . . . . . . . . . . . . . . . . 12 81 8. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 9. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 13 83 10. Traceability . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 11. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 11.1. Abuse Logging and Penalty Boxes . . . . . . . . . . . . . 14 86 11.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 15 87 11.3. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 11.4. Port Randomisation . . . . . . . . . . . . . . . . . . . . 15 89 11.5. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 11.6. Policing Forwarding Behaviour . . . . . . . . . . . . . . 16 91 12. TCP Control Block Sharing . . . . . . . . . . . . . . . . . . 16 92 13. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 14. Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . 17 94 15. IPv6 Transition Issues . . . . . . . . . . . . . . . . . . . . 17 95 16. Introduction of Single Points of Failure . . . . . . . . . . . 18 96 17. State maintenance reduces battery life . . . . . . . . . . . . 18 97 18. Support of Multicast . . . . . . . . . . . . . . . . . . . . . 18 98 19. Support of Mobile-IP . . . . . . . . . . . . . . . . . . . . . 18 99 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 100 21. Security Considerations . . . . . . . . . . . . . . . . . . . 19 101 22. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 102 23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 103 24. Annex . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 104 24.1. Classes of Address Sharing Solution . . . . . . . . . . . 19 105 24.2. Address Space Multiplicative Factor . . . . . . . . . . . 20 106 25. Informative References . . . . . . . . . . . . . . . . . . . . 21 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 109 1. Introduction 111 Allocations of IPv4 addresses from the Internet Assigned Numbers 112 Authority (IANA) are currently forecast to be complete during 2011 113 [IPv4_Report]. Allocations from some Regional Internet Registries 114 (RIRs) are anticipated to be complete around a year later, although 115 the exact date will vary from registry to registry. This is causing 116 service providers around the world to start to question how they will 117 continue providing IPv4 connectivity service to their subscribers 118 when there are no longer sufficient IPv4 addresses to allocate them 119 one per subscriber. Several possible solutions to this problem are 120 now emerging based around the idea of shared IPv4 addressing. These 121 solutions give rise to a number of issues and this memo identifies 122 those common to all such address sharing approaches and collects them 123 in a single document. 125 Over the long term, deploying IPv6 is the only way to ease pressure 126 on the public IPv4 address pool and thereby mitigate the need for 127 address sharing mechanisms that give rise to the issues identified 128 herein. In the short term, maintaining growth of IPv4 services in 129 the presence of IPv4 address depletion will require address sharing. 130 Address sharing will cause issues for end-users, service providers 131 and third parties such as law enforcement agencies and content 132 providers. This memo is intended to highlight and briefly discuss 133 these issues. 135 Increased IPv6 deployment should reduce the burden being placed on an 136 address sharing solution, and should reduce the costs of operating 137 that solution. Increasing IPv6 deployment should cause a reduction 138 in the number of concurrent IPv4 sessions per subscriber. If the 139 percentage of end-to-end IPv6 traffic significantly increases, so 140 that the volume of IPv4 traffic begins decreasing, then the number of 141 IPv4 sessions will decrease. The smaller the number of concurrent 142 IPv4 sessions per subscriber, the higher the number of subscribers 143 able to share the same IPv4 public address, and consequently, the 144 lower the number of IPv4 public addresses required. However, this 145 effect will only occur for subscribers who have both an IPv6 access 146 and a shared IPv4 access. This motivates a strategy to 147 systematically bind a shared IPv4 access to an IPv6 access. It is 148 difficult to foresee to what extent growing IPv6 traffic will reduce 149 the number of concurrent IPv4 sessions, but in any event, IPv6 150 deployment and use should reduce the pressure on the available public 151 IPv4 address pool. 153 2. Shared Addressing Solutions 155 In many networks today a subscriber is provided with a single public 156 IPv4 address at their home or small business. For instance, in fixed 157 broadband access, an IPv4 public address is assigned to each CPE 158 (Customer Premises Equipment). CPEs embed a NAT function which is 159 responsible for translating private IPv4 addresses ([RFC1918] 160 addresses) assigned to hosts within the local network, to the public 161 IPv4 address assigned by the service provider (and vice versa). 162 Therefore, devices located with the LAN share the single public IPv4 163 address and they are all associated with a single subscriber account 164 and a single network operator. 166 A number of proposals currently under consideration in the IETF rely 167 upon the mechanism of multiplexing multiple subscribers' connections 168 over a smaller number of shared IPv4 addresses. This is a 169 significant change. These proposals include Carrier Grade NAT (CGN) 170 [I-D.nishitani-cgn] , Dual-Stack-Lite 171 [I-D.ietf-softwire-dual-stack-lite] , NAT64 172 [I-D.ietf-behave-v6v4-xlate-stateful] , IVI 173 [I-D.ietf-behave-v6v4-xlate] , Address+Port (A+P) proposals 174 [I-D.ymbk-aplusp] , [I-D.boucadair-port-range] and SAM 175 [I-D.despres-sam]. Section 24 provides a classification of these 176 different types of solution and discusses some of the design 177 considerations to be borne in mind when deploying large-scale address 178 sharing. 180 In these new proposals, a single public IPv4 address would be shared 181 by multiple homes or small businesses (i.e. multiple subscribers) so 182 the operational paradigm described above would no longer apply. In 183 this document we refer to this new paradigm as large-scale address 184 sharing. All these proposals extend the address space by adding port 185 information, they differ in the way they manage the port value. 187 Security issues associated with NAT have long been documented (see 188 [RFC2663] and [RFC2993] ). However, sharing IPv4 addresses across 189 multiple subscribers by any means, either moving the NAT 190 functionality from the home gateway to the core of the service 191 provider network, or restricting the port choice in the subscriber's 192 NAT, creates additional issues for subscribers, content providers and 193 network operators. Many of these issues are created today by public 194 wi-fi hotspot deployments. As such large-scale address sharing 195 solutions become more widespread in the face of IPv4 address 196 depletion, these issues will become both more severe and more 197 commonly felt. NAT issues in the past typically only applied to a 198 single legal entity; as large-scale address sharing becomes more 199 prevalent these issues will increasingly span across multiple legal 200 entities simultaneously. 202 All large-scale address sharing proposals share technical and 203 operational issues and these are addressed in the sections that 204 follow. These issues are common to any service-provider NAT, 205 enterprise NAT, and also non-NAT solutions that share individual IPv4 206 addresses across multiple subscribers. This document is intended to 207 bring all of these issues together in one place. 209 3. Analysis of Issues as they Relate to First and Third parties 211 In this section we present an analysis of whether the issues 212 identified in the remainder of this document are applicable to the 213 organisation deploying the shared addressing mechanism (and by 214 extension their subscribers) and/or whether these issues impact third 215 parties (e.g. content providers, law enforcement agencies, etc.). In 216 this analysis, issues that affect end-users are deemed to affect 1st 217 parties, as end-users can be expected to complain to their service 218 provider when problems arise. Where issues can expect to be foreseen 219 and addressed by the party deploying the shared addressing solution, 220 they are not attributed. 222 +------------------------------------------------+--------+---------+ 223 | Issue | 1st | 3rd | 224 | | party | parties | 225 +------------------------------------------------+--------+---------+ 226 | Overly restrictive allocations of outgoing | x | | 227 | ports will impact performance for end users | | | 228 | | | | 229 | Incoming port negotiation mechanisms may fail | x | | 230 | | | | 231 | Incoming connections to Well-Known Ports will | x | | 232 | not work | | | 233 | | | | 234 | Some applications will fail to operate | x | x | 235 | | | | 236 | TCP control block sharing will be affected | x | x | 237 | | | | 238 | Reverse DNS will be affected | x | x | 239 | | | | 240 | Inbound ICMP will fail in many cases | x | x | 241 | | | | 242 | Amplification of security issues | x | x | 243 | | | | 244 | Fragmentation will require special handling | x | | 245 | | | | 246 | Single points of failure and increased | x | | 247 | network instability | | | 248 | | | | 249 | Port randomisation will be affected | x | | 250 | | | | 251 +------------------------------------------------+--------+---------+ 252 | Issue | 1st | 3rd | 253 | | party | parties | 254 +------------------------------------------------+--------+---------+ 255 | Service usage monitoring and abuse logging | x | x | 256 | will be impacted for all elements in the chain | | | 257 | between service provider and content provider | | | 258 | | | | 259 | Penalty boxes will no longer work | x | x | 260 | | | | 261 | Spam blacklisting will be affected | x | x | 262 | | | | 263 | Geo-location services will be impacted | x | x | 264 | | | | 265 | Geo-proximity mechanisms will be impacted | x | x | 266 | | | | 267 | Load balancing algorithms may be impacted | | x | 268 | | | | 269 | Authentication mechanisms may be impacted | | x | 270 | | | | 271 | Traceability of network usage and abusage will | | x | 272 | be affected | | | 273 | | | | 274 | IPv6 transition mechanisms will be affected | x | | 275 | | | | 276 | Frequent keep-alives reduce battery life | x | | 277 | | | | 278 +------------------------------------------------+--------+---------+ 280 Figure 1: Shared addressing issues for first and third parties 282 As can be seen from Figure 1, deployment of large-scale address 283 sharing will create almost as many problems for third parties as it 284 does for the service provider deploying the address sharing 285 mechanism. All of these issues are discussed in further detail 286 below. 288 4. Port Allocation 290 When we talk about port numbers we need to make a distinction between 291 outgoing connections and incoming connections. For outgoing 292 connections, the actual source port number used is usually 293 irrelevant. (While this is true today, in a port-range solution it 294 is necessary for the source port to be within the allocated range). 295 But for incoming connections, the specific port numbers allocated to 296 subscribers matter because they are part of external referrals (used 297 by third parties to contact services run by the subscribers). 299 The total number of subscribers able to share a single IPv4 address 300 will depend upon assumptions about the average number of ports 301 required per active subscriber, and the average number of 302 simultaneously active subscribers. It is important to realise that 303 the TCP design makes it undesirable for clients to re-use ports while 304 they remain in the TIME-WAIT state (typically 4 minutes after the 305 connection has concluded). TIME-WAIT state removes the hazard of old 306 duplicates for "fast" or "long" connections, in which clock-driven 307 Initial Sequence Number selection is unable to prevent overlap of the 308 old and new sequence spaces. The TIME-WAIT delay allows all old 309 duplicate segments time enough to die in the Internet before the 310 connection is reopened [RFC1337]. Therefore ports in this state must 311 be included in calculations concerning port usage per subscriber. 313 Most of the time the source port selected by a client application 314 will be translated (unless there is direct knowledge of a port-range 315 restriction in the client's stack), either by a NAT in the 316 subscriber's device, or by a CPE NAT, or by a CPE NAT and a CGN. 318 IANA has classified the whole port space into three categories (as 319 defined in http://www.iana.org/assignments/port-numbers): 321 o The Well Known Ports are those from 0 through 1023. 323 o The Registered Ports are those from 1024 through 49151. 325 o The Dynamic and/or Private Ports are those from 49152 through 326 65535. 328 [RFC4787] notes that current NATs have different policies with regard 329 to this classification; some NATs restrict their translations to the 330 use of dynamic ports, some also include registered ports, some 331 preserve the port if it is in the well-known range. [RFC4787] makes 332 it clear that the use of port space (1024-65535) is safe: "mapping a 333 source port to a source port that is already registered is unlikely 334 to have any bad effects". Therefore, for all address sharing 335 solutions, there is no reason to only consider a subset of the port 336 space (1024-65535) for outgoing source ports. 338 4.1. Outgoing Ports 340 According to measurements the average number of outgoing ports 341 consumed per active subscriber is much, much smaller than the maximum 342 number of ports a subscriber can use at any given time. However, the 343 distribution is heavy-tailed, so there are typically a small number 344 of subscribers who use a very high number of ports [CGN_Viability]. 345 This means that an algorithm that dynamically allocates outgoing port 346 numbers from a central pool will typically allow more subscribers to 347 share a single IPv4 address than algorithms that statically divide 348 the resource by pre-allocating a fixed number of ports to each 349 subscriber. Similarly, such an algorithm should be more able to 350 accommodate subscribers wishing to use a relatively high number of 351 ports. 353 It is important to note here that the desire to dynamically allocate 354 outgoing port numbers will make a service provider's job of 355 maintaining records of subscriber port number allocations 356 considerably more onerous (see Section 10). The number of records 357 per subscriber will increase from 1 in a scheme where ports are 358 statically allocated, to a much larger number equivalent to the total 359 number of outgoing ports consumed by that subscriber during the time 360 period for which detailed logs must be kept. 362 A potential problem with dynamic allocation occurs when one of the 363 subscriber devices behind such a port-shared IPv4 address becomes 364 infected with a worm, which then quickly sets about opening many 365 outbound connections in order to propagate itself. Such an infection 366 could rapidly exhaust the shared resource of the single IPv4 address 367 for all connected subscribers. It is therefore necessary to impose 368 limits on the total number of ports available to an individual 369 subscriber to ensure that the shared resource (the IPv4 address) 370 remains available in some capacity to all the subscribers using it. 372 4.2. Incoming Ports 374 It is desirable to ensure that incoming ports remain stable over 375 time. This is challenging as the network doesn't know anything in 376 particular about the applications that it is supporting and therefore 377 has no real notion of how long an application/service session is 378 still ongoing and therefore requiring port stability. 380 Early measurements [CGN_Viability] also seem to indicate that, on 381 average, only very few ports are used by subscribers for incoming 382 connections. However, a majority of subscribers accept at least one 383 inbound connection. 385 This means that it is not necessary to pre-allocate a large number of 386 incoming ports to each subscriber. It is possible to either pre- 387 allocate a small number of ports for incoming connections or do port 388 allocation on demand when the application wishing to receive a 389 connection is initiated. The bulk of incoming ports can be reserved 390 as a centralized resource shared by all subscribers using a given 391 public IPv4 address. 393 4.2.1. Port Negotiation 395 In current deployments, one important and widely used feature of many 396 CPE devices is the ability to open incoming ports (port forwarding) 397 either manually, or with a protocol such as UPnP IGD. If a CGN is 398 present, the port must also be open in the CGN. The situation may be 399 alleviated somewhat if the CGN architecture is composed of only one 400 NAT level (no NAT in the CPE) as for DS-Lite, although a service 401 provider operating this solution will still be required to offer some 402 means for configuring incoming ports by their subscribers. This may 403 be either via a UPnP or NAT-PMP relay over a tunnelled direct 404 connection between the CPE and CGN, or a web interface to configure 405 the incoming port mapping on the CGN. Note, that such an interface 406 effectively makes public what was previously a private management 407 interface and this raises security concerns that must be addressed. 409 For port-range solutions, port forwarding capabilities may still be 410 present at the CPE, with the limitation that the open incoming port 411 must be within the allocated port-range (for instance it is not 412 possible to open port 5002 for incoming connections if port 5002 is 413 not within the allocated port-range). 415 4.2.1.1. Universal Plug and Play (UPnP) 417 Using the UPnP semantic, an application asks "I want to use port 418 number X, is that ok?" and the answer is yes or no. If the answer is 419 no, the application will typically try the next port in sequence, 420 until it either finds one that works or gives up after a limited 421 number of attempts. UPnP has, currently, no way to redirect the 422 application to use another port number. UPnP IGD 2.0, currently 423 being defined, should improve this and allow for allocation of any 424 available port. 426 4.2.1.2. NAT Port Mapping Protocol (NAT-PMP) 428 NAT-PMP already has a better semantic here, enabling the NAT to 429 redirect the application to an available port number. 431 4.2.2. Connection to a Well-Known Port Number 433 Once an IPv4 address sharing mechanism is in place, connections to 434 well-known port numbers will not work in the general case. Any 435 application that is not port-agile cannot be expected to work. Some 436 workaround (e.g. redirects to a port-specific URI) could be deployed 437 given sufficient incentives. There exist several proposals for 438 'application service location' protocols which would provide a means 439 of addressing this problem, but historically these proposals have not 440 gained much deployment traction. 442 For example, the use of DNS SRV records [RFC2782] provides a 443 potential solution for subscribers wishing to host services in the 444 presence of a shared-addressing scheme. SRV records make it possible 445 to specify a port value related to a service, thereby making services 446 accessible on ports other than the Well-Known ports. It is worth 447 noting that this mechanism is not applicable to HTTP. 449 5. Impact on Applications 451 Address sharing solutions will have an impact on the following types 452 of applications: 454 o Applications that establish inbound communications - these 455 applications will have to ensure that ports selected for inbound 456 communications are either within the allocated range (for port- 457 range solutions) or are forwarded appropriately by the CGN (for 458 CGN-based solutions). See Section 4.2 for more discussion of 459 this; 461 o Applications that carry address and/or port information in their 462 payload - where translation of port and/or address information is 463 performed at the IP and transport layers by the address sharing 464 solution, an ALG will also be required to ensure application layer 465 data is appropriately modified; 467 o Applications that use fixed ports (e.g. well-known ports) - see 468 Section 4.2.2 for more discussion of this; 470 o Applications that do not use any port (e.g. ICMP) - where address 471 sharing solutions map subscribers to (private) IP addresses on a 472 one-to-one basis this will not be an issue, otherwise such 473 applications will require special handling - see Section 8 for 474 more discussion of this; 476 o Applications that assume the uniqueness of source addresses (e.g. 477 IP address as identifier) - such applications will fail to operate 478 correctly in the presence of multiple, discrete, simultaneous 479 connections from the same source IP address; 481 o Applications that explicitly prohibit concurrent connections from 482 the same address - such applications will fail when multiple 483 subscribers sharing an IP address attempt to use them 484 simultaneously. 486 Applications already frequently implement mechanisms in order to 487 circumvent the presence of NATs (typically CPE NATs): 489 o Application Layer Gateways (ALGs): Many CPE devices today embed 490 ALGs that allow applications to behave correctly despite the 491 presence of NAT on the CPE. When the NAT belongs to the 492 subscriber, the subscriber has flexibility to tailor the device to 493 his or her needs. For CGNs, subscribers will be dependent on the 494 set of ALGs that their service provider makes available. A 495 service provider-based NAT may, or may not, support NAT-traversal 496 for IKE [RFC3947] for example. For port-range solutions, ALGs 497 will require modification to deal with the port-range restriction, 498 but will otherwise have the same capabilities as today. 500 o NAT Traversal Techniques: ICE, STUN, TURN, etc. See 501 Section 4.2.1. 503 6. Geo-location and Geo-proximity 505 IP addresses are frequently used to indicate, with some level of 506 granularity and some level of confidence, where a host is physically 507 located. Geo-location services are used by content providers to 508 allow them to conform with regional content licensing restrictions, 509 to target advertising at specific geographic areas, or to provide 510 customised content. Geo-location services are also necessary for 511 emergency services provision. In some deployment contexts (e.g. 512 centralised CGN), shared addressing will reduce the level of 513 confidence and level of location granularity that IP-based geo- 514 location services can provide. Other forms of geo-location will 515 still work as usual. 517 A slightly different use of an IP address is to calculate the 518 proximity of a connecting host to a particular service delivery 519 point. This use of IP address information impacts the efficient 520 delivery of content to an end-user. If a CGN is introduced in 521 communications and it is far from an end-user connected to it, 522 application performance may be degraded insofar as IP-based geo- 523 proximity is a factor. 525 7. Tracking Service Usage 527 As large-scale address sharing becomes more commonplace, monitoring 528 the number of unique users of a service will become more complex than 529 simply counting the number of connections from unique IP addresses. 530 While this is a somewhat inexact methodology today due to the 531 widespread use of CPE NAT, it will become a much less useful approach 532 in the presence of widespread large-scale address sharing solutions. 533 In general, all elements that monitor usage or abusage in the chain 534 between a service provider that has deployed address sharing and a 535 content provider will need to be upgraded to take account of the port 536 value in addition to IP addresses. 538 8. ICMP 540 ICMP does not carry any port information and is consequently 541 problematic for address sharing mechanisms. Sourcing ICMP from hosts 542 behind an address sharing solution does not pose problems, although 543 responses to outgoing ICMP will require special handling, such as 544 making use of the ICMP identifier value to route the response 545 appropriately. 547 For inbound ICMP there are two cases. The first case is that of ICMP 548 sourced from outside the network of the address sharing solution 549 provider. Several applications make use of this (e.g. P2P 550 applications) and measurements derived by such applications in the 551 presence of an address sharing solution will be erroneous. The 552 second case is that of ICMP sourced from within the network of the 553 address sharing solution provider (e.g. for network management and 554 diagnostic purposes). In this case ICMP can be routed normally for 555 CGN-based solutions owing to the presence of locally unique private 556 IP addresses for each CPE device. For port-range solutions, ICMP 557 will not be routable without special handling, e.g. placing a port 558 number in the ICMP identifier field, and having port-range routers 559 make routing decisions based upon that field. 561 Another concern relating to ICMP in the presence of large-scale 562 address sharing is that a malevolent user could send an ICMP "Packet 563 Too Big" (Type 3, Code 4) message indicating a Next-Hop MTU of 564 anything down to 68 octets. This value will be cached by the off-net 565 server for all subscribers sharing the address of the malevolent 566 user. This could lead to a DoS against both the remote server and 567 the large-scale NAT device itself (as they will both have to handle 568 many more packets per second). 570 9. Fragmentation 572 When a packet is fragmented, transport-layer port information (either 573 UDP or TCP) is only present in the first fragment. Subsequent 574 fragments will not carry the port information and so will require 575 special handling. 577 10. Traceability 579 Legal obligations require a service provider to provide the identity 580 of a subscriber upon request to the authorities. Where one public 581 IPv4 address is shared between several subscribers, the knowledge of 582 the IP address alone is not enough to identify the appropriate 583 subscriber. The legal request should include the information: [IP 584 address - Port - Protocol- Begin_Timestamp - End_Timestamp]. 585 Accurate time-keeping is clearly important. A densely populated CGN 586 could mean even very small amounts of clock skew between a content 587 provider and the CGN operator will result in ambiguity about which 588 customer was using a specific port at a given time. 590 Considering that it is unrealistic to expect all servers to start 591 logging port information of connection attempts, address sharing 592 service providers may need to start logging destinations as well, 593 giving rise to privacy concerns. 595 Address sharing solutions must record and store all mappings 596 (typically during 6 months to one year, depending on the 597 jurisdiction) that they create. If we consider one mapping per 598 session, a service provider should record and retain traces of all 599 sessions created by all subscribers during one year (if the legal 600 storage duration is one year). This may be challenging due to the 601 volume of data requiring storage, the volume of data to repeatedly 602 transfer to the storage location, and the volume of data to search in 603 response to a query. 605 Address sharing solutions may mitigate these issues to some extent by 606 pre-allocating groups of ports. Then only the allocation of the 607 group needs to be recorded, and not the creation of every session 608 binding within that group. There are trade-offs to be made between 609 the sizes of these groups, the ratio of public addresses to 610 subscribers, whether or not these groups timeout, the impact on 611 logging requirements and port randomisation security. 613 11. Security 615 Before noting some specific security-related issues caused by large- 616 scale address sharing, it is perhaps worth noting that, in general, 617 address sharing creates a vector for attack amplification in numerous 618 ways. See Section 8 for one example. 620 11.1. Abuse Logging and Penalty Boxes 622 When an abuse is reported today, it is usually done in the form: IPv4 623 address X has done something bad at time T0. This is not enough 624 information to uniquely identify the subscriber responsible for the 625 abuse when that IPv4 address is shared by more than one subscriber. 626 Law enforcement authorities may be particularly impacted because of 627 this. This particular issue can be fixed by logging port numbers, 628 although this will increase logging data storage requirements. 630 A number of application servers on the network today log IPv4 631 addresses in connection attempts to protect themselves from certain 632 attacks. For example, if a server sees too many login attempts from 633 the same IPv4 address, it may decide to put that address in a penalty 634 box for a certain time. If an IPv4 address is shared by multiple 635 subscribers, this would have unintended consequences in a couple of 636 ways. First it may become the natural behavior to see many login 637 attempts from the same address because it is now shared across a 638 potentially large number of subscribers. Second and more likely is 639 that one user who fails a number of login attempts may block out 640 other users who have not made any previous attempts but who will now 641 fail on their first attempt. In the presence of widespread large- 642 scale address sharing, penalty box solutions to service abuse simply 643 will not work. 645 11.2. Authentication 647 Simple address-based identification mechanisms that are used to 648 populate access control lists will fail when an IP address is no 649 longer sufficient to identify a particular subscriber. Including 650 port numbers in access control list definitions may be possible at 651 the cost of extra complexity, and may also require the service 652 provider to make static port assignments, which conflicts with the 653 requirement for dynamic assignments discussed in Section 4.1 . 655 11.3. Spam 657 Another case of identifying abusers has to do with spam blacklisting. 658 When a spammer is behind a CGN or using a port-shared address, 659 blacklisting of their IP address will result in all other subscribers 660 sharing that address having their ability to source SMTP packets 661 restricted to some extent. 663 11.4. Port Randomisation 665 A blind attack that can be performed against TCP relies on the 666 attacker's ability to guess the 5-tuple (Protocol, Source Address, 667 Destination Address, Source Port, Destination Port) that identifies 668 the transport protocol instance to be attacked. 669 [I-D.ietf-tsvwg-port-randomization] describes a number of methods for 670 the random selection of the source port number, such that the ability 671 of an attacker to correctly guess the 5-tuple is reduced. With 672 shared IPv4 addresses, the port selection space is reduced. 673 Preserving port randomisation is important and may be more or less 674 difficult depending on the address sharing solution and the size of 675 the port space that is being manipulated. Allocation of non- 676 contiguous port ranges could help to mitigate this issue. 678 It should be noted that guessing the port information may not be 679 sufficient to carry out a successful blind attack. The exact TCP 680 Sequence Number (SN) should also be known. A TCP segment is 681 processed only if all previous segments have been received, except 682 for some Reset Segment implementations which immediately process the 683 Reset as long as it is within the Window. If SN is randomly chosen 684 it will be difficult to guess it (SN is 32 bits long); port 685 randomisation is one protection among others against blind attacks. 687 11.5. IPsec 689 The impact of large-scale IP address sharing for IPsec operation 690 should be evaluated and assessed. [RFC3947] proposes a solution to 691 solve issues documented in [RFC3715] . The applicability of 692 [RFC3947] in the context of shared IP address solutions should be 693 evaluated. In particular, service providers may wish to ensure that 694 CGN deployments do not inadvertently block NAT traversal for security 695 protocols such as IKE (refer to [I-D.gont-behave-nat-security] for 696 more information). 698 11.6. Policing Forwarding Behaviour 700 [RFC2827] motivates and discusses a simple, effective, and 701 straightforward method for using ingress traffic filtering to 702 prohibit Denial-of-Service (DoS) attacks which use forged IP 703 addresses. Following this recommendation, service providers 704 operating shared-addressing mechanisms should ensure that source 705 addresses, or source ports in the case of port-range schemes, are set 706 correctly in outgoing packets from their subscribers or they should 707 drop the packets. 709 If some form of IPv6 ingress filtering is deployed in the broadband 710 network and DS-Lite service is restricted to those subscribers, then 711 tunnels terminating at the CGN and coming from registered subscriber 712 IPv6 addresses cannot be spoofed. Thus a simple access control list 713 on the tunnel transport source address is all that is required to 714 accept traffic on the southbound interface of a CGN. 716 12. TCP Control Block Sharing 718 [RFC2140] defines a performance optimisation for TCP based on sharing 719 state between TCP control blocks that pertain to connections to the 720 same host, as opposed to maintaining state for each discrete 721 connection. This optimisation assumes that an address says something 722 about the properties of the path between two hosts, which is clearly 723 not the case if the address in question is shared by multiple hosts 724 at different physical network locations. While CPE NAT today causes 725 problems for sharing TCP control block state across multiple 726 connections to a given IP address, large-scale address sharing will 727 make these issues more severe and more widespread. 729 13. Reverse DNS 731 Many service providers populate forward and reverse DNS zones for the 732 public IPv4 addresses that they allocate to their subscribers. In 733 the case where public addresses are shared across multiple 734 subscribers, such strings are, by definition, no longer sufficient to 735 identify an individual subscriber without additional information. 737 14. Load Balancing 739 Algorithms used to balance traffic load for popular destinations may 740 be affected by the introduction of address sharing. Where balancing 741 is achieved by deterministically routing traffic from specific source 742 IP addresses to specific servers, sudden imbalances in load may be 743 experienced as address sharing is enabled for some of those source IP 744 addresses. This will require re-evaluation of the algorithms used in 745 the load-balancing design. In general, as the scale of address 746 sharing grows, load-balancing designs will need to be re-evaluated 747 and any assumptions about average load per source IP address 748 revisited. 750 15. IPv6 Transition Issues 752 IPv4 address sharing solutions may interfere with existing IPv4 to 753 IPv6 transition mechanisms, which were not designed with IPv4 754 shortage considerations in mind. With port-range solutions for 755 instance, incoming 6to4 packets should be able to find their way from 756 a 6to4 relay to the appropriate 6to4 CPE router, despite the lack of 757 direct port range information (UDP/TCP initial source port did not 758 pass through the CPE port range translation process). One solution 759 would be for a 6to4 IPv6 address to embed not only an IPv4 address 760 but also a port range value. 762 Subscribers allocated with private addresses will not be able to 763 utilise 6to4 to access IPv6, but may be able to utilise Teredo. 765 16. Introduction of Single Points of Failure 767 In common with all deployments of new network functionality, the 768 introduction of new nodes or functions to handle the multiplexing of 769 multiple subscribers across shared IPv4 addresses could create single 770 points of failure in the network. Any IP address sharing solution 771 should consider the opportunity to add redundancy features in order 772 to alleviate the impact on the robustness of the offered IP 773 connectivity service. The ability of the solution to allow hot 774 swapping from one machine to another should be considered. This is 775 especially important where the address sharing solution in question 776 requires the creation of per-flow state in the network. 778 17. State maintenance reduces battery life 780 In order for hosts to maintain network state in the presence of NAT, 781 keep-alive messages have to be sent at frequent intervals. For 782 battery-powered devices, sending these keep-alive messages can result 783 in significantly reduced battery performance than would otherwise be 784 the case [Mobile_Energy_Consumption]. 786 18. Support of Multicast 788 [RFC5135] specifies requirements for a NAT that supports Any Source 789 IP Multicast or Source-Specific IP Multicast. Port-range routers 790 that form part of port-range solutions will need to support similar 791 requirements if multicast support is required. 793 [Placeholder for more details of impact of address sharing on 794 multicast deployments.] 796 19. Support of Mobile-IP 798 IP address sharing within the context of Mobile-IP deployments (in 799 the home network and/or in the visited network), will require Home 800 Agents and/or Foreign Agents to be updated so as to take into account 801 the relevant port information. There may also be issues raised when 802 an additional layer of encapsulation is required thereby causing, or 803 increasing the need for, fragmentation and reassembly. 805 Issues for Mobile-IP in the presence of NAT are discussed in 806 [I-D.haddad-mext-nat64-mobility-harmful] 808 20. IANA Considerations 810 This memo includes no request to IANA. 812 21. Security Considerations 814 This memo does not define any protocol and raises no security issues. 815 Section 11 discusses some of the security and identity-related 816 implications of address sharing. 818 22. Contributors 820 This document is based on sources co-authored by J.L. Grimault and A. 821 Villefranque of France Telecom. 823 23. Acknowledgements 825 This memo was partly inspired by conversations that took place as 826 part of Internet Society (ISOC) hosted roundtable events for 827 operators and content providers deploying IPv6. Participants in 828 those discussions included John Brzozowski, Leslie Daigle, Tom 829 Klieber, Yiu Lee, Kurtis Lindqvist, Wes George, Lorenzo Colliti, Erik 830 Kline, Igor Gashinsky, Jason Fesler, Rick Reed, Adam Bechtel, Larry 831 Campbell, Tom Coffeen, David Temkin, Pete Gelbman, Mark Winter, Will 832 Charnock, Martin Levy, Greg Wood and Christian Jacquenet. The 833 authors are also grateful to Christian Jacquenet, Iain Calder, Joel 834 Halpern, Brian Carpenter, Gregory Lebovitz, Bob Briscoe, Marcelo 835 Bagnulo and Dan Wing for their helpful comments and suggestions for 836 improving this document. 838 This memo was created using the xml2rfc tool. 840 24. Annex 842 24.1. Classes of Address Sharing Solution 844 IP address sharing solutions fall into two classes. Either a 845 service-provider operated NAT function is introduced and subscribers 846 are allocated addresses from [RFC1918] space, or public IPv4 847 addresses are shared across multiple subscribers by restricting the 848 range of ports available to each subscriber. These classes of 849 solution are described in a bit more detail below. 851 o CGN-based solutions: These solutions propose the introduction of a 852 NAPT function in the service provider's network, denoted also as 853 Carrier Grade NAT (CGN), or Large Scale NAT (LSN) 854 [I-D.nishitani-cgn] , or Provider NAT. The CGN is responsible for 855 translating private addresses to publicly routable addresses. 856 Private addresses are assigned to subscribers, a pool of public 857 addresses is assigned to the CGN, and the number of public 858 addresses is smaller than the number of subscribers. A public 859 IPv4 address in the CGN pool is shared by several subscribers at 860 the same time. Solutions making use of a service provider-based 861 NAT include [I-D.shirasaki-nat444] (two layers of NAT) and 862 [I-D.ietf-softwire-dual-stack-lite] (a single layer of NAT). 864 o Port-range solutions: These solutions avoid the presence of a CGN 865 function. A single public IPv4 address is assigned to several 866 subscribers at the same time. A restricted port range is also 867 assigned to each subscriber so that two subscribers with the same 868 IPv4 address have two different port ranges that do not overlap. 869 These solutions are called A+P (Address+Port) [I-D.ymbk-aplusp] , 870 or Port Range [I-D.boucadair-port-range] , or SAM (Stateless 871 Address Mapping) [I-D.despres-sam] . 873 24.2. Address Space Multiplicative Factor 875 The purpose of sharing public IPv4 addresses is to increase the 876 addressing space. A key parameter is the factor by which service 877 providers want or need to multiply their IPv4 public address space; 878 and the consequence is the number of subscribers sharing the same 879 public IPv4 address. We refer to this parameter as the address space 880 multiplicative factor, the inverse is called the compression ratio. 882 The multiplicative factor can only be applied to the subset of 883 subscribers that are eligible for a shared address. The reasons a 884 subscriber cannot have a shared address can be: 886 o It would not be compatible with the service they are currently 887 subscribed to (for example: business subscriber). 889 o Subscriber CPE is not compatible with the address sharing solution 890 selected by the service provider (for example it does not handle 891 port restriction for port-range solutions or it does not allow 892 IPv4 in IPv6 encapsulation for the DS-Lite solution), and its 893 replacement is not easy. 895 Different service providers may have very different needs. A long- 896 lived service provider, whose number of subscribers is rather stable, 897 may have an existing address pool that will only need a small 898 extension to cope with the next few years, assuming that this address 899 pool can be re-purposed for an address sharing solution (small 900 multiplicative factor, less than 10). A new entrant or a new line of 901 business will need a much bigger multiplicative factor (e.g. 1000). 902 A mobile operator may see its addressing needs grow dramatically as 903 the IP-enabled mobile handset market grows. 905 When the multiplicative factor is large, the average number of ports 906 per subscriber is small. Given the large measured disparity between 907 average and peak port consumption [CGN_Viability] , this will create 908 service problems in the event that ports are allocated statically. 909 In this case, it is essential for port allocation to map to need as 910 closely as possible, and to avoid allocating ports for longer than 911 necessary. Therefore, the larger the multiplicative factor, the more 912 dynamic the port assignment has to be. 914 25. Informative References 916 [CGN_Viability] 917 Alcock, S., "Research into the Viability of Service- 918 Provider NAT", 2008, . 921 [I-D.boucadair-port-range] 922 Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, 923 "IPv4 Connectivity Access in the Context of IPv4 Address 924 Exhaustion: Port Range based IP Architecture", 925 draft-boucadair-port-range-02 (work in progress), 926 July 2009. 928 [I-D.despres-sam] 929 Despres, R., "Scalable Multihoming across IPv6 Local- 930 Address Routing Zones Global-Prefix/Local-Address 931 Stateless Address Mapping (SAM)", draft-despres-sam-03 932 (work in progress), July 2009. 934 [I-D.gont-behave-nat-security] 935 Gont, F. and P. Srisuresh, "Security implications of 936 Network Address Translators (NATs)", 937 draft-gont-behave-nat-security-03 (work in progress), 938 October 2009. 940 [I-D.haddad-mext-nat64-mobility-harmful] 941 Haddad, W. and C. Perkins, "A Note on NAT64 Interaction 942 with Mobile IPv6", 943 draft-haddad-mext-nat64-mobility-harmful-00 (work in 944 progress), October 2009. 946 [I-D.ietf-behave-v6v4-xlate] 947 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 948 Algorithm", draft-ietf-behave-v6v4-xlate-10 (work in 949 progress), February 2010. 951 [I-D.ietf-behave-v6v4-xlate-stateful] 952 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 953 NAT64: Network Address and Protocol Translation from IPv6 954 Clients to IPv4 Servers", 955 draft-ietf-behave-v6v4-xlate-stateful-09 (work in 956 progress), March 2010. 958 [I-D.ietf-softwire-dual-stack-lite] 959 Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, 960 Y., and R. Bush, "Dual-stack lite broadband deployments 961 post IPv4 exhaustion", 962 draft-ietf-softwire-dual-stack-lite-03 (work in progress), 963 February 2010. 965 [I-D.ietf-tsvwg-port-randomization] 966 Larsen, M. and F. Gont, "Transport Protocol Port 967 Randomization Recommendations", 968 draft-ietf-tsvwg-port-randomization-06 (work in progress), 969 February 2010. 971 [I-D.nishitani-cgn] 972 Nishitani, T., Yamagata, I., Miyakawa, S., Nakagawa, A., 973 and H. Ashida, "Common Functions of Large Scale NAT 974 (LSN)", draft-nishitani-cgn-03 (work in progress), 975 November 2009. 977 [I-D.shirasaki-nat444] 978 Shirasaki, Y., Yamagata, I., Nakagawa, A., Yamaguchi, J., 979 and H. Ashida, "NAT444", draft-shirasaki-nat444-00 (work 980 in progress), October 2009. 982 [I-D.ymbk-aplusp] 983 Bush, R., "The A+P Approach to the IPv4 Address Shortage", 984 draft-ymbk-aplusp-05 (work in progress), October 2009. 986 [IPv4_Report] 987 Huston, G., "IPv4 Address Report", 2009, 988 . 990 [Mobile_Energy_Consumption] 991 Haverinen, H., Siren, J., and P. Eronen, "Energy 992 Consumption of Always-On Applications in WCDMA Networks", 993 2007, . 995 [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", 996 RFC 1337, May 1992. 998 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 999 E. Lear, "Address Allocation for Private Internets", 1000 BCP 5, RFC 1918, February 1996. 1002 [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, 1003 April 1997. 1005 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1006 Translator (NAT) Terminology and Considerations", 1007 RFC 2663, August 1999. 1009 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1010 specifying the location of services (DNS SRV)", RFC 2782, 1011 February 2000. 1013 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1014 Defeating Denial of Service Attacks which employ IP Source 1015 Address Spoofing", BCP 38, RFC 2827, May 2000. 1017 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 1018 November 2000. 1020 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 1021 (NAT) Compatibility Requirements", RFC 3715, March 2004. 1023 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1024 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1025 January 2005. 1027 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1028 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1029 RFC 4787, January 2007. 1031 [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a 1032 Network Address Translator (NAT) and a Network Address 1033 Port Translator (NAPT)", BCP 135, RFC 5135, February 2008. 1035 Authors' Addresses 1037 Mat Ford (editor) 1038 Internet Society 1039 Geneva 1040 Switzerland 1042 Email: ford@isoc.org 1044 Mohamed Boucadair 1045 France Telecom 1047 Email: mohamed.boucadair@orange-ftgroup.com 1049 Alain Durand 1050 Comcast 1052 Email: Alain_Durand@cable.comcast.com 1054 Pierre Levis 1055 France Telecom 1056 42 rue des Coutures 1057 BP 6243 1058 Caen Cedex 4 14066 1059 France 1061 Email: pierre.levis@orange-ftgroup.com 1063 Phil Roberts 1064 Internet Society 1065 Reston, VA 1066 USA 1068 Email: roberts@isoc.org