draft-ietf-ngtrans-header-trans-01.txt   draft-ietf-ngtrans-header-trans-02.txt 
INTERNET-DRAFT Erik Nordmark, Sun Microsystems INTERNET-DRAFT Erik Nordmark, Sun Microsystems
November 20, 1997 August 7, 1998
Stateless IP/ICMP Translator (SIIT) Stateless IP/ICMP Translator (SIIT)
<draft-ietf-ngtrans-header-trans-01.txt> <draft-ietf-ngtrans-header-trans-02.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
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.''
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 ftp.ietf.org (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 May 20, 1998. This Internet Draft expires February 7, 1999.
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
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Contents Contents
Status of this Memo.......................................... 1 Status of this Memo.......................................... 1
1. INTRODUCTION AND MOTIVATION.............................. 3 1. INTRODUCTION AND MOTIVATION.............................. 3
1.1. Applicability and Limitations....................... 5 1.1. Applicability and Limitations....................... 5
1.2. Impact Outside the Network Layer.................... 6 1.2. Impact Outside the Network Layer.................... 6
2. TERMINOLOGY.............................................. 7 2. TERMINOLOGY.............................................. 7
2.1. Requirements........................................ 8 2.1. Addresses........................................... 8
2.2. Requirements........................................ 8
3. OVERVIEW................................................. 8 3. OVERVIEW................................................. 8
3.1. Assumptions......................................... 8 3.1. Assumptions......................................... 9
4. TRANSLATING FROM IPv4 TO IPv6............................ 9 4. TRANSLATING FROM IPv4 TO IPv6............................ 9
4.1. Translating IPv4 Headers............................ 10 4.1. Translating IPv4 Headers............................ 10
4.2. Translating ICMPv4.................................. 12 4.2. Translating ICMPv4.................................. 12
4.3. Translating ICMPv4 Error Messages................... 14 4.3. Translating ICMPv4 Error Messages................... 14
4.4. Knowing when to Translate........................... 14 4.4. Knowing when to Translate........................... 15
5. TRANSLATING FROM IPv6 TO IPv4............................ 15 5. TRANSLATING FROM IPv6 TO IPv4............................ 15
5.1. Translating IPv6 Headers............................ 16 5.1. Translating IPv6 Headers............................ 17
5.2. Translating ICMPv6.................................. 18 5.2. Translating ICMPv6.................................. 18
5.3. Translating ICMPv6 Error Messages................... 19 5.3. Translating ICMPv6 Error Messages................... 20
5.4. Knowing when to Translate........................... 20 5.4. Knowing when to Translate........................... 21
6. SECURITY CONSIDERATIONS.................................. 20 6. SECURITY CONSIDERATIONS.................................. 21
7. OPEN ISSUES.............................................. 20 7. OPEN ISSUES.............................................. 21
REFERENCES................................................... 21 REFERENCES................................................... 22
AUTHOR'S ADDRESS............................................. 22 AUTHOR'S ADDRESS............................................. 23
APPENDIX A: CHANGES SINCE PREVIOUS DRAFT..................... 22 APPENDIX A: CHANGES SINCE PREVIOUS DRAFT..................... 23
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
skipping to change at page 8, line 7 skipping to change at page 8, line 7
IPv6 capable node: IPv6 capable node:
A node which has an IPv6 protocol stack. In order A node which has an IPv6 protocol stack. In order
for the stack to be usable the node must be assigned for the stack to be usable the node must be assigned
one or more IPv6 addresses. one or more IPv6 addresses.
IPv6 enabled node: A node which has an IPv6 protocol stack IPv6 enabled node: A node which has an IPv6 protocol stack
and is assigned one or more IPv6 addresses. Both and is assigned one or more IPv6 addresses. Both
IPv6-only and IPv6/IPv4 nodes are IPv6 enabled. IPv6-only and IPv6/IPv4 nodes are IPv6 enabled.
2.1. Requirements 2.1. Addresses
In addition to the forms of addresses defined in [ADDR-ARCH] this
document also introduces the new form of IPv4-translated address to
avoid using IPv4-compatible addresses outside the intended use of
automatic tunneling. Thus the address forms are:
IPv4-mapped:
An address of the form 0::ffff:a.b.c.d which refers
to a node that is not IPv6-capable. In addition to
its use in the API this protocol uses IPv4-mapped
addresses in IPv6 packets to refer to an IPv4 node.
IPv4-compatible:
An address of the form 0::0:a.b.c.d which refers to
an IPv6/IPv4 node that supports automatic tunneling.
Such addresses are not used in this protocol.
IPv4-translated:
An address of the form 0::ffff:0:a.b.c.d which refers
to an IPv6-enabled node. Note that the prefix
0::ffff:0:0:0/96 is chosen to checksum to zero to
avoid any changes to the transport protocol's pseudo
header checksum.
2.2. 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
topology that includes some IPv6-only nodes and can also include IPv4 topology that includes some IPv6-only nodes and can also include IPv4
nodes and dual nodes. There has to be a translator on each path in nodes and dual nodes. There has to be a translator on each path in
skipping to change at page 8, line 37 skipping to change at page 9, line 16
IPv6 packets that need translation will have an IPv4-mapped IPv6 IPv6 packets that need translation will have an IPv4-mapped IPv6
destination address. destination address.
Inbound IPv4 packets needing translation are likely to have some Inbound IPv4 packets needing translation are likely to have some
temporary IPv4 address that is drawn from a pool of such addresses. temporary IPv4 address that is drawn from a pool of such addresses.
Thus the internal IPv4 routing tables could have one or more routes Thus the internal IPv4 routing tables could have one or more routes
for the whole pool that direct the packets to the translator. for the whole pool that direct the packets to the translator.
3.1. Assumptions 3.1. Assumptions
The IPv6 nodes using the translator must have an IPv4-compatible IPv6 The IPv6 nodes using the translator must have an IPv4-translated IPv6
address while it is communicating with IPv4 nodes. address while it is communicating with IPv4 nodes.
4. TRANSLATING FROM IPv4 TO IPv6 4. TRANSLATING FROM IPv4 TO IPv6
When an IPv4-to-IPv6 translator receives an IPv4 datagram addressed When an IPv4-to-IPv6 translator receives an IPv4 datagram addressed
to a destination that lies outside of the attached IPv4 island, it to a destination that lies outside of the attached IPv4 island, it
translates the IPv4 header of that packet into an IPv6 header. It translates the IPv4 header of that packet into an IPv6 header. It
then forwards the packet based on the IPv6 destination address. The then forwards the packet based on the IPv6 destination address. The
original IPv4 header on the packet is removed and replaced by a IPv6 original IPv4 header on the packet is removed and replaced by a IPv6
header. Except for ICMP packets the transport layer header and data header. Except for ICMP packets the transport layer header and data
skipping to change at page 10, line 43 skipping to change at page 11, line 15
translated independently using the logic described below. translated independently using the logic described below.
If the DF bit is set and the packet is not a fragment (i.e., the MF If the DF bit is set and the packet is not a fragment (i.e., the MF
flag is not set and the Fragment Offset is zero) then there is no flag is not set and the Fragment Offset is zero) then there is no
need to add a fragment header to the packet. The IPv6 header fields need to add a fragment header to the packet. The IPv6 header fields
are set as follows: are set as follows:
Version: Version:
6 6
Flow ID: Traffic Class:
Copied from IP Type Of Service and Precedence field
(all 8 bits are copied).
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.
Payload Type: Next Header:
Protocol field copied from IPv4 header Protocol field copied from IPv4 header
Hop Limit: Hop Limit:
TTL value copied from IPv4 header, decremented by TTL value copied from IPv4 header. Since the
one. translator is a router, as part of forwarding the
packet it needs to decrement either the IPv4 TTL
(before the translation) or the IPv6 Hop Limit (after
the translation). As part of decrementing the TTL or
Hop Limit the translator (as any router) needs to
check for zero and send the ICMPv4 or ICMPv6 "ttl
exceeded" error.
Source Address: Source Address:
The low-order 32 bits is the IPv4 source address. The low-order 32 bits is the IPv4 source address.
The high-order 96 bits is the IPv4-mapped prefix The high-order 96 bits is the IPv4-mapped prefix
(::ffff:0:0/96) (::ffff:0:0/96)
Destination Address: Destination Address:
The low-order 32 bits is the IPv4 destination The low-order 32 bits is the IPv4 destination
address. The high-order 96 bits is the IPv4- address. The high-order 96 bits is the IPv4-
compatible prefix (0::0/96) translated prefix (0::ffff:0:0:0/96)
If IPv4 options are present in the IPv4 packet, they are ignored If IPv4 options are present in the IPv4 packet, they are ignored
i.e., there is no attempt to translate them. i.e., there is no attempt to translate them.
[Discussion: Should the packet be dropped and an ICMP error be
generated instead?]
If there is need to add a fragment header (the DF bit is not set or If there is need to add a fragment header (the DF bit is not set or
the packet is a fragment) the header fields are set as above with the the packet is a fragment) the header fields are set as above with the
following exceptions: following exceptions:
IPv6 fields: IPv6 fields:
Payload Length: Payload Length:
Total length value from IPv4 header, plus 8 for the Total length value from IPv4 header, plus 8 for the
fragment header, minus the size of the IPv4 header fragment header, minus the size of the IPv4 header
and IPv4 options, if present. and IPv4 options, if present.
Payload Type: Next Header:
Fragment Header (44). Fragment Header (44).
Fragment header fields: Fragment header fields:
Next Header: Next Header:
Protocol field copied from IPv4 header. Protocol field copied from IPv4 header.
Fragment Offset: Fragment Offset:
Fragment Offset copied from the IPv4 header. Fragment Offset copied from the IPv4 header.
skipping to change at page 13, line 20 skipping to change at page 13, line 45
ICMPv4 error messages: ICMPv4 error messages:
Destination Unreachable (Type 3) Destination Unreachable (Type 3)
For all that are not explicitly listed below set the Type to For all that are not explicitly listed below set the Type to
1. 1.
Translate the code field as follows: Translate the code field as follows:
Code 0, 1: Set Code to 0 (no route to destination). Code 0, 1: Set Code to 0 (no route to destination).
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 Next Header
Type field. 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.
Note that if the IPv4 router did not set the MTU field Note that if the IPv4 router did not set the MTU field
i.e. the router does not implement [PMTUv4], then the i.e. the router does not implement [PMTUv4], then the
translator must use the plateau values specified in translator must use the plateau values specified in
[PMTUv4] to determine a likely path MTU and include that [PMTUv4] to determine a likely path MTU and include that
skipping to change at page 16, line 26 skipping to change at page 17, line 16
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)
Type of Service: Type of Service and Precedence:
All zero. Copied from the IPv6 Traffic Class (all 8 bits).
[Discussion: Should this value be derived from the
IPv6 priority field?]
Total Length: Total Length:
Payload length value from IPv6 header, plus the size Payload length value from IPv6 header, plus the size
of the IPv4 header. of the IPv4 header.
Identification: Identification:
All zero. All zero.
[Discussion: In order to make IPv4 header compression
work better for translated packets it might make
sense to make this an incrementing counter. There is
no need for the counter to be correct since the
packets will not be fragmented.]
Flags: Flags:
The More Fragments flag is set to zero. The Don't The More Fragments flag is set to zero. The Don't
Fragments flag is set to one. Fragments flag is set to one.
Fragment Offset: Fragment Offset:
All zero. All zero.
Time to Live: Time to Live:
Hop Limit value copied from IPv6 header, decremented Hop Limit value copied from IPv6 header. Since the
by one. translator is a router, as part of forwarding the
packet it needs to decrement either the IPv6 Hop
Limit (before the translation) or the IPv4 TTL (after
the translation). As part of decrementing the TTL or
Hop Limit the translator (as any router) needs to
check for zero and send the ICMPv4 or ICMPv6 "ttl
exceeded" error.
Protocol: Protocol:
Payload Type field copied from IPv6 header. Next Header field copied from IPv6 header.
Header Checksum: Header Checksum:
Computed once the IPv4 header has been created. Computed once the IPv4 header has been created.
Source Address: Source Address:
If the IPv6 source address is an IPv4-compatible or If the IPv6 source address is an IPv4-translated or
an IPv4-mapped address then the low-order 32 bits of an IPv4-mapped address then the low-order 32 bits of
the IPv6 source address is copied to the IPv4 source the IPv6 source address is copied to the IPv4 source
address. Otherwise, the source address is set to address. Otherwise, the source address is set to
127.0.0.1. 127.0.0.1.
[Discussion: An alternative could be to drop the
packet. However, it would be useful if a traceroute
from the IPv4 node showed something for the IPv6
router hops. Thus either using 127.0.0.1 or 0.0.0.0
seem like reasonable alternatives.]
Destination Address: Destination Address:
IPv6 packets that are translated have a destination IPv6 packets that are translated have a destination
address that is either an IPv4-compatible or an address that is either an IPv4-translated or an
IPv4-mapped address. Thus the low-order 32 bits of IPv4-mapped address. Thus the low-order 32 bits of
the IPv6 destination address is copied to the IPv4 the IPv6 destination address is copied to the IPv4
source address. source address.
If any of an IPv6 hop-by-hop options header, destination options If any of an IPv6 hop-by-hop options header, destination options
header, or routing header are present in the IPv6 packet, they are header, or routing header are present in the IPv6 packet, they are
ignored i.e., there is no attempt to translate them. However, the ignored i.e., there is no attempt to translate them. However, the
Total Length field and the Protocol field would have to be adjusted Total Length field and the Protocol field would have to be adjusted
to "skip" these extension headers. to "skip" these extension headers.
[Discussion: Should the packet be dropped and an ICMP error be
generated instead?]
If the IPv6 packet contains a Fragment header the header fields are If the IPv6 packet contains a Fragment header the header fields are
set as above with the following exceptions: set as above with the following exceptions:
Total Length: Total Length:
Payload length value from IPv6 header, minus 8 for Payload length value from IPv6 header, minus 8 for
the Fragment header, plus the size of the IPv4 the Fragment header, plus the size of the IPv4
header. header.
Identification: Identification:
skipping to change at page 20, line 38 skipping to change at page 21, line 17
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
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 currently specified to include the
IPv4 Identification field and the translating function not being able
to always preserve the Identification field, it is not possible for
an IPv6 endpoint to predict the content of a packet at the IPv4 side
of the translator. As such it is impossible to translate packets
with AH headers.
Packets with ESP can be translated since ESP does not depend on
header fields prior to the ESP header. Note that ESP transport mode
is preferred over ESP tunnel mode since it does not contain an
"extra" encrypted IP header which could confuse the peer.
7. OPEN ISSUES 7. OPEN ISSUES
- Can/should we make AH work through a translator e.g. by removing - 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 the fragment ID field from the AH computation for both IPv4 and
IPv6? IPv6?
- For IPv6 to IPv4 should the Identification be something other than - For IPv6 to IPv4 should the Identification be something other than
zero to be more friendly to header compression? These packets zero to be more friendly to header compression? The packets in
have DF set thus it is possible to choose e.g. a local question have DF set thus it is possible to choose e.g. a local
incrementing counter without adverse effects on reassembly. incrementing counter without adverse effects on reassembly.
- IPv6 to IPv4 when source is pure IPv6 address. What should the - When translation IPv6 to IPv4 when the source is pure IPv6 address
IPv4 source address be set to in order to make traceroute usable? the draft specifies to use 127.0.0.1 as the source address (in
If such packets are not translated an IPv4 traceroute would show order to make an IPv4 traceroute show something). Alternatives
no responses from IPv6 routers. We could use 127.0.0.1 or are to use a different address in this case (e.g. 0.0.0.0) or
0.0.0.0. simply drop the packet (which would not show such hops when using
traceroute).
- When translating IPv4 packets with IP options the draft specifies
that the IPv4 options be silently ignored. Should the packet be
dropped and an ICMP error be generated instead?
- When translating IPv6 packets with Hop-by-hop or destination
options extension headers this document specifies that those
headers be silently ignored. Should the packet be dropped and an
ICMP error be generated instead?
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 22, line 26 skipping to change at page 23, line 25
901 San Antonio Road 901 San Antonio Road
Palo Alto, CA 94303 Palo Alto, CA 94303
USA USA
phone: +1 650 786 5166 phone: +1 650 786 5166
fax: +1 650 786 5896 fax: +1 650 786 5896
email: nordmark@sun.com email: nordmark@sun.com
APPENDIX A: CHANGES SINCE PREVIOUS DRAFT APPENDIX A: CHANGES SINCE PREVIOUS DRAFT
The following changes have been made since version 00 of the draft. The following changes have been made since version 01 of the draft:
o Introduced the notion of IPv4-translated addresses.
o Clarified that IPv4-mapped addresses are sent over the wire.
o Clarified generating ICMP ttl exceeded when ttl or hop limit
reaches zero.
o Added 1-1 mapping between IPv4 TOS and IPv6 Traffic Class.
The following changes have been made since version 00 of the draft:
o Added clarification about applicability for multicast. o Added clarification about applicability for multicast.
o Clarified the terminology with IPv4 capable vs. enabled etc. o Clarified the terminology with IPv4 capable vs. enabled etc.
o Changed the title to provide an acronym (SIIT). o Changed the title to provide an acronym (SIIT).
o Added some figures to explain the applicability. 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/