IETF B. Carpenter Internet Draft C. Jung Nov 1997 Transmission of IPv6 Packets over IPv4 Networks without Tunnels Abstract draft-carpenter-ipng-6over4-00.txt This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses over IPv4 networks. It also specifies the content of the Source/Target Link- layer Address option used the the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement 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 network as their virtual local link. 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 learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Table of Contents: Status of this Memo.............................................1 1. Introduction.................................................2 2. Maximum Transmission Unit....................................2 3. Frame Format.................................................3 4. Stateless Autoconfiguration and Link-Local Addresses.........3 5. Address Mapping -- Unicast...................................4 6. Address Mapping -- Multicast.................................4 7. Mechanisms in the absence of IPv4 multicast..................5 8. Security considerations......................................5 Acknowledgements................................................5 References......................................................6 Authors' Addresses..............................................6 Carpenter Expires May 1997 [Page 1] Internet Draft Transmission of IPv6 Packets over IPv4 Nov 1996 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 networks. It also specifies the content of the Source/Target Link- layer Address option used the the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages described in [DISC], 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 network as their virtual local link. At least one IPv6 router using the same method must be connected to the same IPv4 network 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. 2. Maximum Transmission Unit The default MTU size for IPv6 packets on an IPv4 network is 1480 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option which specifies a smaller MTU, or by manual configuration of each node. [Discussion: 1480 is chosen so that the encapsulated packet fits into an Ethernet packet, in the normal case with no IPv4 options. In theory, any larger size up to 64K could be specified, relying on IPv4 fragmentation/reassembly to do the right thing. An alternative would be to specify the default IPv6 MTU as the locally applicable IPv4 MTU minus the IPv4 header length.] Carpenter Expires May 1997 [Page 2] Internet Draft Transmission of IPv6 Packets over IPv4 Nov 1996 3. Frame Format IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv4 protocol type of TBD1. 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 TBD1 | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 header and payload ... / +-------+-------+-------+-------+-------+------+------+ 4. Stateless Autoconfiguration and Link-Local Addresses The address token [CONF] for an IPv4 interface is the interface's 32-bit IPv4 address, 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 48 bits. When the host has more than one IPv4 address in use on the physical interface concerned, an administrative choice of one of these addresses is made. An IPv6 address prefix used for stateless autoconfiguration of an IPv4 interface must be 80 bits in length. The IPv6 Link-local address [AARCH] for an Ethernet interface is formed by appending the interface's zero-padded IPv4 address to the 80-bit prefix FE80::. +-------+-------+-------+-------+-------+-------+------+------+ | FE 80 00 00 00 00 00 00 | +-------+-------+-------+-------+-------+-------+------+------+ | 00 00 | 00 | 00 | IPv4 Address | +-------+-------+-------+-------+-------+-------+------+------+ Carpenter Expires May 1997 [Page 3] Internet Draft Transmission of IPv6 Packets over IPv4 Nov 1996 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. +-------+-------+-------+-------+-------+-------+-------+-------+ | 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 built-in address used as the address token. 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 whose first byte is the value TBD2 (in the range 224-239) whose last three bytes are the last three bytes of DST, ordered from more to least significant. +-------+-------+-------+-------+ | TBD2 | DST13 | DST14 | DST15 | +-------+-------+-------+-------+ The scope of all multicast groups whose first address byte is TBD2 MUST be administratively limited to the IPv4 network over which operation of IPv6 over IPv4 is desired. Carpenter Expires May 1997 [Page 4] Internet Draft Transmission of IPv6 Packets over IPv4 Nov 1996 7. Mechanisms in the absence of IPv4 multicast It is strongly recommended to use IPv4 multicast as described above. However, if the IPv4 network does not support IPv4 multicast, its effect must be simulated. A solution is to use the IPv4 global broadcast address of 255.255.255.255 as the destination IPv4 address for all IPv6 multicast packets. In this case, the scope of such IPv4 broadcasts MUST be administratively limited to the IPv4 network over which operation of IPv6 over IPv4 is desired. Non-IPv6 IPv4 hosts receiving such broadcasts with protocol type TBD1 MUST silently discard them. This solution SHOULD be implemented as an alternative to use of IPv4 multicast. However, it carries an intrinsic risk of broadcast storms and MUST NOT be the default configuration. This solution SHOULD NOT be used in an IPv4 topology that has alternate paths, as there is no guaranteed way to contain broadcast storms in such a case. Another approach would be treat the IPv4 network as an NBMA network, but this solution is not recommended on grounds of complexity. 8. Security considerations This specification introduces no known new security risks. However, implementors should be aware that, in addition to posssible attacks against IPv6, security attacks against IPv4 must also be considered. 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. Acknowledgements The basic idea presented above is not original, and we have had useful discussions about it with Steve Deering. This document is seriously ripped off from RFC 1972 written by Matt Crawford. Carpenter Expires May 1997 [Page 5] Internet Draft Transmission of IPv6 Packets over IPv4 Nov 1996 References [AARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", RFC 1884, December 1995. [CONF] Thomson, S., and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 1971, August 1996. [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 1970, August 1996. [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995. [RFC 791] Postel, J., "Internet Protocol", September 1981. Authors' Addresses Brian E. Carpenter Computing and Networks Division CERN European Laboratory for Particle Physics 1211 Geneva 23, Switzerland Email: brian@dxcoms.cern.ch Cyndi Jung 3Com Corporation 5400 Bayfront Plaza Santa Clara, California Email: cmj@NSD.3Com.com Carpenter Expires May 1997 [Page 6]