IETF B. Carpenter, IBM Internet Draft C. Jung, 3Com October 1998 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels draft-ietf-ipngwg-6over4-00.txt (revised from draft-carpenter-ipng-6over4-04.txt) Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link- layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement and Redirect messages, when those messages are transmitted on an IPv4 network. The motivation for this method is to allow isolated IPv6 hosts, located on a physical link which has no directly connected IPv6 router, to become fully functional IPv6 hosts by using an IPv4 domain that supports IPv4 multicast as their virtual local link. It uses IPv4 multicast as a "virtual Ethernet." Carpenter, Jung Expires April 1999 [Page 1] ^L Internet Draft Transmission of IPv6 Packets over IPv4 Oct 1998 Table of Contents: 1. Introduction....................................................2 2. Maximum Transmission Unit.......................................3 3. Frame Format....................................................3 4. Stateless Autoconfiguration and Link-Local Addresses............4 5. Address Mapping -- Unicast......................................4 6. Address Mapping -- Multicast....................................5 7. Mechanism in the absence of IPv4 multicast......................5 8. Scaling and Transition Isues....................................5 9. Security considerations.........................................6 Acknowledgements...................................................7 References.........................................................7 APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery........8 Authors' Addresses.................................................9 Full Copyright Notice..............................................9 1. Introduction This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses over IPv4 "domains". For the purposes of this document, an IPv4 domain is a | fully interconnected set of IPv4 subnets, within the same local | multicast scope, on which there are at least two IPv6 nodes conforming to this specification. This IPv4 domain could form part of the globally- unique IPv4 address space, or could form part of a private IPv4 network [RFC 1918]. This memo also specifies the content of the Source/Target Link-layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages described in [DISC], when those messages are transmitted on an IPv4 domain. The motivation for this method is to allow isolated IPv6 hosts, located on a physical link which has no directly connected IPv6 router, to become fully functional IPv6 hosts by using an IPv4 domain as their virtual local link. Thus, at least one IPv6 router using the same method must be connected to the same IPv4 domain if IPv6 routing to other links is required. IPv6 hosts connected using this method do not require IPv4-compatible addresses or configured tunnels. In this way IPv6 gains considerable independence of the underlying links and can step over many hops of | IPv4 subnets. The mechanism is known formally as "IPv6 over IPv4" | or "6over4" and colloquially as "virtual Ethernet." The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Carpenter, Jung Expires April 1999 [Page 2] ^L Internet Draft Transmission of IPv6 Packets over IPv4 Oct 1998 2. Maximum Transmission Unit The default MTU size for IPv6 packets on an IPv4 domain is 1480 octets. This size may be varied by a Router Advertisement [DISC] containing an MTU option which specifies a different MTU, or by manual configuration of each node. Note that if by chance the IPv6 MTU size proves to be too large for some intermediate IPv4 subnet, IPv4 fragmentation will ensue. While | undesirable, this is not disastrous. However, the IPv4 "do not fragment" | bit MUST NOT be set in the encapsulating IPv4 header. 3. Frame Format IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv4 protocol type of 41, the same as has been assigned in RFC 1933 for IPv6 packets that are tunneled inside of IPv4 frames. The IPv4 header contains the Destination and Source IPv4 addresses. The IPv4 packet body contains the IPv6 header followed immediately by the payload. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol 41 | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 header and payload ... / +-------+-------+-------+-------+-------+------+------+ If there are IPv4 options, then padding SHOULD be added to the IPv4 header such that the IPv6 header starts on a boundary that is a 32- bit offset from the end of the datalink header. The Time to Live field SHOULD be set to a low value, to prevent such packets accidentally leaking from the IPv4 domain. This MUST be a configurable parameter, with a recommended default of 8. Carpenter, Jung Expires April 1999 [Page 3] ^L Internet Draft Transmission of IPv6 Packets over IPv4 Oct 1998 4. Stateless Autoconfiguration and Link-Local Addresses The Interface Identifier [AARCH] of an IPv4 interface is the 32-bit IPv4 address of that interface, with the octets in the same order in which they would appear in the header of an IPv4 packet, padded at the left with zeros to a total of 64 bits. Note that the "Universal/ Local" bit is zero, indicating that the Interface Identifer is not globally unique. When the host has more than one IPv4 address in use on the physical interface concerned, an administrative choice of one of these IPv4 addresses is made. An IPv6 address prefix used for stateless autoconfiguration of an | IPv4 interface MUST have a length of 64 bits except for a special | case mentioned in Section 8. The IPv6 Link-local address [AARCH] for an IPv4 virtual interface is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64. +-------+-------+-------+-------+-------+-------+------+------+ | FE 80 00 00 00 00 00 00 | +-------+-------+-------+-------+-------+-------+------+------+ | 00 00 | 00 | 00 | IPv4 Address | +-------+-------+-------+-------+-------+-------+------+------+ 5. Address Mapping -- Unicast The procedure for mapping IPv6 addresses into IPv4 virtual link-layer addresses is described in [DISC]. The Source/Target Link-layer Address option has the following form when the link layer is IPv4. Since the length field is in units of 8 bytes, the value below is 1. +-------+-------+-------+-------+-------+-------+-------+-------+ | Type |Length | must be zero | IPv4 Address | +-------+-------+-------+-------+-------+-------+-------+-------+ Type: 1 for Source Link-layer address. 2 for Target Link-layer address. Length: 1 (in units of 8 octets). IPv4 Address: The 32 bit IPv4 address, in network byte order. This is the address the interface currently responds to, and may be different from the Interface Identifier for stateless autoconfiguration. Carpenter, Jung Expires April 1999 [Page 4] ^L Internet Draft Transmission of IPv6 Packets over IPv4 Oct 1998 6. Address Mapping -- Multicast If IPv4 multicast is available, an IPv6 packet with a multicast destination address DST MUST be transmitted to the IPv4 multicast address of Organization-Local Scope using the mapping below. These IPv4 multicast addresses SHOULD be taken from the block 239.192.0.0/16, a sub-block of the Organization-Local Scope address block, or, if all of those are not available, from the expansion blocks | defined in [ADMIN]. Note that when they are formed using the expansion blocks, they use only a /16 sized block. +-------+-------+-------+-------+ | 239 | OLS | DST14 | DST15 | +-------+-------+-------+-------+ DST14, DST15 last two bytes of IPv6 multicast address. OLS from the configured Organization-Local | Scope address block. SHOULD be 192, | see [ADMIN] for details. | No new IANA registration procedures are required for the above. See appendix A. for a list of all the multicast groups that must be joined to support Neighbor Discovery. 7. Mechanism in the absence of IPv4 multicast It is strongly RECOMMENDED to use IPv4 multicast as described above, and this MUST be the default configuration in implementations. However, if the IPv4 domain does not support IPv4 multicast, a unicast technique is possible. In this case the IPv6 router will handle IPv6 multicast packets by | replication and IPv4 unicast encapsulation to each relevant IPv6 destination (i.e., all those that have joined the IPv6 multicast group), since the mapping onto an IPv4 multicast address is not | available. Similarly, 6over4 hosts will unicast to the router. 8. Scaling and Transition Isues The multicast mechanism described in Section 6 above appears to have essentially the same scaling properties as native IPv6 over most media, except for the slight reduction in MTU size which will slightly reduce bulk throughput. On an ATM network, where IPv4 multicast relies on relatively complex mechanisms, it is to be Carpenter, Jung Expires April 1999 [Page 5] ^L Internet Draft Transmission of IPv6 Packets over IPv4 Oct 1998 expected that IPv6 over IPv4 over ATM will perform less well than native IPv6 over ATM. The unicast mechanism described in Section 7, if used to support IPv6 multicast, will not scale well and should be used only for a small number of IPv6 hosts. For IPv6 unicast traffic, it will have similar scaling properties to configured tunnels. The "IPv6 over IPv4" mechanism is intended to take its place in the range of options available for transition from IPv4 to IPv6. In particular it allows a site to run both IPv4 and IPv6 in coexistence, without having to configure IPv6 hosts either with IPv4-compatible addresses or with tunnels. Interfaces of the IPv6 router and hosts will of course need to be enabled in "6over4" mode. A site may choose to start its IPv6 transition by configuring one IPv6 router to support "6over4" on an interface connected to the site's IPv4 domain, and another IPv6 format on an interface connected to the IPv6 Internet. Any enabled "6over4" hosts in the IPv4 domain will then be able to communicate both with the router and with the IPv6 Internet, without manual configuration of a tunnel and without the need for an IPv4-compatible IPv6 address, either stateless or stateful address configuration providing the IPv6 address to the IPv6 host. | During transition, routers may need to advertise at least two | IPv6 prefixes, one for the native LAN (e.g. Ethernet) and one for | "6over4." As with any IPv6 prefix assigned to an IPv6 subnet, the | latter MUST be unique within its scope, whether site-local or | global addressing is used. | Also note that when a router is handling both native LAN and | "6over4" on the same physical interface, during | stateless autoconfiguration, there is a period when IPv6 link-local | addresses are used, in both cases with the prefix FE80::/64. | Note that the prefix-length for these link-local adddress MUST | then be 128 so that the two cases can be distinguished. As the site installs additional IPv6 routers, "6over4" hosts which become physically adjacent to IPv6 routers can be changed to run as native IPv6 hosts, with the the only impact on IPv6 applications being a slight increase in MTU size. At some stage | during transition, it might be convenient to dual home hosts | in both native LAN and "6over4" mode, but this is not required. 9. Security considerations Implementors should be aware that, in addition to posssible attacks against IPv6, security attacks against IPv4 must also be considered. Carpenter, Jung Expires April 1999 [Page 6] ^L Internet Draft Transmission of IPv6 Packets over IPv4 Oct 1998 Use of IP security at both IPv4 and IPv6 levels should nevertheless be avoided, for efficiency reasons. For example, if IPv6 is running encrypted, encryption of IPv4 would be redundant except if traffic analysis is felt to be a threat. If IPv6 is running authenticated, then authentication of IPv4 will add little. Conversely, IPv4 security will not protect IPv6 traffic once it leaves the IPv6-over- IPv4 domain. Therefore, implementing IPv6 security is required even if IPv4 security is available. | There is a possible spoofing attack in which spurious 6over4 | packets are injected into a 6over4 domain from outside. Thus, | boundary routers MUST discard multicast IPv4 packets with source | or destination multicast addresses of organisation local scope | as defined in section 6 above, if they arrive on physical | interfaces outside that scope. To defend against spurious | unicast 6over4 packets, boundary routers MUST discard incoming | IPv4 packets with protocol type 41 from unknown sources, i.e. | IPv6-in-IPv4 tunnels must only be accepted from trusted sources. | Unless IPSEC authentication is available, the RECOMMENDED technique | for this is an access control list. Acknowledgements The basic idea presented above is not original, and we have had invaluable comments from Matt Crawford, Steve Deering, Dan Harrington, Rich Draves, Erik Nordmark, Quang Nguyen, and other members of the IPNG and NGTRANS working groups. This document is seriously ripped off from RFC 1972 written by Matt Crawford. Brian Carpenter was at CERN when the work was started. References [AARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373 [ADMIN] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, BCP 23. [CONF] Thomson, S., and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC xxxx (1971 update) [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC xxxx (1970 update) [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC xxxx (1883 update) [RFC 791] Postel, J., "Internet Protocol", RFC 791 [RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., Lear, E., "Address Allocation for Private Internets", RFC 1918 [RFC 2119] Key words for use in RFCs to Indicate Requirement Levels. S. Bradner, RFC 2119 Carpenter, Jung Expires April 1999 [Page 7] ^L Internet Draft Transmission of IPv6 Packets over IPv4 Oct 1998 APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery The following IPv4 multicast groups are used to support Neighbor Discovery with this specification. all-nodes multicast address - the administratively-scoped IPv4 multicast address used to reach all nodes in the local IPv4 domain supporting this specification. 239.OLS.0.1 all-routers multicast address - the administratively-scoped IPv4 multicast address to reach all routers in the local IPv4 domain supporting this specification. 239.OLS.0.2 solicited-node multicast address - an administratively scoped multicast address that is computed as a function of the solicited target's address by taking the IPv4 address used to form the IPv6 address and prepending the 96-bit prefix FF02:0:0:0:0:1. This is then mapped to the IPv4 multicast address in the method described in this document. For example, if the IPv4 address used to form the IPv6 address is W.X.Y.Z, then the IPv6 solicited node multicast address is FF02::1:W.X.Y.Z and the corresponding IPv4 multicast address is 239.OLS.Y.Z Carpenter, Jung Expires April 1999 [Page 8] ^L Internet Draft Transmission of IPv6 Packets over IPv4 Oct 1998 Authors' Addresses Brian E. Carpenter Internet Division IBM United Kingdom Laboratories MP 185, Hursley Park Winchester, Hampshire S021 2JN, UK Email: brian@hursley.ibm.com Cyndi Jung 3Com Corporation 5400 Bayfront Plaza, Mailstop 3219 Santa Clara, California 95052-8145 Email: cmj@3Com.com Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Carpenter, Jung Expires April 1999 [Page 9] ^L