idnits 2.17.1 draft-ietf-ipngwg-6over4-02.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 8 longer pages, the longest (page 6) 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 4 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 == There are 1 instance 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 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC 2119' is defined on line 347, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. 'AARCH') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2462 (ref. 'CONF') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2461 (ref. 'DISC') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 1933 (Obsoleted by RFC 2893) Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF B. Carpenter, IBM 3 Internet Draft C. Jung, 3Com 4 January 1998 6 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels 8 draft-ietf-ipngwg-6over4-02.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 multicast 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. Scaling and Transition Isues....................................5 61 8. IANA considerations.............................................6 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 multicast "domains". For the purposes of this document, an IPv4 domain 74 is a fully interconnected set of IPv4 subnets, within the same local 75 multicast scope, on which there are at least two IPv6 nodes conforming 76 to this specification. This IPv4 domain could form part of the 77 globally-unique IPv4 address space, or could form part of a private 78 IPv4 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 multicast 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 multicast 89 domain as their virtual local link. Thus, at least one IPv6 router 90 using the same method must be connected to the same IPv4 domain if 91 IPv6 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 [CONF] of 166 an IPv4 interface MUST have a length of 64 bits except for a special 167 case mentioned in Section 7. 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 IPv4 multicast MUST be 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. Scaling and Transition Issues 232 The multicast mechanism described in Section 6 above appears to have 233 essentially the same scaling properties as native IPv6 over most 234 media, except for the slight reduction in MTU size which will 235 slightly reduce bulk throughput. On an ATM network, where IPv4 236 multicast relies on relatively complex mechanisms, it is to be 237 expected that IPv6 over IPv4 over ATM will perform less well than 238 native IPv6 over ATM. 240 The "IPv6 over IPv4" mechanism is intended to take its place in the 241 range of options available for transition from IPv4 to IPv6. In 242 particular it allows a site to run both IPv4 and IPv6 in coexistence, 243 without having to configure IPv6 hosts either with IPv4-compatible 244 addresses or with tunnels. Interfaces of the IPv6 router and hosts 245 will of course need to be enabled in "6over4" mode. 247 A site may choose to start its IPv6 transition by configuring one 248 IPv6 router to support "6over4" on an interface connected to 249 the site's IPv4 domain, and another IPv6 format on an interface 250 connected to the IPv6 Internet. Any enabled "6over4" hosts 251 in the IPv4 domain will then be able to communicate both with the 252 router and with the IPv6 Internet, without manual configuration of a 253 tunnel and without the need for an IPv4-compatible IPv6 address, 254 either stateless or stateful address configuration providing the IPv6 255 address to the IPv6 host. 257 ^L 258 During transition, routers may need to advertise at least two 259 IPv6 prefixes, one for the native LAN (e.g. Ethernet) and one for 260 "6over4." As with any IPv6 prefix assigned to an IPv6 subnet, the 261 latter MUST be unique within its scope, whether site-local or 262 global addressing is used. 264 Also note that when a router is handling both native LAN and 265 "6over4" on the same physical interface, during 266 stateless autoconfiguration, there is a period when IPv6 link-local 267 addresses are used, in both cases with the prefix FE80::/64. 268 Note that the prefix-length for these link-local adddress MUST 269 then be 128 so that the two cases can be distinguished. 271 As the site installs additional IPv6 routers, "6over4" hosts 272 which become physically adjacent to IPv6 routers can be changed to 273 run as native IPv6 hosts, with the the only impact on IPv6 274 applications being a slight increase in MTU size. At some stage 275 during transition, it might be convenient to dual home hosts 276 in both native LAN and "6over4" mode, but this is not required. 278 8. IANA considerations 280 No assignments by the IANA are required beyond those in [ADMIN]. 282 9. Security considerations 284 Implementors should be aware that, in addition to posssible attacks 285 against IPv6, security attacks against IPv4 must also be considered. 286 Use of IP security at both IPv4 and IPv6 levels should nevertheless 287 be avoided, for efficiency reasons. For example, if IPv6 is running 288 encrypted, encryption of IPv4 would be redundant except if traffic 289 analysis is felt to be a threat. If IPv6 is running authenticated, 290 then authentication of IPv4 will add little. Conversely, IPv4 291 security will not protect IPv6 traffic once it leaves the IPv6-over- 292 IPv4 domain. Therefore, implementing IPv6 security is required even 293 if IPv4 security is available. 295 There is a possible spoofing attack in which spurious 6over4 296 packets are injected into a 6over4 domain from outside. Thus, 297 boundary routers MUST discard multicast IPv4 packets with source 298 or destination multicast addresses of organisation local scope 299 as defined in section 6 above, if they arrive on physical 300 interfaces outside that scope. To defend against spurious 301 unicast 6over4 packets, boundary routers MUST discard incoming 302 IPv4 packets with protocol type 41 from unknown sources, i.e. 303 IPv6-in-IPv4 tunnels must only be accepted from trusted sources. 304 Unless IPSEC authentication is available, the RECOMMENDED technique 305 for this is to configure the boundary router only to accept 306 protocol type 41 packets from source addresses within a trusted 307 range or ranges. 309 ^L 311 Acknowledgements 313 The basic idea presented above is not original, and we have had 314 invaluable comments from Matt Crawford, Steve Deering, Dan 315 Harrington, Rich Draves, Erik Nordmark, Quang Nguyen, Thomas 316 Narten, and other members of the IPNG and NGTRANS working groups. 318 This document is seriously ripped off from RFC 1972 written by 319 Matt Crawford. Brian Carpenter was at CERN when the work was started. 321 References 323 [AARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing 324 Architecture", RFC 2373 326 [ADMIN] Meyer, D., "Administratively Scoped IP Multicast", 327 RFC 2365, BCP 23. 329 [CONF] Thomson, S., and T. Narten, "IPv6 Stateless Address 330 Autoconfiguration", RFC 2462 332 [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 333 Discovery for IP Version 6 (IPv6)", RFC 2461 335 [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 336 (IPv6) Specification", RFC 2460 338 [RFC 791] Postel, J., "Internet Protocol", RFC 791 340 [RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., 341 Lear, E., "Address Allocation for Private Internets", 342 RFC 1918 344 [RFC 1933] Gilligan, R., and Nordmark, E., "Transition Mechanisms for 345 IPv6 Hosts and Routers", RFC 1933 347 [RFC 2119] Key words for use in RFCs to Indicate Requirement Levels. 348 S. Bradner, RFC 2119 350 ^L 352 APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery 354 The following IPv4 multicast groups are used to support Neighbor 355 Discovery with this specification. The IPv4 addresses listed 356 in this section were obtained by looking at the IPv6 multicast 357 addresses that Neigbour Discovery uses, and deriving the resulting 358 IPv4 "virtual link-layer" addresses that are generated from them 359 using the algorithm given in Section 6. 361 all-nodes multicast address 362 - the administratively-scoped IPv4 multicast address used to 363 reach all nodes in the local IPv4 domain supporting this 364 specification. 239.OLS.0.1 366 all-routers multicast address 367 - the administratively-scoped IPv4 multicast address to reach 368 all routers in the local IPv4 domain supporting this 369 specification. 239.OLS.0.2 371 solicited-node multicast address 372 - an administratively scoped multicast address that is computed 373 as a function of the solicited target's address by taking the 374 low-order 24 bits of the IPv4 address used to form the IPv6 375 address, and prepending the prefix FF02:0:0:0:0:1:FF00::/104 376 [AARCH]. This is then mapped to the IPv4 377 multicast address by the method described in this document. 378 For example, if the IPv4 address used to form the IPv6 address 379 is W.X.Y.Z, then the IPv6 solicited node multicast address is 380 FF02::1:255.X.Y.Z and the corresponding IPv4 multicast address is 381 239.OLS.Y.Z 383 ^L 385 Authors' Addresses 387 Brian E. Carpenter 388 Internet Division 389 IBM United Kingdom Laboratories 390 MP 185, Hursley Park 391 Winchester, Hampshire S021 2JN, UK 393 Email: brian@hursley.ibm.com 395 Cyndi Jung 396 3Com Corporation 397 5400 Bayfront Plaza, Mailstop 3219 398 Santa Clara, California 95052-8145 400 Email: cmj@3Com.com 402 Full Copyright Statement 404 Copyright (C) The Internet Society (1998). All Rights Reserved. 406 This document and translations of it may be copied and furnished to 407 others, and derivative works that comment on or otherwise explain it 408 or assist in its implementation may be prepared, copied, published 409 and distributed, in whole or in part, without restriction of any 410 kind, provided that the above copyright notice and this paragraph are 411 included on all such copies and derivative works. However, this 412 document itself may not be modified in any way, such as by removing 413 the copyright notice or references to the Internet Society or other 414 Internet organizations, except as needed for the purpose of 415 developing Internet standards in which case the procedures for 416 copyrights defined in the Internet Standards process must be 417 followed, or as required to translate it into languages other than 418 English. 420 The limited permissions granted above are perpetual and will not be 421 revoked by the Internet Society or its successors or assigns. 423 This document and the information contained herein is provided on an 424 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 425 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 426 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 427 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 428 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 430 ^L