idnits 2.17.1 draft-droms-softwires-snat-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 572. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 585. 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 11 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 7 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2008) is 5765 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3775' is defined on line 516, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Droms 3 Internet-Draft Cisco 4 Intended status: Informational B. Haberman 5 Expires: January 13, 2009 July 12, 2008 7 Softwires Network Address Translation (SNAT) 8 draft-droms-softwires-snat-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 13, 2009. 35 Abstract 37 Service providers (ISPs) are interested in reducing the use of IPv4 38 in their internal networks because of the anticipated exhaustion of 39 the IPv4 address space. Softwires Network Address Translation (SNAT) 40 combines IPv4 NAT and IPv4-in-IPv6 softwires to carry IPv4 traffic 41 through the ISP network that uses only IPv6 service. Multiple 42 subscribers are multiplexed through a single external global IPv4 43 address, reducing the total number of IPv4 addresses in use by the 44 ISP to support Internet traffic to those subscribers. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 50 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 4. Problem statement and requirements . . . . . . . . . . . . . . 4 52 5. SNAT Architecture . . . . . . . . . . . . . . . . . . . . . . 4 53 6. Example message flow . . . . . . . . . . . . . . . . . . . . . 7 54 7. Translation details . . . . . . . . . . . . . . . . . . . . . 11 55 8. Supporting multiple subscribers through one IPv4 address . . . 12 56 9. Setting up state . . . . . . . . . . . . . . . . . . . . . . . 12 57 10. Analysis and Future Work . . . . . . . . . . . . . . . . . . . 13 58 11. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 13 59 11.1. Revision -01 . . . . . . . . . . . . . . . . . . . . . . 13 60 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 61 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 62 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 63 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 15.1. Normative References . . . . . . . . . . . . . . . . . . 14 65 15.2. Informative References . . . . . . . . . . . . . . . . . 14 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 67 Intellectual Property and Copyright Statements . . . . . . . . . . 15 69 1. Introduction 71 Service providers (ISPs) are interested in reducing the use of IPv4 72 in their internal networks because of the anticipated exhaustion of 73 the IPv4 address space. Reducing the use of IPv4 addresses will 74 allow the conservation of addresses assigned to the ISP for use in 75 specific places where IPv4 is required. One way of reducing the use 76 of IPv4 addresses to deploy IPv6 to replace IPv4 in internal 77 networks. 79 Softwires Network Address Translation (SNAT) combines IPv4 NAT 80 [RFC3022] and IPv4-in-IPv6 softwire to carry IPv4 traffic through the 81 ISP network where only IPv6 is deployed. RFC 4925 [RFC4925] 82 describes the two initial softwires WG problem statements, "Hubs and 83 Spokes" (Section 2) and "Mesh" (Section 3). The problem that this 84 document addresses is more narrowly scoped than either of these two 85 initial problem statements, focusing on IPv4 over IPv6 only and the 86 specific needs of a large ISP network facing scaling issues from lack 87 of RFC 1918 address space for all of its devices. It most closely 88 resembles the "converse case" of that depicted in Figure 2, Case 2, 89 of RFC 4925 (except that the Host may be IPv4-only, rather than Dual 90 Stack as depicted, and the portion of the network labeled "IPv4-only" 91 is likely larger than that implied in the diagram). SNAT multiplexes 92 multiple subscribers through a single IPv4 address, reducing the 93 total number of IPv4 addresses in use by the ISP to support Internet 94 traffic to those subscribers. 96 Elements of SNAT are inspired by the proposal from NTT to deploy dual 97 IPv4 NAT and the proposal from Comcast to use IPv4-IPv6-IPv4 98 translation. SNAT retains the characteristics of IPv4-IPV4 NAT, 99 rather than introducing IPv4-IPV6 translation, while saving IPv4 100 addresses in the ISP core network. This document has been submitted 101 to foster discussion about these mechanisms for IPv4 address space 102 conservation. 104 SNAT requires one IPv4-in-IPv6 softwire per subscriber. These 105 softwires will require configuration and special effort for 106 reliability, as well as resources for scaling at the ISP endpoint for 107 potentially thousands or even millions of softwires. SNAT also 108 requires additional functions in subscriber CPEs. 110 2. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 3. Terminology 118 This document uses softwires terminology described in Section 1.1 of 119 RFC 4925 throughout. The reader is expected to refer to this 120 document for a number of terms and abbreviations. In addition to the 121 terminology defined in RFC 4925, this document defines the following 122 terms: 124 HGW: Home gateway; the gateway between the subscriber network and 125 the ISP network 127 Subscriber host or host: A host attached to a subscriber network 129 SPSWE: Service provider softwire endpoint; the endpoint of the 130 softwires in the ISP network 132 4. Problem statement and requirements 134 The motivation for SNAT is to reduce the number of IPv4 addresses in 135 use in an ISP network. The reduction is achieved in two ways: 137 o Use NAT to multiplex subscribers through a single global IPv4 138 address 140 o Use softwires to provide IPv4 service through an ISP core network 141 that uses only IPv6 addresses 143 The following requirements were considered in the design of SNAT: 145 o Provide IPv4 service to CPE through NAT similar to familiar NAT in 146 use today 148 o Minimize the use of global IPv4 addresses for subscriber IPv4 149 service 151 o Eliminate the use of IPv4 addresses (global or RFC 1918) within 152 the ISP as much as possible 154 o No changes to subscriber CPEs (hosts attached to the subscribe 155 network) 157 5. SNAT Architecture 159 As illustrated in Figure 1, SNAT consists of three components: the 160 subscriber home gateway (HGW), the service provider softwire endpoint 161 (SPSWE) and a softwire between the SI in the HGW and the SC in the 162 SPSWE. The SPSWE performs IPv4-IPv4 NAT translations to multiplex 163 multiple subscribers through a single globl IPv4 address. 164 Overlapping address spaces used by subscribers are disambiguated 165 through the identification of tunnel endpoints. 167 +-----------+ 168 | Host | 169 +-----+-----+ 170 |10.0.0.1 171 | 172 | 173 |10.0.0.2 174 +---------|---------+ 175 | | | 176 |HGW | | 177 |+--------+--------+| 178 || SNAT SI || 179 |+--------+--------+| 180 +--------|||--------+ 181 |||2001:0:0:1::1 182 ||| 183 |||<-IPv4-in-IPv6 softwire 184 ||| 185 -------|||------- 186 / ||| \ 187 | ISP core network | 188 \ ||| / 189 -------|||------- 190 ||| 191 |||2001:0:0:2::1 192 +--------|||--------+ 193 |SPSWE ||| | 194 |+--------+--------+| 195 || SNAT SC || 196 |+--------+--------+| 197 | |NAT| | 198 | +-+-+ | 199 +---------|---------+ 200 |129.0.0.1 201 | 202 --------|-------- 203 / | \ 204 | Internet | 205 \ | / 206 --------|-------- 207 | 208 |128.0.0.1 209 +-----+-----+ 210 | IPv4 Host | 211 +-----------+ 213 Figure 1: SNAT Architecture 215 The resulting solution accepts an IPv4 datagram that is translated 216 into an IPv4-in-IPv6 softwire datagram for transmission across the 217 softwire. At the corresponding endpoint, the IPv4 datagram is 218 decapsulated, and the translated IPv4 address is inserted based on a 219 translation from the softwire. 221 6. Example message flow 223 In the example shown in Figure 2, the translation tables in the SPSWE 224 is configured to forward between IP/TCP (10.0.0.1/10000) and IP/TCP 225 (129.0.0.1/5000). That is, a datagram received by the HGW from the 226 CPE at address 10.0.0.1, using TCP DST port 10000 will be translated 227 a datagram with IP SRC address 129.0.0.1 and TCP SRC port 5000 in the 228 Internet. 230 +-----------+ 231 | CPE | 232 +-----+-----+ 233 | |10.0.0.1 234 IPv4 datagram 1 | | 235 | | 236 v |10.0.0.2 237 +---------|---------+ 238 | | | 239 |HGW | | 240 |+--------+--------+| 241 || SNAT SI || 242 |+--------+--------+| 243 +--------|||--------+ 244 | |||2001:0:0:1::1 245 IPv6 datagram 2| ||| 246 | |||<-IPv4-in-IPv6 softwire 247 | ||| 248 -----|-|||------- 249 / | ||| \ 250 | ISP core network | 251 \ | ||| / 252 -----|-|||------- 253 | ||| 254 | |||2001:0:0:2::1 255 +------|-|||--------+ 256 |SPSWE v ||| | 257 |+--------+--------+| 258 || SNAT SC || 259 |+--------+--------+| 260 | |NAT| | 261 | +-+-+ | 262 +---------|---------+ 263 | |129.0.0.1 264 IPv4 datagram 3 | | 265 -----|--|-------- 266 / | | \ 267 | Internet | 268 \ | | / 269 -----|--|-------- 270 | | 271 v |128.0.0.1 272 +-----+-----+ 273 | IPv4 Host | 274 +-----------+ 276 Figure 2: Outbound Datagram 278 +-----------------+--------------+---------------+ 279 | Datagram | Header field | Contents | 280 +-----------------+--------------+---------------+ 281 | IPv4 datagram 1 | IPv4 Dst | 128.0.0.1 | 282 | | IPv4 Src | 10.0.0.1 | 283 | | TCP Dst | 80 | 284 | | TCP Src | 10000 | 285 | --------------- | ------------ | ------------- | 286 | IPv6 Datagram 2 | IPv6 Dst | 2001:0:0:2::2 | 287 | | IPv6 Src | 2001:0:0:1::1 | 288 | | IPv4 Dst | 128.0.0.1 | 289 | | IPv4 Src | 10.0.0.1 | 290 | | TCP Dst | 80 | 291 | | TCP Src | 10000 | 292 | --------------- | ------------ | ------------- | 293 | IPv4 datagram 3 | IPv4 Dst | 128.0.0.1 | 294 | | IPv4 Src | 129.0.0.1 | 295 | | TCP Dst | 80 | 296 | | TCP Src | 5000 | 297 +-----------------+--------------+---------------+ 299 Datagram header contents 301 When datagram 1 is received by the HGW, the SI function encapsulates 302 the datagram in datagram 2 and forwards it to the SPSWE over the 303 softwire. 305 When it receives datagram 2, the SC in the SPSWE hands the IPv4 306 datagram to the NAT, which determines from its translation table that 307 the datagram received on Softwire_1 with TCP SRC port 10000 should be 308 translated to datagram 3 with IP SRC address 129.0.0.1 and TCP SRC 309 port 5000. 311 Figure 3 shows an inbound message received at the SPSWE. When the 312 NAT function in the SPSWE receives datagram 1, it looks up the IP/TCP 313 DST in its translation table. In the example in Figure 3, the NAT 314 translates the TCP DST port to 10000, sets the IP DST address to 315 10.0.0.1 and hands the datagram to the SC for transmission over 316 Softwire_1. The SI in the HGW decapsulates IPv4 datagram from the 317 inbound softwire datagram, and forwards it to the host. 319 +-----------+ 320 | Host | 321 +-----+-----+ 322 ^ |10.0.0.1 323 IPv4 datagram 3 | | 324 | | 325 | |10.0.0.2 326 +---------|---------+ 327 | +-+-+ | 328 |HGW |NAT| | 329 |+--------+--------+| 330 || SNAT SI || 331 |+--------+--------+| 332 +--------|||--------+ 333 ^ |||2001:0:0:1::1 334 IPv6 datagram 2 | ||| 335 | |||<-IPv4-in-IPv6 softwire 336 | ||| 337 -----|-|||------- 338 / | ||| \ 339 | ISP core network | 340 \ | ||| / 341 -----|-|||------- 342 | ||| 343 | |||2001:0:0:2::1 344 +------|-|||--------+ 345 |SPSWE | ||| | 346 |+--------+--------+| 347 || SNAT SC || 348 |+--------+--------+| 349 | |NAT| | 350 | +-+-+ | 351 +---------|---------+ 352 ^ |129.0.0.1 353 IPv4 datagram 1 | | 354 -----|--|-------- 355 / | | \ 356 | Internet | 357 \ | | / 358 -----|--|-------- 359 | | 360 | |128.0.0.1 361 +-----+-----+ 362 | IPv4 Host | 363 +-----------+ 365 The postamble. 367 Figure 3: Inbound Datagram 369 +-----------------+--------------+---------------+ 370 | Datagram | Header field | Contents | 371 +-----------------+--------------+---------------+ 372 | IPv4 datagram 1 | IPv4 Dst | 129.0.0.1 | 373 | | IPv4 Src | 128.0.0.1 | 374 | | TCP Dst | 5000 | 375 | | TCP Src | 80 | 376 | --------------- | ------------ | ------------- | 377 | IPv6 Datagram 2 | IPv6 Dst | 2001:0:0:1::1 | 378 | | IPv6 Src | 2001:0:0:2::2 | 379 | | IPv4 Dst | 10.0.0.1 | 380 | | IP Src | 128.0.0.1 | 381 | | TCP Dst | 10000 | 382 | | TCP Src | 80 | 383 | --------------- | ------------ | ------------- | 384 | IPv4 datagram 3 | IPv4 Dst | 10.0.0.1 | 385 | | IPv4 Src | 128.0.0.1 | 386 | | TCP Dst | 10000 | 387 | | TCP Src | 80 | 388 +-----------------+--------------+---------------+ 390 Datagram header contents 392 7. Translation details 394 The SPSWE has a NAT that translates between softwire/port pairs and 395 IPv4-address/port pairs. The same translation is applied to IPv4 396 datagrams received on the device's external interface and from the 397 softwire endpoint in the device. 399 In Figure 2, the translator network interface in the SPSWE is on the 400 Internet, and the softwire interface connects to the HGW. The SPSWE 401 translator is configured as follows: 403 Network interface: Translate IPv4 destination address and TCP 404 destination port to the softwire identifier and TCP destination 405 port 407 Softwire interface: Translate softwire identifier and TCP source 408 port to IPv4 source address and TCP source port 410 Here is how the translation in Figure 3 works: 412 o Datagram 1 is received on the SPSWE translator network interface. 413 The translator looks up the IPv4-address/port pair in its 414 translator table, rewrites the IPv4 destination address to 415 10.0.0.1 and the TCP source port to 10000, and hands the datagram 416 to the SE to be forwarded over the softwire. 418 o The IPv4 datagram is received on the HGW SI. The SI function 419 extracts the IPv4 datagram and the HGW forwards datagram 3 to the 420 host. 422 +-------------------------------+--------------------+ 423 | Softwire/IPv4/Port | IPv4/Port | 424 +-------------------------------+--------------------+ 425 | Softwire_1/10.0.0.1/TCP 10000 | 129.0.0.1/TCP 5000 | 426 +-------------------------------+--------------------+ 428 SPSWE translation table 430 8. Supporting multiple subscribers through one IPv4 address 432 One key advantage of SNAT is the ability to provide Internet access 433 for multiple subscribers through a single global IPv4 address. The 434 SPTE table can be configured to translate traffic from multiple 435 customers through one global IPv4 address. Even a small degree of 436 multiplexing, as few as five subscribers through each global IPv4 437 address, would give ISPs sufficient IPv4 address space to continue 438 and grow operations until IPv6 is more fully deployed. 440 9. Setting up state 442 The translation tables in the SPSWE can be set up dynamically by 443 outbound traffic from a CPE. When the SPSWE receives the initial 444 datagram in a new flow, there will be no corresponding IPv4-address/ 445 port pair for that flow in the SPSWE NAT translation table. The NAT 446 selects an unused outbound TCP port, adds the resulting mapping to 447 the NAT translation table, performs the appropriate translation and 448 forwards it to the destination. 450 The resulting table entry is now in place for translation of 451 returning inbound traffic. 453 The translation table can also be configured manually, which would 454 allow, for example, traffic to be forwarded to servers on subscriber 455 networks. However, because multiple subscribers may be supported 456 through a single IPv4 address, only one of those subscribers would be 457 able to have statically assigned external server address through the 458 NAT/softwire. 460 10. Analysis and Future Work 462 There are several opportunities for future work on SNAT: 464 o SNAT requires provisioning of a softwire from each HGW to an 465 SPSWE. This document should include a description of at least one 466 provisioning mechanism. Candidates include a new DHCP option and 467 anycast. 469 o SNAT requires an IPv4-in-IPv6 softwire for each subscriber, and 470 NAT for each flow from the subscriber. What are the effects of 471 scaling this architecture to millions of subscribers? 473 o Security issues have not been considered 475 o How can the configuration of the IPv4-in-IPv6 softwire be 476 automated? 478 o What is the interaction between SNAT and native IPv6 service to 479 the subscriber? 481 11. Change log 483 This section shall be removed prior to publication of this document 484 as an RFC. 486 11.1. Revision -01 488 o Eliminated the NAT function in the HGW, which simplifies 489 forwarding IPv4 datagrams over the IPv6 softwire between the HGW 490 and the SPSWE. 492 o Added DHCP as a mechanism for tunnel endpoint discovery. 494 12. Contributors 496 Mark Townsley suggested elimination of a NAT function in the HGW. 498 Bernie Volz and Carlos Pignataro provided substantive and editorial 499 review of draft-droms-softwires-snat-00. 501 13. IANA Considerations 503 This memo includes no requests to IANA. 505 14. Security Considerations 507 Security considerations must be developed. 509 15. References 511 15.1. Normative References 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, March 1997. 516 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 517 in IPv6", RFC 3775, June 2004. 519 15.2. Informative References 521 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 522 Address Translator (Traditional NAT)", RFC 3022, 523 January 2001. 525 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 526 Problem Statement", RFC 4925, July 2007. 528 Authors' Addresses 530 Ralph Droms 531 Cisco 532 1414 Massachusetts Avenue 533 Boxborough, MA 01714 534 US 536 Phone: +1 978.936.1674 537 Email: rdroms@cisco.com 539 Brian Haberman 540 11100 Johns Hopkins Road 541 Laurel, MD 20723-6099 542 US 544 Phone: +1 443 778 1319 545 Email: brian@innovationslab.net 547 Full Copyright Statement 549 Copyright (C) The IETF Trust (2008). 551 This document is subject to the rights, licenses and restrictions 552 contained in BCP 78, and except as set forth therein, the authors 553 retain all their rights. 555 This document and the information contained herein are provided on an 556 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 557 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 558 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 559 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 560 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 561 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 563 Intellectual Property 565 The IETF takes no position regarding the validity or scope of any 566 Intellectual Property Rights or other rights that might be claimed to 567 pertain to the implementation or use of the technology described in 568 this document or the extent to which any license under such rights 569 might or might not be available; nor does it represent that it has 570 made any independent effort to identify any such rights. Information 571 on the procedures with respect to rights in RFC documents can be 572 found in BCP 78 and BCP 79. 574 Copies of IPR disclosures made to the IETF Secretariat and any 575 assurances of licenses to be made available, or the result of an 576 attempt made to obtain a general license or permission for the use of 577 such proprietary rights by implementers or users of this 578 specification can be obtained from the IETF on-line IPR repository at 579 http://www.ietf.org/ipr. 581 The IETF invites any interested party to bring to its attention any 582 copyrights, patents or patent applications, or other proprietary 583 rights that may cover technology that may be required to implement 584 this standard. Please address the information to the IETF at 585 ietf-ipr@ietf.org.