idnits 2.17.1 draft-ietf-ngtrans-natreq4ipv6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 31 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2460], [RFC2119], [RFC2461], [RFC2462], [RFC2463], [Bradner,1996], [RFC2893], [RFC1918], [RFC2663], [RFC3056]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 210: '...functions will MUST provide the transp...' RFC 2119 keyword, line 224: '...le. If the value is null, the NAT MUST...' RFC 2119 keyword, line 225: '...herwise, the NAT MUST replace the dest...' RFC 2119 keyword, line 230: '...sses, it the NAT SHOULD pick one of th...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 21, 2001) is 8459 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) -- Missing reference section? 'RFC2119' on line 364 looks like a reference -- Missing reference section? 'RFC2663' on line 367 looks like a reference -- Missing reference section? 'RFC1918' on line 373 looks like a reference -- Missing reference section? 'RFC3056' on line 377 looks like a reference -- Missing reference section? 'RFC2460' on line 352 looks like a reference -- Missing reference section? 'RFC2461' on line 355 looks like a reference -- Missing reference section? 'RFC2462' on line 358 looks like a reference -- Missing reference section? 'RFC 2463' on line 197 looks like a reference -- Missing reference section? 'RFC2893' on line 370 looks like a reference -- Missing reference section? 'Bradner' on line 326 looks like a reference -- Missing reference section? '1996' on line 326 looks like a reference -- Missing reference section? 'RFC2463' on line 361 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT C. Huitema, Microsoft 2 3 Expires August 21, 2001 February 21, 2001 5 Short term NAT requirements for IPv6 transition 7 Status of this memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet- Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 During the next few years, as the Ipv4 address space moves toward 31 exhaustion, it is likely that the deployment of NAT will accelerate. 32 By 2005, millions of NAT devices will likely be deployed on the 33 Internet, both within enterprises and consumer households. Should 34 those NAT devices not support either native Ipv6, or IPv6 transition 35 mechanisms such as 6 to 4, the result would be significant delays in 36 the deployment of IPv6. 38 This draft presents the requirements that NAT devices must meet in 39 order to enable a future transition to IPv6. Rather than specifying 40 every aspect of a NAT's operation in detail, our focus is solely on 41 identifying those requirements that are absolutely essential to 42 ensure compatibility with what we believe will be the most popular 43 IPv6 transition mechanisms. 45 1 Introduction 47 During the next few years, as the Ipv4 address space moves toward 48 exhaustion, it is likely that the deployment of NAT will accelerate. 49 By 2005, millions of NAT devices will likely be deployed on the 50 Internet, both within enterprises and consumer households. Should 51 those NAT devices not support either native Ipv6, or IPv6 transition 52 mechanisms such as 6 to 4, the result would be significant delays in 53 the deployment of IPv6. 55 This draft presents the requirements that NAT devices must meet in 56 order to enable a future transition to IPv6. Rather than specifying 57 every aspect of a NAT's operation in detail, our focus is solely on 58 identifying those requirements that are absolutely essential to 59 ensure compatibility with what we believe will be the most popular 60 IPv6 transition mechanisms. 62 1.01 Requirements language 64 In this document, the key words "MAY", "MUST", "MUST NOT", 65 "optional","recommended", "SHOULD", and "SHOULD NOT", are to be 66 interpreted as described in [RFC2119]. 68 1.1 The case for IPv6 transition 70 As described in [NAT Complications] today's NAT devices are 71 relatively successful at supporting TCP/UDP "client" applications 72 which represented the bulk of Internet usage during the 1990s. These 73 applications include Web browsing with HTTP and SSL, FTP, email and 74 DNS. However, the current generation of NAT products has some 75 unfortunate consequences on the users ability to deploy new 76 applications, many of which follow a "peer-to-peer" model, and 77 expect all "clients" to be also able to behave as "servers." Napster 78 is a typical example of one such popular application: the peer-to- 79 peer exchanges of music files cannot take place if both peers are 80 located behind a NAT. With peer-to-peer applications such as NAPSTER 81 now comprising more than 75 percent of Internet traffic in some 82 locations, it has become clear that NAT devices are in danger of 83 retarding the evolution of the Internet. 85 We believe that the proper solution to the NAT problem is to move 86 towards IPv6. We realize that IPv6 cannot be turned on instantly, 87 and thus we also believe that the interim solution will be to enable 88 peer-to-peer applications behind NATs by deploying IPv6 on home 89 networks, and linking these IPv6 islands together using IPv6 90 transition mechanisms such as 6to4. Unfortunately, not only does 91 the continued deployment of the current generation of NAT devices 92 make it more difficult to deploy new applications, but it will also 93 make it difficult to handle the IPv6 transition. We therefore 94 believe that action is required now in order to ensure that the 95 generation of NATs that will be deployed over the next few years is 96 IPv6-friendly. 98 Since we expect that the "IPv6 island" solution will eventually give 99 way to widespread native IPv6 deployment, our approach is designed 100 to be minimally intrusive. Rather than requiring large scale changes 101 to NATs in the short term, we are requiring only a few modest 102 changes to ensure IPv6 transition support. Also, rather than 103 requiring modifications to existing host TCP/IP stacks, we only 104 require minimal modifications to the applications. 106 2 Definitions 108 2.1 NAT 110 As defined in [RFC2663], Network Address Translation is a method by 111 which IP addresses are mapped from one realm to another, in an 112 attempt to provide transparent routing to hosts. Traditionally, NAT 113 devices are used to connect an isolated address realm with private 114 unregistered addresses to an external realm with globally unique 115 registered addresses. 117 2.2 Global IPv4 Internet 119 We use the term "global IPv4 Internet" to designate the fraction of 120 the Internet that uses globally unique IP addresses, and where 121 connectivity to all globally unique addresses is expected. 123 2.3 Private network 125 We use the term "private network" to designate a network that uses 126 private addresses as defined in [RFC1918], and that usually connects 127 to the global IPv4 Internet through a NAT device. 129 2.4 Global IPv6 Internet 131 We use the term "global IPv6 Internet" to designate a network of 132 nodes that are use globally unique IPv6 addresses, and where 133 connectivity to all globally unique addresses is expected. 135 3 Model, requirements 137 The goal of this document is to enable easy deployment of IPv6 in 138 private networks that are connected to the "global IPv4 Internet" 139 through a NAT box. The connection can be performed in one of two 140 ways: 142 * The gateway device can support native IPV6 so that it performs 143 IPV6 routing functions in parallel to the IPv4 Network Address 144 Translation function. 146 * Hosts inside the private network can set up automatic tunnels 147 to reach the IPV6 Internet, using the 6to4 transition mechanism 148 [RFC3056]. 150 The preferred solution is to "upgrade" the connection device, so 151 that it performs IPv6 routing functions in parallel to the IPv4 152 address translation function. The second solution is to allow hosts 153 inside the private network to set up automatic tunnels to reach the 154 global IPv6 internet using the 6to4 technology. 156 The goal of supporting these mechanisms is to enable the interim 157 deployment of "peer-to-peer" applications behind NAT. These 158 applications could possibly be built using either TCP or UDP. The 159 ideal solution would be to enable hosts in private networks to 160 publish a set of global IP addresses and port at which they can 161 receive TCP connection requests and UDP datagrams. 163 4 Description of the solution 165 The proposed solution provides IPv6 support either through a local 166 implementation or through a transparent relay. 168 Our assumption is that IPv6 will be initially deployed by means of 169 "tunnels" over the existing IPv4 infrastructure. The "6to4" strategy 170 [RFC3056] allows users to transform a single IPv4 address into an 171 IPv6 prefix; an almost unlimited number of stations can then obtain 172 globally routable addresses using this prefix. 174 In a NAT environment, this can be instantiated handled in two ways: 176 1) An IPv6 capable NAT implements the "6to4 router" functionality, 177 and appears as an IPv6 router to the local PCs, 179 2) A NAT that has no knowledge of IPv6 transparently passes the IPv4 180 packets that encapsulate IPv6 traffic to a local PC, which will in 181 turn act as an IPv6 router for the local network. 183 We discuss the requirements for each of these approaches in turn. 185 4.1 Requirements for NATs implementing native IPV6 187 A NAT device can support IPv6 by providing the 6to4 relay 188 functionality. In this case, the NAT will construct a 6to4 prefix 189 from one of the global IPv4 addresses that it manages, and will 190 advertise this prefix to the local network. A NAT that has obtained 191 connectivity to the global Internet by other means than "6to4", will 192 advertise the correspondent IPv6 prefix to the local network. 194 If the NAT product chooses to implement IPv6, it should do so 195 according to the relevant IETF standards, including the IPv6 196 Specification [RFC2460], Neighbor Discovery [RFC2461], IPv6 197 Stateless Address Autoconfiguration [RFC2462], and ICMPv6[RFC 2463]. 199 4.2 Requirements for NATs supporting transparent IPV6 tunneling 201 However, in the short term it is likely that NAT devices will only 202 fully implement IPv4, and thus will not be capable of routing IPv6 203 natively. In this case, it is required that the NAT device enables 204 the hosts behind the NAT to utilize IPv6. This can be done if they 205 can support transparent tunneling of IPv6 packets. 207 The tunneling of IPv6 packets into IPv4 is defined in [RFC2893]. The 208 tunneled packets are identified by the protocol type "41" in the 209 IPv4 header. NAT devices that do not implement the "6to4" relaying 210 functions will MUST provide the transparency relay function as 211 follows: 213 1) Define a local variable, LOCAL-IPV6-ROUTER holding the IPv4 214 address of the "local IPv6 router." This variable is initially set 215 to the null address, 0.0.0.0. 217 2) When a packet is sent from a local host for a remote destination, 218 specifying protocol type 41, copy the address of the local host 219 into the LOCAL-IPV6-ROUTER variable. Replace the source address by 220 the external address of the NAT. 222 3) When a packet is sent from a remote source to the global address 223 managed by the NAT for protocol type 41, check the value of the 224 LOCAL-IPV6-ROUTER variable. If the value is null, the NAT MUST 225 reject the packet. Otherwise, the NAT MUST replace the destination 226 address by the value of the LOCAL-IPV6-ROUTER variable, and relay 227 the packet to the corresponding local host. 229 This assumes that the NAT manages a single external address. Where 230 it manages several addresses, it the NAT SHOULD pick one of these 231 addresses as the preferred address for IPv6, and behave as if only 232 this address is available. 234 5 Discussion of the solution 236 Implementing an IPv6 relay in the NAT device obviously enables local 237 hosts to use IPv6. Transparent IPV6 tunneling also enables IPv6, if 238 one of the hosts is designated as the IPv6 route implementing 239 [RFC3056], or if several hosts cooperate using the service. 241 5.1 Single 6to4 router 243 The simplest way to deploy IPv6 behind a NAT providing transparent 244 tunneling is to select one of the local hosts to act as a 6to4 245 relay. This host will have to discover the global address used by 246 the local NAT, construct a 6to4 prefix based on that address, and 247 act as an IPv6 router for the local network. The global address can 248 be discovered either through an interaction with the local NAT, or 249 with the help of a server that has access to the global IPv4 250 Internet; specifying these mechanisms is outside the scope of this 251 memo. 253 The selected router will have to ensure that it sends at least one 254 IPv6 packet to an external target before it can receive tunneled 255 packets. Sending one packet will ensure that the address of the 256 selected router will be copied by the NAT in the LOCAL-IPV6-ROUTER 257 variable, and that the selected router will receive the IPv6 packets 258 sent by external hosts. 260 5.2 Cooperation between multiple hosts 262 It is possible to avoid the selection of a specific router by 263 letting several hosts on the private network act as cooperating 6to4 264 relays. Each of these hosts will discover the global address used by 265 the local NAT, construct a 6to4 prefix based on that address, and 266 act as an IPv6 router for the local network. Any of these routers 267 may receive tunneled packed; they must all be ready to relay over 268 the private network the packets that are bound to other hosts. 270 According to the specified algorithm, tunneled IPv6 packets will be 271 forwarded to the last router that sent an encapsulated IPv6 packet 272 to an external node. If all active routers send packets at regular 273 intervals, this ensures that the packets will be sent by the NAT to 274 an active router, rather than possibly being sent in a black hole 275 created by a failing router. 277 6 Security Considerations 279 6.1 The generic security risks of 6to4 tunneling and the appropriate 280 protections are discussed in [RFC3056]. The transparent IPV6 281 tunneling option introduces an additional vulnerability, since a 282 rogue host on the private network could send tunneled packets at 283 regular intervals, be perceived by the NAT as the selected router, 284 and uses this in a denial of service attack. To protect against 285 this vulnerability, the administrators of private networks must 286 ensure that the local hosts adopt proper behavior. 288 7 IANA Considerations 290 None. 292 8 Copyright 294 The following copyright notice is copied from RFC 2026 [Bradner, 295 1996], Section 10.4, and describes the applicable copyright for this 296 document. 298 Copyright (C) The Internet Society XXX 0, 0000. All Rights Reserved. 300 This document and translations of it may be copied and furnished to 301 others, and derivative works that comment on or otherwise explain it 302 or assist in its implementation may be prepared, copied, published 303 and distributed, in whole or in part, without restriction of any 304 kind, provided that the above copyright notice and this paragraph 305 are included on all such copies and derivative works. However, this 306 document itself may not be modified in any way, such as by removing 307 the copyright notice or references to the Internet Society or other 308 Internet organizations, except as needed for the purpose of 309 developing Internet standards in which case the procedures for 310 copyrights defined in the Internet Standards process must be 311 followed, or as required to translate it into languages other than 312 English. 314 The limited permissions granted above are perpetual and will not be 315 revoked by the Internet Society or its successors or assignees. 317 This document and the information contained herein is provided on an 318 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 319 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 320 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 321 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 322 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 324 9 Intellectual Property 326 The following notice is copied from RFC 2026 [Bradner, 1996], 327 Section 10.4, and describes the position of the IETF concerning 328 intellectual property claims made against this document. 330 The IETF takes no position regarding the validity or scope of any 331 intellectual property or other rights that might be claimed to 332 pertain to the implementation or use other technology described in 333 this document or the extent to which any license under such rights 334 might or might not be available; neither does it represent that it 335 has made any effort to identify any such rights. Information on the 336 IETF's procedures with respect to rights in standards-track and 337 standards-related documentation can be found in BCP-11. Copies of 338 claims of rights made available for publication and any assurances 339 of licenses to be made available, or the result of an attempt made 340 to obtain a general license or permission for the use of such 341 proprietary rights by implementers or users of this specification 342 can be obtained from the IETF Secretariat. 344 The IETF invites any interested party to bring to its attention any 345 copyrights, patents or patent applications, or other proprietary 346 rights which may cover technology that may be required to practice 347 this standard. Please address the information to the IETF Executive 348 Director. 350 10 References 352 [RFC2460] S. Deering, R. Hinden. Internet Protocol, Version 6 (IPv6) 353 Specification. RFC 2460, December 1998. 355 [RFC2461] T. Narten, E. Nordmark, W. Simpson. Neighbor Discovery for 356 IP Version 6 (IPv6). RFC 2461, December 1998. 358 [RFC2462] S. Thomson, T. Narten. IPv6 Stateless Address 359 Autoconfiguration. RFC 2462, December 1998. 361 [RFC2463] A. Conta, S. Deering. Internet Control Message Protocol 362 (ICMPv6) for the Internet. RFC 2463, December 1998. 364 [RFC2119] S. Bradner. Key words for use in RFCs to Indicate 365 Requirement Levels. RFC 2119, March 1997. 367 [RFC2663] P. Srisuresh, M. Holdrege. IP Network Address Translator 368 (NAT) Terminology and Considerations. RFC 2663, August 1999. 370 [RFC2893] R. Gilligan, E. Nordmark. Transition Mechanisms for IPv6 371 Hosts and Routers. RFC 2893, August 2000. 373 [RFC1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot & 374 E. Lear. Address Allocation for Private Internets. RFC 1918, 375 February 1996. 377 [RFC3056] B. Carpenter, K. Moore. Connection of IPv6 Domains via 378 IPv4 Clouds. RFC 3056, February 2001. 380 [NAT Complications] M. Holdrege, P. Srisuresh. Protocol 381 Complications with the IP Network Address Translator. Work in 382 Progress. 384 11 Authors' Addresses 386 Christian Huitema 387 Microsoft Corporation 388 One Microsoft Way 389 Redmond, WA 98052-6399 391 Email: huitema@microsoft.com