idnits 2.17.1 draft-durand-v6ops-natv4v6v4-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 340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 364. 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 1 instance 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. 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 (February 24, 2008) is 5906 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC1918' is mentioned on line 161, but not defined Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Durand 3 Internet-Draft Comcast 4 Intended status: Informational February 24, 2008 5 Expires: August 27, 2008 7 Distributed NAT for broadband deployments post IPv4 exhaustion 8 draft-durand-v6ops-natv4v6v4-01 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 August 27, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 The common thinking for the last 10+ years has been to say that dual 42 stack was the answer to IPv6 transition and that most things would be 43 converted to dual stack way before we ran out of IPv4. Well, it has 44 not happened. We are going to run out of IPv4 addresses soon, way 45 before any significant IPv6 deployment will have occured. However, 46 the quasi totality of the Internet and most of the computers in the 47 home are still IPv4-only. Several distributed NAT architectures, 48 based on different possible flavors of a carrier-grade NAT, are 49 presented as solutions to maintain some form of connectivity between 50 those home environments and the legacy Internet. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 56 2. IPv4 exhaustion coming sooner than expected . . . . . . . . . . 3 57 3. Handling the legacy . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Legacy edges of the Internet for broadband customers . . . 3 59 3.2. Content and Services available on the Internet . . . . . . 4 60 3.3. Burden on service providers . . . . . . . . . . . . . . . . 4 61 4. Solution space . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.2. Double IPv4->IPv4->IPv4 NAT . . . . . . . . . . . . . . . . 4 64 4.3. Double IPv4->IPv6->IPv4 NAT . . . . . . . . . . . . . . . . 5 65 4.4. IPv6 Tunneling plus carrier-grade IPv4->IPv4 NAT . . . . . 6 66 5. Carrier-grade NAT considerations . . . . . . . . . . . . . . . 6 67 6. Standardization considerations . . . . . . . . . . . . . . . . 7 68 7. Multicast considerations . . . . . . . . . . . . . . . . . . . 7 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 72 11. Normative References . . . . . . . . . . . . . . . . . . . . . 8 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 Intellectual Property and Copyright Statements . . . . . . . . . . 9 76 1. Introduction 78 This memo will present a service provider view on deployments post 79 IPv4 exhaustion and some of the necessary technologies to achieve it. 81 1.1. Requirements Language 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [RFC2119]. 87 2. IPv4 exhaustion coming sooner than expected 89 Global public IPv4 addresses coming from the IANA free pool are 90 running out faster than predicted a few years ago. The current model 91 shows that exhaustion could happen as early as 2010. See 92 http://ipv4.potaroo.net for more details. Those projection are based 93 on the assumption that tomorrow is going to be very similar to today, 94 ie looking at recent address consumption figures is a good indicator 95 of future consumption patterns. This of course, does not take into 96 account any new large scale deployment of IP technology or any human 97 reaction when facing an upcoming shortage. 99 The prediction of the exact date of exhaustion of the IANA free pool 100 is outside the scope of this document, however one conclusion must be 101 drawn from that study: there will be in the near future a point where 102 new global public IPv4 addresses will not be available and thus any 103 new broadband deployment may have to consider the option of not 104 provisioning any (global) IPv4 addresses to the WAN facing interface 105 of edge devices. The classic IPv6 deployment model known as "dual 106 stack" can be a non starter in such environments. 108 3. Handling the legacy 110 3.1. Legacy edges of the Internet for broadband customers 112 Broadband customers have a mix and match of IP enable devices at 113 home. The most recent operating systems (eg Windows Vista or 114 MacOS-X) can operate in an IPv6-only environment, however most of the 115 legacy one can't. It has been reported, for example, that windows XP 116 cannot process DNS requests over IPv6 transport. Expecting broadband 117 customers to massively upgrade their software (and in most cases the 118 corresponding hardware) to deploy IPv6 is a very tall order. 120 3.2. Content and Services available on the Internet 122 IPv6 deployment has been very long to take off, so the current 123 situation is that almost none of the content and services available 124 on the Internet are accessible over IPv6. This will probably change 125 in the future, but for now, one has to make the assumption that most 126 of the traffic generated by (and to) broadband customers will be sent 127 to (and originated by) IPv4 nodes. 129 3.3. Burden on service providers 131 As a conclusion, broadband service providers may be faced with the 132 situation where they have IPv4 customers willing to communicate with 133 IPv4 servers on the Internet but may not have any IPv4 addresses left 134 to assign to them... 136 4. Solution space 138 A number of solutions can be studied: IPv6-only, double 139 IPv4>IPv4->IPv4 NAT, double IPv4->IPv6->IPv4 NAT, and IPv4 over IPv6 140 tunneling plus carrier grade IPv4->IPv4 NAT. All of them are 141 essentially a variation on the theme of a distributed NAT where 142 instead of provisioning each broadband customer with a unique global 143 IPv4 address, global IPv4 addresses are share among broadband 144 customers. 146 4.1. IPv6-only 148 The first solution that comes to mind is to simply provision new 149 broadband customers with only IPv6 addresses. However, two immediate 150 issues come to mind: 152 a. Legacy devices in the customer home will not be able to 153 communicate with the outside. 155 b. New IPv6-only capable devices will not be able to communicate 156 with legacy IPv4-only servers in the Internet. 158 4.2. Double IPv4->IPv4->IPv4 NAT 160 This solution consists of provisioning broadband customers with a 161 private [RFC1918] address on the WAN side of the home gateway, and 162 then translate this private IPv4 address somewhere within the service 163 provider network by a carrier grade NAT into a global IPv4 address. 164 Devices behind the home gateway will then be translated twice, once 165 by the home gateway itself, and another time by the NAT within the 166 service provider. 168 This solution has the advantage of being simple to understand and is 169 the easiest to deploy in the home. It has however a number of 170 drawbacks. 172 The first drawback is that some applications may have a more 173 difficult time going through the two levels of NAT. Application 174 relying on port mapping or port opening using UPnP may not work as 175 expected as the carrier grade NAT may not allow those NAT traversal 176 techniques. Note that this drawback is not specific to this 177 solution, it is tied to the presence of a carrier-grade NAT in the 178 architecture. 180 Another drawback is that this solution limits the number of customer 181 within an access network to the size of net 10, ie somewhere between 182 10 and 16 million depending on address efficiency. Note that very 183 large networks such as Comcast have already ran out of RFC1918 space 184 a few years ago. A possible way to get around this problem is for 185 the service provider to run several instances of net 10, one per 186 "regional area". However, there are serious operational issues with 187 this, especially if the service provider is running a unified 188 backbone and a unified set of services. 190 A third drawback of this solution is that it can potentially create a 191 conflict on the home gateway if the same variant of RFC1918 space is 192 used on the WAN port and the LAN port. For example, if both the WAN 193 port and the LAN port are configured with 10.0.0.1/24, some NAT 194 implementations may get confused. 196 4.3. Double IPv4->IPv6->IPv4 NAT 198 When private address space is running out and/or the service provider 199 does not want to run multiple copies of net 10, the next step is to 200 to provision the home gateway only with an IPv6 address and 201 associated prefix and let that home gateway translate internal 202 RFC1918 space into global IPv6 addresses. However, as the final 203 destination may not be configured to accept IPv6 connections, those 204 packets will have to be translated a second time into IPv4 packets. 206 The first translation hapening in the home gateway can be very 207 straightforward and in most cases stateless. This consists in header 208 swapping and embedding the source & destination IPv4 addresses within 209 source & destination IPv6 addresses. The prefix used to embed the 210 source address can be any sub-prefix of the one delegated to the home 211 gateway. The prefix used to embed the destination address is used to 212 route the IPv6 packets to the local farm of IPv6->IPv4 translator 213 within the service provider network. The discovery of that second 214 prefix by the home gateway can be achive in many ways, for example 215 through a DHCPv6 option yet to be defined. 217 The second translation will have to occur within the service provider 218 network in a carrier-grade IPv6->IPv4 NAT. This translation is a 219 traditional NAT that requires keeping track of IP addresses and port 220 numbers allocated. 222 The implications of this second level of translation are very similar 223 to those in the model above of a double IPv4->IPv4->IPv4 translation. 224 There will be a need for a farm of translators within the service 225 provider network operating at line speed. Some applications may have 226 a harder time working through the carrier-grade NAT. On top of that, 227 some MTU adaptation will have to take place to accommodate for the 228 longer IPv6 header. 230 Another issue with this approach is the role of ALGs. Although 231 IPv4->IPv4 ALGs are now fairly well understood, there is little 232 experience with IPv4->IPv6 or IPv6->IPv4 ALGs. One of the questions 233 raised is, should the first home NAT, translating from IPv4 to IPv6, 234 also use IPv4->IPv6 ALGs to translate the payload addresses to IPv6, 235 or should it leave them in IPv4 format, knowing that the carrier- 236 grade NAT will anyway translate them back to IPv4? 238 4.4. IPv6 Tunneling plus carrier-grade IPv4->IPv4 NAT 240 When IPv6-only connectivity is offered to the customer, one can look 241 at IPv4 over IPv6 tunnels to re-establish connectivity for the legacy 242 IPv4 hosts. The Softwire hub and spoke solution, based on L2TP 243 tunnels could be the perfect candidate in that space. 245 The caveat is that this technique alone is not enough, the service 246 provider still needs to assign one IPv4 address per customer. One 247 need to collocate a carrier-grade NAT with the tunnel concentrator 248 within the service provider. In that solution, the IPv4 private 249 addresses generated inside of the customer network would be 250 transported (and not translated) within IPv6 packets across the 251 service provider network to be decapsulated and then translated 252 IPv4->IPv4 by the combined tunnel concentrator/carrier-grade NAT. 254 Note that, as in the above solutions, the presence of a carrier-grade 255 NAT will break some NAT traversal techniques 257 5. Carrier-grade NAT considerations 259 One constant element in the architecture of all the above solution is 260 the presence of a carrier-grade NAT, either IPv4->IPv4 or IPv6->IPv4. 261 As some traditional NAT traversal techniques will stop working, this 262 will have consequences on the set of applications that can be run in 263 IPv4 mode. 265 Also, because IPv4 addresses will be share among customers and 266 potentially a large address space reduction factor may be applied, in 267 average, only a limited number of TCP or UDP port numbers will be 268 available per customer. This means that applications opening a very 269 large number of TCP ports may have a harder time to work. For 270 example, it has been reported that a very well know web site was 271 using AJAX techniques and was opening up to 69 TCP ports per web 272 page... If we make the hypothesis of an address space reduction of a 273 factor 100 (one IPv4 address per 100 customers), a home with 10 PCs, 274 and 65k ports per IPv4 addresses available, that makes a total of 65 275 ports available simultaneously for each PC, which is right on the 276 edge of the number reported above for that well known application... 278 6. Standardization considerations 280 Any of the above solution could work. The double NAT IPv4>IPv4->IPv4 281 does not require any standard effort nor any new code in order to be 282 deployed. However, dealing with multiple copies of net 10 may be a 283 show stopper for large service providers, as the opex associated may 284 be high. Both the double NAT IPv4->IPv6->IPv4 and IPv6 tunneling 285 plus carrier-grade IPv4->IPv4 NAT may require some new code in the 286 home gateways. Thus some standardization on a framework how to use 287 these techniques is required. 289 7. Multicast considerations 291 This document only describes unicast IPv4. Some multicast IPv4 292 considerations need to be discussed as well. This section is a 293 placeholder. 295 8. Acknowledgements 297 Send the author comments if you want your name listed here. 299 9. IANA Considerations 301 This memo includes no request to IANA. 303 This draft does not request any IANA action. 305 10. Security Considerations 307 Security issues associated with NAT have long been documented. A 308 future version of this document may include some references here to 309 previous work. 311 11. Normative References 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, March 1997. 316 Author's Address 318 Alain Durand 319 Comcast 320 1500 Market st 321 Philadelphia, PA 19102 322 USA 324 Email: alain_durand@cable.comcast.com 326 Full Copyright Statement 328 Copyright (C) The IETF Trust (2008). 330 This document is subject to the rights, licenses and restrictions 331 contained in BCP 78, and except as set forth therein, the authors 332 retain all their rights. 334 This document and the information contained herein are provided on an 335 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 336 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 337 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 338 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 339 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 340 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 342 Intellectual Property 344 The IETF takes no position regarding the validity or scope of any 345 Intellectual Property Rights or other rights that might be claimed to 346 pertain to the implementation or use of the technology described in 347 this document or the extent to which any license under such rights 348 might or might not be available; nor does it represent that it has 349 made any independent effort to identify any such rights. Information 350 on the procedures with respect to rights in RFC documents can be 351 found in BCP 78 and BCP 79. 353 Copies of IPR disclosures made to the IETF Secretariat and any 354 assurances of licenses to be made available, or the result of an 355 attempt made to obtain a general license or permission for the use of 356 such proprietary rights by implementers or users of this 357 specification can be obtained from the IETF on-line IPR repository at 358 http://www.ietf.org/ipr. 360 The IETF invites any interested party to bring to its attention any 361 copyrights, patents or patent applications, or other proprietary 362 rights that may cover technology that may be required to implement 363 this standard. Please address the information to the IETF at 364 ietf-ipr@ietf.org. 366 Acknowledgment 368 Funding for the RFC Editor function is provided by the IETF 369 Administrative Support Activity (IASA).