idnits 2.17.1 draft-arkko-dual-stack-extra-lite-03.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 (October 25, 2010) is 4930 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-06 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Standards Track L. Eggert 5 Expires: April 28, 2011 Nokia 6 October 25, 2010 8 Scalable Operation of Address Translators with Per-Interface Bindings 9 draft-arkko-dual-stack-extra-lite-03 11 Abstract 13 This document explains how to employ address translation in networks 14 that serve a large number of individual customers without requiring a 15 correspondingly large amount of private IPv4 address space. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 28, 2011. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 This document explains how to employ address translation without 52 consuming a large amount of private address space. This is important 53 in networks that serve a large number of individual customers. 54 Networks that serve more than 2^24 (16 million) users cannot assign a 55 unique private IPv4 address to each user, because the largest 56 reserved private address block reserved is 10/8 [RFC1918]. Many 57 networks are already hitting these limits today, for instance, in the 58 consumer Internet service market. Even some individual devices may 59 approach these limits, for instance, cellular network gateways or 60 mobile IP home agents. 62 If ample IPv4 address space was available, this would be a non-issue, 63 because the current practice of assigning public IPv4 addresses to 64 each user would remain viable, and the complications associated with 65 using the more limited private address space could be avoided. 66 However, as the IPv4 address pool is becoming depleted, this practice 67 is becoming increasingly difficult to sustain. 69 It has been suggested that more of the unassigned IPv4 space should 70 be converted for private use, in order to allow the provisioning of 71 larger networks with private IPv4 address space. At the time of 72 writing, the IANA "free pool" contained only 12 unallocated unicast 73 IPv4 /8 prefixes. Although reserving a few of those for private use 74 would create some breathing room for such deployments, it would not 75 result in a solution with long-term viability, would result in 76 significant operational and management overheads, and would further 77 reduce the number of available IPv4 addresses. 79 Segmenting a network into areas of overlapping private address space 80 is another possible technique, but it severely complicates the design 81 and operation of a network. 83 Finally, the transition to IPv6 will eventually eliminate these 84 addressing limitations. However, during the migration period when 85 IPv4 and IPv6 have to co-exist, there will be the need to reach IPv4 86 destinations, which involves the use of address or protocol 87 translation. 89 The rest of this document is organized as follows. Section 2 gives 90 an outline of the solution, Section 3 introduces some terms, 91 Section 4 specifies the required behavior for managing NAT bindings 92 and Section 5 discusses the use of this technique with IPv6. 94 2. Solution Outline 96 The need for address or protocol translation during the migration 97 period to IPv6 creates the opportunity to deploy these mechanisms in 98 a way that allows the support of a large user base without the need 99 for a correspondingly large IPv4 address block. 101 A Network Address Translator (NAT) is typically configured to connect 102 a network domain that uses private IPv4 addresses to the public 103 Internet. The NAT device - which is configured with a public IPv4 104 address - creates and maintains a mapping for each communication 105 session from a device inside the domain it serves to devices in the 106 public Internet. It does that by translating the packet flow of each 107 session such that the externally visible traffic uses only public 108 addresses. 110 In most NAT deployments, the network domain connected by the NAT to 111 the public Internet is a broadcast network sharing the same media, 112 where each individual device must have a unique IPv4 address. In 113 such deployments it is natural to also implement the NAT 114 functionality such that it uses this unique IPv4 address when looking 115 up which mapping should be used to translate a given communication 116 session. 118 It is important to note, however, that this is not an inherent 119 requirement. When other methods of identifying the correct mapping 120 are available, and the NAT is not connecting a shared-media broadcast 121 network to the Internet, there is no need to assign each device in 122 the domain a unique IPv4 address. 124 This is the case, for example, when the NAT connects devices to the 125 Internet that connect to it with individual point-to-point links. In 126 this case, it becomes possible to use the same private addresses many 127 times, making it possible to support any number of devices behind a 128 NAT using very few IPv4 addresses. 130 There are tunneling-based techniques to reach the same benefits, by 131 establishing new tunnels over any IP network 132 [I-D.ietf-softwire-dual-stack-lite]. However, where the point-to- 133 point links already exists, creating an additional layer of tunneling 134 is unnecessary (and even potentially harmful due to effects to the 135 Maximum Transfer Unit) MTU settings). The approach described in this 136 document can be implemented and deployed within a single device and 137 has no effect to hosts behind it. In addition, as no additional 138 layers of tunneling are introduced, there is no effect to the MTU. 139 It is also unnecessary to implement tunnel endpoint discovery, 140 security mechanisms or other aspects of a tunneling solution. In 141 fact, there are no changes to the devices behind the NAT. 143 Note, however, that existing tunnels are a common special case of 144 point-to-point links. For instance, cellular network gateways 145 terminate a large number of tunnels that are already needed for 146 mobility management reasons. Implementing the approach described in 147 this document is particularly attractive in such environments, given 148 that no additional tunneling mechanisms, negotiation, or host changes 149 are required. In addition, since there is no additional tunneling, 150 packets continue to take the same path as they would normally take. 151 Other commonly appearing network technology that may be of interest 152 include Point-to-Point Protocol (PPP) [RFC1661] links, PPP over 153 Ethernet (PPPoE) [RFC2516] encapsulation, Asynchronous Transfer Mode 154 (ATM) Permanent Virtual Circuits (PVCs), and per-subscriber virtual 155 LAN (VLAN) allocation in consumer broadband networks. 157 The approach described here also results overlapping private address 158 space, like the segmentation of the network to different areas. 159 However, this overlap is applied only at the network edges, and does 160 not impact routing or reachability of servers in a negative way. 162 3. Terms 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 "NAT" in this document includes both "Basic NAT" and "Network 169 Address/Port Translator (NAPT)" as defined by [RFC2663]. The term 170 "NAT Session" is adapted from [RFC5382] and is defined as follows. 172 NAT Session - A NAT session is an association between a transport 173 layer session as seen in the internal realm and a session as seen in 174 the external realm, by virtue of NAT translation. The NAT session 175 will provide the translation glue between the two session 176 representations. 178 This document uses the term mapping as defined in [RFC4787] to refer 179 to state at the NAT necessary for network address and port 180 translation of sessions. 182 4. Per-Interface Bindings 184 To support a mode of operation that uses a fixed number of IPv4 185 addresses to serve an arbitrary number of devices, a NAT MUST manage 186 its mappings on a per-interface basis, by associating a particular 187 NAT session not only with the five tuples used for the transport 188 connection on both sides of the NAT, but also with the internal 189 interface on which the user device is connected to the NAT. This 190 approach allows each internal interface to use the same private IPv4 191 address range. Note that the interface need not be physical, it may 192 also correspond to a tunnel, VLAN, or other identifiable 193 communications channel. 195 For deployments where exactly one user device is connected with a 196 separate tunnel interface and all tunnels use the same IPv4 address 197 for the user devices, it is redundant to store this address in the 198 mapping in addition to the internal interface identifier. When the 199 internal interface identifier is shorter than a 32-bit IPv4 address, 200 this may decrease the storage requirements of a mapping entry by a 201 small measure, which may aid NAT scalability. For other deployments, 202 it is likely necessary to store both the user device IPv4 address and 203 the internal interface identifier, which slightly increases the size 204 of the mapping entry. 206 This mode of operation is only suitable in deployments where user 207 devices connect to the NAT over point-to-point links. If supported, 208 this mode of operation SHOULD be configurable, and it should be 209 disabled by default in general-purpose NAT devices. 211 5. IPv6 Considerations 213 Private address space conservation is important even during the 214 migration to IPv6, because it will be necessary to communicate with 215 the IPv4 Internet for a long time. This document specifies two 216 recommended deployment models for IPv6. In the first deployment 217 model the mechanisms specified in this document are useful. In the 218 second deployment model no additional mechanisms are needed, because 219 IPv6 addresses are already sufficient to distinguish mappings from 220 each other. 222 The first deployment model employs dual stack [RFC4213]. The IPv6 223 side of dual stack operates based on global addresses and direct end- 224 to-end communication. However, on the IPv4 side private addressing 225 and NATs are a necessity. The use of per-interface NAT mappings is 226 RECOMMENDED for the IPv4 side under these circumstances. Per- 227 interface mappings help the NAT scale, while dual stack operation 228 helps reduce the pressure on the NAT device by moving key types of 229 traffic to IPv6, eliminating the need for NAT processing. 231 The second deployment model involves the use of address and protocol 232 translation, such as the one defined in 233 [I-D.ietf-behave-v6v4-xlate-stateful]. In this deployment model 234 there is no IPv4 in the internal network at all. This model is 235 applicable only in situations where all relevant devices and 236 applications are IPv6-capable. In this situation, per-interface 237 mappings could be employed as specified above, but they are generally 238 unnecessary as the IPv6 address space is large enough to provide a 239 sufficient number of mappings. 241 6. Security Considerations 243 This practices outlined in this document do not affect the security 244 properties of address translation. 246 7. IANA Considerations 248 This document has no IANA implications. 250 8. References 252 8.1. Normative References 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, March 1997. 257 8.2. Informative References 259 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 260 RFC 1661, July 1994. 262 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 263 E. Lear, "Address Allocation for Private Internets", 264 BCP 5, RFC 1918, February 1996. 266 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 267 and R. Wheeler, "A Method for Transmitting PPP Over 268 Ethernet (PPPoE)", RFC 2516, February 1999. 270 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 271 Translator (NAT) Terminology and Considerations", 272 RFC 2663, August 1999. 274 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 275 for IPv6 Hosts and Routers", RFC 4213, October 2005. 277 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 278 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 279 RFC 4787, January 2007. 281 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 282 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 283 RFC 5382, October 2008. 285 [I-D.ietf-softwire-dual-stack-lite] 286 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 287 Stack Lite Broadband Deployments Following IPv4 288 Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work 289 in progress), August 2010. 291 [I-D.arkko-townsley-coexistence] 292 Arkko, J. and M. Townsley, "IPv4 Run-Out and IPv4-IPv6 Co- 293 Existence Scenarios", draft-arkko-townsley-coexistence-06 294 (work in progress), October 2010. 296 [I-D.ietf-behave-v6v4-xlate-stateful] 297 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 298 NAT64: Network Address and Protocol Translation from IPv6 299 Clients to IPv4 Servers", 300 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 301 progress), July 2010. 303 [I-D.miles-behave-l2nat] 304 Miles, D. and M. Townsley, "Layer2-Aware NAT", 305 draft-miles-behave-l2nat-00 (work in progress), 306 March 2009. 308 [TRILOGY] "Trilogy Project", http://www.trilogy-project.org/. 310 Appendix A. Contributors 312 The ideas in this draft were first presented in 313 [I-D.ietf-softwire-dual-stack-lite]. This document also in debt to 314 [I-D.arkko-townsley-coexistence] and [I-D.miles-behave-l2nat]. 315 However, all of these documents focused on additional components, 316 such as tunneling protocols or the allocation of special IP address 317 ranges. We wanted to publish a specification that just focuses on 318 the core functionality of a per-interface NAT mappings. However, 319 Mark Townsley, David Miles, and Alain Durand should be credited with 320 coming up with the ideas discussed in this memo. 322 Appendix B. Acknowledgments 324 The authors would also like to thank Randy Bush, Fredrik Garneij, Dan 325 Wing, Christian Vogt, Marcelo Braun, Joel Halpern, Wassim Haddad, 326 Alan Kavanaugh and others for interesting discussions in this problem 327 space. 329 Lars Eggert is partly funded by the Trilogy Project [TRILOGY], a 330 research project supported by the European Commission under its 331 Seventh Framework Program. 333 Authors' Addresses 335 Jari Arkko 336 Ericsson 337 Jorvas 02420 338 Finland 340 Email: jari.arkko@piuha.net 342 Lars Eggert 343 Nokia Research Center 344 P.O. Box 407 345 Nokia Group 00045 346 Finland 348 Phone: +358 50 48 24461 349 Email: lars.eggert@nokia.com 350 URI: http://research.nokia.com/people/lars_eggert/