draft-ietf-ngtrans-header-trans-00.txt   draft-ietf-ngtrans-header-trans-01.txt 
INTERNET-DRAFT Erik Nordmark, Sun Microsystems INTERNET-DRAFT Erik Nordmark, Sun Microsystems
July 30, 1997 November 20, 1997
Site prefixes in Neighbor Discovery Stateless IP/ICMP Translator (SIIT)
<draft-ietf-ngtrans-header-trans-00.txt> <draft-ietf-ngtrans-header-trans-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 1, line 29 skipping to change at page 1, line 30
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim). Rim).
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This Internet Draft expires January 30, 1998. This Internet Draft expires May 20, 1998.
Abstract Abstract
This document specifies a transition mechanism in addition to those This document specifies a transition mechanism in addition to those
already specified in RFC 1933. The new mechanism can be used as part already specified in RFC 1933. The new mechanism can be used as part
of a solution that allows IPv6 hosts that do not have a permanently of a solution that allows IPv6 hosts that do not have a permanently
assigned IPv4 address to communication with IPv4-only hosts. assigned IPv4 address to communication with IPv4-only hosts.
Acknowledgements Acknowledgements
Some text has been pulled from an old Internet Draft titled "IPAE: Some text has been pulled from an old Internet Draft titled "IPAE:
The SIPP Interoperability and Transition Mechanism" authored by R. The SIPP Interoperability and Transition Mechanism" authored by R.
Gilligan, E. Nordmark, and B. Hinden. Gilligan, E. Nordmark, and B. Hinden. George Tsirtsis provides the
figures for Section 1.
Contents Contents
Status of this Memo.......................................... 1 Status of this Memo.......................................... 1
1. INTRODUCTION AND MOTIVATION.............................. 2 1. INTRODUCTION AND MOTIVATION.............................. 3
1.1. Applicability and Limitations....................... 4 1.1. Applicability and Limitations....................... 5
1.2. Impact Outside the Network Layer.................... 5 1.2. Impact Outside the Network Layer.................... 6
2. TERMINOLOGY.............................................. 6 2. TERMINOLOGY.............................................. 7
2.1. Requirements........................................ 6 2.1. Requirements........................................ 8
3. OVERVIEW................................................. 6 3. OVERVIEW................................................. 8
3.1. Assumptions......................................... 7 3.1. Assumptions......................................... 8
4. TRANSLATING FROM IPv4 TO IPv6............................ 7 4. TRANSLATING FROM IPv4 TO IPv6............................ 9
4.1. Translating IPv4 Headers............................ 8 4.1. Translating IPv4 Headers............................ 10
4.2. Translating ICMPv4.................................. 10 4.2. Translating ICMPv4.................................. 12
4.3. Translating ICMPv4 Error Messages................... 12 4.3. Translating ICMPv4 Error Messages................... 14
4.4. Knowing when to Translate........................... 13 4.4. Knowing when to Translate........................... 14
5. TRANSLATING FROM IPv6 TO IPv4............................ 13 5. TRANSLATING FROM IPv6 TO IPv4............................ 15
5.1. Translating IPv6 Headers............................ 14 5.1. Translating IPv6 Headers............................ 16
5.2. Translating ICMPv6.................................. 16 5.2. Translating ICMPv6.................................. 18
5.3. Translating ICMPv6 Error Messages................... 17 5.3. Translating ICMPv6 Error Messages................... 19
5.4. Knowing when to Translate........................... 18 5.4. Knowing when to Translate........................... 20
6. SECURITY CONSIDERATIONS.................................. 18 6. SECURITY CONSIDERATIONS.................................. 20
REFERENCES................................................... 19 7. OPEN ISSUES.............................................. 20
AUTHOR'S ADDRESS............................................. 20 REFERENCES................................................... 21
AUTHOR'S ADDRESS............................................. 22
APPENDIX A: CHANGES SINCE PREVIOUS DRAFT..................... 22
1. INTRODUCTION AND MOTIVATION 1. INTRODUCTION AND MOTIVATION
The transition mechanisms specified in [TRANS-MECH] handle the case The transition mechanisms specified in [TRANS-MECH] handle the case
of dual IPv4/IPv6 hosts interoperating with both dual hosts and of dual IPv4/IPv6 hosts interoperating with both dual hosts and
IPv4-only hosts which is needed early in the transition to IPv6. The 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. dual hosts are assigned both an IPv4 and one or more IPv6 addresses.
As the pool of globally unique IPv4 addresses becomes smaller and As the pool of globally unique IPv4 addresses becomes smaller and
smaller as the Internet grows there will be a desire to take smaller as the Internet grows there will be a desire to take
advantage of the large IPv6 address and not require that every new advantage of the large IPv6 address and not require that every new
Internet node have a permanently assigned IPv4 address. Internet node have a permanently assigned IPv4 address.
There are several different scenarios where there might be IPv6-only There are several different scenarios where there might be IPv6-only
hosts that need to communicate with IPv4-only hosts. [Note: the hosts that need to communicate with IPv4-only hosts. These IPv6
terminology is somewhat unclear is this area. Is a node with that hosts might be IPv4-capable, i.e. include an IPv4 implementation but
implements both IPv4 and IPv6 but has no IPv4 address assigned to any not be assigned an IPv4 address, or they might not even include an
of its interfaces a dual host or an IPv6-only host?] IPv4 implementation.
- A completely new network with new devices that all support IPv6. - A completely new network with new devices that all support IPv6.
In this case it might be beneficial to not have to configure the 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 routers within the new network to route IPv4 since none of the
hosts in the new network are configured with IPv4 addresses. But hosts in the new network are configured with IPv4 addresses. But
these new IPv6 devices might occasionally need to communicate with these new IPv6 devices might occasionally need to communicate with
some IPv4 nodes out on the Internet. some IPv4 nodes out on the Internet.
- An existing network where a large number of IPv6 devices are - An existing network where a large number of IPv6 devices are
added. The IPv6 devices might have both an IPv4 and an IPv6 added. The IPv6 devices might have both an IPv4 and an IPv6
skipping to change at page 3, line 48 skipping to change at page 4, line 10
a solution would require the pool of temporary IPv4 addresses to be a solution would require the pool of temporary IPv4 addresses to be
partitioned across all the subnets in the cloud which would either partitioned across all the subnets in the cloud which would either
require a larger pool of IPv4 addresses or result in cases where require a larger pool of IPv4 addresses or result in cases where
communication would fail due to no available IPv4 address for the communication would fail due to no available IPv4 address for the
node's subnet. node's subnet.
This document specifies a mechanism by which IPv6-only nodes can This document specifies a mechanism by which IPv6-only nodes can
interoperate with IPv4-only nodes by having the IPv6-only nodes interoperate with IPv4-only nodes by having the IPv6-only nodes
somehow acquire a temporary IPv4 address. That IPv4 address will be somehow acquire a temporary IPv4 address. That IPv4 address will be
used as an IPv4-compatible IPv6 address and the packets will travel used as an IPv4-compatible IPv6 address and the packets will travel
through a stateless IP header translator that will translate the through a stateless IP/ICMP translator that will translate the packet
packet headers between IPv4 and IPv6 and translate the addresses in headers between IPv4 and IPv6 and translate the addresses in those
those headers between IPv4 addresses on one side and IPv4-compatible headers between IPv4 addresses on one side and IPv4-compatible or
or IPv4-mapped IPv6 addresses on the other side. IPv4-mapped IPv6 addresses on the other side.
This specification does not cover how an IPv6 node can acquire a This specification does not cover how an IPv6 node can acquire a
temporary IPv4 address and how such a temporary address be registered temporary IPv4 address and how such a temporary address be registered
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. The mechanism for that is outside the scope of this document. The mechanism for
routing this temporary IPv4 address (or the IPv4-compatible IPv6 routing this temporary IPv4 address (or the IPv4-compatible IPv6
address) in the site is currently not specified in this document. address) in the site is currently not specified in this document.
The figures below show how the Stateless IP/ICMP Translator (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
an 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.)
___________
/ \
[IPv6 Host]---[SIIT]---------< IPv4 network>--[IPv4 Host]
| \___________/
(pool of v4 addresses)
Figure 1. Using SIIT for a single IPv6-only subnet.
___________ ___________
/ \ / \
[IPv6 Host]--< Dual network>--[SIIT]--< IPv4 network>--[IPv4 Host]
\___________/ | \___________/
(pool of v4 addresses)
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.
1.1. Applicability and Limitations 1.1. Applicability and Limitations
The IPv6 protocol [IPv6] has been designed so that the transport The IPv6 protocol [IPv6] has been designed so that the transport
pseudo-header checksums are not affected by such a translation thus pseudo-header checksums are not affected by such a translation thus
the translator does not need to modify TCP and UDP headers. However, the translator does not need to modify TCP and UDP headers. However,
ICMPv6 include a pseudo-header checksum but it is not present in 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 ICMPv4 thus the checksum in ICMP messages need to be modified by the
translator. In addition, ICMP error messages contain an IP header as translator. In addition, ICMP error messages contain an IP header as
part of the payload thus the translator need to rewrite those parts part of the payload thus the translator need to rewrite those parts
of the packets to make the receiver be able to understand the of the packets to make the receiver be able to understand the
skipping to change at page 5, line 12 skipping to change at page 6, line 13
messages) packets encrypted using ESP in Transport-mode can be messages) packets encrypted using ESP in Transport-mode can be
carried through the translator. [Note that this assumes that the key carried through the translator. [Note that this assumes that the key
management can operate between the IPv6-only and the IPv4-only node.] management can operate between the IPv6-only and the IPv4-only node.]
The use of AH headers is more complex since the AH computation covers The use of AH headers is more complex since the AH computation covers
most of the fields in the IP header. Should it be possible for the most of the fields in the IP header. Should it be possible for the
IPv6 node to predict the value of all the IPv4 header fields on the IPv6 node to predict the value of all the IPv4 header fields on the
other side of the translator then the IPv6 node could calculate the other side of the translator then the IPv6 node could calculate the
authentication data using an IPv4 header instead of the IPv6 header authentication data using an IPv4 header instead of the IPv6 header
even though it is sending and receiving IPv6 packets. [Currently even though it is sending and receiving IPv6 packets. [Currently
this is not possible since the IP fragment identification field is this is not possible since the IP fragment identification field is
not carried end-to-end through the translator in all cases.] For ESP not carried end-to-end through the translator in all cases. This
Tunnel-mode the IPv6 node would have to be able to parse and generate could be resolved by changing AH to not include the fragment
"inner" IPv4 headers since the inner IP will be encrypted together identification field in the AH computation for either IPv4 or IPv6.]
with the transport protocol. For ESP Tunnel-mode the IPv6 node would have to be able to parse and
generate "inner" IPv4 headers since the inner IP will be encrypted
together with the transport protocol.
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 translation aspect of this draft works
for multicast packets this address mapping limitation makes it hard
to the techniques in this draft for multicast traffic.
1.2. Impact Outside the Network Layer 1.2. Impact Outside the Network Layer
The potential existence of header translators is already taken care The potential existence of stateless IP/ICMP translators is already
of from a protocol perspective in [IPv6]. However, an IPv6 node that taken care of from a protocol perspective in [IPv6]. However, an
wants to be able to use translators need some additional logic in the IPv6 node that wants to be able to use translators need some
network layer. additional logic in the network layer.
The network layer in an IPv6-only node when presented with either an The network layer in an IPv6-only node when presented with either an
IPv4 destination address or an IPv4-mapped IPv6 destination address IPv4 destination address or an IPv4-mapped IPv6 destination address
by the application is likely to drop the packet and return some error by the application is likely to drop the packet and return some error
message to the application. In order to take advantage of message to the application. In order to take advantage of
translators such a node should instead send an IPv6 packet where the translators such a node should instead send an IPv6 packet where the
destination address is the IPv4-mapped address and the source address destination address is the IPv4-mapped address and the source address
is the nodes temporarily assigned IPv4-compatible address. If the is the nodes temporarily assigned IPv4-compatible address. If the
node does not have a temporarily assigned IPv4-compatible address it node does not have a temporarily assigned IPv4-compatible address it
should acquire one using mechanisms that are not discussed in this should acquire one using mechanisms that are not discussed in this
skipping to change at page 6, line 22 skipping to change at page 7, line 31
generation of the IPv4 packets takes place in the sending node. In generation of the IPv4 packets takes place in the sending node. In
an IPv6-only node conceptually the only difference is that the IPv4 an IPv6-only node conceptually the only difference is that the IPv4
packet is generated by the translator - all the information that the packet is generated by the translator - all the information that the
transport layer passed to the network layer will be conveyed to the transport layer passed to the network layer will be conveyed to the
translator in some form. That form just "happens" to be in the form translator in some form. That form just "happens" to be in the form
of an IPv6 header. of an IPv6 header.
2. TERMINOLOGY 2. TERMINOLOGY
This documents uses the terminology defined in [IPv6] and [TRANS- This documents uses the terminology defined in [IPv6] and [TRANS-
MECH]. MECH] with these clarifications:
IPv4 capable node:
A node which has an IPv4 protocol stack. In order
for the stack to be usable the node must be assigned
one or more IPv4 addresses.
IPv4 enabled node: A node which has an IPv4 protocol stack
and is assigned one or more IPv4 addresses. Both
IPv4-only and IPv6/IPv4 nodes are IPv4 enabled.
IPv6 capable node:
A node which has an IPv6 protocol stack. In order
for the stack to be usable the node must be assigned
one or more IPv6 addresses.
IPv6 enabled node: A node which has an IPv6 protocol stack
and is assigned one or more IPv6 addresses. Both
IPv6-only and IPv6/IPv4 nodes are IPv6 enabled.
2.1. Requirements 2.1. Requirements
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [KEYWORDS]. document, are to be interpreted as described in [KEYWORDS].
3. OVERVIEW 3. OVERVIEW
The protocol translators are assumed to fit around some piece of The protocol translators are assumed to fit around some piece of
skipping to change at page 7, line 40 skipping to change at page 9, line 32
+-------------+ +-------------+ +-------------+ +-------------+
| | | Transport | | | | Transport |
~ Data ~ | Layer | ~ Data ~ | Layer |
| | | Header | | | | Header |
+-------------+ +-------------+ +-------------+ +-------------+
| | | |
~ Data ~ ~ Data ~
| | | |
+-------------+ +-------------+
IPv4-to-IPv6 Header Translation IPv4-to-IPv6 Translation
One of the differences between IPv4 and IPv6 is that in IPv6 path MTU One of the differences between IPv4 and IPv6 is that in IPv6 path MTU
discovery is mandatory but it is optional in IPv4. This implies that discovery is mandatory but it is optional in IPv4. This implies that
IPv6 routers will never fragment a packet - only the sender can do IPv6 routers will never fragment a packet - only the sender can do
fragmentation. fragmentation.
When the IPv4 node performs path MTU discovery (by setting the DF bit When the IPv4 node performs path MTU discovery (by setting the DF bit
in the header) the path MTU discovery can operate end-to-end i.e. in the header) the path MTU discovery can operate end-to-end i.e.
across the translator. In this case either IPv4 or IPv6 routers across the translator. In this case either IPv4 or IPv6 routers
might send back ICMP "packet too big" messages to the sender. When might send back ICMP "packet too big" messages to the sender. When
skipping to change at page 10, line 24 skipping to change at page 12, line 13
More Fragments bit copied from the IPv4 header. More Fragments bit copied from the IPv4 header.
Identification: Identification:
The low-order 16 bits copied from the Identification The low-order 16 bits copied from the Identification
field in the IPv4 header. The high-order 16 bits set field in the IPv4 header. The high-order 16 bits set
to zero. to zero.
4.2. Translating ICMPv4 4.2. Translating ICMPv4
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 has checksum field be updated as part of the translation since ICMPv6,
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 needs 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)
skipping to change at page 11, line 39 skipping to change at page 13, line 28
Code 2: Translate to an ICMPv6 Parameter Problem (Type 4, Code 2: Translate to an ICMPv6 Parameter Problem (Type 4,
Code 1) and make the Pointer point to the IPv6 Payload Code 1) and make the Pointer point to the IPv6 Payload
Type field. Type field.
Code 3: Set Code to 4 (port unreachable). Code 3: Set Code to 4 (port unreachable).
Code 4: Translate to an ICMPv6 Packet Too Big message Code 4: Translate to an ICMPv6 Packet Too Big message
(Type 2) with code 0. The MTU field needs to be adjusted (Type 2) with code 0. The MTU field needs to be adjusted
for the difference between the IPv4 and IPv6 header sizes. for the difference between the IPv4 and IPv6 header sizes.
[TBD: What if the IPv4 router did not set the MTU field Note that if the IPv4 router did not set the MTU field
i.e. does not implement [PMTUv4]. Should the translator i.e. the router does not implement [PMTUv4], then the
use the plateau values as specified?] translator must use the plateau values specified in
[PMTUv4] to determine a likely path MTU and include that
path MTU in the ICMPv6 packet. (Use the greatest plateau
value that is less than the returned Total Length field.)
Code 5: Set Code to 2 (not a neighbor). Code 5: Set Code to 2 (not a neighbor).
Code 6,7: Set Code to 0 (no route to destination). Code 6,7: Set Code to 0 (no route to destination).
Code 8: Set Code to 0 (no route to destination). Code 8: Set Code to 0 (no route to destination).
Code 9, 10: Set Code to 1 (communication with destination Code 9, 10: Set Code to 1 (communication with destination
administratively prohibited) administratively prohibited)
skipping to change at page 12, line 44 skipping to change at page 14, line 38
+-------------+ +-------------+ +-------------+ +-------------+
| IPv4 | ===> | IPv6 | | IPv4 | ===> | IPv6 |
| Header | | Header | | Header | | Header |
+-------------+ +-------------+ +-------------+ +-------------+
| Partial | | Partial | | Partial | | Partial |
| Transport | | Transport | | Transport | | Transport |
| Layer | | Layer | | Layer | | Layer |
| Header | | Header | | Header | | Header |
+-------------+ +-------------+ +-------------+ +-------------+
IPv4-to-IPv6 ICMP Error Header Translation IPv4-to-IPv6 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
The translator is assumed to know the pool(s) of IPv4 address that The translator is assumed to know the pool(s) of IPv4 address that
are used to represent the internal IPv6-only nodes. Thus if the are used to represent the internal IPv6-only nodes. Thus if the
destination address falls in these configured sets of prefixes the destination address falls in these configured sets of prefixes the
packet needs to be translated to IPv6. packet needs to be translated to IPv6.
5. TRANSLATING FROM IPv6 TO IPv4 5. TRANSLATING FROM IPv6 TO IPv4
When an IPv6-to-IPv4 translator receives an IPv6 datagram addressed When an IPv6-to-IPv4 translator receives an IPv6 datagram addressed
to an IPv4-mapped IPv6 address, it translates the IPv6 header of that to an IPv4-mapped IPv6 address, it translates the IPv6 header of that
packet into an IPv7 header. It then forwards the packet based on the packet into an IPv6 header. It then forwards the packet based on the
IPv4 destination address. The original IPv6 header on the packet is IPv4 destination address. The original IPv6 header on the packet is
removed and replaced by a IPv4 header. Except for ICMP packets the removed and replaced by a IPv4 header. Except for ICMP packets the
transport layer header and data portion of the packet are left transport layer header and data portion of the packet are left
unchanged. unchanged.
+-------------+ +-------------+ +-------------+ +-------------+
| IPv6 | | IPv4 | | IPv6 | | IPv4 |
| Header | | Header | | Header | | Header |
+-------------+ +-------------+ +-------------+ +-------------+
| Fragment | | Transport | | Fragment | | Transport |
skipping to change at page 13, line 39 skipping to change at page 15, line 32
+-------------+ +-------------+ +-------------+ +-------------+
| Transport | | | | Transport | | |
| Layer | ~ Data ~ | Layer | ~ Data ~
| Header | | | | Header | | |
+-------------+ +-------------+ +-------------+ +-------------+
| | | |
~ Data ~ ~ Data ~
| | | |
+-------------+ +-------------+
IPv6-to-IPv4 Header Translation IPv6-to-IPv4 Translation
There are some differences between IPv6 and IPv4 in the area of There are some differences between IPv6 and IPv4 in the area of
fragmentation and the minimum link MTU that effect the translation. fragmentation and the minimum link MTU that effect the translation.
An IPv6 link has to have an MTU of 576 bytes or greater. The An IPv6 link has to have an MTU of 576 bytes or greater. The
corresponding limit for IPv4 is 68 bytes. Thus, unless there were corresponding limit for IPv4 is 68 bytes. Thus, unless there were
special measures, it would not be possible to do end-to-end path MTU special measures, it would not be possible to do end-to-end path MTU
discovery when the path includes an IPv6-to-IPv4 translator since the discovery when the path includes an IPv6-to-IPv4 translator since the
IPv6 node might receive ICMP "packet too big" messages originated by IPv6 node might receive ICMP "packet too big" messages originated by
an IPv4 router that report an MTU less than 576. However, [IPv6] an IPv4 router that report an MTU less than 576. However, [IPv6]
requires IPv6 nodes to handle such ICMP "packet too big" message by requires IPv6 nodes to handle such ICMP "packet too big" message by
skipping to change at page 16, line 30 skipping to change at page 18, line 22
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.
5.2. Translating ICMPv6 5.2. Translating ICMPv6
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 has checksum field be updated as part of the translation since ICMPv6,
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 needs 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)
skipping to change at page 18, line 24 skipping to change at page 20, line 21
+-------------+ +-------------+ +-------------+ +-------------+
| IPv6 | ===> | IPv4 | | IPv6 | ===> | IPv4 |
| Header | | Header | | Header | | Header |
+-------------+ +-------------+ +-------------+ +-------------+
| Partial | | Partial | | Partial | | Partial |
| Transport | | Transport | | Transport | | Transport |
| Layer | | Layer | | Layer | | Layer |
| Header | | Header | | Header | | Header |
+-------------+ +-------------+ +-------------+ +-------------+
IPv6-to-IPv4 ICMP Error Header 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.
5.4. Knowing when to Translate 5.4. Knowing when to Translate
When the translator receives a IPv6 packet with an IPv4-mapped When the translator receives a IPv6 packet with an IPv4-mapped
destination address the packet will be translated to IPv4. destination address the packet will be translated to IPv4.
6. SECURITY CONSIDERATIONS 6. SECURITY CONSIDERATIONS
TBD The use of stateless IP/ICMP translators does not introduce any new
security issues beyond the security issues that are already present
in the IPv4 and IPv6 protocols and in the routing protocols which are
used to make the packets reach the translator.
7. OPEN ISSUES
- Can/should we make AH work through a translator e.g. by removing
the fragment ID field from the AH computation for both IPv4 and
IPv6?
- For IPv6 to IPv4 should the Identification be something other than
zero to be more friendly to header compression? These packets
have DF set thus it is possible to choose e.g. a local
incrementing counter without adverse effects on reassembly.
- IPv6 to IPv4 when source is pure IPv6 address. What should the
IPv4 source address be set to in order to make traceroute usable?
If such packets are not translated an IPv4 traceroute would show
no responses from IPv6 routers. We could use 127.0.0.1 or
0.0.0.0.
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 1883, January 1996. 6 (IPv6) Specification", RFC 1883, January 1996.
[IPv4] J. Postel, "Internet Protocol", RFC 791, September 1981. [IPv4] J. Postel, "Internet Protocol", RFC 791, September 1981.
skipping to change at page 20, line 13 skipping to change at page 22, line 20
IP version 6", RFC 1981, August 1996. IP version 6", RFC 1981, August 1996.
AUTHOR'S ADDRESS AUTHOR'S ADDRESS
Erik Nordmark Erik Nordmark
Sun Microsystems, Inc. Sun Microsystems, Inc.
901 San Antonio Road 901 San Antonio Road
Palo Alto, CA 94303 Palo Alto, CA 94303
USA USA
phone: +1 415 786 5166 phone: +1 650 786 5166
fax: +1 415 786 5896 fax: +1 650 786 5896
email: nordmark@sun.com email: nordmark@sun.com
APPENDIX A: CHANGES SINCE PREVIOUS DRAFT
The following changes have been made since version 00 of the draft.
o Added clarification about applicability for multicast.
o Clarified the terminology with IPv4 capable vs. enabled etc.
o Changed the title to provide an acronym (SIIT).
o Added some figures to explain the applicability.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/