idnits 2.17.1 draft-ietf-v6ops-ivi-icmp-address-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6145, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 12, 2012) is 4207 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Li 3 Internet-Draft C. Bao 4 Updates: 6145 (if approved) CERNET Center/Tsinghua 5 Intended status: Standards Track University 6 Expires: April 15, 2013 D. Wing 7 R. Vaithianathan 8 Cisco 9 G. Huston 10 APNIC 11 October 12, 2012 13 Stateless Source Address Mapping for ICMPv6 Packets 14 draft-ietf-v6ops-ivi-icmp-address-07 16 Abstract 18 A stateless IPv4/IPv6 translator may receive ICMPv6 packets 19 containing non IPv4-translatable addresses as the source. These 20 packets should be passed across the translator as ICMP packets 21 directed to the IPv4 destination. This document presents 22 recommendations for source address translation in ICMPv6 headers to 23 handle such cases. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 15, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 61 3. Problem Statement and Considerations . . . . . . . . . . . . . 3 62 3.1. Considerations . . . . . . . . . . . . . . . . . . . . . . 3 63 3.2. Recommendations . . . . . . . . . . . . . . . . . . . . . . 4 64 4. ICMP Extension . . . . . . . . . . . . . . . . . . . . . . . . 4 65 5. Stateless Address Mapping Algorithm . . . . . . . . . . . . . . 4 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 68 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 5 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 [RFC6145] section 5.2 of the "IP/ICMP Translation Algorithm" 77 document. states that "the IPv6 addresses in the ICMPv6 header may 78 not be IPv4-translatable addresses and there will be no corresponding 79 IPv4 addresses representing this IPv6 address. In this case, the 80 translator can do stateful translation. A mechanism by which the 81 translator can instead do stateless translation is left for future 82 work." This document, Stateless Source Address Mapping for ICMPv6 83 Packets, provides recommendations for this case. 85 For the purposes of this document, the term IPv4-translatable 86 address" is as defined in Section 2.2 of [RFC6052]. 88 2. Notational Conventions 90 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 91 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 92 document, are to be interpreted as described in [RFC2119]. 94 3. Problem Statement and Considerations 96 When a stateless IPv4/IPv6 translator receives an ICMPv6 message 97 [RFC4443] (for example "Packet Too Big") sourced from an non-IPv4- 98 translatable IPv6 address, bound for to an IPv4-translatable IPv6 99 address, the translator needs to pick a source address with which to 100 generate an ICMP message. For the reasons discussed below, this 101 choice is problematic. 103 3.1. Considerations 105 The source address used, SHOULD NOT cause the ICMP packet to be 106 discarded. It SHOULD NOT be drawn from [RFC1918] address space, 107 because [RFC1918] sourced packets are likely to be subject to uRPF 108 [RFC3704] filtering. 110 IPv4/IPv6 translation is intended for use in contexts where IPv4 111 addresses may not be readily available, so it is not considered 112 appropriate to assign IPv4-translatable IPv6 addresses for all 113 internal points in the IPv6 network that may originate ICMPv6 114 messages. 116 Another consideration for source selection is that it should be 117 possible for the IPv4 recipients of the ICMP message to be able to 118 distinguish between different IPv6 network origination of ICMPv6 119 messages, (for example, to support a traceroute diagnostic utility 120 that provides some limited network level visibility across the IPv4/ 121 IPv6 translator). This consideration implies that an IPv4/IPv6 122 translator needs to have a pool of IPv4 addresses for mapping the 123 source address of ICMPv6 packets generated from different origins, or 124 to include the IPv6 source address information for mapping the source 125 address by others means. Currently, the TRACEROUTE and MTR [MTR] are 126 the only consumers of translated ICMPv6 messages that care about the 127 ICMPv6 source address. 129 3.2. Recommendations 131 The recommended approach to source selection is to use the a single 132 (or small pool) of public IPv4 address as the source address of the 133 translated ICMP message and leverage ICMP extension [RFC5837] to 134 include IPv6 address as an Interface IP Address Sub-Object. 136 4. ICMP Extension 138 In the case of either a single public IPv4 address (the IPv4 139 interface address or loopback address of the translator) or a pool of 140 public IPv4 addresses, the translator SHOULD implement ICMP extension 141 defined by [RFC5837]. The ICMP message SHOULD include the Interface 142 IP Address Sub-Object, and specify the source IPv6 addresses of the 143 original ICMPv6. When an enhanced traceroute application is used, it 144 can derive the real IPv6 source addresses which generated the ICMPv6 145 messages. Therefore, it would be able improve on visibility towards 146 the origin rather than simply blackholing at or beyond the 147 translator. In the future, a new ICMP extension whose presence 148 indicates that the packet has been translated and that the source 149 address belongs to the translator, not the originating node can also 150 be considered. 152 5. Stateless Address Mapping Algorithm 154 If a pool of public IPv4 addresses is configured on the translator, 155 it is RECOMMENDED to randomly select the IPv4 source address from the 156 pool. Random selection reduces the probability that two ICMP 157 messages elicited by the same TRACEROUTE might specify the same 158 source address and, therefore, erroneously present the appearance of 159 a routing loop. 161 [RFC5837] extensions and an enhanced traceroute application, if used, 162 will reveal the IPv6 source addresses which generated the original 163 ICMPv6 messages. 165 6. Security Considerations 167 This document recommends the generation of IPv4 ICMP messages from 168 IPv6 ICMP messages. These messages would otherwise have been 169 discarded. It is not expected that new considerations result from 170 this change. As with a number of ICMP messages, a spoofed source 171 address may result in replies arriving at hosts that did not expect 172 them using the facility of the translator. 174 7. IANA Considerations 176 There is no consideration requested of IANA. 178 8. Acknowledgments 180 The authors would like to acknowledge the following contributors of 181 this document: Kevin Yin, Chris Metz, Neeraj Gupta and Joel Jaeggli. 182 The authors would also like to thank Ronald Bonica, Ray Hunter, 183 George Wes, Yu Guanghui, Sowmini Varadhan, David Farmer, Fred Baker, 184 Leo Vegoda, Joel Jaeggli, Henrik Levkowetz, Henrik Levkowetz, Randy 185 Bush and Warren Kumari for their comments and suggestions. 187 9. References 189 9.1. Normative References 191 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 192 E. Lear, "Address Allocation for Private Internets", 193 BCP 5, RFC 1918, February 1996. 195 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 196 Requirement Levels", BCP 14, RFC 2119, March 1997. 198 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 199 Networks", BCP 84, RFC 3704, March 2004. 201 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 202 Message Protocol (ICMPv6) for the Internet Protocol 203 Version 6 (IPv6) Specification", RFC 4443, March 2006. 205 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 206 Rivers, "Extending ICMP for Interface and Next-Hop 207 Identification", RFC 5837, April 2010. 209 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 211 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 212 October 2010. 214 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 215 Algorithm", RFC 6145, April 2011. 217 9.2. Informative References 219 [MTR] "http://www.bitwizard.nl/mtr/". 221 Authors' Addresses 223 Xing Li 224 CERNET Center/Tsinghua University 225 Room 225, Main Building, Tsinghua University 226 Beijing 100084 227 CN 229 Phone: +86 10-62785983 230 Email: xing@cernet.edu.cn 232 Congxiao Bao 233 CERNET Center/Tsinghua University 234 Room 225, Main Building, Tsinghua University 235 Beijing 100084 236 CN 238 Phone: +86 10-62785983 239 Email: congxiao@cernet.edu.cn 241 Dan Wing 242 Cisco Systems, Inc. 243 170 West Tasman Drive 244 San Jose, CA 95134 245 USA 247 Email: dwing@cisco.com 248 Ramji Vaithianathan 249 Cisco Systems, Inc. 250 A 5-2, BGL 12-4, SEZ Unit, 251 Cessna Business Park, Varthur Hobli 252 Sarjapur Outer Ring Road 253 BANGALORE KARNATAKA 560 103 254 INDIA 256 Phone: +91 80 4426 0895 257 Email: rvaithia@cisco.com 259 Geoff Huston 260 APNIC 262 Email: gih@apnic.net