One document matched: draft-carpenter-ipng-6over4-01.txt
Differences from draft-carpenter-ipng-6over4-00.txt
IETF B. Carpenter
Internet Draft C. Jung
March 1997
Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
Abstract
draft-carpenter-ipng-6over4-01.txt
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
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
domain, preferably supporting IPv4 multicast, as their virtual local
link.
Originally submitted to the IPNG WG, this draft will be discussed in
the NGTRANS WG, ngtrans[-request]@sunroof.Eng.Sun.COM.
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).
Carpenter, Jung Expires September 1997 [Page 1]
Internet Draft Transmission of IPv6 Packets over IPv4 March 1997
Table of Contents:
Status of this Memo.............................................1
1. Introduction.................................................3
2. Maximum Transmission Unit....................................3
3. Frame Format.................................................4
4. Stateless Autoconfiguration and Link-Local Addresses.........5
5. Address Mapping -- Unicast...................................6
6. Address Mapping -- Multicast.................................6
7. Mechanism in the absence of IPv4 multicast...................7
8. Scaling and Transition Isues.................................7
9. Security considerations......................................8
Acknowledgements................................................8
References......................................................9
Authors' Addresses..............................................9
APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery....10
Carpenter, Jung Expires September 1997 [Page 2]
Internet Draft Transmission of IPv6 Packets over IPv4 March 1997
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 on which there is at least
one IPv6 router and at least one IPv6 host 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, and Neighbor Advertisement messages described
in [DISC], when those messages are transmitted on an IPv4 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.
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 domain is 1480
octets. This size may be varied by a Router Advertisement [DISC]
containing an MTU option which specifies a different MTU, or by
manual configuration of each node.
Note that if by accident the IPv6 MTU size proves to be too large for
some intermediate IPv4 subnet, IPv4 fragmentation will ensue. While
undesirable, this is not disastrous.
Carpenter, Jung Expires September 1997 [Page 3]
Internet Draft Transmission of IPv6 Packets over IPv4 March 1997
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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol 41 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 header and payload ... /
+-------+-------+-------+-------+-------+------+------+
If there are IPv4 options, then padding SHOULD added to the IPv4
header such that the IPv6 header starts on a boundary that is a 32-
bit offset from the end of the datalink header.
The Time to Live field SHOULD be set to a low value, to prevent such
packets accidentally leaking from the IPv4 domain. This MUST be a
configurable parameter, with a recommended default of 8.
Carpenter, Jung Expires September 1997 [Page 4]
Internet Draft Transmission of IPv6 Packets over IPv4 March 1997
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 no more than 80 bits in length, and if less
than 80 bits, the bits in the gap are set to zero.
The IPv6 Link-local address [AARCH] for an IPv4 virtual interface is
formed by appending the interface's zero-padded IPv4 address to the
prefix FE80::.
+-------+-------+-------+-------+-------+-------+------+------+
| FE 80 00 00 00 00 00 00 |
+-------+-------+-------+-------+-------+-------+------+------+
| 00 00 | 00 | 00 | IPv4 Address |
+-------+-------+-------+-------+-------+-------+------+------+
Carpenter, Jung Expires September 1997 [Page 5]
Internet Draft Transmission of IPv6 Packets over IPv4 March 1997
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.
Since the length field is in units of 8 bytes, the value below is 1.
+-------+-------+-------+-------+-------+-------+-------+-------+
| 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
address used as the address token for stateless autoconfiguration
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 domain over which
operation of IPv6 over IPv4 is desired.
See appendix A. for a list of all the multicast groups that must be
joined to support Neighbor Discovery.
Carpenter, Jung Expires September 1997 [Page 6]
Internet Draft Transmission of IPv6 Packets over IPv4 March 1997
7. Mechanism in the absence of IPv4 multicast
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 used.
One option is to use a configured tunnel to an IPv6 router as
specified in [DISC]. However, this does not support multicast.
Another option is to use exactly the same formats as defined in 2
through 5 above, but to transmit all packets to a "standard tunnel",
either to a configured unicast address or to a well-known ("anycast")
IPv4 address TBD3 used by convention for all IPv6 routers
implementing this specification. A route to this address MUST be
injected into the routing system of the IPv4 domain.
In this case the IPv6 router MUST handle IPv6 multicast packets by
replication to all relevant IPv6 destinations (i.e. all those that
have joined the relevant multicast group). Thus the sending rule in
the router MUST be modified accordingly.
8. Scaling and Transition Isues
The multicast mechanism described in Section 6 above appears to have
essentially the same scaling properties as native IPv6 over most
media, except for the slight reduction in MTU size which will
slightly reduce bulk throughput. On an ATM network, where IPv4
multicast relies on relatively complex mechanisms, it is to be
expected that IPv6 over IPv4 over ATM will perform less well than
native IPv6 over ATM.
The standard tunnel mechanism described in Section 8, 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
range of options available for transition from IPv4 to IPv6. In
particular it allows a site to run both IPv4 and IPv6 in coexistence,
without having to configure IPv6 hosts either with IPv4-compatible
addresses or with tunnels. Interfaces of the IPv6 router and hosts
will of course need to be enabled in "IPv6 over IPv4" mode
A site may choose to start its IPv6 transition by configuring one
IPv6 router to support "IPv6 over IPv4" on an interface connected to
the site's IPv4 domain, and another IPv6 format on an interface
connected to the IPv6 Internet. Any enabled "IPv6 over IPv4" hosts in
the IPv4 domain will then be able to communicate both with the router
and with the IPv6 Internet, without manual configuration of a tunnel
and without the need for an IPv4-compatible IPv6 address, either
stateless or stateful address configuration providing the Ipv6
address to the Ipv6 host.
Carpenter, Jung Expires September 1997 [Page 7]
Internet Draft Transmission of IPv6 Packets over IPv4 March 1997
As the site installs additional IPv6 routers, "IPv6 over IPv4" hosts
which become physically adjacent to IPv6 routers can be changed to
run as native IPv6 hosts, with the the only impact on IPv6
applications being a slight increase in MTU size.
9. 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
invaluable comments from Matt Crawford, Steve Deering, Dan
Harrington, and members of the IPNG and NGTRANS working groups. This
document is seriously ripped off from RFC 1972 written by Matt
Crawford.
Carpenter, Jung Expires September 1997 [Page 8]
Internet Draft Transmission of IPv6 Packets over IPv4 March 1997
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.
[RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.,
Lear, E., "Address Allocation for Private Internets",
RFC 1918, February 1996
Authors' Addresses
Brian E Carpenter
IBM United Kingdom Laboratories
MP 185, Hursley Park phone: +44 1962 816833
Winchester, Hampshire SO21 2JN, UK fax: +44 1962 818101
Email: brian@hursley.ibm.com
Cyndi Jung
3Com Corporation
5400 Bayfront Plaza
Santa Clara, California
Email: cmj@NSD.3Com.com
Carpenter, Jung Expires September 1997 [Page 9]
Internet Draft Transmission of IPv6 Packets over IPv4 March 1997
APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery
The following IPv4 multicast groups are used to support Neighbor
Discovery with this specification.
all-nodes multicast address
- the administratively-scoped IPv4 multicast address used
to reach all nodes in the local IPv4 domain supporting
this specification. TBD2.0.0.1
all-routers multicast address
- the administratively-scoped IPv4 multicast address to
reach all routers in the local IPv4 domain supporting
this specification. TBD2.0.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. For example, if the IPv4
address used to form the IPv6 address is W.X.Y.Z, then
the corresponding IPv4 multicast address is TBD2.X.Y.Z
and the IPv6 multicast address is FF02:0:0:0:0:1:W.X.Y.Z.
Carpenter, Jung Expires September 1997 [Page 10]
Internet Draft Transmission of IPv6 Packets over IPv4 March 1997
Carpenter, Jung Expires September 1997 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 06:54:34 |