draft-ietf-v6ops-ivi-icmp-address-07.txt		rfc6791.txt
	Network Working Group X. Li		Internet Engineering Task Force (IETF) X. Li
	Internet-Draft C. Bao		Request for Comments: 6791 C. Bao
	Updates: 6145 (if approved) CERNET Center/Tsinghua		Updates: 6145 CERNET Center/Tsinghua University
	Intended status: Standards Track University		Category: Standards Track D. Wing
	Expires: April 15, 2013 D. Wing		ISSN: 2070-1721 R. Vaithianathan
	R. Vaithianathan
	Cisco		Cisco
	G. Huston		G. Huston
	APNIC		APNIC
	October 12, 2012		November 2012
	Stateless Source Address Mapping for ICMPv6 Packets		Stateless Source Address Mapping for ICMPv6 Packets
	draft-ietf-v6ops-ivi-icmp-address-07
	Abstract		Abstract
	A stateless IPv4/IPv6 translator may receive ICMPv6 packets		A stateless IPv4/IPv6 translator may receive ICMPv6 packets
	containing non IPv4-translatable addresses as the source. These		containing non-IPv4-translatable addresses as the source. These
	packets should be passed across the translator as ICMP packets		packets should be passed across the translator as ICMP packets
	directed to the IPv4 destination. This document presents		directed to the IPv4 destination. This document presents
	recommendations for source address translation in ICMPv6 headers to		recommendations for source address translation in ICMPv6 headers to
	handle such cases.		handle such cases.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		This is an Internet Standards Track document.
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 5741.
	This Internet-Draft will expire on April 15, 2013.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc6791.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3		2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
	3. Problem Statement and Considerations . . . . . . . . . . . . . 3		3. Problem Statement and Considerations . . . . . . . . . . . . . 3
	3.1. Considerations . . . . . . . . . . . . . . . . . . . . . . 3		3.1. Considerations . . . . . . . . . . . . . . . . . . . . . . 3
	3.2. Recommendations . . . . . . . . . . . . . . . . . . . . . . 4		3.2. Recommendations . . . . . . . . . . . . . . . . . . . . . . 3
	4. ICMP Extension . . . . . . . . . . . . . . . . . . . . . . . . 4		4. ICMP Extension . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Stateless Address Mapping Algorithm . . . . . . . . . . . . . . 4		5. Stateless Address Mapping Algorithm . . . . . . . . . . . . . . 4
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5		6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5		8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 5		8.2. Informative References . . . . . . . . . . . . . . . . . . 5
	9.2. Informative References . . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
	1. Introduction		1. Introduction
	[RFC6145] section 5.2 of the "IP/ICMP Translation Algorithm"		Section 5.3 of "IP/ICMP Translation Algorithm" [RFC6145] states that
	document. states that "the IPv6 addresses in the ICMPv6 header may		"the IPv6 addresses in the IPv6 header may not be IPv4-translatable
	not be IPv4-translatable addresses and there will be no corresponding		addresses and there will be no corresponding IPv4 addresses
	IPv4 addresses representing this IPv6 address. In this case, the		representing this IPv6 address. In this case, the translator can do
	translator can do stateful translation. A mechanism by which the		stateful translation. A mechanism by which the translator can
	translator can instead do stateless translation is left for future		instead do stateless translation of this address is left for future
	work." This document, Stateless Source Address Mapping for ICMPv6		work." This document, "Stateless Source Address Mapping for ICMPv6
	Packets, provides recommendations for this case.		Packets", provides recommendations for this case.
	For the purposes of this document, the term IPv4-translatable		For the purposes of this document, the term "IPv4-translatable IPv6
	address" is as defined in Section 2.2 of [RFC6052].		address" is as defined in Section 2.2 of [RFC6052].
	2. Notational Conventions		2. Notational Conventions
	The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,		The key words 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 [RFC2119].		document, are to be interpreted as described in [RFC2119].
	3. Problem Statement and Considerations		3. Problem Statement and Considerations
	When a stateless IPv4/IPv6 translator receives an ICMPv6 message		When a stateless IPv4/IPv6 translator receives an ICMPv6 message
	[RFC4443] (for example "Packet Too Big") sourced from an non-IPv4-		[RFC4443] (for example, "Packet Too Big") sourced from a non-IPv4-
	translatable IPv6 address, bound for to an IPv4-translatable IPv6		translatable IPv6 address and bound for an IPv4-translatable IPv6
	address, the translator needs to pick a source address with which to		address, the translator needs to pick a source address with which to
	generate an ICMP message. For the reasons discussed below, this		generate an ICMP message. For the reasons discussed below, this
	choice is problematic.		choice is problematic.
	3.1. Considerations		3.1. Considerations
	The source address used, SHOULD NOT cause the ICMP packet to be		The source address used SHOULD NOT cause the ICMP packet to be
	discarded. It SHOULD NOT be drawn from [RFC1918] address space,		discarded. It SHOULD NOT be drawn from [RFC1918] or [RFC6598]
	because [RFC1918] sourced packets are likely to be subject to uRPF		address space, because that address space is likely to be subject to
	[RFC3704] filtering.		unicast Reverse Path Forwarding (uRPF) [RFC3704] filtering.
	IPv4/IPv6 translation is intended for use in contexts where IPv4		IPv4/IPv6 translation is intended for use in contexts where IPv4
	addresses may not be readily available, so it is not considered		addresses may not be readily available. Therefore, it is not
	appropriate to assign IPv4-translatable IPv6 addresses for all		considered appropriate to assign IPv4-translatable IPv6 addresses for
	internal points in the IPv6 network that may originate ICMPv6		all internal points in the IPv6 network that may originate ICMPv6
	messages.		messages.
	Another consideration for source selection is that it should be		Another consideration for source selection is that it should be
	possible for the IPv4 recipients of the ICMP message to be able to		possible for the IPv4 recipients of the ICMP message to be able to
	distinguish between different IPv6 network origination of ICMPv6		distinguish between different IPv6 network origination of ICMPv6
	messages, (for example, to support a traceroute diagnostic utility		messages (for example, to support a traceroute diagnostic utility
	that provides some limited network level visibility across the IPv4/		that provides some limited network-level visibility across the IPv4/
	IPv6 translator). This consideration implies that an IPv4/IPv6		IPv6 translator). This consideration implies that an IPv4/IPv6
	translator needs to have a pool of IPv4 addresses for mapping the		translator needs to have a pool of IPv4 addresses for mapping the
	source address of ICMPv6 packets generated from different origins, or		source address of ICMPv6 packets generated from different origins, or
	to include the IPv6 source address information for mapping the source		to include the IPv6 source address information for mapping the source
	address by others means. Currently, the TRACEROUTE and MTR [MTR] are		address by others means. Currently, the TRACEROUTE and MTR [MTR] are
	the only consumers of translated ICMPv6 messages that care about the		the only consumers of translated ICMPv6 messages that care about the
	ICMPv6 source address.		ICMPv6 source address.
	3.2. Recommendations		3.2. Recommendations
	The recommended approach to source selection is to use the a single		The recommended approach to source selection is to use a single (or
	(or small pool) of public IPv4 address as the source address of the		small pool of) public IPv4 address as the source address of the
	translated ICMP message and leverage ICMP extension [RFC5837] to		translated ICMP message and leverage the ICMP extension [RFC5837] to
	include IPv6 address as an Interface IP Address Sub-Object.		include the IPv6 address as an Interface IP Address Sub-Object.
	4. ICMP Extension		4. ICMP Extension
	In the case of either a single public IPv4 address (the IPv4		In the case of either a single public IPv4 address (the IPv4
	interface address or loopback address of the translator) or a pool of		interface address or loopback address of the translator) or a pool of
	public IPv4 addresses, the translator SHOULD implement ICMP extension		public IPv4 addresses, the translator SHOULD implement the ICMP
	defined by [RFC5837]. The ICMP message SHOULD include the Interface		extension defined by [RFC5837]. The ICMP message SHOULD include the
	IP Address Sub-Object, and specify the source IPv6 addresses of the		Interface IP Address Sub-Object and specify the source IPv6 addresses
	original ICMPv6. When an enhanced traceroute application is used, it		of the original ICMPv6. When an enhanced traceroute application is
	can derive the real IPv6 source addresses which generated the ICMPv6		used, it can derive the real IPv6 source addresses that generated the
	messages. Therefore, it would be able improve on visibility towards		ICMPv6 messages. Therefore, it would be able improve on visibility
	the origin rather than simply blackholing at or beyond the		towards the origin rather than simply blackholing at or beyond the
	translator. In the future, a new ICMP extension whose presence		translator. In the future, a new ICMP extension whose presence
	indicates that the packet has been translated and that the source		indicates that the packet has been translated and that the source
	address belongs to the translator, not the originating node can also		address belongs to the translator, not the originating node, can also
	be considered.		be considered.
	5. Stateless Address Mapping Algorithm		5. Stateless Address Mapping Algorithm
	If a pool of public IPv4 addresses is configured on the translator,		If a pool of public IPv4 addresses is configured on the translator,
	it is RECOMMENDED to randomly select the IPv4 source address from the		it is RECOMMENDED to randomly select the IPv4 source address from the
	pool. Random selection reduces the probability that two ICMP		pool. Random selection reduces the probability that two ICMP
	messages elicited by the same TRACEROUTE might specify the same		messages elicited by the same TRACEROUTE might specify the same
	source address and, therefore, erroneously present the appearance of		source address and, therefore, erroneously present the appearance of
	a routing loop.		a routing loop.
	[RFC5837] extensions and an enhanced traceroute application, if used,		[RFC5837] extensions and an enhanced traceroute application, if used,
	will reveal the IPv6 source addresses which generated the original		will reveal the IPv6 source addresses that generated the original
	ICMPv6 messages.		ICMPv6 messages.
	6. Security Considerations		6. Security Considerations
	This document recommends the generation of IPv4 ICMP messages from		This document recommends the generation of IPv4 ICMP messages from
	IPv6 ICMP messages. These messages would otherwise have been		IPv6 ICMP messages. These messages would otherwise have been
	discarded. It is not expected that new considerations result from		discarded. New considerations are not expected to result from this
	this change. As with a number of ICMP messages, a spoofed source		change. As with a number of ICMP messages, a spoofed source address
	address may result in replies arriving at hosts that did not expect		may result in replies arriving at hosts that did not expect them
	them using the facility of the translator.		using the facility of the translator.
	7. IANA Considerations
	There is no consideration requested of IANA.
	8. Acknowledgments		7. Acknowledgments
	The authors would like to acknowledge the following contributors of		The authors would like to acknowledge the following contributors of
	this document: Kevin Yin, Chris Metz, Neeraj Gupta and Joel Jaeggli.		this document: Kevin Yin, Chris Metz, Neeraj Gupta, and Joel Jaeggli.
	The authors would also like to thank Ronald Bonica, Ray Hunter,		The authors would also like to thank Ronald Bonica, Ray Hunter,
	George Wes, Yu Guanghui, Sowmini Varadhan, David Farmer, Fred Baker,		George Wes, Yu Guanghui, Sowmini Varadhan, David Farmer, Fred Baker,
	Leo Vegoda, Joel Jaeggli, Henrik Levkowetz, Henrik Levkowetz, Randy		Leo Vegoda, Joel Jaeggli, Henrik Levkowetz, Randy Bush, and Warren
	Bush and Warren Kumari for their comments and suggestions.		Kumari for their comments and suggestions.
	9. References		8. References
	9.1. Normative References		8.1. Normative References
	[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and		[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.,
	E. Lear, "Address Allocation for Private Internets",		and E. Lear, "Address Allocation for Private Internets",
	BCP 5, RFC 1918, February 1996.		BCP 5, RFC 1918, February 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed		[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
	Networks", BCP 84, RFC 3704, March 2004.		Networks", BCP 84, RFC 3704, March 2004.
	[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control		[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
	Message Protocol (ICMPv6) for the Internet Protocol		Control Message Protocol (ICMPv6) for the Internet
	Version 6 (IPv6) Specification", RFC 4443, March 2006.		Protocol Version 6 (IPv6) Specification", RFC 4443,
			March 2006.
	[RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR.		[RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen,
	Rivers, "Extending ICMP for Interface and Next-Hop		N., and JR. Rivers, "Extending ICMP for Interface and
	Identification", RFC 5837, April 2010.		Next-Hop Identification", RFC 5837, April 2010.
	[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.		[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
	Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,		Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
	October 2010.		October 2010.
	[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation		[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
	Algorithm", RFC 6145, April 2011.		Algorithm", RFC 6145, April 2011.
	9.2. Informative References		[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
			M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
			Space", BCP 153, RFC 6598, April 2012.
	[MTR] "http://www.bitwizard.nl/mtr/".		8.2. Informative References
			[MTR] "BitWizard B.V. - The Linux Experts",
			<http://www.bitwizard.nl/mtr/>.
	Authors' Addresses		Authors' Addresses
	Xing Li		Xing Li
	CERNET Center/Tsinghua University		CERNET Center/Tsinghua University
	Room 225, Main Building, Tsinghua University		Room 225, Main Building, Tsinghua University
	Beijing 100084		Beijing 100084
	CN		China
	Phone: +86 10-62785983		Phone: +86 10-62785983
	Email: xing@cernet.edu.cn		EMail: xing@cernet.edu.cn
	Congxiao Bao		Congxiao Bao
	CERNET Center/Tsinghua University		CERNET Center/Tsinghua University
	Room 225, Main Building, Tsinghua University		Room 225, Main Building, Tsinghua University
	Beijing 100084		Beijing 100084
	CN		China
	Phone: +86 10-62785983		Phone: +86 10-62785983
	Email: congxiao@cernet.edu.cn		EMail: congxiao@cernet.edu.cn
	Dan Wing		Dan Wing
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		United States
			EMail: dwing@cisco.com
	Email: dwing@cisco.com
	Ramji Vaithianathan		Ramji Vaithianathan
	Cisco Systems, Inc.		Cisco Systems, Inc.
	A 5-2, BGL 12-4, SEZ Unit,		A 5-2, BGL 12-4, SEZ Unit,
	Cessna Business Park, Varthur Hobli		Cessna Business Park, Varthur Hobli
	Sarjapur Outer Ring Road		Sarjapur Outer Ring Road
	BANGALORE KARNATAKA 560 103		Bangalore Karnataka 560 103
	INDIA		India
	Phone: +91 80 4426 0895		Phone: +91 80 4426 0895
	Email: rvaithia@cisco.com		EMail: rvaithia@cisco.com
	Geoff Huston		Geoff Huston
	APNIC		APNIC
	Email: gih@apnic.net		EMail: gih@apnic.net
End of changes. 42 change blocks.
	98 lines changed or deleted		93 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/