📄 rfc2893.txt
字号:
- IPv6/IPv4 node that does not perform tunneling.
- IPv6/IPv4 node that performs configured tunneling only.
- IPv6/IPv4 node that performs configured tunneling and automatic
tunneling.
Gilligan & Nordmark Standards Track [Page 6]
RFC 2893 IPv6 Transition Mechanisms August 2000
2.1. Address Configuration
Because they 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) to
acquire their IPv6-native addresses. Section 5.2 describes a
mechanism by which IPv6/IPv4 nodes that support automatic tunneling
MAY use IPv4 protocol mechanisms to acquire their IPv4-compatible
IPv6 address.
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
"A6" has been defined for IPv6 addresses [6] with support for an
earlier record named "AAAA". 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 "A6" and "AAAA" records.
DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of handling
both A6/AAAA and A records. However, when a query locates an A6/AAAA
record holding an IPv6 address, and an A record holding an IPv4
address, the resolver library MAY filter or order the results
returned to the application in order to influence the version of IP
packets used to communicate with that node. In terms of filtering,
the resolver library has three alternatives:
- Return only the IPv6 address to the application.
- Return only the IPv4 address to the application.
- Return both addresses to the application.
If it returns only the IPv6 address, the application will communicate
with the node using IPv6. If it returns only the IPv4 address, the
application will communicate with the node using IPv4. If it returns
both addresses, the application will have the choice which address to
use, and thus which IP protocol to employ.
If it returns both, the resolver MAY elect to order the addresses --
IPv6 first, or IPv4 first. Since most applications try the addresses
in the order they are returned by the resolver, this can affect the
IP version "preference" of applications.
Gilligan & Nordmark Standards Track [Page 7]
RFC 2893 IPv6 Transition Mechanisms August 2000
The decision to filter or order DNS results is implementation
specific. IPv6/IPv4 nodes MAY provide policy configuration to
control filtering or ordering of addresses returned by the resolver,
or leave the decision entirely up to the application.
An implementation MUST allow the application to control whether or
not such filtering takes place.
2.3. Advertising Addresses in the DNS
There are some constraint placed on the use of the DNS during
transition. Most of these are obvious but are stated here for
completeness.
The recommendation is that A6/AAAA records for a node should not be
added to the DNS until all of these are true:
1) The address is assigned to the interface on the node.
2) The address is configured on the interface.
3) The interface is on a link which is connected to the IPv6
infrastructure.
If an IPv6 node is isolated from an IPv6 perspective (e.g. it is not
connected to the 6bone to take a concrete example) constraint #3
would mean that it should not have an address in the DNS.
This works great when other dual stack nodes tries to contact the
isolated dual stack node. There is no IPv6 address in the DNS thus
the peer doesn't even try communicating using IPv6 but goes directly
to IPv4 (we are assuming both nodes have A records in the DNS.)
However, this does not work well when the isolated node is trying to
establish communication. Even though it does not have an IPv6
address in the DNS it will find A6/AAAA records in the DNS for the
peer. Since the isolated node has IPv6 addresses assigned to at
least one interface it will try to communicate using IPv6. If it has
no IPv6 route to the 6bone (e.g. because the local router was
upgraded to advertise IPv6 addresses using Neighbor Discovery but
that router doesn't have any IPv6 routes) this communication will
fail. Typically this means a few minutes of delay as TCP times out.
The TCP specification says that ICMP unreachable messages could be
due to routing transients thus they should not immediately terminate
the TCP connection. This means that the normal TCP timeout of a few
minutes apply. Once TCP times out the application will hopefully try
the IPv4 addresses based on the A records in the DNS, but this will
be painfully slow.
Gilligan & Nordmark Standards Track [Page 8]
RFC 2893 IPv6 Transition Mechanisms August 2000
A possible implication of the recommendations above is that, if one
enables IPv6 on a node on a link without IPv6 infrastructure, and
choose to add A6/AAAA records to the DNS for that node, then external
IPv6 nodes that might see these A6/AAAA records will possibly try to
reach that node using IPv6 and suffer delays or communication failure
due to unreachability. (A delay is incurred if the application
correctly falls back to using IPv4 if it can not establish
communication using IPv6 addresses. If this fallback is not done the
application would fail to communicate in this case.) Thus it is
suggested that either the recommendations be followed, or care be
taken to only do so with nodes that will not be impacted by external
accessing delays and/or communication failure.
In the future when a site or node removes the support for IPv4 the
above recommendations apply to when the A records for the node(s)
should be removed from the DNS.
3. Common 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.
Gilligan & Nordmark Standards Track [Page 9]
RFC 2893 IPv6 Transition Mechanisms August 2000
Tunneling techniques are usually classified according to the
mechanism by which the encapsulating node determines the address of
the node at the end of the tunnel. In the first two tunneling
methods listed above -- router-to-router and host-to-router -- the
IPv6 packet is being tunneled to a router. The endpoint of this type
of tunnel is an intermediary router which must decapsulate the IPv6
packet and forward it on to its final destination. When tunneling to
a router, the endpoint of the tunnel is different from the
destination of the packet being tunneled. So the addresses in the
IPv6 packet being tunneled can not provide the IPv4 address of the
tunnel endpoint. Instead, the tunnel endpoint address must be
determined from configuration information on the node performing the
tunneling. We use the term "configured tunneling" to describe the
type of tunneling where the endpoint is explicitly configured.
In the last two tunneling methods -- host-to-host and router-to-host
-- the IPv6 packet is tunneled all the way to its final destination.
In this case, the destination address of both the IPv6 packet and the
encapsulating IPv4 header identify the same node! This fact can be
exploited by encoding information in the IPv6 destination address
that will allow the encapsulating node to determine tunnel endpoint
IPv4 address automatically. Automatic tunneling employs this
technique, using an special IPv6 address format with an embedded IPv4
address to allow tunneling nodes to automatically derive the tunnel
endpoint IPv4 address. This eliminates the need to explicitly
configure the tunnel endpoint address, greatly simplifying
configuration.
The two tunneling techniques -- automatic and configured -- differ
primarily in how they determine the tunnel endpoint address. Most of
the underlying mechanisms are the same:
- The entry node of the tunnel (the encapsulating node) creates an
encapsulating IPv4 header and transmits the encapsulated packet.
- The exit node of the tunnel (the decapsulating node) receives the
encapsulated packet, reassembles the packet if needed, removes the
IPv4 header, updates the IPv6 header, and processes the received
IPv6 packet.
- The encapsulating node 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. Since
the number of tunnels that any one host or router may be using may
grow to be quite large, this state information can be cached and
discarded when not in use.
Gilligan & Nordmark Standards Track [Page 10]
RFC 2893 IPv6 Transition Mechanisms August 2000
The remainder of this section discusses the common mechanisms that
apply to both types of tunneling. Subsequent sections discuss how
the tunnel endpoint address is determined for automatic and
configured tunneling.
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 encapsulating node also has
to handle some more complex issues:
- Determine when to fragment and when to report an ICMP "packet too
big" error back to the source.
- How to reflect IPv4 ICMP errors from routers along the tunnel path
back to the source as IPv6 ICMP errors.
Those issues are discussed in the following sections.
3.2. Tunnel MTU and Fragmentation
The encapsulating node could view encapsulation as IPv6 using IPv4 as
a link layer with a very large MTU (65535-20 bytes to be exact; 20
bytes "extra" are needed for the encapsulating IPv4 header). The
encapsulating node would need only to report IPv6 ICMP "packet too
big" errors back to the source for packets that exceed this MTU.
However, such a scheme would be inefficient for two reasons:
Gilligan & Nordmark Standards Track [Page 11]
RFC 2893 IPv6 Transition Mechanisms August 2000
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
[11].
2) Any IPv4 fragmentation occurring inside the tunnel would have to
be reassembled at the tunnel endpoint. For tunnels that terminate
at a router, this would require additional memory to reassemble
the IPv4 fragments into a complete IPv6 packet before that packet
could be forwarded onward.
The fragmentation inside the tunnel can be reduced to a minimum by
having the encapsulating node track the IPv4 Path MTU across the
tunnel, using the IPv4 Path MTU Discovery Protocol [8] and recording
the resulting path MTU. The IPv6 layer in the encapsulating node 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 completely 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 [4].) In this case the IPv6 layer has to "see" a
link layer with an MTU of 1280 bytes and the encapsulating node has
to use IPv4 fragmentation in order to forward the 1280 byte IPv6
packets.
The encapsulating node can 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
IPv6 ICMP "packet too big" message:
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -