idnits 2.17.1 draft-xli-v6ops-ivi-icmp-address-00.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 (July 26, 2011) is 4656 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: January 27, 2012 University 6 D. Wing 7 R. Vaithianathan 8 Cisco 9 G. Huston 10 APNIC 11 July 26, 2011 13 Stateless Source Address Mapping for ICMPv6 Packets 14 draft-xli-v6ops-ivi-icmp-address-00 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 the stateless address mapping algorithms 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 January 27, 2012. 42 Copyright Notice 44 Copyright (c) 2011 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. Possible Stateless Address Mapping Algorithms . . . . . . . . . 4 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 66 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 69 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 The IP/ICMP translation document of IPv4/IPv6 translation [RFC6145] 75 states that "the IPv6 addresses in the ICMPv6 header may not be IPv4- 76 translatable addresses and there will be no corresponding IPv4 77 addresses represented of this IPv6 address. In this case, the 78 translator can do stateful translation. A mechanism by which the 79 translator can instead do stateless translation is left for future 80 work." This document defines such a stateless translation mechanism. 82 2. Notational Conventions 84 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 85 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 86 document, are to be interpreted as described in [RFC2119]. 88 3. Problem Statement and Considerations 90 When a stateless IPv4/IPv6 translator receives an ICMPv6 message (for 91 example "Packet Too Big") sourced from an non-IPv4-translatable IPv6 92 address, directed to an IPv4-translatable IPv6 address, it needs to 93 generate an ICMP message. For the reasons discussed below, choosing 94 the source IPv4 address of this ICMP message is problematic. 96 The address used should not cause the ICMP packet to be a candidate 97 for discarding, particularly in the contest of uRPF filters 98 [RFC3704]. This consideration precludes the use of private IPv4 99 address space [RFC1918] in this context. 101 It is also a consideration that the IPv4/IPv6 translation is intended 102 for use in contexts where IPv4 addresses may not be readily 103 available, so it is not considered to be appropriate to use IPv4- 104 translatable IPv6 addresses for all internal points in the IPv6 105 network that may originate ICMPv6 messages. 107 It is also an objective that it is possible for the IPv4 recipient of 108 the ICMP message be able to distinguish between different IPv6 ICMPv6 109 originations (for example, to support a traceroute diagnostic utility 110 that provides some limited network level visibility across the IPv4/ 111 IPv6 translator). This implies that a IPv4/IPv6 translator needs to 112 have a pool of IPv4 addresses to be used for mapping the source 113 address of ICMPv6 packets generated from different originations. 115 These addresses are for use in the source address of ICMP packets, 116 and therefore are not intended to be used as a destination address 117 for any packet. It is therefore possible to use a common address 118 pool for the IPv4/IPv6 translation protocol, and, considering an 119 objective of constraining the use of these IPv4 addresses in this 120 application, it is feasible to use a common address pool for mapping 121 the source addresses of non-translatable ICMPv6 packets as a part of 122 the protocol specification. 124 These considerations leads to the recommendation of drawing an IPv4 125 /24 prefix from the IANA Special Purpose Address Registry as a "Well- 126 Known Prefix" for use by IPv4/IPv6 translators for the purpose of 127 mapping otherwise untranslatable IPv6 source addresses of ICMPv6 128 messages to IPv4 ICMP messages. 130 4. Routing Considerations 132 Addresses from the assigned address prefix are intended to be used as 133 source addresses and not as destination addresses in the context of 134 the public network. As packets passing through the public network 135 need to pass through conventional packet filters, including uRPF 136 filters [RFC3704], this implies that the assigned address may be used 137 in routing advertisements. Such routing advertisements are non- 138 exclusive and should be accepted from any originating AS in an 139 anycast fashion. 141 5. Possible Stateless Address Mapping Algorithms 143 When an IPv4 /24 prefix is allocated to represent the source address 144 of ICMP, the Last Octet can be generated using one of the following 145 algorithms. 147 o The translator can randomly generates the Last Octet of the /24 148 prefix for different non IPv4-translatable addresses. However, in 149 this case the translator may need to maintain states to ensure 150 same non IPv4-translatable IPv6 address maps to same IPv4 address. 152 o The translator can copy the "Hop Count" in the IPv6 header of the 153 ICMPv6 to the Last Octet. Routers typically emit ICMPv6 packets 154 with the same hop count, thus as the ICMPv6 packet is routed 155 through the network its hop count is decreased. However, if the 156 routers emit ICMPv6 packets with different hop counts, it may give 157 the appearance of a routing loop to tools such as traceroute. 158 That minor side-effect in that particular case cannot be avoided 159 while still being stateless. 161 o Hashing of the IPv6 address to generate a 8 bit value which will 162 be used to generate the last octet. In this case, there is no 163 need to maintain expensive states, except hashing table which 164 should be simple with minimal memory usage and consume minimal CPU 165 cycles. If the hashing function is good and there are limited 166 number of IPv6 routers (< 256) on the IPv6 side of the network, we 167 will get unique IPv4 addresses to map the addresses of the IPv6 168 routers with O(1) lookup. 170 The selection of the algorithm SHOULD be a configuration function in 171 the IPv4/IPv6 translator. 173 6. Security Considerations 175 The use of an address for source addresses in ICMP packets is 176 considered "safe" in so far as ICMP packets are not intended to 177 generate responses directed to the source address. 179 However it is possible to use this address as a means of gaining 180 anonymity when launching a denial of service attacks by using this 181 address as the source address for other forms of malicious traffic. 182 Packet firewall filters should be configured to treat addresses in 183 the IANA-assigned /24 network as martian addresses by discarding all 184 non-ICMP packets that use the IANA-assigned /24 network as a source 185 address, and all packets that use the IANA-assigned /24 network as a 186 destination address. 188 7. IANA Considerations 190 IANA is requested to make a permanent assignment of a /24 from the 191 IPv4 Special Purpose Address Registry [RFC5736]. The assigned 192 address is to be used in the context of generating an IPv4 source 193 address for mapped ICMPv6 packets being passed through a stateless 194 IPv4/IPv6 translator. The assignment is under the category of a 195 specialized use of a designated address block in an anycast context 196 associated with an Internet Standards Track protocol. 198 The IANA IPv4 Special Purpose Address Registry records are: 200 o Prefix 192.70.192.0/24 202 o Description: To be used in the context of generating an IPv4 203 source address for mapped ICMPv6 packets being passed through a 204 stateless IPv4/IPv6 translator. 206 o Begin: 2011-06-01 208 o End: Never 209 o Purpose: Stateless ICMPv6/ICMP translation 211 o Contact: See RFC 213 o Scope: Addresses from the assigned address prefix are intended to 214 be used as source addresses and not as destination addresses in 215 the context of the public network. 217 o RFC: This draft. 219 8. Acknowledgments 221 The authors would like to acknowledge the following contributors of 222 this document: Kevin Yin, Chris Metz and Neeraj Gupta. 224 9. References 226 9.1. Normative References 228 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 229 E. Lear, "Address Allocation for Private Internets", 230 BCP 5, RFC 1918, February 1996. 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, March 1997. 235 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 236 Networks", BCP 84, RFC 3704, March 2004. 238 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 239 Algorithm", RFC 6145, April 2011. 241 9.2. Informative References 243 [RFC5736] Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special 244 Purpose Address Registry", RFC 5736, January 2010. 246 Authors' Addresses 248 Xing Li 249 CERNET Center/Tsinghua University 250 Room 225, Main Building, Tsinghua University 251 Beijing 100084 252 CN 254 Phone: +86 10-62785983 255 Email: xing@cernet.edu.cn 257 Congxiao Bao 258 CERNET Center/Tsinghua University 259 Room 225, Main Building, Tsinghua University 260 Beijing 100084 261 CN 263 Phone: +86 10-62785983 264 Email: congxiao@cernet.edu.cn 266 Dan Wing 267 Cisco Systems, Inc. 268 170 West Tasman Drive 269 San Jose, CA 95134 270 USA 272 Email: dwing@cisco.com 274 Ramji Vaithianathan 275 Cisco Systems, Inc. 276 A 5-2, BGL 12-4, SEZ Unit, 277 Cessna Business Park, Varthur Hobli 278 Sarjapur Outer Ring Road 279 BANGALORE KARNATAKA 560 103 280 INDIA 282 Phone: +91 80 4426 0895 283 Email: rvaithia@cisco.com 285 Geoff Huston 286 APNIC 288 Email: gih@apnic.net