< draft-ietf-ngtrans-siit-07.txt   draft-ietf-ngtrans-siit-08.txt >
INTERNET-DRAFT Erik Nordmark, Sun Microsystems INTERNET-DRAFT Erik Nordmark, Sun Microsystems
November 15, 1999 December 9, 1999
Stateless IP/ICMP Translation Algorithm (SIIT) Stateless IP/ICMP Translation Algorithm (SIIT)
<draft-ietf-ngtrans-siit-07.txt> <draft-ietf-ngtrans-siit-08.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 30 skipping to change at page 1, line 30
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet Draft expires May 15, 2000. This Internet Draft expires June 9, 2000.
Abstract Abstract
This document specifies a transition mechanism algorithm in addition This document specifies a transition mechanism algorithm in addition
to the mechanisms already specified in RFC 1933. The algorithm to the mechanisms already specified in [TRANS-MECH]. The algorithm
translates between IPv4 and IPv6 packet headers (including ICMP translates between IPv4 and IPv6 packet headers (including ICMP
headers) without requiring any per-connection state. This new 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, algorithm can be used as part of a solution that allows IPv6 hosts,
which do not have a permanently assigned IPv4 addresses, to which do not have a permanently assigned IPv4 addresses, to
communicate with IPv4-only hosts. The document neither specifies communicate with IPv4-only hosts. The document neither specifies
address assignment nor routing to and from the IPv6 hosts when they address assignment nor routing to and from the IPv6 hosts when they
communicate with the IPv4-only hosts. communicate with the IPv4-only hosts.
Acknowledgements Acknowledgements
This document is a product of the NGTRANS working group. Some text This document is a product of the NGTRANS working group. Some text
has been extracted from an old Internet Draft titled "IPAE: The SIPP has been extracted from an old Internet Draft titled "IPAE: The SIPP
skipping to change at page 2, line 27 skipping to change at page 2, line 27
1. INTRODUCTION AND MOTIVATION.............................. 3 1. INTRODUCTION AND MOTIVATION.............................. 3
1.1. Applicability and Limitations....................... 6 1.1. Applicability and Limitations....................... 6
1.2. Assumptions......................................... 7 1.2. Assumptions......................................... 7
1.3. Impact Outside the Network Layer.................... 8 1.3. Impact Outside the Network Layer.................... 8
2. TERMINOLOGY.............................................. 9 2. TERMINOLOGY.............................................. 9
2.1. Addresses........................................... 9 2.1. Addresses........................................... 9
2.2. Requirements........................................ 10 2.2. Requirements........................................ 10
3. TRANSLATING FROM IPv4 TO IPv6............................ 10 3. TRANSLATING FROM IPv4 TO IPv6............................ 10
3.1. Translating IPv4 Headers............................ 12 3.1. Translating IPv4 Headers into IPv6 Headers.......... 12
3.2. Translating UDP over IPv4........................... 14 3.2. Translating UDP over IPv4........................... 14
3.3. Translating ICMPv4.................................. 14 3.3. Translating ICMPv4 Headers into ICMPv6 Headers...... 14
3.4. Translating ICMPv4 Error Messages................... 17 3.4. Translating ICMPv4 Error Messages into ICMPv6....... 17
3.5. Knowing when to Translate........................... 17 3.5. Knowing when to Translate........................... 17
4. TRANSLATING FROM IPv6 TO IPv4............................ 18 4. TRANSLATING FROM IPv6 TO IPv4............................ 18
4.1. Translating IPv6 Headers............................ 19 4.1. Translating IPv6 Headers into IPv4 Headers.......... 19
4.2. Translating ICMPv6.................................. 21 4.2. Translating ICMPv6 Headers into ICMPv4 Headers...... 21
4.3. Translating ICMPv6 Error Messages................... 23 4.3. Translating ICMPv6 Error Messages into ICMPv4....... 23
4.4. Knowing when to Translate........................... 23 4.4. Knowing when to Translate........................... 23
5. IMPLICATIONS FOR IPv6-ONLY NODES......................... 24 5. IMPLICATIONS FOR IPv6-ONLY NODES......................... 24
6. SECURITY CONSIDERATIONS.................................. 24 6. SECURITY CONSIDERATIONS.................................. 24
7. CHANGE LOG............................................... 25 7. CHANGE LOG............................................... 25
REFERENCES................................................... 26 REFERENCES................................................... 26
skipping to change at page 3, line 44 skipping to change at page 3, line 44
it is more likely that the routers in the network already route it is more likely that the routers in the network already route
IPv4 and are upgraded to dual routers. IPv4 and are upgraded to dual routers.
However, there are other potential solutions in this area: However, there are other potential solutions in this area:
- If there is no IPv4 routing inside the network i.e., the cloud - If there is no IPv4 routing inside the network i.e., the cloud
that contains the new devices, some possible solutions are to that contains the new devices, some possible solutions are to
either use the translators specified in this document at the either use the translators specified in this document at the
boundary of the cloud, or to use Application Layer Gateways (ALG) boundary of the cloud, or to use Application Layer Gateways (ALG)
on dual nodes at the cloud's boundary. The ALG solution is less on dual nodes at the cloud's boundary. The ALG solution is less
flexible in that it is application protocol specific and it is flexible in that it is application protocol specific and it is
also less robust since a the ALG box is likely to be a single also less robust since an ALG box is likely to be a single point
point of failure for a connection using that box. of failure for a connection using that box.
- Otherwise, if there IPv4 routing is supported inside the cloud and - Otherwise, if IPv4 routing is supported inside the cloud and the
the implementations support both IPv6 and IPv4 it might suffice to implementations support both IPv6 and IPv4 it might suffice to
have a mechanism for allocating temporary IPv4 and use IPv4 end to have a mechanism for allocating a temporary address IPv4 and use
end when communicating with IPv4-only nodes. However, it would IPv4 end to end when communicating with IPv4-only nodes. However,
seem that such a solution would require the pool of temporary IPv4 it would seem that such a solution would require the pool of
addresses to be partitioned across all the subnets in the cloud temporary IPv4 addresses to be partitioned across all the subnets
which would either require a larger pool of IPv4 addresses or in the cloud which would either require a larger pool of IPv4
result in cases where communication would fail due to no available addresses or result in cases where communication would fail due to
IPv4 address for the node's subnet. no available IPv4 address for the node's subnet.
This document specifies an algorithm that is one of the components This document specifies an algorithm that is one of the components
needed to make IPv6-only nodes interoperate with IPv4-only nodes. needed to make IPv6-only nodes interoperate with IPv4-only nodes.
Other components, not specified in this document, are a mechanism for Other components, not specified in this document, are a mechanism for
the IPv6-only node to somehow acquire a temporary IPv4 address, and a the IPv6-only node to somehow acquire a temporary IPv4 address, and a
mechanism for providing routing (perhaps using tunneling) to and from mechanism for providing routing (perhaps using tunneling) to and from
the temporary IPv4 address assigned to the node. the temporary IPv4 address assigned to the node.
The temporary IPv4 address will be used as an IPv4-translated IPv6 The temporary IPv4 address will be used as an IPv4-translated IPv6
address and the packets will travel through a stateless IP/ICMP address and the packets will travel through a stateless IP/ICMP
skipping to change at page 4, line 34 skipping to change at page 4, line 34
in the DNS. The DHCP protocol, perhaps with some extensions, could in the DNS. The DHCP protocol, perhaps with some extensions, could
probably be used to acquire temporary addresses with short leases but probably be used to acquire temporary addresses with short leases but
that is outside the scope of this document. Also, the mechanism for that is outside the scope of this document. Also, the mechanism for
routing this IPv4-translated IPv6 address in the site is not routing this IPv4-translated IPv6 address in the site is not
specified in this document. specified in this document.
The figures below show how the Stateless IP/ICMP Translation The figures below show how the Stateless IP/ICMP Translation
algorithm (SIIT) can be used initially for small networks (e.g., a 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 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 dual IPv4/IPv6 network. This use assumes a mechanism for the IPv6
nodes to acquire an temporary address from the pool of IPv4 nodes to acquire a temporary address from the pool of IPv4 addresses.
addresses. Note that SIIT is not likely to be useful later during Note that SIIT is not likely to be useful later during transition
transition when most of the Internet is IPv6 and there are only small when most of the Internet is IPv6 and there are only small islands of
islands of IPv4 nodes, since such use would either require the IPv6 IPv4 nodes, since such use would either require the IPv6 nodes to
nodes to acquire temporary IPv4 addresses from a "distant" SIIT box acquire temporary IPv4 addresses from a "distant" SIIT box operated
operated by a different administration, or require that the IPv6 by a different administration, or require that the IPv6 routing
routing contain routes for IPv6-mapped addresses. (The latter is contain routes for IPv6-mapped addresses. (The latter is known to be
known to be a very bad idea due to the size of the IPv4 routing table a very bad idea due to the size of the IPv4 routing table that would
that would potentially be injected into IPv6 routing in the form of potentially be injected into IPv6 routing in the form of IPv4-mapped
IPv4-mapped addresses.) addresses.)
___________ ___________
/ \ / \
[IPv6 Host]---[SIIT]---------< IPv4 network>--[IPv4 Host] [IPv6 Host]---[SIIT]---------< IPv4 network>--[IPv4 Host]
| \___________/ | \___________/
(pool of IPv4 addresses) (pool of IPv4 addresses)
IPv4-translatable -> IPv4->IPv4 addresser IPv4-translatable -> IPv4->IPv4 addresser
IPv4-mapped IPv4-mapped
Figure 1. Using SIIT for a single IPv6-only subnet. Figure 1. Using SIIT for a single IPv6-only subnet.
skipping to change at page 6, line 13 skipping to change at page 6, line 13
new notion of an IPv4-translatable address. new notion of an IPv4-translatable address.
1.1. Applicability and Limitations 1.1. Applicability and Limitations
The use of this translation algorithm assumes that the IPv6 network The use of this translation algorithm assumes that the IPv6 network
is somehow well connected i.e. when an IPv6 node wants to communicate 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 with another IPv6 node there is an IPv6 path between them. Various
tunneling schemes exist that can provide such a path, but those tunneling schemes exist that can provide such a path, but those
mechanisms and their use is outside the scope of this document. mechanisms and their use is outside the scope of this document.
The IPv6 protocol [IPv6] has been designed so that the transport The IPv6 protocol [IPv6] has been designed so that the TCP and UDP
pseudo-header checksums are not affected by such a translation thus pseudo-header checksums are not affected by the translations
the translator does not need to modify normal TCP and UDP headers. specified in this document, thus the translator does not need to
The only exceptions are unfragmented IPv4 UDP packets which need to modify normal TCP and UDP headers. The only exceptions are
have a UDP checksum computed since a pseudo-header checksum is unfragmented IPv4 UDP packets which need to have a UDP checksum
required for UDP in IPv6. Also, ICMPv6 include a pseudo-header computed since a pseudo-header checksum is required for UDP in IPv6.
checksum but it is not present in ICMPv4 thus the checksum in ICMP Also, ICMPv6 include a pseudo-header checksum but it is not present
messages need to be modified by the translator. In addition, ICMP in ICMPv4 thus the checksum in ICMP messages need to be modified by
error messages contain an IP header as part of the payload thus the the translator. In addition, ICMP error messages contain an IP
translator need to rewrite those parts of the packets to make the header as part of the payload thus the translator need to rewrite
receiver be able to understand the included IP header. However, all those parts of the packets to make the receiver be able to understand
of the translator's operations, including path MTU discovery, are the included IP header. However, all of the translator's operations,
stateless in the sense that the translator operates independently on including path MTU discovery, are stateless in the sense that the
each packet and does not retain any state from one packet to another. translator operates independently on each packet and does not retain
This allows redundant translator boxes without any coordination and a any state from one packet to another. This allows redundant
given TCP connection can have the two directions of packets go translator boxes without any coordination and a given TCP connection
through different translator boxes. can have the two directions of packets go through different
translator boxes.
The translating function as specified in this document does not The translating function as specified in this document does not
translate any IPv4 options and it does not translate IPv6 routing translate any IPv4 options and it does not translate IPv6 routing
headers, hop-by-hop extension headers, or destination options headers, hop-by-hop extension headers, or destination options
headers. It could be possible to define a translation between source headers. It could be possible to define a translation between source
routing in IPv4 and IPv6. However such a translation would not be routing in IPv4 and IPv6. However such a translation would not be
semantically correct due to the slight differences between the IPv4 semantically correct due to the slight differences between the IPv4
and IPv6 source routing. Also, the usefulness of source routing when and IPv6 source routing. Also, the usefulness of source routing when
going through a header translator might be limited since all the going through a header translator might be limited since all the
IPv6-only routers would need to have an IPv4-translated IPv6 address IPv6-only routers would need to have an IPv4-translated IPv6 address
skipping to change at page 12, line 14 skipping to change at page 12, line 14
IPv6 fragment header to indicate that the sender might not be using IPv6 fragment header to indicate that the sender might not be using
path MTU discovery i.e. the packet should not have the DF flag set path MTU discovery i.e. the packet should not have the DF flag set
should it later be translated back to IPv4. should it later be translated back to IPv4.
Other than the special rules for handling fragments and path MTU Other than the special rules for handling fragments and path MTU
discovery the actual translation of the packet header consists of a discovery the actual translation of the packet header consists of a
simple mapping as defined below. Note that ICMP packets require simple mapping as defined below. Note that ICMP packets require
special handling in order to translate the content of ICMP error special handling in order to translate the content of ICMP error
message and also to add the ICMP pseudo-header checksum. message and also to add the ICMP pseudo-header checksum.
3.1. Translating IPv4 Headers 3.1. Translating IPv4 Headers into IPv6 Headers
If the DF flag is not set and the IPv4 packet will result in an IPv6 If the DF flag is not set and the IPv4 packet will result in an IPv6
packet larger than 1280 bytes the IPv4 packet MUST be fragmented packet larger than 1280 bytes the IPv4 packet MUST be fragmented
prior to translating it. Since IPv4 packets with DF not set will prior to translating it. Since IPv4 packets with DF not set will
always result in a fragment header being added to the packet the IPv4 always result in a fragment header being added to the packet the IPv4
packets must be fragmented so that their length, excluding the IPv4 packets must be fragmented so that their length, excluding the IPv4
header, is at most 1232 bytes (1280 minus 40 for the IPv6 header and header, is at most 1232 bytes (1280 minus 40 for the IPv6 header and
8 for the Fragment header). The resulting fragments are then 8 for the Fragment header). The resulting fragments are then
translated independently using the logic described below. translated independently using the logic described below.
skipping to change at page 12, line 40 skipping to change at page 12, line 40
Version: Version:
6 6
Traffic Class: Traffic Class:
By default, copied from IP Type Of Service and By default, copied from IP Type Of Service and
Precedence field (all 8 bits are copied). According Precedence field (all 8 bits are copied). According
to [DIFFSERV] the semantics of the bits are identical to [DIFFSERV] the semantics of the bits are identical
in IPv4 and IPv6. However, in some IPv4 environments in IPv4 and IPv6. However, in some IPv4 environments
these fields might be used with the old semantics of these fields might be used with the old semantics of
"Type Of Service and Precedence". An implementation "Type Of Service and Precedence". An implementation
of a translator SHOULD provide a the ability to of a translator SHOULD provide the ability to ignore
ignore the IPv4 "TOS" and always set the IPv6 traffic the IPv4 "TOS" and always set the IPv6 traffic class
class to zero. to zero.
Flow Label: Flow Label:
0 (all zero bits) 0 (all zero bits)
Payload Length: Payload Length:
Total length value from IPv4 header, minus the size Total length value from IPv4 header, minus the size
of the IPv4 header and IPv4 options, if present. of the IPv4 header and IPv4 options, if present.
Next Header: Next Header:
Protocol field copied from IPv4 header Protocol field copied from IPv4 header
skipping to change at page 14, line 40 skipping to change at page 14, line 40
the IP addresses and port numbers in the packet. When it receives the IP addresses and port numbers in the packet. When it receives
fragments other than the first it SHOULD silently drop the packet, fragments other than the first it SHOULD silently drop the packet,
since there is no port information to log. since there is no port information to log.
When a translator receives an unfragmented UDP IPv4 packet and the When a translator receives an unfragmented UDP IPv4 packet and the
checksum field is zero the translator MUST compute the missing UDP checksum field is zero the translator MUST compute the missing UDP
checksum as part of translating the packet. Also, the translator checksum as part of translating the packet. Also, the translator
SHOULD maintain a counter of how many UDP checksums are generated in SHOULD maintain a counter of how many UDP checksums are generated in
this manner. this manner.
3.3. Translating ICMPv4 3.3. Translating ICMPv4 Headers into ICMPv6 Headers
All ICMP messages that are to be translated require that the ICMP All ICMP messages that are to be translated require that the ICMP
checksum field be updated as part of the translation since ICMPv6, checksum field be updated as part of the translation since ICMPv6,
unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP. unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP.
In addition all ICMP packets needs to have the Type value translated In addition all ICMP packets need to have the Type value translated
and for ICMP error messages the included IP header also needs and for ICMP error messages the included IP header also needs
translation. translation.
The actions needed to translate various ICMPv4 messages are: The actions needed to translate various ICMPv4 messages are:
ICMPv4 query messages: ICMPv4 query messages:
Echo and Echo Reply (Type 8 and Type 0) Echo and Echo Reply (Type 8 and Type 0)
Adjust the type to 128 and 129, respectively, and adjust the Adjust the type to 128 and 129, respectively, and adjust the
ICMP checksum both to take the type change into account and ICMP checksum both to take the type change into account and
skipping to change at page 17, line 10 skipping to change at page 17, line 10
Obsoleted in ICMPv6. Silently drop. Obsoleted in ICMPv6. Silently drop.
Time Exceeded (Type 11) Time Exceeded (Type 11)
Set the Type field to 3. The Code field is unchanged. Set the Type field to 3. The Code field is unchanged.
Parameter Problem (Type 12) Parameter Problem (Type 12)
Set the Type field to 4. The Pointer needs to be updated to Set the Type field to 4. The Pointer needs to be updated to
point to the corresponding field in the translated include IP point to the corresponding field in the translated include IP
header. header.
3.4. Translating ICMPv4 Error Messages 3.4. Translating ICMPv4 Error Messages into ICMPv6
There are some differences between the IPv4 and the IPv6 ICMP error There are some differences between the IPv4 and the IPv6 ICMP error
message formats as detailed above. In addition, the ICMP error message formats as detailed above. In addition, the ICMP error
messages contain the IP header for the packet in error which needs to messages contain the IP header for the packet in error which needs to
be translated just like a normal IP header. This translated is be translated just like a normal IP header. The translation of this
likely to change the length of the datagram thus the Payload Length "packet in error" is likely to change the length of the datagram thus
field in the outer IPv6 header might need to be updated. the Payload Length field in the outer IPv6 header might need to be
updated.
+-------------+ +-------------+ +-------------+ +-------------+
| IPv4 | | IPv6 | | IPv4 | | IPv6 |
| Header | | Header | | Header | | Header |
+-------------+ +-------------+ +-------------+ +-------------+
| ICMPv4 | | ICMPv6 | | ICMPv4 | | ICMPv6 |
| Header | | Header | | Header | | Header |
+-------------+ +-------------+ +-------------+ +-------------+
| IPv4 | ===> | IPv6 | | IPv4 | ===> | IPv6 |
| Header | | Header | | Header | | Header |
skipping to change at page 19, line 18 skipping to change at page 19, line 18
path MTU on the IPv4 side of the translator is smaller then the IPv6 path MTU on the IPv4 side of the translator is smaller then the IPv6
sender will not receive any ICMP "too big" errors and can not adjust sender will not receive any ICMP "too big" errors and can not adjust
the size fragments it is sending. the size fragments it is sending.
Other than the special rules for handling fragments and path MTU Other than the special rules for handling fragments and path MTU
discovery the actual translation of the packet header consists of a discovery the actual translation of the packet header consists of a
simple mapping as defined below. Note that ICMP packets require simple mapping as defined below. Note that ICMP packets require
special handling in order to translate the content of ICMP error special handling in order to translate the content of ICMP error
message and also to add the ICMP pseudo-header checksum. message and also to add the ICMP pseudo-header checksum.
4.1. Translating IPv6 Headers 4.1. Translating IPv6 Headers into IPv4 Headers
If there is no IPv6 Fragment header the IPv4 header fields are set as If there is no IPv6 Fragment header the IPv4 header fields are set as
follows: follows:
Version: Version:
4 4
Internet Header Length: Internet Header Length:
5 (no IPv4 options) 5 (no IPv4 options)
skipping to change at page 21, line 30 skipping to change at page 21, line 30
to zero allowing this packet to be fragmented by IPv4 to zero allowing this packet to be fragmented by IPv4
routers. routers.
Fragment Offset: Fragment Offset:
Copied from the Fragment Offset field in the Fragment Copied from the Fragment Offset field in the Fragment
Header. Header.
Protocol: Protocol:
Next Header value copied from Fragment header. Next Header value copied from Fragment header.
4.2. Translating ICMPv6 4.2. Translating ICMPv6 Headers into ICMPv4 Headers
All ICMP messages that are to be translated require that the ICMP All ICMP messages that are to be translated require that the ICMP
checksum field be updated as part of the translation since ICMPv6, checksum field be updated as part of the translation since ICMPv6,
unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP. unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP.
In addition all ICMP packets needs to have the Type value translated In addition all ICMP packets need to have the Type value translated
and for ICMP error messages the included IP header also needs and for ICMP error messages the included IP header also needs
translation. translation.
The actions needed to translate various ICMPv6 messages are: The actions needed to translate various ICMPv6 messages are:
ICMPv6 informational messages: ICMPv6 informational messages:
Echo Request and Echo Reply (Type 128 and 129) Echo Request and Echo Reply (Type 128 and 129)
Adjust the type to 0 and 8, respectively, and adjust the ICMP Adjust the type to 0 and 8, respectively, and adjust the ICMP
checksum both to take the type change into account and to checksum both to take the type change into account and to
skipping to change at page 23, line 8 skipping to change at page 23, line 8
Parameter Problem (Type 4) Parameter Problem (Type 4)
If the Code is 1 translate this to an ICMPv4 protocol If the Code is 1 translate this to an ICMPv4 protocol
unreachable (Type 3, Code 2). Otherwise set the Type to 12 unreachable (Type 3, Code 2). Otherwise set the Type to 12
and the Code to zero. The Pointer needs to be updated to and the Code to zero. The Pointer needs to be updated to
point to the corresponding field in the translated include IP point to the corresponding field in the translated include IP
header. header.
Unknown error messages Unknown error messages
Silently drop. Silently drop.
4.3. Translating ICMPv6 Error Messages 4.3. Translating ICMPv6 Error Messages into ICMPv4
There are some differences between the IPv4 and the IPv6 ICMP error There are some differences between the IPv4 and the IPv6 ICMP error
message formats as detailed above. In addition, the ICMP error message formats as detailed above. In addition, the ICMP error
messages contain the IP header for the packet in error which needs to messages contain the IP header for the packet in error which needs to
be translated just like a normal IP header. This translated is be translated just like a normal IP header. The translation of this
likely to change the length of the datagram thus the Payload Length "packet in error" is likely to change the length of the datagram thus
field in the outer IPv6 header might need to be updated. the Total Length field in the outer IPv4 header might need to be
updated.
+-------------+ +-------------+ +-------------+ +-------------+
| IPv6 | | IPv4 | | IPv6 | | IPv4 |
| Header | | Header | | Header | | Header |
+-------------+ +-------------+ +-------------+ +-------------+
| ICMPv6 | | ICMPv4 | | ICMPv6 | | ICMPv4 |
| Header | | Header | | Header | | Header |
+-------------+ +-------------+ +-------------+ +-------------+
| IPv6 | ===> | IPv4 | | IPv6 | ===> | IPv4 |
| Header | | Header | | Header | | Header |
skipping to change at page 23, line 40 skipping to change at page 23, line 41
| Header | | Header | | Header | | Header |
+-------------+ +-------------+ +-------------+ +-------------+
IPv6-to-IPv4 ICMP Error Translation IPv6-to-IPv4 ICMP Error Translation
The translation of the inner IP header can be done by recursively The translation of the inner IP header can be done by recursively
invoking the function that translated the outer IP headers. invoking the function that translated the outer IP headers.
4.4. Knowing when to Translate 4.4. Knowing when to Translate
When the translator receives a IPv6 packet with an IPv4-mapped When the translator receives an IPv6 packet with an IPv4-mapped
destination address the packet will be translated to IPv4. destination address the packet will be translated to IPv4.
5. IMPLICATIONS FOR IPv6-ONLY NODES 5. IMPLICATIONS FOR IPv6-ONLY NODES
An IPv6-only node which works through SIIT translators need some An IPv6-only node which works through SIIT translators need some
modifications beyond a normal IPv6-only node. modifications beyond a normal IPv6-only node.
As specified in Section 1.3 the application protocols need to handle As specified in Section 1.3 the application protocols need to handle
operation on a dual stack node. In addition the protocol stack needs operation on a dual stack node. In addition the protocol stack needs
to be able to: to be able to:
skipping to change at page 24, line 44 skipping to change at page 24, line 44
IPv6 again. It is considered preferable to instead signal a IPv6 again. It is considered preferable to instead signal a
failure to communicate to the application. failure to communicate to the application.
6. SECURITY CONSIDERATIONS 6. SECURITY CONSIDERATIONS
The use of stateless IP/ICMP translators does not introduce any new The use of stateless IP/ICMP translators does not introduce any new
security issues beyond the security issues that are already present security issues beyond the security issues that are already present
in the IPv4 and IPv6 protocols and in the routing protocols which are in the IPv4 and IPv6 protocols and in the routing protocols which are
used to make the packets reach the translator. used to make the packets reach the translator.
As the Authentication Header is specified to include the IPv4 As the Authentication Header [IPv6-AUTH] is specified to include the
Identification field and the translating function not being able to IPv4 Identification field and the translating function not being able
always preserve the Identification field, it is not possible for an to always preserve the Identification field, it is not possible for
IPv6 endpoint to compute AH on received packets that have been an IPv6 endpoint to compute AH on received packets that have been
translated from IPv4 packets. Thus AH does not work through a translated from IPv4 packets. Thus AH does not work through a
translator. translator.
Packets with ESP can be translated since ESP does not depend on Packets with ESP can be translated since ESP does not depend on
header fields prior to the ESP header. Note that ESP transport mode header fields prior to the ESP header. Note that ESP transport mode
is easier to handle than ESP tunnel mode; in order to use ESP tunnel is easier to handle than ESP tunnel mode; in order to use ESP tunnel
mode the IPv6 node needs to be able to generate an inner IPv4 header mode the IPv6 node needs to be able to generate an inner IPv4 header
when transmitting packets and remove such an IPv4 header when when transmitting packets and remove such an IPv4 header when
receiving packets. receiving packets.
skipping to change at page 26, line 4 skipping to change at page 25, line 47
more clear that this is just a component of a solution. more clear that this is just a component of a solution.
o Clarified that the IPv4 address pool should not be allocation to o Clarified that the IPv4 address pool should not be allocation to
regular IPv4 subnets "inside" a dual site. regular IPv4 subnets "inside" a dual site.
o Clarified why IPv4-translatable addresses are needed. o Clarified why IPv4-translatable addresses are needed.
o Made it clear that AH does not work through a translator. o Made it clear that AH does not work through a translator.
o Stated the assumption that fragmented UDP IPv4 packets with a zero o Stated the assumption that fragmented UDP IPv4 packets with a zero
UDP checksum are rare and appears only to occur in security UDP checksum are rare and appears only to occur in security
attacks thus can be dropped by the translator. attacks thus can be dropped by the translator.
o Clarified PMTU discovery issue for fragmented UDP packets. o Clarified PMTU discovery issue for fragmented UDP packets.
o Specified implications for IPv6-nodes in Section 5. o Specified implications for IPv6-nodes in Section 5.
Changes since version -07 of the draft:
o Specified in the abstract that translator "boxes" are used.
o Editorial fixes.
REFERENCES REFERENCES
[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998. 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv4] J. Postel, "Internet Protocol", RFC 791, September 1981. [IPv4] J. Postel, "Internet Protocol", RFC 791, September 1981.
 End of changes. 26 change blocks. 
71 lines changed or deleted 80 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/