idnits 2.17.1 draft-durand-v6ops-natv4v6v4-00.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 245. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 256. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 269. 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 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 (November 12, 2007) is 6009 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC1918' is mentioned on line 152, but not defined Summary: 1 error (**), 0 flaws (~~), 3 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 November 12, 2007 5 Expires: May 15, 2008 7 Non dual-stack IPv6 deployments for broadband providers 8 draft-durand-v6ops-natv4v6v4-00 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 May 15, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The common thinking for the last 10+ years has been to say that dual 42 stack was the answer to v6 transition and that most things would be 43 converted to dual stack way before we ran out of v4. 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 occur. As a result, 46 broadband deployments now need to contemplate IPv6-only provisioning 47 and NAT as a classic solution to maintain some form of connectivity 48 between those environments and the legacy Internet. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 54 2. IPv4 exhaustion coming sooner than expected . . . . . . . . . . 3 55 3. Handling the legacy . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Legacy edges of the Internet for broadband customers . . . 3 57 3.2. Content and Services available on the Internet . . . . . . 4 58 3.3. Burden on service providers . . . . . . . . . . . . . . . . 4 59 4. Solution space . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.2. Double IPv4->IPv4->IPv4 NAT . . . . . . . . . . . . . . . . 4 62 4.3. Double IPv4->IPv6->IPv4 NAT . . . . . . . . . . . . . . . . 5 63 4.4. Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 67 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 Intellectual Property and Copyright Statements . . . . . . . . . . 7 71 1. Introduction 73 This memo will present a service provider view on IPv6 deployment and 74 some of the necessary technologies to achieve it. 76 1.1. Requirements Language 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC 2119 [RFC2119]. 82 2. IPv4 exhaustion coming sooner than expected 84 Global public IPv4 addresses coming from the IANA free pool are 85 running out faster than predicted a few years ago. The current model 86 shows that exhaustion could happen as early as 2010. See 87 http://ipv4.potaroo.net for more details. Those projection ares 88 based on the assumption that tomorrow is going to be very similar to 89 today, ie looking at recent address consumption figures is a good 90 indicator of future consumption patterns. This of course, does not 91 take into account any new large scale deployment of IP technology or 92 any human reaction when facing an upcoming shortage. 94 The prediction of the exact date of exhaustion of the IANA free pool 95 is outside the scope of this document, however one conclusion must be 96 drawn from that study: there will be in the near future a point where 97 new global public IPv4 addresses will not be available and thus any 98 new broadband deployment may have to consider the option of not 99 provisioning any IPv4 addresses to the WAN facing interface of edge 100 devices. The IPv6 deployment model known as "dual stack" can be a 101 non starter in such environments. 103 3. Handling the legacy 105 3.1. Legacy edges of the Internet for broadband customers 107 Broadband customers have a mix and match of IP enable devices at 108 home. The most recent operating systems (eg Windows Vista or 109 MacOS-X) can operate in an IPv6-only environment, however most of the 110 legacy one can't. It has been reported, for example, that windows XP 111 cannot process DNS requests over IPv6 transport. Expecting broadband 112 customers to massively upgrade their software (and in most cases the 113 corresponding hardware) to deploy IPv6 is a very tall order. 115 3.2. Content and Services available on the Internet 117 IPv6 deployment has been very long to take off, so the current 118 situation is that almost none of the content and services available 119 on the Internet are accessible over IPv6. This will probably change 120 in the future, but for now, one has to make the assumption that most 121 of the traffic generated by (and to) broadband customers will be sent 122 to (and originated by) IPv4 nodes. 124 3.3. Burden on service providers 126 As a conclusion, broadband service providers may be faced with the 127 situation where they have IPv4 customers willing to communicate with 128 IPv4 servers on the Internet but may not have any IPv4 addresses left 129 to assign to them... 131 4. Solution space 133 A number of solution can be studied in that space: IPv6-only, double 134 IPv4>IPv4->IPv4 NAT, double IPv4->IPv6->IPv4 NAT, and IPv4 over IPv6 135 tunneling. 137 4.1. IPv6-only 139 The first solution that comes to mind is simply to provision new 140 broadband customers with only IPv6 addresses. However, two immediate 141 issues come to mind: 143 a. Legacy devices in the customer home will not be able to 144 communicate with the outside. 146 b. New IPv6-only capable devices will not be able to communicate 147 with legacy IPv4-only servers in the Internet. 149 4.2. Double IPv4->IPv4->IPv4 NAT 151 This solution consists of provisioning broadband customers with a 152 private [RFC1918] address on the WAN side of the home gateway, and 153 then translate this private IPv4 address somewhere within the service 154 provider network into a global IPv4 address. Devices behind the home 155 gateway will then be translated twice, once by the home gateway 156 itself, and another time by the NAT within the service provider. 158 This solution has the advantage of reducing the total number of 159 global IPv4 addresses needed by consolidating the traffic of multiple 160 customers on a unique IPv4 addresses. The first drawback is that 161 some applications may have a more difficult time going through two 162 levels of NAT. Another drawback that can be a show stopper is that 163 this solution limits the number of customer within an access network 164 to the size of net 10, ie somewhere between 10 and 16 million 165 depending on address efficiency. Note that very large networks such 166 as Comcast have already ran out of RFC1918 space a few years ago. 168 4.3. Double IPv4->IPv6->IPv4 NAT 170 When private address space is running out as well, the next step is 171 to have the home gateway translate internal RFC1918 space into global 172 IPv6 addresses. However, as the final destination may not be 173 configured with IPv6, those packets will have to be translated a 174 second time into IPv4 packets. This second translation will have to 175 occur within the service provider network. 177 The implications of this second level of translation is very similar 178 to those in the model above of a double IPv4->IPv4->IPv4 translation. 179 There will be a need for a far of translator within the service 180 provider network operating at line speed. Some applications may have 181 a harder time working through a second level of NAT. On top of that, 182 some MTU adaptation will have to take place to accommodate for the 183 longer IPv6 header. 185 4.4. Tunneling 187 When IPv6-only connectivity is offered to the customer, one could be 188 tempted to look at IPv4 over IPv6 tunnels to re-establish 189 connectivity for the legacy IPv4 hosts. The Softwire hub and spoke 190 solution, based on L2TP tunnels could be the perfect candidate in 191 that space. 193 However, the main drawback of that solution is that it would require 194 an IPv4 address to be configured on that tunnel. More, that address 195 could not be shared among subscribers. As such, this solution would 196 not consume less IPv4 addresses than a regular dual-stack deployment 197 and will be be a non starter in environment where IPv4 addresses are 198 rare. 200 5. Acknowledgements 202 Send the author comments if you want your name listed here. 204 6. IANA Considerations 206 This memo includes no request to IANA. 208 This draft does not request any IANA action. 210 7. Security Considerations 212 Security issues associated with NAT have long been documented. A 213 future version of this document may include some references here to 214 previous work. 216 8. Normative References 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, March 1997. 221 Author's Address 223 Alain Durand 224 Comcast 225 1500 Market st 226 Philadelphia, PA 19102 227 USA 229 Email: alain_durand@cable.comcast.com 231 Full Copyright Statement 233 Copyright (C) The IETF Trust (2007). 235 This document is subject to the rights, licenses and restrictions 236 contained in BCP 78, and except as set forth therein, the authors 237 retain all their rights. 239 This document and the information contained herein are provided on an 240 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 241 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 242 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 243 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 244 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 245 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 247 Intellectual Property 249 The IETF takes no position regarding the validity or scope of any 250 Intellectual Property Rights or other rights that might be claimed to 251 pertain to the implementation or use of the technology described in 252 this document or the extent to which any license under such rights 253 might or might not be available; nor does it represent that it has 254 made any independent effort to identify any such rights. Information 255 on the procedures with respect to rights in RFC documents can be 256 found in BCP 78 and BCP 79. 258 Copies of IPR disclosures made to the IETF Secretariat and any 259 assurances of licenses to be made available, or the result of an 260 attempt made to obtain a general license or permission for the use of 261 such proprietary rights by implementers or users of this 262 specification can be obtained from the IETF on-line IPR repository at 263 http://www.ietf.org/ipr. 265 The IETF invites any interested party to bring to its attention any 266 copyrights, patents or patent applications, or other proprietary 267 rights that may cover technology that may be required to implement 268 this standard. Please address the information to the IETF at 269 ietf-ipr@ietf.org. 271 Acknowledgment 273 Funding for the RFC Editor function is provided by the IETF 274 Administrative Support Activity (IASA).