--- 1/draft-ietf-ipngwg-6over4-01.txt 2006-12-03 11:47:24.000000000 +0100 +++ 2/draft-ietf-ipngwg-6over4-02.txt 2006-12-03 11:47:24.000000000 +0100 @@ -1,18 +1,18 @@ IETF B. Carpenter, IBM Internet Draft C. Jung, 3Com -December 1998 +January 1998 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels - draft-ietf-ipngwg-6over4-01.txt + draft-ietf-ipngwg-6over4-02.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 @@ -32,27 +32,27 @@ 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. + IPv4 multicast 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.' + link. It uses IPv4 multicast as a "virtual Ethernet." ^L 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 @@ -63,39 +63,39 @@ 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]. + multicast "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. + multicast 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. + router, to become fully functional IPv6 hosts by using an IPv4 multicast + 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]. @@ -110,21 +110,21 @@ 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 + 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -155,22 +155,22 @@ 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 + An IPv6 address prefix used for stateless autoconfiguration [CONF] of + an IPv4 interface MUST have a length of 64 bits except for a special case mentioned in Section 7. 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 | @@ -295,86 +295,96 @@ 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. + for this is to configure the boundary router only to accept + protocol type 41 packets from source addresses within a trusted + range or ranges. ^L 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. + Harrington, Rich Draves, Erik Nordmark, Quang Nguyen, Thomas + Narten, 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) + Autoconfiguration", RFC 2462 [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor - Discovery for IP Version 6 (IPv6)", RFC xxxx (1970 update) + Discovery for IP Version 6 (IPv6)", RFC 2461 [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 - (IPv6) Specification", RFC xxxx (1883 update) + (IPv6) Specification", RFC 2460 [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 1933] Gilligan, R., and Nordmark, E., "Transition Mechanisms for + IPv6 Hosts and Routers", RFC 1933 + [RFC 2119] Key words for use in RFCs to Indicate Requirement Levels. S. Bradner, RFC 2119 ^L APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery The following IPv4 multicast groups are used to support Neighbor - Discovery with this specification. + Discovery with this specification. The IPv4 addresses listed + in this section were obtained by looking at the IPv6 multicast + addresses that Neigbour Discovery uses, and deriving the resulting + IPv4 "virtual link-layer" addresses that are generated from them + using the algorithm given in Section 6. 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. + low-order 24 bits of the IPv4 address used to form the IPv6 + address, and prepending the prefix FF02:0:0:0:0:1:FF00::/104 + [AARCH]. This is then mapped to the IPv4 + multicast address by 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 + FF02::1:255.X.Y.Z and the corresponding IPv4 multicast address is 239.OLS.Y.Z ^L Authors' Addresses Brian E. Carpenter Internet Division IBM United Kingdom Laboratories MP 185, Hursley Park