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/