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/