Request for Comments: 4213 Sun Microsystems, Inc.
Obsoletes: 2893 R. Gilligan
Category: Standards Track Intransa, Inc.
October 2005
Basic Transition Mechanisms for IPv6 Hosts and Routers
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document specifies IPv4 compatibility mechanisms that can be
implemented by IPv6 hosts and routers. Two mechanisms are specified,
dual stack and configured tunneling. Dual stack implies providing
complete implementations of both versions of the Internet Protocol
(IPv4 and IPv6), and configured tunneling provides a means to carry
IPv6 packets over unmodified IPv4 routing infrastructures.
This document obsoletes RFC 2893.
Table of Contents
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Dual IP Layer Operation .........................................4
2.1. Address Configuration ......................................5
2.2. DNS ........................................................5
3. Configured Tunneling Mechanisms .................................6
3.1. Encapsulation ..............................................7
3.2. Tunnel MTU and Fragmentation ...............................8
3.2.1. Static Tunnel MTU ...................................9
3.2.2. Dynamic Tunnel MTU ..................................9
3.3. Hop Limit .................................................11
3.4. Handling ICMPv4 Errors ....................................11
3.5. IPv4 Header Construction ..................................13
3.6. Decapsulation .............................................14
3.7. Link-Local Addresses ......................................17
3.8. Neighbor Discovery over Tunnels ...........................18
4. Threat Related to Source Address Spoofing ......................18
5. Security Considerations ........................................19
6. Acknowledgements ...............................................21
7. References .....................................................21
7.1. Normative References ......................................21
7.2. Informative References ....................................21
8. Changes from RFC 2893 ..........................................23
1. Introduction
The key to a successful IPv6 transition is compatibility with the
large installed base of IPv4 hosts and routers. Maintaining
compatibility with IPv4 while deploying IPv6 will streamline the task
of transitioning the Internet to IPv6. This specification defines
two mechanisms that IPv6 hosts and routers may implement in order to
be compatible with IPv4 hosts and routers.
The mechanisms in this document are designed to be employed by IPv6
hosts and routers that need to interoperate with IPv4 hosts and
utilize IPv4 routing infrastructures. We expect that most nodes in
the Internet will need such compatibility for a long time to come,
and perhaps even indefinitely.
The mechanisms specified here are:
- Dual IP layer (also known as dual stack): A technique for
providing complete support for both Internet protocols -- IPv4 and
IPv6 -- in hosts and routers.
- Configured tunneling of IPv6 over IPv4: A technique for
establishing point-to-point tunnels by encapsulating IPv6 packets
within IPv4 headers to carry them over IPv4 routing
infrastructures.
The mechanisms defined here are intended to be the core of a
"transition toolbox" -- a growing collection of techniques that
implementations and users may employ to ease the transition. The
tools may be used as needed. Implementations and sites decide which
techniques are appropriate to their specific needs.
This document defines the basic set of transition mechanisms, but
these are not the only tools available. Additional transition and
compatibility mechanisms are specified in other documents.
1.1. Terminology
The following terms are used in this document:
Types of Nodes
IPv4-only node:
A host or router that implements only IPv4. An IPv4-only node
does not understand IPv6. The installed base of IPv4 hosts and
routers existing before the transition begins are IPv4-only
nodes.
IPv6/IPv4 node:
A host or router that implements both IPv4 and IPv6.
IPv6-only node:
A host or router that implements IPv6 and does not implement
IPv4. The operation of IPv6-only nodes is not addressed in
this memo.
IPv6 node:
Any host or router that implements IPv6. IPv6/IPv4 and IPv6-
only nodes are both IPv6 nodes.
IPv4 node:
Any host or router that implements IPv4. IPv6/IPv4 and IPv4-
only nodes are both IPv4 nodes.
Techniques Used in the Transition
IPv6-over-IPv4 tunneling:
The technique of encapsulating IPv6 packets within IPv4 so that
they can be carried across IPv4 routing infrastructures.
Configured tunneling:
IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint
address(es) are determined by configuration information on
tunnel endpoints. All tunnels are assumed to be bidirectional.
The tunnel provides a (virtual) point-to-point link to the IPv6
layer, using the configured IPv4 addresses as the lower-layer
endpoint addresses.
Other transition mechanisms, including other tunneling mechanisms,
are outside the scope of this document.
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119].
2. Dual IP Layer Operation
The most straightforward way for IPv6 nodes to remain compatible with
IPv4-only nodes is by providing a complete IPv4 implementation. IPv6
nodes that provide complete IPv4 and IPv6 implementations are called
"IPv6/IPv4 nodes". IPv6/IPv4 nodes have the ability to send and
receive both IPv4 and IPv6 packets. They can directly interoperate
with IPv4 nodes using IPv4 packets, and also directly interoperate
with IPv6 nodes using IPv6 packets.
Even though a node may be equipped to support both protocols, one or
the other stack may be disabled for operational reasons. Here we use
a rather loose notion of "stack". A stack being enabled has IP
addresses assigned, but whether or not any particular application is
available on the stacks is explicitly not defined. Thus, IPv6/IPv4
nodes may be operated in one of three modes:
- With their IPv4 stack enabled and their IPv6 stack disabled.
- With their IPv6 stack enabled and their IPv4 stack disabled.
- With both stacks enabled.
IPv6/IPv4 nodes with their IPv6 stack disabled will operate like
IPv4-only nodes. Similarly, IPv6/IPv4 nodes with their IPv4 stacks
disabled will operate like IPv6-only nodes. IPv6/IPv4 nodes MAY
provide a configuration switch to disable either their IPv4 or IPv6
stack.
The configured tunneling technique, which is described in Section 3,
may or may not be used in addition to the dual IP layer operation.
2.1. Address Configuration
Because the nodes support both protocols, IPv6/IPv4 nodes may be
configured with both IPv4 and IPv6 addresses. IPv6/IPv4 nodes use
IPv4 mechanisms (e.g., DHCP) to acquire their IPv4 addresses, and
IPv6 protocol mechanisms (e.g., stateless address autoconfiguration
[RFC2462] and/or DHCPv6) to acquire their IPv6 addresses.
2.2. DNS
The Domain Naming System (DNS) is used in both IPv4 and IPv6 to map
between hostnames and IP addresses. A new resource record type named
"AAAA" has been defined for IPv6 addresses [RFC3596]. Since
IPv6/IPv4 nodes must be able to interoperate directly with both IPv4
and IPv6 nodes, they must provide resolver libraries capable of
dealing with IPv4 "A" records as well as IPv6 "AAAA" records. Note
that the lookup of A versus AAAA records is independent of whether
the DNS packets are carried in IPv4 or IPv6 packets and that there is
no assumption that the DNS servers know the IPv4/IPv6 capabilities of
the requesting node.
The issues and operational guidelines for using IPv6 with DNS are
described at more length in other documents, e.g., [DNSOPV6].
DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of handling
both AAAA and A records. However, when a query locates an AAAA
record holding an IPv6 address, and an A record holding an IPv4
address, the resolver library MAY order the results returned to the
application in order to influence the version of IP packets used to
communicate with that specific node -- IPv6 first, or IPv4 first.
The applications SHOULD be able to specify whether they want IPv4,
IPv6, or both records [RFC3493]. That defines which address families
the resolver looks up. If there is not an application choice, or if
the application has requested both, the resolver library MUST NOT
filter out any records.
Since most applications try the addresses in the order they are
returned by the resolver, this can affect the IP version "preference"
of applications.
The actual ordering mechanisms are out of scope of this memo.
Address selection is described at more length in [RFC3484].
3. Configured Tunneling Mechanisms
In most deployment scenarios, the IPv6 routing infrastructure will be
built up over time. While the IPv6 infrastructure is being deployed,
the existing IPv4 routing infrastructure can remain functional and
can be used to carry IPv6 traffic. Tunneling provides a way to
utilize an existing IPv4 routing infrastructure to carry IPv6
traffic.
IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of
IPv4 routing topology by encapsulating them within IPv4 packets.
Tunneling can be used in a variety of ways:
- Router-to-Router. IPv6/IPv4 routers interconnected by an IPv4
infrastructure can tunnel IPv6 packets between themselves. In
this case, the tunnel spans one segment of the end-to-end path
that the IPv6 packet takes.
- Host-to-Router. IPv6/IPv4 hosts can tunnel IPv6 packets to an
intermediary IPv6/IPv4 router that is reachable via an IPv4
infrastructure. This type of tunnel spans the first segment of
the packet’s end-to-end path.
- Host-to-Host. IPv6/IPv4 hosts that are interconnected by an IPv4
infrastructure can tunnel IPv6 packets between themselves. In
this case, the tunnel spans the entire end-to-end path that the
packet takes.
- Router-to-Host. IPv6/IPv4 routers can tunnel IPv6 packets to
their final destination IPv6/IPv4 host. This tunnel spans only
the last segment of the end-to-end path.
Configured tunneling can be used in all of the above cases, but it is
most likely to be used router-to-router due to the need to explicitly
configure the tunneling endpoints.
The underlying mechanisms for tunneling are:
- The entry node of the tunnel (the encapsulator) creates an
encapsulating IPv4 header and transmits the encapsulated packet.
- The exit node of the tunnel (the decapsulator) receives the
encapsulated packet, reassembles the packet if needed, removes the
IPv4 header, and processes the received IPv6 packet.
- The encapsulator may need to maintain soft-state information for
each tunnel recording such parameters as the MTU of the tunnel in
order to process IPv6 packets forwarded into the tunnel.
In configured tunneling, the tunnel endpoint addresses are determined
in the encapsulator from configuration information stored for each
tunnel. When an IPv6 packet is transmitted over a tunnel, the
destination and source addresses for the encapsulating IPv4 header
are set as described in Section 3.5.
The determination of which packets to tunnel is usually made by
routing information on the encapsulator. This is usually done via a
routing table, which directs packets based on their destination
address using the prefix mask and match technique.
The decapsulator matches the received protocol-41 packets to the
tunnels it has configured, and allows only the packets in which IPv4
source addresses match the tunnels configured on the decapsulator.
Therefore, the operator must ensure that the tunnel’s IPv4 address
configuration is the same both at the encapsulator and the
decapsulator.
3.1. Encapsulation
The encapsulation of an IPv6 datagram in IPv4 is shown below:
+-------------+
| IPv4 |
| Header |
+-------------+ +-------------+
| IPv6 | | IPv6 |
| Header | | Header |
+-------------+ +-------------+
| Transport | | Transport |
| Layer | ===> | Layer |
| Header | | Header |
+-------------+ +-------------+
| | | |
~ Data ~ ~ Data ~
| | | |
+-------------+ +-------------+
Encapsulating IPv6 in IPv4
In addition to adding an IPv4 header, the encapsulator also has to
handle some more complex issues:
- Determine when to fragment and when to report an ICMPv6 "packet
too big" error back to the source.
- How to reflect ICMPv4 errors from routers along the tunnel path
back to the source as ICMPv6 errors.
Those issues are discussed in the following sections.
3.2. Tunnel MTU and Fragmentation
Naively, the encapsulator could view encapsulation as IPv6 using IPv4
as a link layer with a very large MTU (65535-20 bytes at most; 20
bytes "extra" are needed for the encapsulating IPv4 header). The
encapsulator would only need to report ICMPv6 "packet too big" errors
back to the source for packets that exceed this MTU. However, such a
scheme would be inefficient or non-interoperable for three reasons
and therefore MUST NOT be used:
1) It would result in more fragmentation than needed. IPv4 layer
fragmentation should be avoided due to the performance problems
caused by the loss unit being smaller than the retransmission unit
[KM97].
2) Any IPv4 fragmentation occurring inside the tunnel, i.e., between
the encapsulator and the decapsulator, would have to be
reassembled at the tunnel endpoint. For tunnels that terminate at
a router, this would require additional memory and other resources
to reassemble the IPv4 fragments into a complete IPv6 packet
before that packet could be forwarded.
3) The encapsulator has no way of knowing that the decapsulator is
able to defragment such IPv4 packets (see Section 3.6 for
details), and has no way of knowing that the decapsulator is able
to handle such a large IPv6 Maximum Receive Unit (MRU).
Hence, the encapsulator MUST NOT treat the tunnel as an interface
with an MTU of 64 kilobytes, but instead either use the fixed static
MTU or OPTIONAL dynamic MTU determination based on the IPv4 path MTU
to the tunnel endpoint.
If both the mechanisms are implemented, the decision of which to use
SHOULD be configurable on a per-tunnel endpoint basis.
3.2.1. Static Tunnel MTU
A node using static tunnel MTU treats the tunnel interface as having
a fixed-interface MTU. By default, the MTU MUST be between 1280 and
1480 bytes (inclusive), but it SHOULD be 1280 bytes. If the default
is not 1280 bytes, the implementation MUST have a configuration knob
that can be used to change the MTU value.
A node must be able to accept a fragmented IPv6 packet that, after
reassembly, is as large as 1500 octets [RFC2460]. This memo also
includes requirements (see Section 3.6) for the amount of IPv4
reassembly and IPv6 MRU that MUST be supported by all the
decapsulators. These ensure correct interoperability with any fixed
MTUs between 1280 and 1480 bytes.
A larger fixed MTU than supported by these requirements must not be
configured unless it has been administratively ensured that the
decapsulator can reassemble or receive packets of that size.
The selection of a good tunnel MTU depends on many factors, at least:
- Whether the IPv4 protocol-41 packets will be transported over
media that may have a lower path MTU (e.g., IPv4 Virtual Private
Networks); then picking too high a value might lead to IPv4
fragmentation.
- Whether the tunnel is used to transport IPv6 tunneled packets
(e.g., a mobile node with an IPv6-in-IPv4 configured tunnel, and
an IPv6-in-IPv6 tunnel interface); then picking too low a value
might lead to IPv6 fragmentation.
If layered encapsulation is believed to be present, it may be prudent
to consider supporting dynamic MTU determination instead as it is
able to minimize fragmentation and optimize packet sizes.
When using the static tunnel MTU, the Don’t Fragment bit MUST NOT be
set in the encapsulating IPv4 header. As a result, the encapsulator
should not receive any ICMPv4 "packet too big" messages as a result
of the packets it has encapsulated.
3.2.2. Dynamic Tunnel MTU
The dynamic MTU determination is OPTIONAL. However, if it is
implemented, it SHOULD have the behavior described in this document.
The fragmentation inside the tunnel can be reduced to a minimum by
having the encapsulator track the IPv4 path MTU across the tunnel,
using the IPv4 Path MTU Discovery Protocol [RFC1191] and recording
the resulting path MTU. The IPv6 layer in the encapsulator can then
view a tunnel as a link layer with an MTU equal to the IPv4 path MTU,
minus the size of the encapsulating IPv4 header.
Note that this does not eliminate IPv4 fragmentation in the case when
the IPv4 path MTU would result in an IPv6 MTU less than 1280 bytes.
(Any link layer used by IPv6 has to have an MTU of at least 1280
bytes [RFC2460].) In this case, the IPv6 layer has to "see" a link
layer with an MTU of 1280 bytes and the encapsulator has to use IPv4
fragmentation in order to forward the 1280 byte IPv6 packets.
The encapsulator SHOULD employ the following algorithm to determine
when to forward an IPv6 packet that is larger than the tunnel’s path
MTU using IPv4 fragmentation, and when to return an ICMPv6 "packet
too big" message per [RFC1981]:
if (IPv4 path MTU - 20) is less than 1280
if packet is larger than 1280 bytes
Send ICMPv6 "packet too big" with MTU = 1280.
Drop packet.
else
Encapsulate but do not set the Don’t Fragment
flag in the IPv4 header. The resulting IPv4
packet might be fragmented by the IPv4 layer
on the encapsulator or by some router along
the IPv4 path.
endif
else
if packet is larger than (IPv4 path MTU - 20)
Send ICMPv6 "packet too big" with
MTU = (IPv4 path MTU - 20).
Drop packet.
else
Encapsulate and set the Don’t Fragment flag
in the IPv4 header.
endif
endif
Encapsulators that have a large number of tunnels may choose between
dynamic versus static tunnel MTUs on a per-tunnel endpoint basis. In
cases where the number of tunnels that any one node is using is
large, it is helpful to observe that this state information can be
cached and discarded when not in use.
Note that using dynamic tunnel MTU is subject to IPv4 path MTU
blackholes should the ICMPv4 "packet too big" messages be dropped by
firewalls or not generated by the routers [RFC1435, RFC2923].
3.3. Hop Limit
IPv6-over-IPv4 tunnels are modeled as "single-hop" from the IPv6
perspective. The tunnel is opaque to users of the network, and it is
not detectable by network diagnostic tools such as traceroute.
The single-hop model is implemented by having the encapsulators and
decapsulators process the IPv6 hop limit field as they would if they
were forwarding a packet on to any other datalink. That is, they
decrement the hop limit by 1 when forwarding an IPv6 packet. (The
originating node and final destination do not decrement the hop
limit.)
The TTL of the encapsulating IPv4 header is selected in an
implementation-dependent manner. The current suggested value is
published in the "Assigned Numbers" RFC [RFC3232][ASSIGNED].
Implementations MAY provide a mechanism to allow the administrator to
configure the IPv4 TTL as the IP Tunnel MIB [RFC4087].
3.4. Handling ICMPv4 Errors
In response to encapsulated packets it has sent into the tunnel, the
encapsulator might receive ICMPv4 error messages from IPv4 routers
inside the tunnel. These packets are addressed to the encapsulator
because it is the IPv4 source of the encapsulated packet.
ICMPv4 error handling is only applicable to dynamic MTU