idnits 2.17.1 draft-ietf-v6ops-ivi-icmp-address-01.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (February 25, 2012) is 4444 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) -- Obsolete informational reference (is this intentional?): RFC 5736 (Obsoleted by RFC 6890) Summary: 1 error (**), 0 flaws (~~), 3 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 Intended status: BCP CERNET Center/Tsinghua 5 Expires: August 28, 2012 University 6 D. Wing 7 R. Vaithianathan 8 Cisco 9 G. Huston 10 APNIC 11 February 25, 2012 13 Stateless Source Address Mapping for ICMPv6 Packets 14 draft-ietf-v6ops-ivi-icmp-address-01 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 the 21 IPv4-translatable destination. This document discusses the 22 considerations and presents a stateless address mapping algorithm for 23 source address translation in ICMPv6 headers for 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 August 28, 2012. 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. Routing Considerations . . . . . . . . . . . . . . . . . . . . 4 63 5. Stateless Address Mapping Algorithm . . . . . . . . . . . . . . 4 64 6. ICMP Extension . . . . . . . . . . . . . . . . . . . . . . . . 5 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 66 7.1. Filtering Recommendations . . . . . . . . . . . . . . . . . 5 67 7.2. Rate-limiting Recommendations . . . . . . . . . . . . . . . 5 68 7.3. RFC5837 Recommendations . . . . . . . . . . . . . . . . . . 5 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 70 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 The IP/ICMP translation document of IPv4/IPv6 translation [RFC6145] 79 states that "the IPv6 addresses in the ICMPv6 header may not be IPv4- 80 translatable addresses and there will be no corresponding IPv4 81 addresses represented of this IPv6 address. In this case, the 82 translator can do stateful translation. A mechanism by which the 83 translator can instead do stateless translation is left for future 84 work." This document defines such a stateless translation mechanism. 86 2. Notational Conventions 88 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 89 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 90 document, are to be interpreted as described in [RFC2119]. 92 3. Problem Statement and Considerations 94 When a stateless IPv4/IPv6 translator receives an ICMPv6 message (for 95 example "Packet Too Big") sourced from an non-IPv4-translatable IPv6 96 address, directed to an IPv4-translatable IPv6 address, it needs to 97 generate an ICMP message. For the reasons discussed below, choosing 98 the source IPv4 address of this ICMP message is problematic. 100 The address used should not cause the ICMP packet to be a candidate 101 for discarding, particularly in the contest of uRPF filters 102 [RFC3704]. This consideration precludes the use of private IPv4 103 address space [RFC1918] in this context. 105 It is also a consideration that the IPv4/IPv6 translation is intended 106 for use in contexts where IPv4 addresses may not be readily 107 available, so it is not considered to be appropriate to use IPv4- 108 translatable IPv6 addresses for all internal points in the IPv6 109 network that may originate ICMPv6 messages. 111 It is also an objective that it is possible for the IPv4 recipient of 112 the ICMP message be able to distinguish between different IPv6 ICMPv6 113 originations (for example, to support a traceroute diagnostic utility 114 that provides some limited network level visibility across the IPv4/ 115 IPv6 translator). This implies that a IPv4/IPv6 translator needs to 116 have a pool of IPv4 addresses to be used for mapping the source 117 address of ICMPv6 packets generated from different originations. 119 These addresses are for use in the source address of ICMP packets, 120 and therefore are not intended to be used as a destination address 121 for any packet. It is therefore possible to use a common address 122 pool for the IPv4/IPv6 translation protocol, and, considering an 123 objective of constraining the use of these IPv4 addresses in this 124 application, it is feasible to use a common address pool for mapping 125 the source addresses of non-translatable ICMPv6 packets as a part of 126 the protocol specification. 128 These considerations leads to the recommendation of drawing an IPv4 129 /24 prefix from the IANA Special Purpose Address Registry as a "Well- 130 Known Prefix" for use by IPv4/IPv6 translators for the purpose of 131 mapping otherwise untranslatable IPv6 source addresses of ICMPv6 132 messages to IPv4 ICMP messages. 134 The ICMP extension defined by [RFC5837] provides a mechanism to 135 process the ICMPv4 messages that contain IP Address Sub-Objects that 136 specify IPv6 addresses. However, an enhanced traceroute application 137 must be used, which has not yet been widely available. In this 138 document, a combined approach is proposed, i.e. non IPv4-translatable 139 address is mapped to IANA-assigned /24, and the resulting ICMP is 140 extended according to [RFC5837]. Therefore, ordinary ICMP processing 141 tools (traceroute) can be utilized in normal cases and when DDoS 142 happens, enhanced ICMP process tools can be utilized to identify the 143 real source. 145 4. Routing Considerations 147 Addresses from the assigned address prefix are intended to be used as 148 source addresses and not as destination addresses in the context of 149 the public network. As packets passing through the public network 150 need to pass through conventional packet filters, including uRPF 151 filters [RFC3704], this implies that the assigned address may be used 152 in routing advertisements. Such routing advertisements are non- 153 exclusive and should be accepted from any originating AS in an 154 anycast fashion. 156 5. Stateless Address Mapping Algorithm 158 When an IPv4 /24 prefix is allocated to represent the source address 159 of ICMP, the translator MUST copy the "Hop Count" in the IPv6 header 160 of the ICMPv6 to the Last Octet. When routers emit ICMPv6 packets 161 with the same hop count, as the ICMPv6 packet is routed through the 162 network its hop count is decreased. However, if the routers emit 163 ICMPv6 packets with different hop counts, it may give the appearance 164 of a routing loop to tools such as traceroute. That minor side- 165 effect in that particular case cannot be avoided while still being 166 stateless. 168 6. ICMP Extension 170 When translator is configured to use the IANA-assigned /24 to map non 171 IPv4-translatable address, the translator MUST implement ICMP 172 extension defined by [RFC5837]. The resulting ICMP extension MUST 173 include the IP address Sub-Objects that specify the source IPv6 174 addresses in the original ICMPv6. Therefore, an enhanced traceroute 175 application can get the real IPv6 source addresses which generate the 176 ICMPv6 messages, be able to traceback to their origins and take 177 filtering/rate-limiting actions if necessary. 179 7. Security Considerations 181 The use of an address for source addresses in ICMP packets is 182 considered "safe" in so far as ICMP packets are not intended to 183 generate responses directed to the source address. 185 However it is possible to use this address as a means of gaining 186 anonymity when launching a denial of service attacks by using this 187 address as the source address for other forms of malicious traffic. 188 Packet firewall filters should be configured to treat addresses in 189 the IANA-assigned /24 network as martian addresses by discarding all 190 non-ICMP packets that use the IANA-assigned /24 network as a source 191 address, and all packets that use the IANA-assigned /24 network as a 192 destination address. 194 7.1. Filtering Recommendations 196 o SHOULD allow ICMP type 3 - Destination Unreachable (inc PTB). 198 o SHOULD allow ICMP type 11 - Time Exceeded. 200 o MAY allow ICMP type 12 - Parameter Problem. 202 o SHOULD NOT allow any of the various ICMP request messages. 204 7.2. Rate-limiting Recommendations 206 The rate limiting of traffic from the prefix SHOULD also be enabled 207 as additional countermeasure against abuse of this prefix. The 208 methods presented in [RFC4443] [RFC5597] [RFC6192] [RFC6398] 209 [RFC6450] can be used. 211 7.3. RFC5837 Recommendations 213 Advanced filtering and rate-limiting techniques which can process the 214 ICMP extension defined in [RFC5837] MAY also be used to control the 215 source of the ICMP. 217 8. IANA Considerations 219 IANA is requested to make a permanent assignment of a /24 from the 220 IPv4 Special Purpose Address Registry [RFC5736]. The assigned 221 address is to be used in the context of generating an IPv4 source 222 address for mapped ICMPv6 packets being passed through a stateless 223 IPv4/IPv6 translator. The assignment is under the category of a 224 specialized use of a designated address block in an anycast context 225 associated with an Internet Standards Track protocol. 227 The IANA IPv4 Special Purpose Address Registry records are: 229 o Prefix 192.70.192.0/24 231 o Description: To be used in the context of generating an IPv4 232 source address for mapped ICMPv6 packets being passed through a 233 stateless IPv4/IPv6 translator. 235 o Begin: 2011-06-01 237 o End: Never 239 o Purpose: Stateless ICMPv6/ICMP translation 241 o Contact: See RFC 243 o Scope: Addresses from the assigned address prefix are intended to 244 be used as source addresses and not as destination addresses in 245 the context of the public network. 247 o RFC: This draft. 249 9. Acknowledgments 251 The authors would like to acknowledge the following contributors of 252 this document: Kevin Yin, Chris Metz and Neeraj Gupta. 254 10. References 256 10.1. Normative References 258 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 259 E. Lear, "Address Allocation for Private Internets", 260 BCP 5, RFC 1918, February 1996. 262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, March 1997. 265 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 266 Networks", BCP 84, RFC 3704, March 2004. 268 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 269 Message Protocol (ICMPv6) for the Internet Protocol 270 Version 6 (IPv6) Specification", RFC 4443, March 2006. 272 [RFC5597] Denis-Courmont, R., "Network Address Translation (NAT) 273 Behavioral Requirements for the Datagram Congestion 274 Control Protocol", BCP 150, RFC 5597, September 2009. 276 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 277 Rivers, "Extending ICMP for Interface and Next-Hop 278 Identification", RFC 5837, April 2010. 280 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 281 Algorithm", RFC 6145, April 2011. 283 [RFC6398] Le Faucheur, F., "IP Router Alert Considerations and 284 Usage", BCP 168, RFC 6398, October 2011. 286 [RFC6450] Venaas, S., "Multicast Ping Protocol", RFC 6450, 287 December 2011. 289 10.2. Informative References 291 [RFC5736] Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special 292 Purpose Address Registry", RFC 5736, January 2010. 294 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 295 Router Control Plane", RFC 6192, March 2011. 297 Authors' Addresses 299 Xing Li 300 CERNET Center/Tsinghua University 301 Room 225, Main Building, Tsinghua University 302 Beijing 100084 303 CN 305 Phone: +86 10-62785983 306 Email: xing@cernet.edu.cn 308 Congxiao Bao 309 CERNET Center/Tsinghua University 310 Room 225, Main Building, Tsinghua University 311 Beijing 100084 312 CN 314 Phone: +86 10-62785983 315 Email: congxiao@cernet.edu.cn 317 Dan Wing 318 Cisco Systems, Inc. 319 170 West Tasman Drive 320 San Jose, CA 95134 321 USA 323 Email: dwing@cisco.com 325 Ramji Vaithianathan 326 Cisco Systems, Inc. 327 A 5-2, BGL 12-4, SEZ Unit, 328 Cessna Business Park, Varthur Hobli 329 Sarjapur Outer Ring Road 330 BANGALORE KARNATAKA 560 103 331 INDIA 333 Phone: +91 80 4426 0895 334 Email: rvaithia@cisco.com 336 Geoff Huston 337 APNIC 339 Email: gih@apnic.net