idnits 2.17.1 draft-ietf-ipngwg-6over4-01.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 2) being 60 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 5 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 (December 1998) is 9263 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 327, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 342, 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: 9 errors (**), 0 flaws (~~), 8 warnings (==), 5 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 December 1998 6 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels 8 draft-ietf-ipngwg-6over4-01.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. 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 "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 77 globally-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 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 an access control list. 307 ^L 309 Acknowledgements 311 The basic idea presented above is not original, and we have had 312 invaluable comments from Matt Crawford, Steve Deering, Dan 313 Harrington, Rich Draves, Erik Nordmark, Quang Nguyen, and 314 other members of the IPNG and NGTRANS working groups. 316 This document is seriously ripped off from RFC 1972 written by 317 Matt Crawford. Brian Carpenter was at CERN when the work was started. 319 References 321 [AARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing 322 Architecture", RFC 2373 324 [ADMIN] Meyer, D., "Administratively Scoped IP Multicast", 325 RFC 2365, BCP 23. 327 [CONF] Thomson, S., and T. Narten, "IPv6 Stateless Address 328 Autoconfiguration", RFC xxxx (1971 update) 330 [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 331 Discovery for IP Version 6 (IPv6)", RFC xxxx (1970 update) 333 [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 334 (IPv6) Specification", RFC xxxx (1883 update) 336 [RFC 791] Postel, J., "Internet Protocol", RFC 791 338 [RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., 339 Lear, E., "Address Allocation for Private Internets", 340 RFC 1918 342 [RFC 2119] Key words for use in RFCs to Indicate Requirement Levels. 343 S. Bradner, RFC 2119 345 ^L 347 APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery 349 The following IPv4 multicast groups are used to support Neighbor 350 Discovery with this specification. 352 all-nodes multicast address 353 - the administratively-scoped IPv4 multicast address used to 354 reach all nodes in the local IPv4 domain supporting this 355 specification. 239.OLS.0.1 357 all-routers multicast address 358 - the administratively-scoped IPv4 multicast address to reach 359 all routers in the local IPv4 domain supporting this 360 specification. 239.OLS.0.2 362 solicited-node multicast address 363 - an administratively scoped multicast address that is computed 364 as a function of the solicited target's address by taking the 365 IPv4 address used to form the IPv6 address and prepending the 366 96-bit prefix FF02:0:0:0:0:1. This is then mapped to the IPv4 367 multicast address in the method described in this document. 368 For example, if the IPv4 address used to form the IPv6 address 369 is W.X.Y.Z, then the IPv6 solicited node multicast address is 370 FF02::1:W.X.Y.Z and the corresponding IPv4 multicast address is 371 239.OLS.Y.Z 373 ^L 375 Authors' Addresses 377 Brian E. Carpenter 378 Internet Division 379 IBM United Kingdom Laboratories 380 MP 185, Hursley Park 381 Winchester, Hampshire S021 2JN, UK 383 Email: brian@hursley.ibm.com 385 Cyndi Jung 386 3Com Corporation 387 5400 Bayfront Plaza, Mailstop 3219 388 Santa Clara, California 95052-8145 390 Email: cmj@3Com.com 392 Full Copyright Statement 394 Copyright (C) The Internet Society (1998). All Rights Reserved. 396 This document and translations of it may be copied and furnished to 397 others, and derivative works that comment on or otherwise explain it 398 or assist in its implementation may be prepared, copied, published 399 and distributed, in whole or in part, without restriction of any 400 kind, provided that the above copyright notice and this paragraph are 401 included on all such copies and derivative works. However, this 402 document itself may not be modified in any way, such as by removing 403 the copyright notice or references to the Internet Society or other 404 Internet organizations, except as needed for the purpose of 405 developing Internet standards in which case the procedures for 406 copyrights defined in the Internet Standards process must be 407 followed, or as required to translate it into languages other than 408 English. 410 The limited permissions granted above are perpetual and will not be 411 revoked by the Internet Society or its successors or assigns. 413 This document and the information contained herein is provided on an 414 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 415 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 416 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 417 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 418 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 420 ^L