--- 1/draft-ietf-v6ops-ivi-icmp-address-06.txt 2012-10-12 10:14:15.009342447 +0200 +++ 2/draft-ietf-v6ops-ivi-icmp-address-07.txt 2012-10-12 10:14:15.025342172 +0200 @@ -1,24 +1,24 @@ Network Working Group X. Li Internet-Draft C. Bao -Intended status: BCP CERNET Center/Tsinghua -Expires: March 15, 2013 University - D. Wing +Updates: 6145 (if approved) CERNET Center/Tsinghua +Intended status: Standards Track University +Expires: April 15, 2013 D. Wing R. Vaithianathan Cisco G. Huston APNIC - September 11, 2012 + October 12, 2012 Stateless Source Address Mapping for ICMPv6 Packets - draft-ietf-v6ops-ivi-icmp-address-06 + draft-ietf-v6ops-ivi-icmp-address-07 Abstract A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non IPv4-translatable addresses as the source. These packets should be passed across the translator as ICMP packets directed to the IPv4 destination. This document presents recommendations for source address translation in ICMPv6 headers to handle such cases. @@ -30,21 +30,21 @@ Internet-Drafts are working documents of the Internet Engineering 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 15, 2013. + This Internet-Draft will expire on April 15, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -56,79 +56,82 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement and Considerations . . . . . . . . . . . . . 3 3.1. Considerations . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Recommendations . . . . . . . . . . . . . . . . . . . . . . 4 4. ICMP Extension . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Stateless Address Mapping Algorithm . . . . . . . . . . . . . . 4 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1. Normative References . . . . . . . . . . . . . . . . . . . 5 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction [RFC6145] section 5.2 of the "IP/ICMP Translation Algorithm" document. states that "the IPv6 addresses in the ICMPv6 header may not be IPv4-translatable addresses and there will be no corresponding IPv4 addresses representing this IPv6 address. In this case, the translator can do stateful translation. A mechanism by which the translator can instead do stateless translation is left for future work." This document, Stateless Source Address Mapping for ICMPv6 Packets, provides recommendations for this case. + For the purposes of this document, the term IPv4-translatable + address" is as defined in Section 2.2 of [RFC6052]. + 2. Notational Conventions The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 3. Problem Statement and Considerations When a stateless IPv4/IPv6 translator receives an ICMPv6 message [RFC4443] (for example "Packet Too Big") sourced from an non-IPv4- translatable IPv6 address, bound for to an IPv4-translatable IPv6 address, the translator needs to pick a source address with which to generate an ICMP message. For the reasons discussed below, this choice is problematic. 3.1. Considerations - The source address used, should not cause the ICMP packet to be a - candidate for discarding. The possibility of uRPF filters in the - path are a critical consideration [RFC3704] which precludes the use - of private IPv4 address space [RFC1918] in this context. + The source address used, SHOULD NOT cause the ICMP packet to be + discarded. It SHOULD NOT be drawn from [RFC1918] address space, + because [RFC1918] sourced packets are likely to be subject to uRPF + [RFC3704] filtering. IPv4/IPv6 translation is intended for use in contexts where IPv4 addresses may not be readily available, so it is not considered appropriate to assign IPv4-translatable IPv6 addresses for all internal points in the IPv6 network that may originate ICMPv6 messages. - Another consideration for source selection is that it be possible for - the IPv4 recipients of the ICMP message to be able to distinguish - between different IPv6 network origination of ICMPv6 messages, (for - example, to support a traceroute diagnostic utility that provides - some limited network level visibility across the IPv4/IPv6 - translator). This consideration implies that an IPv4/IPv6 translator - needs to have a pool of IPv4 addresses for mapping the source address - of ICMPv6 packets generated from different origins, or to include the - IPv6 source address information for mapping the source address by - others means. Currently, the TRACEROUTE and MTR [MTR] are the only - consumers of translated ICMPv6 messages that care about the ICMPv6 - source address. + Another consideration for source selection is that it should be + possible for the IPv4 recipients of the ICMP message to be able to + distinguish between different IPv6 network origination of ICMPv6 + messages, (for example, to support a traceroute diagnostic utility + that provides some limited network level visibility across the IPv4/ + IPv6 translator). This consideration implies that an IPv4/IPv6 + translator needs to have a pool of IPv4 addresses for mapping the + source address of ICMPv6 packets generated from different origins, or + to include the IPv6 source address information for mapping the source + address by others means. Currently, the TRACEROUTE and MTR [MTR] are + the only consumers of translated ICMPv6 messages that care about the + ICMPv6 source address. 3.2. Recommendations The recommended approach to source selection is to use the a single (or small pool) of public IPv4 address as the source address of the translated ICMP message and leverage ICMP extension [RFC5837] to include IPv6 address as an Interface IP Address Sub-Object. 4. ICMP Extension @@ -146,23 +149,25 @@ address belongs to the translator, not the originating node can also be considered. 5. Stateless Address Mapping Algorithm If a pool of public IPv4 addresses is configured on the translator, it is RECOMMENDED to randomly select the IPv4 source address from the pool. Random selection reduces the probability that two ICMP messages elicited by the same TRACEROUTE might specify the same source address and, therefore, erroneously present the appearance of - a routing loop. An enhanced traceroute application is RECOMMENDED in - order to obtain the IPv6 source addresses which generated the ICMPv6 - messages. + a routing loop. + + [RFC5837] extensions and an enhanced traceroute application, if used, + will reveal the IPv6 source addresses which generated the original + ICMPv6 messages. 6. Security Considerations This document recommends the generation of IPv4 ICMP messages from IPv6 ICMP messages. These messages would otherwise have been discarded. It is not expected that new considerations result from this change. As with a number of ICMP messages, a spoofed source address may result in replies arriving at hosts that did not expect them using the facility of the translator. @@ -194,20 +199,25 @@ Networks", BCP 84, RFC 3704, March 2004. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. Rivers, "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010. + [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. + + Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, + October 2010. + [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. 9.2. Informative References [MTR] "http://www.bitwizard.nl/mtr/". Authors' Addresses Xing Li