draft-ietf-ipngwg-6over4-01.txt   draft-ietf-ipngwg-6over4-02.txt 
IETF B. Carpenter, IBM IETF B. Carpenter, IBM
Internet Draft C. Jung, 3Com Internet Draft C. Jung, 3Com
December 1998 January 1998
Transmission of IPv6 over IPv4 Domains without Explicit Tunnels 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 Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract Abstract
This memo specifies the frame format for transmission of IPv6 [IPV6] This memo specifies the frame format for transmission of IPv6 [IPV6]
packets and the method of forming IPv6 link-local addresses over IPv4 packets and the method of forming IPv6 link-local addresses over IPv4
domains. It also specifies the content of the Source/Target Link- domains. It also specifies the content of the Source/Target Link-
layer Address option used in the Router Solicitation, Router layer Address option used in the Router Solicitation, Router
Advertisement, Neighbor Solicitation, and Neighbor Advertisement Advertisement, Neighbor Solicitation, and Neighbor Advertisement
and Redirect messages, when those messages are transmitted on an 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, The motivation for this method is to allow isolated IPv6 hosts,
located on a physical link which has no directly connected IPv6 located on a physical link which has no directly connected IPv6
router, to become fully functional IPv6 hosts by using an IPv4 router, to become fully functional IPv6 hosts by using an IPv4
domain that supports IPv4 multicast as their virtual local 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 ^L
Table of Contents: Table of Contents:
1. Introduction....................................................2 1. Introduction....................................................2
2. Maximum Transmission Unit.......................................3 2. Maximum Transmission Unit.......................................3
3. Frame Format....................................................3 3. Frame Format....................................................3
4. Stateless Autoconfiguration and Link-Local Addresses............4 4. Stateless Autoconfiguration and Link-Local Addresses............4
5. Address Mapping -- Unicast......................................4 5. Address Mapping -- Unicast......................................4
skipping to change at page 2, line 28 skipping to change at page 2, line 28
Acknowledgements...................................................7 Acknowledgements...................................................7
References.........................................................7 References.........................................................7
APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery........8 APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery........8
Authors' Addresses.................................................9 Authors' Addresses.................................................9
Full Copyright Notice..............................................9 Full Copyright Notice..............................................9
1. Introduction 1. Introduction
This memo specifies the frame format for transmission of IPv6 [IPV6] This memo specifies the frame format for transmission of IPv6 [IPV6]
packets and the method of forming IPv6 link-local addresses over IPv4 packets and the method of forming IPv6 link-local addresses over IPv4
"domains". For the purposes of this document, an IPv4 domain is a multicast "domains". For the purposes of this document, an IPv4 domain
fully interconnected set of IPv4 subnets, within the same local is a fully interconnected set of IPv4 subnets, within the same local
multicast scope, on which there are at least two IPv6 nodes multicast scope, on which there are at least two IPv6 nodes conforming
conforming to this specification. This IPv4 domain could form part of the to this specification. This IPv4 domain could form part of the
globally-unique IPv4 address space, or could form part of a private IPv4 globally-unique IPv4 address space, or could form part of a private
network [RFC 1918]. IPv4 network [RFC 1918].
This memo also specifies the content of the Source/Target Link-layer This memo also specifies the content of the Source/Target Link-layer
Address option used in the Router Solicitation, Router Advertisement, Address option used in the Router Solicitation, Router Advertisement,
Neighbor Solicitation, Neighbor Advertisement and Redirect messages Neighbor Solicitation, Neighbor Advertisement and Redirect messages
described in [DISC], when those messages are transmitted on an IPv4 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, The motivation for this method is to allow isolated IPv6 hosts,
located on a physical link which has no directly connected IPv6 located on a physical link which has no directly connected IPv6
router, to become fully functional IPv6 hosts by using an IPv4 domain router, to become fully functional IPv6 hosts by using an IPv4 multicast
as their virtual local link. Thus, at least one IPv6 router using domain as their virtual local link. Thus, at least one IPv6 router
the same method must be connected to the same IPv4 domain if IPv6 using the same method must be connected to the same IPv4 domain if
routing to other links is required. IPv6 routing to other links is required.
IPv6 hosts connected using this method do not require IPv4-compatible IPv6 hosts connected using this method do not require IPv4-compatible
addresses or configured tunnels. In this way IPv6 gains considerable addresses or configured tunnels. In this way IPv6 gains considerable
independence of the underlying links and can step over many hops of independence of the underlying links and can step over many hops of
IPv4 subnets. The mechanism is known formally as "IPv6 over IPv4" IPv4 subnets. The mechanism is known formally as "IPv6 over IPv4"
or "6over4" and colloquially as "virtual Ethernet." or "6over4" and colloquially as "virtual Ethernet."
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 3, line 22 skipping to change at page 3, line 22
manual configuration of each node. manual configuration of each node.
Note that if by chance the IPv6 MTU size proves to be too large for Note that if by chance the IPv6 MTU size proves to be too large for
some intermediate IPv4 subnet, IPv4 fragmentation will ensue. While some intermediate IPv4 subnet, IPv4 fragmentation will ensue. While
undesirable, this is not disastrous. However, the IPv4 "do not fragment" undesirable, this is not disastrous. However, the IPv4 "do not fragment"
bit MUST NOT be set in the encapsulating IPv4 header. bit MUST NOT be set in the encapsulating IPv4 header.
3. Frame Format 3. Frame Format
IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv4 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 IPv6 packets that are tunneled inside of IPv4 frames. The IPv4
header contains the Destination and Source IPv4 addresses. The IPv4 header contains the Destination and Source IPv4 addresses. The IPv4
packet body contains the IPv6 header followed immediately by the packet body contains the IPv6 header followed immediately by the
payload. payload.
0 1 2 3 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 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 | |Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 4, line 18 skipping to change at page 4, line 18
The Interface Identifier [AARCH] of an IPv4 interface is the 32-bit 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 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 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/ 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 Local" bit is zero, indicating that the Interface Identifer is not
globally unique. When the host has more than one IPv4 address in use globally unique. When the host has more than one IPv4 address in use
on the physical interface concerned, an administrative choice of one on the physical interface concerned, an administrative choice of one
of these IPv4 addresses is made. of these IPv4 addresses is made.
An IPv6 address prefix used for stateless autoconfiguration of an An IPv6 address prefix used for stateless autoconfiguration [CONF] of
IPv4 interface MUST have a length of 64 bits except for a special an IPv4 interface MUST have a length of 64 bits except for a special
case mentioned in Section 7. case mentioned in Section 7.
The IPv6 Link-local address [AARCH] for an IPv4 virtual interface is The IPv6 Link-local address [AARCH] for an IPv4 virtual interface is
formed by appending the Interface Identifier, as defined above, to formed by appending the Interface Identifier, as defined above, to
the prefix FE80::/64. the prefix FE80::/64.
+-------+-------+-------+-------+-------+-------+------+------+ +-------+-------+-------+-------+-------+-------+------+------+
| FE 80 00 00 00 00 00 00 | | FE 80 00 00 00 00 00 00 |
+-------+-------+-------+-------+-------+-------+------+------+ +-------+-------+-------+-------+-------+-------+------+------+
| 00 00 | 00 | 00 | IPv4 Address | | 00 00 | 00 | 00 | IPv4 Address |
skipping to change at page 6, line 53 skipping to change at page 6, line 53
There is a possible spoofing attack in which spurious 6over4 There is a possible spoofing attack in which spurious 6over4
packets are injected into a 6over4 domain from outside. Thus, packets are injected into a 6over4 domain from outside. Thus,
boundary routers MUST discard multicast IPv4 packets with source boundary routers MUST discard multicast IPv4 packets with source
or destination multicast addresses of organisation local scope or destination multicast addresses of organisation local scope
as defined in section 6 above, if they arrive on physical as defined in section 6 above, if they arrive on physical
interfaces outside that scope. To defend against spurious interfaces outside that scope. To defend against spurious
unicast 6over4 packets, boundary routers MUST discard incoming unicast 6over4 packets, boundary routers MUST discard incoming
IPv4 packets with protocol type 41 from unknown sources, i.e. IPv4 packets with protocol type 41 from unknown sources, i.e.
IPv6-in-IPv4 tunnels must only be accepted from trusted sources. IPv6-in-IPv4 tunnels must only be accepted from trusted sources.
Unless IPSEC authentication is available, the RECOMMENDED technique 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 ^L
Acknowledgements Acknowledgements
The basic idea presented above is not original, and we have had The basic idea presented above is not original, and we have had
invaluable comments from Matt Crawford, Steve Deering, Dan invaluable comments from Matt Crawford, Steve Deering, Dan
Harrington, Rich Draves, Erik Nordmark, Quang Nguyen, and Harrington, Rich Draves, Erik Nordmark, Quang Nguyen, Thomas
other members of the IPNG and NGTRANS working groups. Narten, and other members of the IPNG and NGTRANS working groups.
This document is seriously ripped off from RFC 1972 written by This document is seriously ripped off from RFC 1972 written by
Matt Crawford. Brian Carpenter was at CERN when the work was started. Matt Crawford. Brian Carpenter was at CERN when the work was started.
References References
[AARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing [AARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373 Architecture", RFC 2373
[ADMIN] Meyer, D., "Administratively Scoped IP Multicast", [ADMIN] Meyer, D., "Administratively Scoped IP Multicast",
RFC 2365, BCP 23. RFC 2365, BCP 23.
[CONF] Thomson, S., and T. Narten, "IPv6 Stateless Address [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 [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] 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 791] Postel, J., "Internet Protocol", RFC 791
[RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., [RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.,
Lear, E., "Address Allocation for Private Internets", Lear, E., "Address Allocation for Private Internets",
RFC 1918 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. [RFC 2119] Key words for use in RFCs to Indicate Requirement Levels.
S. Bradner, RFC 2119 S. Bradner, RFC 2119
^L ^L
APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery
The following IPv4 multicast groups are used to support Neighbor 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 all-nodes multicast address
- the administratively-scoped IPv4 multicast address used to - the administratively-scoped IPv4 multicast address used to
reach all nodes in the local IPv4 domain supporting this reach all nodes in the local IPv4 domain supporting this
specification. 239.OLS.0.1 specification. 239.OLS.0.1
all-routers multicast address all-routers multicast address
- the administratively-scoped IPv4 multicast address to reach - the administratively-scoped IPv4 multicast address to reach
all routers in the local IPv4 domain supporting this all routers in the local IPv4 domain supporting this
specification. 239.OLS.0.2 specification. 239.OLS.0.2
solicited-node multicast address solicited-node multicast address
- an administratively scoped multicast address that is computed - an administratively scoped multicast address that is computed
as a function of the solicited target's address by taking the as a function of the solicited target's address by taking the
IPv4 address used to form the IPv6 address and prepending the low-order 24 bits of the IPv4 address used to form the IPv6
96-bit prefix FF02:0:0:0:0:1. This is then mapped to the IPv4 address, and prepending the prefix FF02:0:0:0:0:1:FF00::/104
multicast address in the method described in this document. [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 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 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 239.OLS.Y.Z
^L ^L
Authors' Addresses Authors' Addresses
Brian E. Carpenter Brian E. Carpenter
Internet Division Internet Division
IBM United Kingdom Laboratories IBM United Kingdom Laboratories
MP 185, Hursley Park MP 185, Hursley Park
 End of changes. 18 change blocks. 
29 lines changed or deleted 39 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/