One document matched: draft-carpenter-ipng-6over4-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 06:55:43 |