idnits 2.17.1 draft-penno-softwire-sdnat-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2012) is 4429 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) == Unused Reference: 'RFC0792' is defined on line 420, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pcp-base' is defined on line 438, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-ipv6-00 ** Downref: Normative reference to an Informational draft: draft-ietf-dhc-dhcpv4-over-ipv6 (ref. 'I-D.ietf-dhc-dhcpv4-over-ipv6') == Outdated reference: A later version (-11) exists of draft-cui-softwire-b4-translated-ds-lite-05 == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-23 == Outdated reference: A later version (-10) exists of draft-ietf-softwire-public-4over6-00 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Penno 3 Internet-Draft A. Durand 4 Intended status: Standards Track Juniper Networks 5 Expires: September 12, 2012 A. Clauberg 6 Deutsche Telekom AG 7 L. Hoffmann 8 Bouygues Telecom 9 March 11, 2012 11 Stateless DS-Lite 12 draft-penno-softwire-sdnat-02 14 Abstract 16 This memo define a simple stateless and deterministic mode of 17 operating a carrier-grade NAT as a backward compatible evolution of 18 DS-Lite. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 12, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Stateless DS-Lite CPE . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Learning external IPv4 address . . . . . . . . . . . . . . 4 57 2.2. Learning external port range . . . . . . . . . . . . . . . 4 58 2.3. Stateless DS-Lite CPE operation . . . . . . . . . . . . . 5 59 2.4. Host-based Stateless DS-Lite . . . . . . . . . . . . . . . 5 60 3. Stateless AFTR . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Anycast IPv6 address for Stateless AFTR . . . . . . . . . 5 62 3.2. Stateless AFTR IPv4 address pool . . . . . . . . . . . . . 5 63 3.3. Stateless AFTR per-subscriber mapping table . . . . . . . 5 64 3.4. Stateless AFTR decapsulation rules . . . . . . . . . . . . 6 65 3.5. Stateless AFTR encapsulation rules . . . . . . . . . . . . 6 66 3.6. Redundancy and fail over . . . . . . . . . . . . . . . . . 7 67 3.7. SD-AFTR stateless domain . . . . . . . . . . . . . . . . . 7 68 4. Backward compatibility with DS-Lite . . . . . . . . . . . . . 7 69 5. ICMP port restricted message . . . . . . . . . . . . . . . . . 8 70 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.2. Source port restricted ICMP . . . . . . . . . . . . . . . 8 72 5.3. Host behavior . . . . . . . . . . . . . . . . . . . . . . 9 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 8.1. Normative references . . . . . . . . . . . . . . . . . . . 10 77 8.2. Informative references . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 DS-Lite [RFC6333],is a solution to deal with the IPv4 exhaustion 83 problem once an IPv6 access network is deployed. It enables 84 unmodified IPv4 application to access the IPv4 Internet over the IPv6 85 access network. In the DS-Lite architecture, global IPv4 addresses 86 are shared among subscribers in the AFTR, acting as a Carrier-Grade 87 NAT (CGN). 89 [I-D.ietf-softwire-public-4over6] extends the original DS-Lite model 90 to offer a mode where the NAT function is performed in the CPE. This 91 simplifies the AFTR operation as it does not have to perform the NAT 92 function anymore, however, the flip side is that the address sharing 93 function among subscribers was no longer available. 94 [I-D.cui-softwire-b4-translated-ds-lite] introduces port 95 restrictions, but does not completely specifies how the CPE acquires 96 the information about its IPv4 address and its port range. More 97 importantly, that draft does not explain how this solution can be 98 deployed in a regular DS-Lite environment. This memo addresses these 99 issues and clarifies the operation model. 101 Other approaches like variations of 4rd allows also for a full 102 stateless operation of the decapsulation device. By introducing a 103 strong coupling between the IPv6 address and the derived IPv4 104 address, they get rid of the per-subscriber state on the 105 decapsulation devices. The approach take here argues that such per- 106 subscriber state is not an issue as it is easily replicated among all 107 decapsulation devices. Eliminating the strong coupling between IPv6 108 and IPv4 derived addresses, the approach presented here enables 109 service providers a greater flexibility on how their limited pool of 110 IPv4 addresses is managed. It also provide greater freedom on how 111 IPv6 addresses are allocated, as sequential allocation is no longer a 112 pre-requisite. 114 The approach presented here is stateless and deterministic. It is 115 stateless is NAT bindings are maintained on the CPE, not on the AFTR. 116 It is deterministic as no logs are required on the AFTR to identify 117 which subscriber is using an external Ipv4 address and port. 119 The stateless DS-Lite architecture has the following characteristics: 121 o Backward compatible with DS-Lite. A mix of regular DS-Lite CPE 122 and stateless DS-Lite CPEs can interoperate with a stateless DS- 123 Lite AFTR. 125 o Zero log: Because the AFTR relies only on a per-subscriber mapping 126 table that is reversible, the ISP does not need to keep any NAT 127 binding logs. 129 o Stateless AFTR: There is no per-session state on the AFTRs. By 130 leveraging this stateless and deterministic mode of operation, an 131 ISP can deploy any number of AFTRs to provide redundancy and 132 scalability at low cost. Because there is no per-flow state to 133 maintain, AFTR can implement the functionality in hardware and 134 perform it at high speed with low latency. 136 o Flexibility of operation: The ISP can add or remove addresses from 137 the NAT pool without having to renumber the access network. 139 o Leverage IPv6: This stateless DS-Lite model leverage the IPv6 140 access network deployed by the ISPs. 142 2. Stateless DS-Lite CPE 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [RFC2119]. 148 A Stateless DS-Lite CPE operates in similar fashion than a regular 149 DS-Lite CPE, where the NAT function is re-introduced in CPE with a 150 modification on how ports are managed. 152 2.1. Learning external IPv4 address 154 A stateless DS-Lite CPE MUST implement the DHCPv4 client relay option 155 defined in [I-D.ietf-dhc-dhcpv4-over-ipv6] to learn is external IPv4 156 address. Other mechanism, such as manual configuration or TR69, MAY 157 be implemented. 159 2.2. Learning external port range 161 A stateless DS-Lite CPE MUST implement the ICMP "port restricted" 162 option defined later in this memo. 164 At boot time and later at intervals of 1h +/- a random number of 165 seconds between 0 and 900), the stateless DS-Lite CPE MUST send 166 packets with source port 0, source IPv4 address of the B4 element, 167 destination IPv4 address 192.0.0.1 (the AFTR well-known IPv4 address) 168 destination port 0, for each of the supported transport protocols 169 (usually TCP and UDP). This will trigger an ICMP "port restricted" 170 message from the AFTR. 172 After validating the content of the "ICMP port restricted" message, 173 the stateless DS-Lite CPE MUST configure its port pool with it. If 174 existing connections were using source ports outside of that range, 175 the stateless DS-Lite CPE MUST terminate them. 177 2.3. Stateless DS-Lite CPE operation 179 The stateless DS-Lite CPE performs IPv4 NAPT from the internal 180 RFC1918 addresses to the IPv4 address configured on the WAN 181 interface, restricting its available ports to the range obtained as 182 described above. 184 2.4. Host-based Stateless DS-Lite 186 Any host initiating directly a DS-Lite IPv4 over IPv6 tunnel can 187 benefit from this techniques by implementing a 'virtual' stateless 188 DS-Lite CPE function within its IP stack. 190 3. Stateless AFTR 192 3.1. Anycast IPv6 address for Stateless AFTR 194 All stateless AFTRs associated to a domain (or group of subscribers) 195 will be configured with the same IPv6 address on the interface facing 196 IPv6 subscribers. A route for that IPv6 address will be anycasted 197 within the access network. 199 3.2. Stateless AFTR IPv4 address pool 201 All stateless AFTRs associated to a domain (or group of subscribers) 202 MUST be configured with the same pool of global IPv4 addresses. 204 Routes to the pool of global IPv4 addresses configured on the 205 stateless AFTRs will be anycasted by the relevant AFTRs within the 206 ISP routing domain. 208 3.3. Stateless AFTR per-subscriber mapping table 210 Stateless AFTRs associated to a domain (or group of subscribers) MUST 211 be configured with the same per-subscriber mapping table, associating 212 the IPv6 address of the subscriber CPE to the external IPv4 address 213 and port range provisioned for this subscriber. 215 Because the association IPv6 address --- IPv4 address + port range is 216 not tied to a mathematical formula, the ISP maintains all flexibility 217 to allocate independently IPv6 address and IPv4 addresses. In 218 particular, IPv6 addresses do not have to be allocated sequentially 219 and IPv4 resources can be modified freely. 221 +--------------+------------+----------+ 222 | IPv6 address |IPv4 address|port-range| 223 +--------------+------------+----------+ 224 |2001:db8::1 | 1.2.3.4 | 1000-1999| 225 |2001:db8::5 | 1.2.3.4 | 2000-2999| 226 |2001:db8::a:1 | 1.2.3.4 | 3000-3999| 227 +--------------+------------+----------+ 229 Figure 1: Per-subscriber mapping table example 231 This per-subscriber mapping table can be implemented in various ways 232 which details are out of scope for this memo. In its simplest form, 233 it can be a static file that is replicated out-of-band on the AFTRs. 234 In a more elaborated way, this table can be dynamically built using 235 radius queries to a subscriber database. 237 3.4. Stateless AFTR decapsulation rules 239 Upstream IPv4 over IPv6 traffic will be decapsulated by the AFTR. 240 The AFTR MUST check the outer IPv6 source address belongs to an 241 identified subscriber and drop the traffic if not. The AFTR MUST 242 then check the inner IPv4 header to make sure the IPv4 source address 243 and ports are valid according to the per-subscriber mapping table. 245 If the inner IPv4 source address does not match the entry in the per- 246 subscriber mapping table, the packet MUST be discarded and an ICMP 247 'administratively prohibited' message MAY be returned. 249 If the IPv4 source port number falls outside of the range allocated 250 to the subscriber, the AFTR MUST discard the datagram and MUST send 251 back an ICMP "port restricted" message to the IPv6 source address of 252 the packet. 254 Fragmentation and reassembly is treated as in DS-Lite [RFC6333]. 256 3.5. Stateless AFTR encapsulation rules 258 Downstream traffic is validated using the per-subscriber mapping 259 table. Traffic that falls outside of the IPv4 address/port range 260 entries in that table MUST be discarded. Validated traffic is then 261 encapsulated in IPv6 and forwarded to the associated IPv6 address. 263 Fragmentation and reassembly is treated as in DS-Lite [RFC6333]. 265 3.6. Redundancy and fail over 267 Because there is no per-flow state, upstream and downstream traffic 268 can use any stateless AFTR. 270 3.7. SD-AFTR stateless domain 272 Using the DHCPv6 DS-Lite tunnel-end-point option, groups of 273 subscribers and can be associated to a different stateless AFTR 274 domain. That can allow for differentiated level of services, e.g. 275 number of ports per customer device, QoS, bandwidth, value added 276 services,... 278 4. Backward compatibility with DS-Lite 280 A number of service providers are, or are in the process of, 281 deploying DS-Lite in their network. They are interested in evolving 282 their design toward a stateless model. Backward compatibility is a 283 critical issue, as, from an operational perspective, it is difficult 284 to get all CPEs evolve at the same time. 286 So AFTRs have to be ready to service CPEs that are pure DS-Lite, some 287 that are implementing only DHCPv4 over IPv6 and handle the NAT on the 288 full IPv4 address themselves and some that also implement port 289 restrictions via the ICMP message described here. For this reason, a 290 AFTR operating in backward compatibility mode MAY decide to re-NAT 291 upstream packets which source port number do not fall into the 292 predefined range instead of simply dropping the packets. 294 The operating model is the following: 296 o Stateless DS-Lite: for CPEs that pre-NAT and pre-shape the source 297 port space into the range assigned to the subscriber: decapsulate, 298 check per-subscriber mapping, forward. 300 o B4-translated DS-Lite: for CPEs that performs NAT before 301 encapsulation and are allocated a full IPv4 address: decapsulate, 302 check per-subscriber mapping, forward. 304 o Re-shaper DS-Lite: for CPEs that pre NAT but fail to restrict the 305 source ports: decapsulate, check per-subscriber mapping, re-NAT 306 statefully the packets into the restricted port range, mark range 307 as 'stateful', forward. 309 o Regular DS-Lite: for regular DS-Lite CPEs that do not pre-NAT: 310 decapsulate, NAT statefully, forward. 312 In such a backward compatibility mode, the AFTR is only operating 313 statelessly for the stateless DS-Lite CPEs. It needs to maintain 314 per-flow state for the regular DS-Lite CPEs and the non-ICMP port 315 restricted compliant CPEs. In this legacy mode where per-flow state 316 is required, the simple anycast-based fail-over mechanism is no 317 longer available. 319 5. ICMP port restricted message 321 Note: this section may end-up being a separate Internet draft. 323 5.1. Introduction 325 In the framework of A+P RFC 6346 [RFC6346], sources may be restricted 326 to use only a subset of the port range of a transport protocol 327 associated with an IPv4 address. When that source transmit a packet 328 with a source outside of the pre-authorized range, the upstream NAT 329 will drop the packet and use the ICMP message defined here to inform 330 the source of the actual port range allocated. 332 This memo defines such ICMP messages for TCP and UDP and leaves the 333 definition of the ICMP option for other transport protocol for future 334 work. 336 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 337 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 338 document are to be interpreted as described in RFC 2119 [RFC2119]. 340 5.2. Source port restricted ICMP 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Type | Code | Checksum | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Min Port | Max Port | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | | 348 ~ Original Internet Headers + 64 bits of Payload ~ 349 | | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Figure 2: Source Port Restricted ICMP 354 Type: TBD for Source Port Restricted 356 Checksum: The checksum is the 16-bit ones's complement of the one's 357 complement sum of the ICMP message starting with the ICMP Type. For 358 computing the checksum , the checksum field should be zero. This 359 checksum may be replaced in the future. 361 Code: 6 for TCP, 17 for UDP 363 Min Port: The lowest port number allocated for that source. 365 Max Port: The highest port number allocated for that source. 367 5.3. Host behavior 369 A host receiving an ICMP type TBD message for a given transport 370 protocol SHOULD NOT send packets sourced by the IP address(es) 371 corresponding to the interface that received that ICMP message with 372 source ports outside of the range specified for the given transport 373 protocol. 375 Packets sourced with port numbers outside of the restricted range MAY 376 be dropped or NATed upstream to fit within the restricted range. 378 A host MUST NOT take port restriction information applying to a given 379 IP address and transport protocol and applies it to other IP 380 addresses on other interfaces and/or other transport protocols. 382 If Min Port = 0 and Max Port = 65535, it indicates that the entire 383 port range for the given transport protocol is available. If such 384 'full range' messages are received for all transport protocols, the 385 host can take this as an indication that its IP address is probably 386 not shared with other devices. 388 In order to mitigate possible man in the middle attacks, a host MUST 389 discard ICMP type TBD messages if the associated port range (Max Port 390 - Min Port) is lower than 64. 392 6. IANA Considerations 394 IANA is to allocated a code point for this ICMP message type. 396 7. Security Considerations 398 This ICMP message type has the same security properties as other ICMP 399 messages such as Redirect or Destination Unreachable. A man-in-the- 400 middle attack can be mounted to create a DOS attack on the source. 401 Ingress filtering on network boundary can mitigate such attacks. 402 However, in case such filtering measures are not enough, the 403 additional provision that a host MUST discard such ICMP message with 404 a port range smaller than 64 can mitigate even further such attacks. 406 As described in [RFC6269], with any fixed size address sharing 407 techniques, port randomization is achieved with a smaller entropy. 409 Recommendations listed in [RFC6302] applies. 411 8. References 413 8.1. Normative references 415 [I-D.ietf-dhc-dhcpv4-over-ipv6] 416 Lemon, T., Cui, Y., Wu, P., and J. Wu, "DHCPv4 over IPv6 417 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-00 (work in 418 progress), November 2011. 420 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 421 RFC 792, September 1981. 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, March 1997. 426 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 427 Stack Lite Broadband Deployments Following IPv4 428 Exhaustion", RFC 6333, August 2011. 430 8.2. Informative references 432 [I-D.cui-softwire-b4-translated-ds-lite] 433 Boucadair, M., Sun, Q., Tsou, T., Lee, Y., and Y. Cui, 434 "Lightweight 4over6: An Extension to DS-Lite 435 Architecture", draft-cui-softwire-b4-translated-ds-lite-05 436 (work in progress), February 2012. 438 [I-D.ietf-pcp-base] 439 Cheshire, S., Boucadair, M., Selkirk, P., Wing, D., and R. 440 Penno, "Port Control Protocol (PCP)", 441 draft-ietf-pcp-base-23 (work in progress), February 2012. 443 [I-D.ietf-softwire-public-4over6] 444 Cui, Y., Wu, J., Wu, P., Metz, C., Vautrin, O., and Y. 445 Lee, "Public IPv4 over Access IPv6 Network", 446 draft-ietf-softwire-public-4over6-00 (work in progress), 447 September 2011. 449 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 450 Roberts, "Issues with IP Address Sharing", RFC 6269, 451 June 2011. 453 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 454 "Logging Recommendations for Internet-Facing Servers", 455 BCP 162, RFC 6302, June 2011. 457 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 458 IPv4 Address Shortage", RFC 6346, August 2011. 460 Authors' Addresses 462 Reinaldo Penno 463 Juniper Networks 464 1194 North Mathilda Avenue 465 Sunnyvale, CA 94089-1206 466 USA 468 Email: rpenno@juniper.net 470 Alain Durand 471 Juniper Networks 472 1194 North Mathilda Avenue 473 Sunnyvale, CA 94089-1206 474 USA 476 Email: adurand@juniper.net 478 Alex Clauberg 479 Deutsche Telekom AG 480 GTN-FM4 481 Landgrabenweg 151 482 Bonn, CA 53227 483 Germany 485 Email: axel.clauberg@telekom.de 486 Lionel Hoffmann 487 Bouygues Telecom 488 TECHNOPOLE 489 13/15 Avenue du Marechal Juin 490 Meudon 92360 491 France 493 Email: lhoffman@bouyguestelecom.fr