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
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
|
<pre>Network Working Group S. Roy
Request for Comments: 4943 Sun Microsystems, Inc.
Category: Informational A. Durand
Comcast
J. Paugh
Nominum, Inc.
September 2007
<span class="h1">IPv6 Neighbor Discovery On-Link Assumption Considered Harmful</span>
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract
This document describes the historical and background information
behind the removal of the "on-link assumption" from the conceptual
host sending algorithm defined in Neighbor Discovery for IP Version 6
(IPv6). According to the algorithm as originally described, when a
host's default router list is empty, the host assumes that all
destinations are on-link. This is particularly problematic with
IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g.,
no default router). This document describes how making this
assumption causes problems and how these problems outweigh the
benefits of this part of the conceptual sending algorithm.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Background on the On-link Assumption . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-3">3</a>. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. First Rule of Destination Address Selection . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.2">3.2</a>. Delays Associated with Address Resolution . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.3">3.3</a>. Multi-interface Ambiguity . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.4">3.4</a>. Security-Related Issues . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4">4</a>. Changes to <a href="./rfc2461">RFC 2461</a> . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-6">6</a>. Normative References . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#appendix-A">Appendix A</a>. Acknowledgments . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<span class="grey">Roy, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4943">RFC 4943</a> On-Link Assumption Harmful September 2007</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Neighbor Discovery for IPv6 [<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>] defines a conceptual sending
algorithm for hosts. The version of the algorithm described in
[<a href="./rfc2461" title=""Neighbor Discovery for IP Version 6 (IPv6)"">RFC2461</a>] states that if a host's default router list is empty, then
the host assumes that all destinations are on-link. This memo
documents the removal of this assumption in the updated Neighbor
Discovery specification [<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>] and describes the reasons why this
assumption was removed.
This assumption is problematic with IPv6-capable nodes that do not
have off-link IPv6 connectivity. This is typical when systems that
have IPv6 enabled on their network interfaces (either on by default
or administratively configured that way) are attached to networks
that have no IPv6 services such as off-link routing. Such systems
will resolve DNS names to AAAA and A records, and they may attempt to
connect to unreachable IPv6 off-link nodes.
The on-link assumption creates problems for destination address
selection as defined in [<a href="./rfc3484" title=""Default Address Selection for Internet Protocol version 6 (IPv6)"">RFC3484</a>], and it adds connection delays
associated with unnecessary address resolution and neighbor
unreachability detection. The behavior associated with the
assumption is undefined on multi-interface nodes and has some subtle
security implications. All of these issues are discussed in this
document.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Background on the On-link Assumption</span>
This part of Neighbor Discovery's [<a href="./rfc2461" title=""Neighbor Discovery for IP Version 6 (IPv6)"">RFC2461</a>] conceptual sending
algorithm was created to facilitate communication on a single link
between systems configured with different global prefixes in the
absence of an IPv6 router. For example, consider the case where two
systems on separate links are manually configured with global
addresses and are then plugged in back-to-back. They can still
communicate with each other via their global addresses because
they'll correctly assume that each is on-link.
Without the on-link assumption, the above scenario wouldn't work, and
the systems would need to be configured to share a common prefix such
as the link-local prefix. On the other hand, the on-link assumption
introduces several problems to various parts of the networking stack
described in <a href="#section-3">Section 3</a>. As such, this document points out that the
problems introduced by the on-link assumption outweigh the benefit
that the assumption lends to this scenario. It is more beneficial to
the end user to remove the on-link assumption from Neighbor Discovery
and declare this scenario illegitimate (or a misconfiguration).
<span class="grey">Roy, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4943">RFC 4943</a> On-Link Assumption Harmful September 2007</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Problems</span>
The on-link assumption causes the following problems.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. First Rule of Destination Address Selection</span>
Default Address Selection for IPv6 [<a href="./rfc3484" title=""Default Address Selection for Internet Protocol version 6 (IPv6)"">RFC3484</a>] defines a destination
address selection algorithm that takes an unordered list of
destination addresses as input and produces a sorted list of
destination addresses as output. The algorithm consists of
destination address sorting rules, the first of which is "Avoid
unusable destinations". The idea behind this rule is to place
unreachable destinations at the end of the sorted list so that
applications will be least likely to try to communicate with those
addresses first.
The on-link assumption could potentially cause false positives when
attempting unreachability determination for this rule. On a network
where there is no IPv6 router (all off-link IPv6 destinations are
unreachable), the on-link assumption states that destinations are
assumed to be on-link. An implementation could interpret that as, if
the default router list is empty, then all destinations are reachable
on-link. This may cause the rule to prefer an unreachable IPv6
destination over a reachable IPv4 destination.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Delays Associated with Address Resolution</span>
Users expect that applications quickly connect to a given destination
regardless of the number of IP addresses assigned to that
destination. If a destination name resolves to multiple addresses
and the application attempts to communicate to each address until one
succeeds, this process shouldn't take an unreasonable amount of time.
It is therefore important that the system quickly determine if IPv6
destinations are unreachable so that the application can try other
destinations when those IPv6 destinations are unreachable.
For an IPv6-enabled host deployed on a network that has no IPv6
routers, the result of the on-link assumption is that link-layer
address resolution must be performed on all IPv6 addresses to which
the host sends packets. The application will not receive
acknowledgment of the unreachability of destinations that are not on-
link until at least address resolution has failed, which is no less
than 3 seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER). This is
greatly amplified by transport protocol delays. For example,
<a href="./rfc1122#section-4.2.3.5">[RFC1122] Section 4.2.3.5</a> requires that TCP retransmit for at least 3
minutes before aborting the connection attempt.
<span class="grey">Roy, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4943">RFC 4943</a> On-Link Assumption Harmful September 2007</span>
When the application has a large list of off-link unreachable IPv6
addresses followed by at least one reachable IPv4 address, the delay
associated with Neighbor Unreachability Detection (NUD) of each IPv6
address before successful communication with the IPv4 address is
unacceptable.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Multi-interface Ambiguity</span>
There is no defined way to implement this aspect of the sending
algorithm on a node that is attached to multiple links.
Specifically, a problem arises when a node is faced with sending a
packet to an IPv6 destination address to which it has no route, and
the sending node is attached to multiple links. With the on-link
assumption, this node assumes that the destination is on-link, but on
which link? From an implementor's point of view, there are three
ways to handle sending an IPv6 packet to a destination in the face of
the on-link assumption on a multi-interface node:
1. Attempt to send the packet on a single link (either
administratively pre-defined or using some algorithm).
2. Attempt to send the packet on every link.
3. Drop the packet.
If the destination is indeed on-link, the first option might not
succeed since the wrong link could be picked. The second option
might succeed in reaching the destination but is more complex to
implement and isn't guaranteed to pick the correct destination. For
example, there could be more than one node configured with the same
address, each reachable through a different link. The address by
itself does not disambiguate which destination the sender actually
wanted to reach, so attempting to send the packet to every link is
not guaranteed to reach the anticipated destination. The third
option, dropping the packet, is equivalent to not making the on-link
assumption at all. In other words, if there is no route to the
destination, don't attempt to send the packet. An implementation
that behaves this way would require an administrator to configure
routes to the destination in order to have reachability to the
destination, thus eliminating the ambiguity.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Security-Related Issues</span>
The on-link assumption discussed here introduces a security
vulnerability to the Neighbor Discovery protocol described in <a href="#section-4.2.2">Section</a>
<a href="#section-4.2.2">4.2.2</a> of IPv6 Neighbor Discovery Trust Models and Threats [<a href="./rfc3756" title=""IPv6 Neighbor Discovery (ND) Trust Models and Threats"">RFC3756</a>]
titled "Default router is 'killed'". There is a threat that a host's
router can be maliciously killed in order to cause the host to start
<span class="grey">Roy, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4943">RFC 4943</a> On-Link Assumption Harmful September 2007</span>
sending all packets on-link. The attacker can then spoof off-link
nodes by sending packets on the same link as the host. The
vulnerability is discussed in detail in [<a href="./rfc3756" title=""IPv6 Neighbor Discovery (ND) Trust Models and Threats"">RFC3756</a>].
Another security-related side-effect of the on-link assumption has to
do with virtual private networks (VPNs). It has been observed that
some commercially available VPN software solutions that don't support
IPv6 send IPv6 packets to the local media in the clear (their
security policy doesn't simply drop IPv6 packets). Consider a
scenario where a system has a single Ethernet interface with VPN
software that encrypts and encapsulates certain packets. The system
attempts to send a packet to an IPv6 destination that it obtained by
doing a DNS lookup, and the packet ends up going in the clear to the
local media. A malicious third party could then spoof the
destination on-link.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Changes to <a href="./rfc2461">RFC 2461</a></span>
The following changes have been made to the Neighbor Discovery
specification between [<a href="./rfc2461" title=""Neighbor Discovery for IP Version 6 (IPv6)"">RFC2461</a>] and [<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>]:
The last sentence of the second paragraph of <a href="#section-5.2">Section 5.2</a>
("Conceptual Sending Algorithm") was removed. This sentence was,
"If the Default Router List is empty, the sender assumes that the
destination is on-link."
Bullet item 3) in <a href="#section-6.3.6">Section 6.3.6</a> ("Default Router Selection") was
removed. The item read, "If the Default Router List is empty,
assume that all destinations are on-link as specified in <a href="#section-5.2">Section</a>
<a href="#section-5.2">5.2</a>."
APPENDIX A was modified to remove on-link assumption related text
in bullet item 1) under the discussion on what happens when a
multihomed host fails to receive Router Advertisements.
The result of these changes is that destinations are considered
unreachable when there is no routing information for that destination
(through a default router or otherwise). Instead of attempting link-
layer address resolution when sending to such a destination, a node
should send an ICMPv6 Destination Unreachable message (code 0 - no
route to destination) message up the stack.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
The removal of the on-link assumption from Neighbor Discovery
addresses all of the security-related vulnerabilities of the protocol
as described in <a href="#section-3.4">Section 3.4</a>.
<span class="grey">Roy, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4943">RFC 4943</a> On-Link Assumption Harmful September 2007</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Normative References</span>
[<a id="ref-RFC1122">RFC1122</a>] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, <a href="./rfc1122">RFC 1122</a>, October 1989.
[<a id="ref-RFC2461">RFC2461</a>] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", <a href="./rfc2461">RFC 2461</a>,
December 1998.
[<a id="ref-RFC3484">RFC3484</a>] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", <a href="./rfc3484">RFC 3484</a>, February 2003.
[<a id="ref-RFC3756">RFC3756</a>] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", <a href="./rfc3756">RFC 3756</a>,
May 2004.
[<a id="ref-RFC4861">RFC4861</a>] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", <a href="./rfc4861">RFC 4861</a>,
September 2007.
<span class="grey">Roy, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4943">RFC 4943</a> On-Link Assumption Harmful September 2007</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Acknowledgments</span>
The authors gratefully acknowledge the contributions of Jim Bound,
Spencer Dawkins, Tony Hain, Mika Liljeberg, Erik Nordmark, Pekka
Savola, and Ronald van der Pol.
Authors' Addresses
Sebastien Roy
Sun Microsystems, Inc.
1 Network Drive
UBUR02-212
Burlington, MA 01803
EMail: sebastien.roy@sun.com
Alain Durand
Comcast
1500 Market Street
Philadelphia, PA 19102
EMail: alain_durand@cable.comcast.com
James Paugh
Nominum, Inc.
2385 Bay Road
Redwood City, CA 94063
EMail: jim.paugh@nominum.com
<span class="grey">Roy, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4943">RFC 4943</a> On-Link Assumption Harmful September 2007</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Roy, et al. Informational [Page 8]
</pre>
|
