1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
|
<pre>Internet Engineering Task Force (IETF) X. Li
Request for Comments: 6791 C. Bao
Updates: <a href="./rfc6145">6145</a> CERNET Center/Tsinghua University
Category: Standards Track D. Wing
ISSN: 2070-1721 R. Vaithianathan
Cisco
G. Huston
APNIC
November 2012
<span class="h1">Stateless Source Address Mapping for ICMPv6 Packets</span>
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.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6791">http://www.rfc-editor.org/info/rfc6791</a>.
<span class="grey">Li, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6791">RFC 6791</a> Source Address Mapping for ICMPv6 November 2012</span>
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Notational Conventions . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Problem Statement and Considerations . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. Considerations . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.2">3.2</a>. Recommendations . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-4">4</a>. ICMP Extension . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-5">5</a>. Stateless Address Mapping Algorithm . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-7">7</a>. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
<a href="#section-5.3">Section 5.3</a> of "IP/ICMP Translation Algorithm" [<a href="./rfc6145" title=""IP/ICMP Translation Algorithm"">RFC6145</a>] states that
"the IPv6 addresses in the IPv6 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 of this address 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 IPv6
address" is as defined in <a href="./rfc6052#section-2.2">Section 2.2 of [RFC6052]</a>.
<span class="grey">Li, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6791">RFC 6791</a> Source Address Mapping for ICMPv6 November 2012</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Notational Conventions</span>
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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Problem Statement and Considerations</span>
When a stateless IPv4/IPv6 translator receives an ICMPv6 message
[<a href="./rfc4443" title=""Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"">RFC4443</a>] (for example, "Packet Too Big") sourced from a non-IPv4-
translatable IPv6 address and bound for 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.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Considerations</span>
The source address used SHOULD NOT cause the ICMP packet to be
discarded. It SHOULD NOT be drawn from [<a href="./rfc1918" title=""Address Allocation for Private Internets"">RFC1918</a>] or [<a href="./rfc6598" title=""IANA-Reserved IPv4 Prefix for Shared Address Space"">RFC6598</a>]
address space, because that address space is likely to be subject to
unicast Reverse Path Forwarding (uRPF) [<a href="./rfc3704" title=""Ingress Filtering for Multihomed Networks"">RFC3704</a>] filtering.
IPv4/IPv6 translation is intended for use in contexts where IPv4
addresses may not be readily available. Therefore, 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 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 [<a href="#ref-MTR" title=""BitWizard B.V. - The Linux Experts"">MTR</a>] are
the only consumers of translated ICMPv6 messages that care about the
ICMPv6 source address.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Recommendations</span>
The recommended approach to source selection is to use a single (or
small pool of) public IPv4 address as the source address of the
translated ICMP message and leverage the ICMP extension [<a href="./rfc5837" title=""Extending ICMP for Interface and Next-Hop Identification"">RFC5837</a>] to
include the IPv6 address as an Interface IP Address Sub-Object.
<span class="grey">Li, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6791">RFC 6791</a> Source Address Mapping for ICMPv6 November 2012</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. ICMP Extension</span>
In the case of either a single public IPv4 address (the IPv4
interface address or loopback address of the translator) or a pool of
public IPv4 addresses, the translator SHOULD implement the ICMP
extension defined by [<a href="./rfc5837" title=""Extending ICMP for Interface and Next-Hop Identification"">RFC5837</a>]. The ICMP message SHOULD include the
Interface IP Address Sub-Object and specify the source IPv6 addresses
of the original ICMPv6. When an enhanced traceroute application is
used, it can derive the real IPv6 source addresses that generated the
ICMPv6 messages. Therefore, it would be able improve on visibility
towards the origin rather than simply blackholing at or beyond the
translator. In the future, a new ICMP extension whose presence
indicates that the packet has been translated and that the source
address belongs to the translator, not the originating node, can also
be considered.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Stateless Address Mapping Algorithm</span>
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.
[<a id="ref-RFC5837">RFC5837</a>] extensions and an enhanced traceroute application, if used,
will reveal the IPv6 source addresses that generated the original
ICMPv6 messages.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
This document recommends the generation of IPv4 ICMP messages from
IPv6 ICMP messages. These messages would otherwise have been
discarded. New considerations are not expected to 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.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgments</span>
The authors would like to acknowledge the following contributors of
this document: Kevin Yin, Chris Metz, Neeraj Gupta, and Joel Jaeggli.
The authors would also like to thank Ronald Bonica, Ray Hunter,
George Wes, Yu Guanghui, Sowmini Varadhan, David Farmer, Fred Baker,
Leo Vegoda, Joel Jaeggli, Henrik Levkowetz, Randy Bush, and Warren
Kumari for their comments and suggestions.
<span class="grey">Li, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6791">RFC 6791</a> Source Address Mapping for ICMPv6 November 2012</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC1918">RFC1918</a>] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
<a href="https://www.rfc-editor.org/bcp/bcp5">BCP 5</a>, <a href="./rfc1918">RFC 1918</a>, February 1996.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC3704">RFC3704</a>] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", <a href="https://www.rfc-editor.org/bcp/bcp84">BCP 84</a>, <a href="./rfc3704">RFC 3704</a>, March 2004.
[<a id="ref-RFC4443">RFC4443</a>] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", <a href="./rfc4443">RFC 4443</a>,
March 2006.
[<a id="ref-RFC5837">RFC5837</a>] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen,
N., and JR. Rivers, "Extending ICMP for Interface and
Next-Hop Identification", <a href="./rfc5837">RFC 5837</a>, April 2010.
[<a id="ref-RFC6052">RFC6052</a>] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", <a href="./rfc6052">RFC 6052</a>,
October 2010.
[<a id="ref-RFC6145">RFC6145</a>] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", <a href="./rfc6145">RFC 6145</a>, April 2011.
[<a id="ref-RFC6598">RFC6598</a>] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
Space", <a href="https://www.rfc-editor.org/bcp/bcp153">BCP 153</a>, <a href="./rfc6598">RFC 6598</a>, April 2012.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-MTR">MTR</a>] "BitWizard B.V. - The Linux Experts",
<<a href="http://www.bitwizard.nl/mtr/">http://www.bitwizard.nl/mtr/</a>>.
<span class="grey">Li, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6791">RFC 6791</a> Source Address Mapping for ICMPv6 November 2012</span>
Authors' Addresses
Xing Li
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing 100084
China
Phone: +86 10-62785983
EMail: xing@cernet.edu.cn
Congxiao Bao
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing 100084
China
Phone: +86 10-62785983
EMail: congxiao@cernet.edu.cn
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
United States
EMail: dwing@cisco.com
Ramji Vaithianathan
Cisco Systems, Inc.
A 5-2, BGL 12-4, SEZ Unit,
Cessna Business Park, Varthur Hobli
Sarjapur Outer Ring Road
Bangalore Karnataka 560 103
India
Phone: +91 80 4426 0895
EMail: rvaithia@cisco.com
Geoff Huston
APNIC
EMail: gih@apnic.net
Li, et al. Standards Track [Page 6]
</pre>
|
