📄 rfc2765.txt
字号:
Network Working Group E. Nordmark
Request for Comments: 2765 Sun Microsystems
Category: Standards Track February 2000
Stateless IP/ICMP Translation Algorithm (SIIT)
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 (2000). All Rights Reserved.
Abstract
This document specifies a transition mechanism algorithm in addition
to the mechanisms already specified in [TRANS-MECH]. The algorithm
translates between IPv4 and IPv6 packet headers (including ICMP
headers) in separate translator "boxes" in the network without
requiring any per-connection state in those "boxes". This new
algorithm can be used as part of a solution that allows IPv6 hosts,
which do not have a permanently assigned IPv4 addresses, to
communicate with IPv4-only hosts. The document neither specifies
address assignment nor routing to and from the IPv6 hosts when they
communicate with the IPv4-only hosts.
Acknowledgements
This document is a product of the NGTRANS working group. Some text
has been extracted from an old Internet Draft titled "IPAE: The SIPP
Interoperability and Transition Mechanism" authored by R. Gilligan,
E. Nordmark, and B. Hinden. George Tsirtsis provides the figures for
Section 1. Keith Moore provided a careful review of the document.
Nordmark Standards Track [Page 1]
RFC 2765 SIIT February 2000
Table of Contents
1. Introduction and Motivation.............................. 2
1.1. Applicability and Limitations....................... 5
1.2. Assumptions......................................... 7
1.3. Impact Outside the Network Layer.................... 7
2. Terminology.............................................. 8
2.1. Addresses........................................... 9
2.2. Requirements........................................ 9
3. Translating from IPv4 to IPv6............................ 9
3.1. Translating IPv4 Headers into IPv6 Headers.......... 11
3.2. Translating UDP over IPv4........................... 13
3.3. Translating ICMPv4 Headers into ICMPv6 Headers...... 13
3.4. Translating ICMPv4 Error Messages into ICMPv6....... 16
3.5. Knowing when to Translate........................... 16
4. Translating from IPv6 to IPv4............................ 17
4.1. Translating IPv6 Headers into IPv4 Headers.......... 18
4.2. Translating ICMPv6 Headers into ICMPv4 Headers...... 20
4.3. Translating ICMPv6 Error Messages into ICMPv4....... 22
4.4. Knowing when to Translate........................... 22
5. Implications for IPv6-Only Nodes......................... 22
6. Security Considerations.................................. 23
References................................................... 24
Author's Address............................................. 25
Full Copyright Statement..................................... 26
1. Introduction and Motivation
The transition mechanisms specified in [TRANS-MECH] handle the case
of dual IPv4/IPv6 hosts interoperating with both dual hosts and
IPv4-only hosts, which is needed early in the transition to IPv6.
The dual hosts are assigned both an IPv4 and one or more IPv6
addresses. As the number of available globally unique IPv4 addresses
becomes smaller and smaller as the Internet grows there will be a
desire to take advantage of the large IPv6 address and not require
that every new Internet node have a permanently assigned IPv4
address.
There are several different scenarios where there might be IPv6-only
hosts that need to communicate with IPv4-only hosts. These IPv6
hosts might be IPv4-capable, i.e. include an IPv4 implementation but
not be assigned an IPv4 address, or they might not even include an
IPv4 implementation.
- A completely new network with new devices that all support IPv6.
In this case it might be beneficial to not have to configure the
routers within the new network to route IPv4 since none of the
Nordmark Standards Track [Page 2]
RFC 2765 SIIT February 2000
hosts in the new network are configured with IPv4 addresses. But
these new IPv6 devices might occasionally need to communicate with
some IPv4 nodes out on the Internet.
- An existing network where a large number of IPv6 devices are
added. The IPv6 devices might have both an IPv4 and an IPv6
protocol stack but there is not enough global IPv4 address space
to give each one of them a permanent IPv4 address. In this case
it is more likely that the routers in the network already route
IPv4 and are upgraded to dual routers.
However, there are other potential solutions in this area:
- If there is no IPv4 routing inside the network i.e., the cloud
that contains the new devices, some possible solutions are to
either use the translators specified in this document at the
boundary of the cloud, or to use Application Layer Gateways (ALG)
on dual nodes at the cloud's boundary. The ALG solution is less
flexible in that it is application protocol specific and it is
also less robust since an ALG box is likely to be a single point
of failure for a connection using that box.
- Otherwise, if IPv4 routing is supported inside the cloud and the
implementations support both IPv6 and IPv4 it might suffice to
have a mechanism for allocating a temporary address IPv4 and use
IPv4 end to end when communicating with IPv4-only nodes. However,
it would seem that such a solution would require the pool of
temporary IPv4 addresses to be partitioned across all the subnets
in the cloud which would either require a larger pool of IPv4
addresses or result in cases where communication would fail due to
no available IPv4 address for the node's subnet.
This document specifies an algorithm that is one of the components
needed to make IPv6-only nodes interoperate with IPv4-only nodes.
Other components, not specified in this document, are a mechanism for
the IPv6-only node to somehow acquire a temporary IPv4 address, and a
mechanism for providing routing (perhaps using tunneling) to and from
the temporary IPv4 address assigned to the node.
The temporary IPv4 address will be used as an IPv4-translated IPv6
address and the packets will travel through a stateless IP/ICMP
translator that will translate the packet headers between IPv4 and
IPv6 and translate the addresses in those headers between IPv4
addresses on one side and IPv4-translated or IPv4-mapped IPv6
addresses on the other side.
Nordmark Standards Track [Page 3]
RFC 2765 SIIT February 2000
This specification does not cover how an IPv6 node can acquire a
temporary IPv4 address and how such a temporary address be registered
in the DNS. The DHCP protocol, perhaps with some extensions, could
probably be used to acquire temporary addresses with short leases but
that is outside the scope of this document. Also, the mechanism for
routing this IPv4-translated IPv6 address in the site is not
specified in this document.
The figures below show how the Stateless IP/ICMP Translation
algorithm (SIIT) can be used initially for small networks (e.g., a
single subnet) and later for a site which has IPv6-only hosts in a
dual IPv4/IPv6 network. This use assumes a mechanism for the IPv6
nodes to acquire a temporary address from the pool of IPv4 addresses.
Note that SIIT is not likely to be useful later during transition
when most of the Internet is IPv6 and there are only small islands of
IPv4 nodes, since such use would either require the IPv6 nodes to
acquire temporary IPv4 addresses from a "distant" SIIT box operated
by a different administration, or require that the IPv6 routing
contain routes for IPv6-mapped addresses. (The latter is known to be
a very bad idea due to the size of the IPv4 routing table that would
potentially be injected into IPv6 routing in the form of IPv4-mapped
addresses.)
___________
/ \
[IPv6 Host]---[SIIT]---------< IPv4 network>--[IPv4 Host]
| \___________/
(pool of IPv4 addresses)
IPv4-translatable -> IPv4->IPv4 addresser
IPv4-mapped
Figure 1. Using SIIT for a single IPv6-only subnet.
___________ ___________
/ \ / \
[IPv6 Host]--< Dual network>--[SIIT]--< IPv4 network>--[IPv4 Host]
\___________/ | \___________/
(pool of IPv4 addresses)
IPv4-translatable -> IPv4->IPv4 addresser
IPv4-mapped
Figure 2. Using SIIT for an IPv6-only or dual cloud (e.g. a site)
which contains some IPv6-only hosts as well as IPv4 hosts.
Nordmark Standards Track [Page 4]
RFC 2765 SIIT February 2000
The protocol translators are assumed to fit around some piece of
topology that includes some IPv6-only nodes and that may also include
IPv4 nodes as well as dual nodes. There has to be a translator on
each path used by routing the "translatable" packets in and out of
this cloud to ensure that such packets always get translated. This
does not require a translator at every physical connection between
the cloud and the rest of the Internet since the routing can be used
to deliver the packets to the translator.
The IPv6-only node communicating with an IPv4 node through a
translator will see an IPv4-mapped address for the peer and use an
IPv4-translatable address for its local address for that
communication. When the IPv6-only node sends packets the IPv4-mapped
address indicates that the translator needs to translate the packets.
When the IPv4 node sends packets those will translated to have the
IPv4-translatable address as a destination; it is not possible to use
an IPv4-mapped or an IPv4-compatible address as a destination since
that would either route the packet back to the translator (for the
IPv4-mapped address) or make the packet be encapsulated in IPv4 (for
the IPv4-compatible address). Thus this specification introduces the
new notion of an IPv4-translatable address.
1.1. Applicability and Limitations
The use of this translation algorithm assumes that the IPv6 network
is somehow well connected i.e. when an IPv6 node wants to communicate
with another IPv6 node there is an IPv6 path between them. Various
tunneling schemes exist that can provide such a path, but those
mechanisms and their use is outside the scope of this document.
The IPv6 protocol [IPv6] has been designed so that the TCP and UDP
pseudo-header checksums are not affected by the translations
specified in this document, thus the translator does not need to
modify normal TCP and UDP headers. The only exceptions are
unfragmented IPv4 UDP packets which need to have a UDP checksum
computed since a pseudo-header checksum is required for UDP in IPv6.
Also, ICMPv6 include a pseudo-header checksum but it is not present
in ICMPv4 thus the checksum in ICMP messages need to be modified by
the translator. In addition, ICMP error messages contain an IP
header as part of the payload thus the translator need to rewrite
those parts of the packets to make the receiver be able to understand
the included IP header. However, all of the translator's operations,
including path MTU discovery, are stateless in the sense that the
translator operates independently on each packet and does not retain
any state from one packet to another. This allows redundant
translator boxes without any coordination and a given TCP connection
can have the two directions of packets go through different
translator boxes.
Nordmark Standards Track [Page 5]
RFC 2765 SIIT February 2000
The translating function as specified in this document does not
translate any IPv4 options and it does not translate IPv6 routing
headers, hop-by-hop extension headers, or destination options
headers. It could be possible to define a translation between source
routing in IPv4 and IPv6. However such a translation would not be
semantically correct due to the slight differences between the IPv4
and IPv6 source routing. Also, the usefulness of source routing when
going through a header translator might be limited since all the
IPv6-only routers would need to have an IPv4-translated IPv6 address
since the IPv4-only node will send a source route option containing
only IPv4 addresses.
At first sight it might appear that the IPsec functionality [IPv6-SA,
IPv6-ESP, IPv6-AH] can not be carried across the translator.
However, since the translator does not modify any headers above the
logical IP layer (IP headers, IPv6 fragment headers, and ICMP
messages) packets encrypted using ESP in Transport-mode can be
carried through the translator. [Note that this assumes that the key
management can operate between the IPv6-only node and the IPv4-only
node.] The AH computation covers parts of the IPv4 header fields
such as IP addresses, and the identification field (fields that are
either immutable or predictable by the sender) [IPv6-AUTH]. While
the SIIT algorithm is specified so that those IPv4 fields can be
predicted by the IPv6 sender it is not possible for the IPv6 receiver
to determine the value of the IPv4 Identification field in packets
sent by the IPv4 node. Thus as the translation algorithm is
specified in this document it is not possible to use end-to-end AH
through the translator.
For ESP Tunnel-mode to work through the translator the IPv6 node
would have to be able to both parse and generate "inner" IPv4 headers
since the inner IP will be encrypted together with the transport
protocol.
Thus in practise, only ESP transport mode is relatively easy to make
work through a translator.
IPv4 multicast addresses can not be mapped to IPv6 multicast
addresses. For instance, ::ffff:224.1.2.3 is an IPv4 mapped IPv6
address with a class D address, however it is not an IPv6 multicast
address. While the IP/ICMP header translation aspect of this memo in
theory works for multicast packets this address mapping limitation
makes it impossible to apply the techniques in this memo for
multicast traffic.
Nordmark Standards Track [Page 6]
RFC 2765 SIIT February 2000
1.2. Assumptions
The IPv6 nodes using the translator must have an IPv4-translated IPv6
address while it is communicating with IPv4-only nodes.
The use of the algorithm assumes that there is an IPv4 address pool
used to generate IPv4-translated addresses. Routing needs to be able
to route any IPv4 packets, whether generated "outside" or "inside"
the translator, destined to addresses in this pool towards the
translator. This implies that the address pool can not be assigned
to subnets but must be separated from the IPv4 subnets used on the
"inside" of the translator.
Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e.
the UDP checksum field is zero) are not of significant use over
wide-areas in the Internet and will not be translated by the
translator. An informal trace [MILLER] in the backbone showed that
out of 34,984,468 IP packets there were 769 fragmented UDP packets
with a zero checksum. However, all of them were due to malicious or
broken behavior; a port scan and first fragments of IP packets that
are not a multiple of 8 bytes.
1.3. Impact Outside the Network Layer
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -