idnits 2.17.1 draft-ietf-ipngwg-6over4-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 7) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 15 characters in excess of 72. ** The abstract seems to contain references ([IPV6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 1998) is 9318 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: 'RFC2119' is mentioned on line 102, but not defined == Unused Reference: 'CONF' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 357, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. 'AARCH') (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. 'CONF' -- Possible downref: Non-RFC (?) normative reference: ref. 'DISC' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPV6' Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF B. Carpenter, IBM 2 Internet Draft C. Jung, 3Com 3 October 1998 5 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels 7 draft-ietf-ipngwg-6over4-00.txt 8 (revised from draft-carpenter-ipng-6over4-04.txt) 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute 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 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 "work in progress." 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 Copyright Notice 32 Copyright (C) The Internet Society (1998). All Rights Reserved. 34 Abstract 36 This memo specifies the frame format for transmission of IPv6 [IPV6] 37 packets and the method of forming IPv6 link-local addresses over IPv4 38 domains. It also specifies the content of the Source/Target Link- 39 layer Address option used in the Router Solicitation, Router 40 Advertisement, Neighbor Solicitation, and Neighbor Advertisement 41 and Redirect messages, when those messages are transmitted on an 42 IPv4 network. 44 The motivation for this method is to allow isolated IPv6 hosts, 45 located on a physical link which has no directly connected IPv6 46 router, to become fully functional IPv6 hosts by using an IPv4 47 domain that supports IPv4 multicast as their virtual local 48 link. It uses IPv4 multicast as a "virtual Ethernet." 50 ^L 52 Table of Contents: 54 1. Introduction....................................................2 55 2. Maximum Transmission Unit.......................................3 56 3. Frame Format....................................................3 57 4. Stateless Autoconfiguration and Link-Local Addresses............4 58 5. Address Mapping -- Unicast......................................4 59 6. Address Mapping -- Multicast....................................5 60 7. Mechanism in the absence of IPv4 multicast......................5 61 8. Scaling and Transition Isues....................................5 62 9. Security considerations.........................................6 63 Acknowledgements...................................................7 64 References.........................................................7 65 APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery........8 66 Authors' Addresses.................................................9 67 Full Copyright Notice..............................................9 69 1. Introduction 71 This memo specifies the frame format for transmission of IPv6 [IPV6] 72 packets and the method of forming IPv6 link-local addresses over IPv4 73 "domains". For the purposes of this document, an IPv4 domain is a 74 | fully interconnected set of IPv4 subnets, within the same local 75 | multicast scope, on which there are at least two IPv6 nodes 76 conforming to this specification. This IPv4 domain could form part of the globally- 77 unique IPv4 address space, or could form part of a private IPv4 78 network [RFC 1918]. 80 This memo also specifies the content of the Source/Target Link-layer 81 Address option used in the Router Solicitation, Router Advertisement, 82 Neighbor Solicitation, Neighbor Advertisement and Redirect messages 83 described in [DISC], when those messages are transmitted on an IPv4 84 domain. 86 The motivation for this method is to allow isolated IPv6 hosts, 87 located on a physical link which has no directly connected IPv6 88 router, to become fully functional IPv6 hosts by using an IPv4 domain 89 as their virtual local link. Thus, at least one IPv6 router using 90 the same method must be connected to the same IPv4 domain if IPv6 91 routing to other links is required. 93 IPv6 hosts connected using this method do not require IPv4-compatible 94 addresses or configured tunnels. In this way IPv6 gains considerable 95 independence of the underlying links and can step over many hops of 96 | IPv4 subnets. The mechanism is known formally as "IPv6 over IPv4" 97 | or "6over4" and colloquially as "virtual Ethernet." 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 ^L 105 2. Maximum Transmission Unit 107 The default MTU size for IPv6 packets on an IPv4 domain is 1480 108 octets. This size may be varied by a Router Advertisement [DISC] 109 containing an MTU option which specifies a different MTU, or by 110 manual configuration of each node. 112 Note that if by chance the IPv6 MTU size proves to be too large for 113 some intermediate IPv4 subnet, IPv4 fragmentation will ensue. While 114 | undesirable, this is not disastrous. However, the IPv4 "do not fragment" 115 | bit MUST NOT be set in the encapsulating IPv4 header. 117 3. Frame Format 119 IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv4 120 protocol type of 41, the same as has been assigned in RFC 1933 for 121 IPv6 packets that are tunneled inside of IPv4 frames. The IPv4 122 header contains the Destination and Source IPv4 addresses. The IPv4 123 packet body contains the IPv6 header followed immediately by the 124 payload. 126 0 1 2 3 127 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 |Version| IHL |Type of Service| Total Length | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Identification |Flags| Fragment Offset | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Time to Live | Protocol 41 | Header Checksum | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Source Address | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Destination Address | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Options | Padding | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | IPv6 header and payload ... / 142 +-------+-------+-------+-------+-------+------+------+ 144 If there are IPv4 options, then padding SHOULD be added to the IPv4 145 header such that the IPv6 header starts on a boundary that is a 32- 146 bit offset from the end of the datalink header. 148 The Time to Live field SHOULD be set to a low value, to prevent such 149 packets accidentally leaking from the IPv4 domain. This MUST be a 150 configurable parameter, with a recommended default of 8. 152 ^L 154 4. Stateless Autoconfiguration and Link-Local Addresses 156 The Interface Identifier [AARCH] of an IPv4 interface is the 32-bit 157 IPv4 address of that interface, with the octets in the same order in 158 which they would appear in the header of an IPv4 packet, padded at 159 the left with zeros to a total of 64 bits. Note that the "Universal/ 160 Local" bit is zero, indicating that the Interface Identifer is not 161 globally unique. When the host has more than one IPv4 address in use 162 on the physical interface concerned, an administrative choice of one 163 of these IPv4 addresses is made. 165 An IPv6 address prefix used for stateless autoconfiguration of an 166 | IPv4 interface MUST have a length of 64 bits except for a special 167 | case mentioned in Section 8. 169 The IPv6 Link-local address [AARCH] for an IPv4 virtual interface is 170 formed by appending the Interface Identifier, as defined above, to 171 the prefix FE80::/64. 173 +-------+-------+-------+-------+-------+-------+------+------+ 174 | FE 80 00 00 00 00 00 00 | 175 +-------+-------+-------+-------+-------+-------+------+------+ 176 | 00 00 | 00 | 00 | IPv4 Address | 177 +-------+-------+-------+-------+-------+-------+------+------+ 179 5. Address Mapping -- Unicast 181 The procedure for mapping IPv6 addresses into IPv4 virtual link-layer 182 addresses is described in [DISC]. The Source/Target Link-layer 183 Address option has the following form when the link layer is IPv4. 184 Since the length field is in units of 8 bytes, the value below is 1. 186 +-------+-------+-------+-------+-------+-------+-------+-------+ 187 | Type |Length | must be zero | IPv4 Address | 188 +-------+-------+-------+-------+-------+-------+-------+-------+ 190 Type: 191 1 for Source Link-layer address. 192 2 for Target Link-layer address. 194 Length: 195 1 (in units of 8 octets). 197 IPv4 Address: 199 The 32 bit IPv4 address, in network byte order. This is the address 200 the interface currently responds to, and may be different from the 201 Interface Identifier for stateless autoconfiguration. 203 ^L 205 6. Address Mapping -- Multicast 207 If IPv4 multicast is available, an IPv6 packet with a multicast 208 destination address DST MUST be transmitted to the IPv4 multicast 209 address of Organization-Local Scope using the mapping below. These 210 IPv4 multicast addresses SHOULD be taken from the block 239.192.0.0/16, 211 a sub-block of the Organization-Local Scope address block, or, if 212 all of those are not available, from the expansion blocks 213 | defined in [ADMIN]. Note that when they are formed 214 using the expansion blocks, they use only a /16 sized block. 216 +-------+-------+-------+-------+ 217 | 239 | OLS | DST14 | DST15 | 218 +-------+-------+-------+-------+ 220 DST14, DST15 last two bytes of IPv6 multicast address. 222 OLS from the configured Organization-Local 223 | Scope address block. SHOULD be 192, 224 | see [ADMIN] for details. 226 | No new IANA registration procedures are required for the above. 227 See appendix A. for a list of all the multicast groups that must be 228 joined to support Neighbor Discovery. 230 7. Mechanism in the absence of IPv4 multicast 232 It is strongly RECOMMENDED to use IPv4 multicast as described above, 233 and this MUST be the default configuration in implementations. 234 However, if the IPv4 domain does not support IPv4 multicast, a 235 unicast technique is possible. 237 In this case the IPv6 router will handle IPv6 multicast packets by 238 | replication and IPv4 unicast encapsulation to each relevant IPv6 239 destination (i.e., all those that have joined the IPv6 multicast 240 group), since the mapping onto an IPv4 multicast address is not 241 | available. Similarly, 6over4 hosts will unicast to the router. 243 8. Scaling and Transition Isues 245 The multicast mechanism described in Section 6 above appears to have 246 essentially the same scaling properties as native IPv6 over most 247 media, except for the slight reduction in MTU size which will 248 slightly reduce bulk throughput. On an ATM network, where IPv4 249 multicast relies on relatively complex mechanisms, it is to be 251 ^L 252 expected that IPv6 over IPv4 over ATM will perform less well than 253 native IPv6 over ATM. 255 The unicast mechanism described in Section 7, if used to 256 support IPv6 multicast, will not scale well and should be used only 257 for a small number of IPv6 hosts. For IPv6 unicast traffic, it will 258 have similar scaling properties to configured tunnels. 260 The "IPv6 over IPv4" mechanism is intended to take its place in the 261 range of options available for transition from IPv4 to IPv6. In 262 particular it allows a site to run both IPv4 and IPv6 in coexistence, 263 without having to configure IPv6 hosts either with IPv4-compatible 264 addresses or with tunnels. Interfaces of the IPv6 router and hosts 265 will of course need to be enabled in "6over4" mode. 267 A site may choose to start its IPv6 transition by configuring one 268 IPv6 router to support "6over4" on an interface connected to 269 the site's IPv4 domain, and another IPv6 format on an interface 270 connected to the IPv6 Internet. Any enabled "6over4" hosts 271 in the IPv4 domain will then be able to communicate both with the 272 router and with the IPv6 Internet, without manual configuration of a 273 tunnel and without the need for an IPv4-compatible IPv6 address, 274 either stateless or stateful address configuration providing the IPv6 275 address to the IPv6 host. 277 | During transition, routers may need to advertise at least two 278 | IPv6 prefixes, one for the native LAN (e.g. Ethernet) and one for 279 | "6over4." As with any IPv6 prefix assigned to an IPv6 subnet, the 280 | latter MUST be unique within its scope, whether site-local or 281 | global addressing is used. 283 | Also note that when a router is handling both native LAN and 284 | "6over4" on the same physical interface, during 285 | stateless autoconfiguration, there is a period when IPv6 link-local 286 | addresses are used, in both cases with the prefix FE80::/64. 287 | Note that the prefix-length for these link-local adddress MUST 288 | then be 128 so that the two cases can be distinguished. 290 As the site installs additional IPv6 routers, "6over4" hosts 291 which become physically adjacent to IPv6 routers can be changed to 292 run as native IPv6 hosts, with the the only impact on IPv6 293 applications being a slight increase in MTU size. At some stage 294 | during transition, it might be convenient to dual home hosts 295 | in both native LAN and "6over4" mode, but this is not required. 297 9. Security considerations 299 Implementors should be aware that, in addition to posssible attacks 300 against IPv6, security attacks against IPv4 must also be considered. 302 ^L 303 Use of IP security at both IPv4 and IPv6 levels should nevertheless 304 be avoided, for efficiency reasons. For example, if IPv6 is running 305 encrypted, encryption of IPv4 would be redundant except if traffic 306 analysis is felt to be a threat. If IPv6 is running authenticated, 307 then authentication of IPv4 will add little. Conversely, IPv4 308 security will not protect IPv6 traffic once it leaves the IPv6-over- 309 IPv4 domain. Therefore, implementing IPv6 security is required even 310 if IPv4 security is available. 312 | There is a possible spoofing attack in which spurious 6over4 313 | packets are injected into a 6over4 domain from outside. Thus, 314 | boundary routers MUST discard multicast IPv4 packets with source 315 | or destination multicast addresses of organisation local scope 316 | as defined in section 6 above, if they arrive on physical 317 | interfaces outside that scope. To defend against spurious 318 | unicast 6over4 packets, boundary routers MUST discard incoming 319 | IPv4 packets with protocol type 41 from unknown sources, i.e. 320 | IPv6-in-IPv4 tunnels must only be accepted from trusted sources. 321 | Unless IPSEC authentication is available, the RECOMMENDED technique 322 | for this is an access control list. 324 Acknowledgements 326 The basic idea presented above is not original, and we have had 327 invaluable comments from Matt Crawford, Steve Deering, Dan 328 Harrington, Rich Draves, Erik Nordmark, Quang Nguyen, and 329 other members of the IPNG and NGTRANS working groups. 331 This document is seriously ripped off from RFC 1972 written by 332 Matt Crawford. Brian Carpenter was at CERN when the work was started. 334 References 336 [AARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing 337 Architecture", RFC 2373 339 [ADMIN] Meyer, D., "Administratively Scoped IP Multicast", 340 RFC 2365, BCP 23. 342 [CONF] Thomson, S., and T. Narten, "IPv6 Stateless Address 343 Autoconfiguration", RFC xxxx (1971 update) 345 [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 346 Discovery for IP Version 6 (IPv6)", RFC xxxx (1970 update) 348 [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 349 (IPv6) Specification", RFC xxxx (1883 update) 351 [RFC 791] Postel, J., "Internet Protocol", RFC 791 353 [RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., 354 Lear, E., "Address Allocation for Private Internets", 355 RFC 1918 357 [RFC 2119] Key words for use in RFCs to Indicate Requirement Levels. 358 S. Bradner, RFC 2119 360 ^L 362 APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery 364 The following IPv4 multicast groups are used to support Neighbor 365 Discovery with this specification. 367 all-nodes multicast address 368 - the administratively-scoped IPv4 multicast address used to 369 reach all nodes in the local IPv4 domain supporting this 370 specification. 239.OLS.0.1 372 all-routers multicast address 373 - the administratively-scoped IPv4 multicast address to reach 374 all routers in the local IPv4 domain supporting this 375 specification. 239.OLS.0.2 377 solicited-node multicast address 378 - an administratively scoped multicast address that is computed 379 as a function of the solicited target's address by taking the 380 IPv4 address used to form the IPv6 address and prepending the 381 96-bit prefix FF02:0:0:0:0:1. This is then mapped to the IPv4 382 multicast address in the method described in this document. 383 For example, if the IPv4 address used to form the IPv6 address 384 is W.X.Y.Z, then the IPv6 solicited node multicast address is 385 FF02::1:W.X.Y.Z and the corresponding IPv4 multicast address is 386 239.OLS.Y.Z 388 ^L 390 Authors' Addresses 392 Brian E. Carpenter 393 Internet Division 394 IBM United Kingdom Laboratories 395 MP 185, Hursley Park 396 Winchester, Hampshire S021 2JN, UK 398 Email: brian@hursley.ibm.com 400 Cyndi Jung 401 3Com Corporation 402 5400 Bayfront Plaza, Mailstop 3219 403 Santa Clara, California 95052-8145 405 Email: cmj@3Com.com 407 Full Copyright Statement 409 Copyright (C) The Internet Society (1998). All Rights Reserved. 411 This document and translations of it may be copied and furnished to 412 others, and derivative works that comment on or otherwise explain it 413 or assist in its implementation may be prepared, copied, published 414 and distributed, in whole or in part, without restriction of any 415 kind, provided that the above copyright notice and this paragraph are 416 included on all such copies and derivative works. However, this 417 document itself may not be modified in any way, such as by removing 418 the copyright notice or references to the Internet Society or other 419 Internet organizations, except as needed for the purpose of 420 developing Internet standards in which case the procedures for 421 copyrights defined in the Internet Standards process must be 422 followed, or as required to translate it into languages other than 423 English. 425 The limited permissions granted above are perpetual and will not be 426 revoked by the Internet Society or its successors or assigns. 428 This document and the information contained herein is provided on an 429 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 430 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 431 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 432 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 433 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 435 ^L