idnits 2.17.1 draft-ietf-v6ops-ivi-icmp-address-03.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 : ---------------------------------------------------------------------------- No issues found here. 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 (July 11, 2012) is 4306 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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 (==), 1 comment (--). 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 Intended status: BCP CERNET Center/Tsinghua 5 Expires: January 12, 2013 University 6 D. Wing 7 R. Vaithianathan 8 Cisco 9 G. Huston 10 APNIC 11 July 11, 2012 13 Stateless Source Address Mapping for ICMPv6 Packets 14 draft-ietf-v6ops-ivi-icmp-address-03 16 Abstract 18 A stateless IPv4/IPv6 translator may receive ICMPv6 packets 19 containing non IPv4-translatable addresses as the source that should 20 be passed across the translator as an ICMP packet directed to the 21 IPv4-translatable destination. This document presents 22 recommendations for source address translation in ICMPv6 headers for 23 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 January 12, 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 4. ICMP Extension . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Stateless Address Mapping Algorithm . . . . . . . . . . . . . . 4 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 66 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 67 9. Normative References . . . . . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 The IP/ICMP translation document of IPv4/IPv6 translation [RFC6145] 73 states that "the IPv6 addresses in the ICMPv6 header may not be IPv4- 74 translatable addresses and there will be no corresponding IPv4 75 addresses represented of this IPv6 address. In this case, the 76 translator can do stateful translation. A mechanism by which the 77 translator can instead do stateless translation is left for future 78 work." This document presents recommendations for this case. 80 2. Notational Conventions 82 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 83 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 84 document, are to be interpreted as described in [RFC2119]. 86 3. Problem Statement and Considerations 88 When a stateless IPv4/IPv6 translator receives an ICMPv6 message 89 [RFC4443] (for example "Packet Too Big") sourced from an non-IPv4- 90 translatable IPv6 address, directed to an IPv4-translatable IPv6 91 address, it needs to generate an ICMP message. For the reasons 92 discussed below, choosing the source IPv4 address of this ICMP 93 message is problematic. 95 The address used should not cause the ICMP packet to be a candidate 96 for discarding, particularly in the contest of uRPF filters 97 [RFC3704]. This consideration precludes the use of private IPv4 98 address space [RFC1918] in this context. 100 It is also a consideration that the IPv4/IPv6 translation is intended 101 for use in contexts where IPv4 addresses may not be readily 102 available, so it is not considered to be appropriate to use IPv4- 103 translatable IPv6 addresses for all internal points in the IPv6 104 network that may originate ICMPv6 messages. 106 It is also an objective that it is possible for the IPv4 recipient of 107 the ICMP message be able to distinguish between different IPv6 ICMPv6 108 originations (for example, to support a traceroute diagnostic utility 109 that provides some limited network level visibility across the IPv4/ 110 IPv6 translator). This implies that an IPv4/IPv6 translator needs to 111 have a pool of IPv4 addresses for mapping the source address of 112 ICMPv6 packets generated from different originations, or to include 113 the IPv6 source address information for mapping the source address by 114 others means. 116 These considerations leads to the recommendation of using the a 117 single (or small pool) of public IPv4 address as the source address 118 of translated ICMP and using ICMP extension [RFC5837] to include IPv6 119 address as Interface IP Address Sub-Object. 121 4. ICMP Extension 123 No matter a single public IPv4 address (in the IPv4 interface or a 124 loopback address of the translator) or a pool of public IPv4 125 addresses are used, the translator SHOULD implement ICMP extension 126 defined by [RFC5837]. The resulting ICMP extension SHOULD include 127 the Interface IP Address Sub-Object that specify the source IPv6 128 addresses in the original ICMPv6. When an enhanced traceroute 129 application is used, it can get the real IPv6 source addresses which 130 generate the ICMPv6 messages. Therefore, it is able to traceback to 131 their origins and take filtering/rate-limiting actions if necessary. 133 5. Stateless Address Mapping Algorithm 135 If a pool of public IPv4 addresses is configured in the translator, 136 it is RECOMMENDED to randomly pick up the IPv4 public address in the 137 pool. This can somehow avoid the appearance of a routing loop to 138 tools such as traceroute. An enhanced traceroute application is 139 still RECOMMENDED in order to obtain the real IPv6 source addresses 140 which generate the ICMPv6 messages. 142 6. Security Considerations 144 This document does not introduce any new security considerations. 146 7. IANA Considerations 148 None. 150 8. Acknowledgments 152 The authors would like to acknowledge the following contributors of 153 this document: Kevin Yin, Chris Metz and Neeraj Gupta. The authors 154 would also like to thank Ronald Bonica, Ray Hunter, George Wes, Yu 155 Guanghui, Sowmini Varadhan, David Farmer, Fred Baker, Leo Vegoda, 156 Joel Jaeggli, Henrik Levkowetz, Henrik Levkowetz, Randy Bush and 157 Warren Kumari for their comments and suggestions. 159 9. Normative References 161 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 162 E. Lear, "Address Allocation for Private Internets", 163 BCP 5, RFC 1918, February 1996. 165 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 166 Requirement Levels", BCP 14, RFC 2119, March 1997. 168 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 169 Networks", BCP 84, RFC 3704, March 2004. 171 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 172 Message Protocol (ICMPv6) for the Internet Protocol 173 Version 6 (IPv6) Specification", RFC 4443, March 2006. 175 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 176 Rivers, "Extending ICMP for Interface and Next-Hop 177 Identification", RFC 5837, April 2010. 179 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 180 Algorithm", RFC 6145, April 2011. 182 Authors' Addresses 184 Xing Li 185 CERNET Center/Tsinghua University 186 Room 225, Main Building, Tsinghua University 187 Beijing 100084 188 CN 190 Phone: +86 10-62785983 191 Email: xing@cernet.edu.cn 193 Congxiao Bao 194 CERNET Center/Tsinghua University 195 Room 225, Main Building, Tsinghua University 196 Beijing 100084 197 CN 199 Phone: +86 10-62785983 200 Email: congxiao@cernet.edu.cn 201 Dan Wing 202 Cisco Systems, Inc. 203 170 West Tasman Drive 204 San Jose, CA 95134 205 USA 207 Email: dwing@cisco.com 209 Ramji Vaithianathan 210 Cisco Systems, Inc. 211 A 5-2, BGL 12-4, SEZ Unit, 212 Cessna Business Park, Varthur Hobli 213 Sarjapur Outer Ring Road 214 BANGALORE KARNATAKA 560 103 215 INDIA 217 Phone: +91 80 4426 0895 218 Email: rvaithia@cisco.com 220 Geoff Huston 221 APNIC 223 Email: gih@apnic.net