draft-ietf-ipngwg-6over4-00.txt   draft-ietf-ipngwg-6over4-01.txt 
IETF B. Carpenter, IBM IETF B. Carpenter, IBM
Internet Draft C. Jung, 3Com Internet Draft C. Jung, 3Com
October 1998 December 1998
Transmission of IPv6 over IPv4 Domains without Explicit Tunnels Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
draft-ietf-ipngwg-6over4-00.txt draft-ietf-ipngwg-6over4-01.txt
(revised from draft-carpenter-ipng-6over4-04.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 50 skipping to change at page 1, line 49
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 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
6. Address Mapping -- Multicast....................................5 6. Address Mapping -- Multicast....................................5
7. Mechanism in the absence of IPv4 multicast......................5 7. Scaling and Transition Isues....................................5
8. Scaling and Transition Isues....................................5 8. IANA considerations.............................................6
9. Security considerations.........................................6 9. Security considerations.........................................6
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 "domains". For the purposes of this document, an IPv4 domain is a
| fully interconnected set of IPv4 subnets, within the same local 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 to this specification. This IPv4 domain could form part of the globally- conforming to this specification. This IPv4 domain could form part of the
unique IPv4 address space, or could form part of a private IPv4 globally-unique IPv4 address space, or could form part of a private IPv4
network [RFC 1918]. 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. 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 domain
as their virtual local link. Thus, at least one IPv6 router using 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 the same method must be connected to the same IPv4 domain if IPv6
routing to other links is required. 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].
^L ^L
2. Maximum Transmission Unit 2. Maximum Transmission Unit
The default MTU size for IPv6 packets on an IPv4 domain is 1480 The default MTU size for IPv6 packets on an IPv4 domain is 1480
octets. This size may be varied by a Router Advertisement [DISC] octets. This size may be varied by a Router Advertisement [DISC]
containing an MTU option which specifies a different MTU, or by containing an MTU option which specifies a different MTU, or by
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.
skipping to change at page 4, line 19 skipping to change at page 4, line 19
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 of an
| IPv4 interface MUST have a length of 64 bits except for a special IPv4 interface MUST have a length of 64 bits except for a special
| case mentioned in Section 8. 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 5, line 9 skipping to change at page 5, line 9
IPv4 Address: IPv4 Address:
The 32 bit IPv4 address, in network byte order. This is the 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 the interface currently responds to, and may be different from the
Interface Identifier for stateless autoconfiguration. Interface Identifier for stateless autoconfiguration.
^L ^L
6. Address Mapping -- Multicast 6. Address Mapping -- Multicast
If IPv4 multicast is available, an IPv6 packet with a multicast IPv4 multicast MUST be available. An IPv6 packet with a multicast
destination address DST MUST be transmitted to the IPv4 multicast destination address DST MUST be transmitted to the IPv4 multicast
address of Organization-Local Scope using the mapping below. These address of Organization-Local Scope using the mapping below. These
IPv4 multicast addresses SHOULD be taken from the block 239.192.0.0/16, 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 a sub-block of the Organization-Local Scope address block, or, if
all of those are not available, from the expansion blocks all of those are not available, from the expansion blocks
| defined in [ADMIN]. Note that when they are formed defined in [ADMIN]. Note that when they are formed
using the expansion blocks, they use only a /16 sized block. using the expansion blocks, they use only a /16 sized block.
+-------+-------+-------+-------+ +-------+-------+-------+-------+
| 239 | OLS | DST14 | DST15 | | 239 | OLS | DST14 | DST15 |
+-------+-------+-------+-------+ +-------+-------+-------+-------+
DST14, DST15 last two bytes of IPv6 multicast address. DST14, DST15 last two bytes of IPv6 multicast address.
OLS from the configured Organization-Local OLS from the configured Organization-Local
| Scope address block. SHOULD be 192, Scope address block. SHOULD be 192,
| see [ADMIN] for details. see [ADMIN] for details.
| No new IANA registration procedures are required for the above. No new IANA registration procedures are required for the above.
See appendix A. for a list of all the multicast groups that must be See appendix A. for a list of all the multicast groups that must be
joined to support Neighbor Discovery. joined to support Neighbor Discovery.
7. Mechanism in the absence of IPv4 multicast 7. Scaling and Transition Issues
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 The multicast mechanism described in Section 6 above appears to have
essentially the same scaling properties as native IPv6 over most essentially the same scaling properties as native IPv6 over most
media, except for the slight reduction in MTU size which will media, except for the slight reduction in MTU size which will
slightly reduce bulk throughput. On an ATM network, where IPv4 slightly reduce bulk throughput. On an ATM network, where IPv4
multicast relies on relatively complex mechanisms, it is to be multicast relies on relatively complex mechanisms, it is to be
^L
expected that IPv6 over IPv4 over ATM will perform less well than expected that IPv6 over IPv4 over ATM will perform less well than
native IPv6 over ATM. 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 The "IPv6 over IPv4" mechanism is intended to take its place in the
range of options available for transition from IPv4 to IPv6. In range of options available for transition from IPv4 to IPv6. In
particular it allows a site to run both IPv4 and IPv6 in coexistence, particular it allows a site to run both IPv4 and IPv6 in coexistence,
without having to configure IPv6 hosts either with IPv4-compatible without having to configure IPv6 hosts either with IPv4-compatible
addresses or with tunnels. Interfaces of the IPv6 router and hosts addresses or with tunnels. Interfaces of the IPv6 router and hosts
will of course need to be enabled in "6over4" mode. will of course need to be enabled in "6over4" mode.
A site may choose to start its IPv6 transition by configuring one A site may choose to start its IPv6 transition by configuring one
IPv6 router to support "6over4" on an interface connected to IPv6 router to support "6over4" on an interface connected to
the site's IPv4 domain, and another IPv6 format on an interface the site's IPv4 domain, and another IPv6 format on an interface
connected to the IPv6 Internet. Any enabled "6over4" hosts connected to the IPv6 Internet. Any enabled "6over4" hosts
in the IPv4 domain will then be able to communicate both with the in the IPv4 domain will then be able to communicate both with the
router and with the IPv6 Internet, without manual configuration of a router and with the IPv6 Internet, without manual configuration of a
tunnel and without the need for an IPv4-compatible IPv6 address, tunnel and without the need for an IPv4-compatible IPv6 address,
either stateless or stateful address configuration providing the IPv6 either stateless or stateful address configuration providing the IPv6
address to the IPv6 host. address to the IPv6 host.
| During transition, routers may need to advertise at least two ^L
| IPv6 prefixes, one for the native LAN (e.g. Ethernet) and one for During transition, routers may need to advertise at least two
| "6over4." As with any IPv6 prefix assigned to an IPv6 subnet, the IPv6 prefixes, one for the native LAN (e.g. Ethernet) and one for
| latter MUST be unique within its scope, whether site-local or "6over4." As with any IPv6 prefix assigned to an IPv6 subnet, the
| global addressing is used. 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 Also note that when a router is handling both native LAN and
| "6over4" on the same physical interface, during "6over4" on the same physical interface, during
| stateless autoconfiguration, there is a period when IPv6 link-local stateless autoconfiguration, there is a period when IPv6 link-local
| addresses are used, in both cases with the prefix FE80::/64. addresses are used, in both cases with the prefix FE80::/64.
| Note that the prefix-length for these link-local adddress MUST Note that the prefix-length for these link-local adddress MUST
| then be 128 so that the two cases can be distinguished. then be 128 so that the two cases can be distinguished.
As the site installs additional IPv6 routers, "6over4" hosts As the site installs additional IPv6 routers, "6over4" hosts
which become physically adjacent to IPv6 routers can be changed to which become physically adjacent to IPv6 routers can be changed to
run as native IPv6 hosts, with the the only impact on IPv6 run as native IPv6 hosts, with the the only impact on IPv6
applications being a slight increase in MTU size. At some stage applications being a slight increase in MTU size. At some stage
| during transition, it might be convenient to dual home hosts during transition, it might be convenient to dual home hosts
| in both native LAN and "6over4" mode, but this is not required. in both native LAN and "6over4" mode, but this is not required.
8. IANA considerations
No assignments by the IANA are required beyond those in [ADMIN].
9. Security considerations 9. Security considerations
Implementors should be aware that, in addition to posssible attacks Implementors should be aware that, in addition to posssible attacks
against IPv6, security attacks against IPv4 must also be considered. against IPv6, security attacks against IPv4 must also be considered.
^L
Use of IP security at both IPv4 and IPv6 levels should nevertheless Use of IP security at both IPv4 and IPv6 levels should nevertheless
be avoided, for efficiency reasons. For example, if IPv6 is running be avoided, for efficiency reasons. For example, if IPv6 is running
encrypted, encryption of IPv4 would be redundant except if traffic encrypted, encryption of IPv4 would be redundant except if traffic
analysis is felt to be a threat. If IPv6 is running authenticated, analysis is felt to be a threat. If IPv6 is running authenticated,
then authentication of IPv4 will add little. Conversely, IPv4 then authentication of IPv4 will add little. Conversely, IPv4
security will not protect IPv6 traffic once it leaves the IPv6-over- security will not protect IPv6 traffic once it leaves the IPv6-over-
IPv4 domain. Therefore, implementing IPv6 security is required even IPv4 domain. Therefore, implementing IPv6 security is required even
if IPv4 security is available. if IPv4 security is available.
| 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 an access control list.
^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, and
other members of the IPNG and NGTRANS working groups. 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.
 End of changes. 20 change blocks. 
68 lines changed or deleted 52 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/