idnits 2.17.00 (12 Aug 2021) /tmp/idnits60812/draft-ietf-v6ops-onlinkassumption-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 427. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 417. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 9, 2006) is 5969 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2462' is defined on line 292, but no explicit reference was found in the text == Outdated reference: draft-ietf-ipv6-2461bis has been published as RFC 4861 ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Downref: Normative reference to an Informational RFC: RFC 3756 -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Roy 3 Internet-Draft Sun Microsystems, Inc. 4 Expires: July 13, 2006 A. Durand 5 Comcast Corporation 6 J. Paugh 7 Nominum, Inc. 8 January 9, 2006 10 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful 11 draft-ietf-v6ops-onlinkassumption-04.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on July 13, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document describes the historical and background information 45 behind the removal of the "on-link assumption" from the conceptual 46 host sending algorithm defined in Neighbor Discovery for IP Version 6 47 (IPv6). According to the algorithm as originally described, when a 48 host's default router list is empty, the host assumes that all 49 destinations are on-link. This is particularly problematic with 50 IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., 51 no default router). This document describes how making this 52 assumption causes problems, and describes how these problems outweigh 53 the benefits of this part of the conceptual sending algorithm. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Background on the On-link Assumption . . . . . . . . . . . . . 3 59 3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. First Rule of Destination Address Selection . . . . . . . 4 61 3.2. Delays Associated with Address Resolution . . . . . . . . 4 62 3.3. Multi-interface Ambiguity . . . . . . . . . . . . . . . . 5 63 3.4. Security Related Issues . . . . . . . . . . . . . . . . . 5 64 4. Changes to RFC2461 . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 68 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 69 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 7 70 Appendix B. Changes from draft-ietf-v6ops-onlinkassumption-03 . . 7 71 Appendix C. Changes from draft-ietf-v6ops-onlinkassumption-02 . . 8 72 Appendix D. Changes from draft-ietf-v6ops-onlinkassumption-01 . . 8 73 Appendix E. Changes from draft-ietf-v6ops-onlinkassumption-00 . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 75 Intellectual Property and Copyright Statements . . . . . . . . . . 11 77 1. Introduction 79 Neighbor Discovery for IPv6 [I-D.ietf-ipv6-2461bis] defines a 80 conceptual sending algorithm for hosts. The version of the algorithm 81 described in [RFC2461] states that if a host's default router list is 82 empty, then the host assumes that all destinations are on-link. This 83 memo documents the removal of this assumption in the updated Neighbor 84 Discovery specification [I-D.ietf-ipv6-2461bis], and describes the 85 reasons why this assumption was removed. 87 This assumption is problematic with IPv6-capable nodes that do not 88 have off-link IPv6 connectivity. This is typical when systems that 89 have IPv6 enabled on their network interfaces (either on by default 90 or administratively configured that way) are attached to networks 91 that have no IPv6 services such as off-link routing. Such systems 92 will resolve DNS names to AAAA and A records, and may attempt to 93 connect to unreachable IPv6 off-link nodes. 95 The on-link assumption creates problems for destination address 96 selection as defined in [RFC3484], and adds connection delays 97 associated with unnecessary address resolution and neighbor 98 unreachability detection. The behavior associated with the 99 assumption is undefined on multi-interface nodes, and has some subtle 100 security implications. All of these issues are discussed in this 101 document. 103 2. Background on the On-link Assumption 105 This part of Neighbor Discovery's [RFC2461] conceptual sending 106 algorithm was created to facilitate communication on a single link 107 between systems configured with different global prefixes in the 108 absence of an IPv6 router. For example, consider the case where two 109 systems on separate links are manually configured with global 110 addresses, and are then plugged in back-to-back. They can still 111 communicate with each other via their global addresses because 112 they'll correctly assume that each is on-link. 114 Without the on-link assumption, the above scenario wouldn't work, and 115 the systems would need to be configured to share a common prefix such 116 as the link-local prefix. On the other hand, the on-link assumption 117 introduces several problems to various parts of the networking stack 118 described in Section 3. As such, this document points out that the 119 problems introduced by the on-link assumption outweigh the benefit 120 that the assumption lends to this scenario. It is more beneficial to 121 the end user to remove the on-link assumption from Neighbor Discovery 122 and declare this scenario illegitimate (or a misconfiguration). 124 3. Problems 126 The on-link assumption causes the following problems. 128 3.1. First Rule of Destination Address Selection 130 Default Address Selection for IPv6 [RFC3484] defines a destination 131 address selection algorithm that takes an unordered list of 132 destination addresses as input, and produces a sorted list of 133 destination addresses as output. The algorithm consists of 134 destination address sorting rules, the first of which is "Avoid 135 unusable destinations". The idea behind this rule is to place 136 unreachable destinations at the end of the sorted list so that 137 applications will be least likely to try to communicate with those 138 addresses first. 140 The on-link assumption could potentially cause false positives when 141 attempting unreachability determination for this rule. On a network 142 where there is no IPv6 router (all off-link IPv6 destinations are 143 unreachable), the on-link assumption states that destinations are 144 assumed to be on-link. An implementation could interpret that as, if 145 the default router list is empty, then all destinations are reachable 146 on-link. This may cause the rule to prefer an unreachable IPv6 147 destination over a reachable IPv4 destination. 149 3.2. Delays Associated with Address Resolution 151 Users expect that applications quickly connect to a given destination 152 regardless of the number of IP addresses assigned to that 153 destination. If a destination name resolves to multiple addresses 154 and the application attempts to communicate to each address until one 155 succeeds, this process shouldn't take an unreasonable amount of time. 156 It is therefore important that the system quickly determine if IPv6 157 destinations are unreachable so that the application can try other 158 destinations when those IPv6 destinations are unreachable. 160 For an IPv6 enabled host deployed on a network that has no IPv6 161 routers, the result of the on-link assumption is that link-layer 162 address resolution must be performed on all IPv6 addresses to which 163 the host sends packets. The Application will not receive 164 acknowledgment of the unreachability of destinations that are not on- 165 link until at least address resolution has failed, which is no less 166 than three seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER). This is 167 greatly amplified by transport protocol delays. For example, 168 [RFC1122] section 4.2.3.5 requires that TCP retransmit for at least 3 169 minutes before aborting the connection attempt. 171 When the application has a large list of off-link unreachable IPv6 172 addresses followed by at least one reachable IPv4 address, the delay 173 associated with Neighbor Unreachability Detection (NUD) of each IPv6 174 addresses before successful communication with the IPv4 address is 175 unacceptable. 177 3.3. Multi-interface Ambiguity 179 There is no defined way to implement this aspect of the sending 180 algorithm on a node that is attached to multiple links. 181 Specifically, a problem arises when a node is faced with sending a 182 packet to an IPv6 destination address to which it has no route, and 183 the sending node is attached to multiple links. With the on-link 184 assumption, this node assumes that the destination is on-link, but on 185 which link? From an implementor's point of view, there are three 186 ways to handle sending an IPv6 packet to a destination in the face of 187 the on-link assumption on a multi-interface node: 189 1. Attempt to send the packet on a single link (either 190 administratively pre-defined or using some algorithm.) 192 2. Attempt to send the packet on every link. 194 3. Drop the packet. 196 If the destination is indeed on-link, the first option might not 197 succeed since the wrong link could be picked. The second option 198 might succeed in reaching the destination but is more complex to 199 implement, and isn't guaranteed to pick the correct destination. For 200 example, there could be more than one node configured with the same 201 address, each reachable through a different link. The address by 202 itself does not disambiguate which destination the sender actually 203 wanted to reach, so attempting to send the packet to every link is 204 not guaranteed to reach the anticipated destination. The third 205 option, dropping the packet, is equivalent to not making the on-link 206 assumption at all. In other words, if there is no route to the 207 destination, don't attempt to send the packet. An implementation 208 that behaves this way would require an administrator to configure 209 routes to the destination in order to have reachability to the 210 destination, thus eliminating the ambiguity. 212 3.4. Security Related Issues 214 The on-link assumption discussed here introduces a security 215 vulnerability to the Neighbor Discovery protocol described in section 216 4.2.2 of IPv6 Neighbor Discovery Trust Models and Threats [RFC3756] 217 titled "Default router is 'killed'". There is a threat that a host's 218 router can be maliciously killed in order to cause the host to start 219 sending all packets on-link. The attacker can then spoof off-link 220 nodes by sending packets on the same link as the host. The 221 vulnerability is discussed in detail in [RFC3756]. 223 Another security related side-effect of the on-link assumption has to 224 do with virtual private networks (VPN's). It has been observed that 225 some commercially available VPN software solutions that don't support 226 IPv6 send IPv6 packets to the local media in the clear (their 227 security policy doesn't simply drop IPv6 packets). Consider a 228 scenario where a system has a single Ethernet interface with VPN 229 software that encrypts and encapsulates certain packets. The system 230 attempts to send a packet to an IPv6 destination that it obtained by 231 doing a DNS lookup, and the packet ends up going in the clear to the 232 local media. A malicious third party could then spoof the 233 destination on-link. 235 4. Changes to RFC2461 237 The following changes have been made to the Neighbor Discovery 238 specification between [RFC2461] and [I-D.ietf-ipv6-2461bis]: 240 The last sentence of the second paragraph of section 5.2 241 ("Conceptual Sending Algorithm") was removed. This sentence was, 242 "If the Default Router List is empty, the sender assumes that the 243 destination is on-link." 245 Bullet item 3) in section 6.3.6 ("Default Router Selection") was 246 removed. The item read, "If the Default Router List is empty, 247 assume that all destinations are on-link as specified in Section 248 5.2." 250 APPENDIX A was modified to remove on-link assumption related text 251 in bullet item 1) under the discussion on what happens when a 252 multihomed host fails to receive Router Advertisements. 254 The result of these changes is that destinations are considered 255 unreachable when there is no routing information for that destination 256 (through a default router or otherwise). Instead of attempting link- 257 layer address resolution when sending to such a destination, a node 258 should send an ICMPv6 Destination Unreachable message (code 0 - no 259 route to destination) message up the stack. 261 5. Security Considerations 263 The removal of the on-link assumption from Neighbor Discovery 264 addresses all of the security-related vulnerabilities of the protocol 265 as described in Section 3.4. 267 6. References 269 6.1. Normative References 271 [I-D.ietf-ipv6-2461bis] 272 Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 273 draft-ietf-ipv6-2461bis-05 (work in progress), 274 October 2005. 276 [RFC1122] Braden, R., "Requirements for Internet Hosts - 277 Communication Layers", STD 3, RFC 1122, October 1989. 279 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 280 Discovery for IP Version 6 (IPv6)", RFC 2461, 281 December 1998. 283 [RFC3484] Draves, R., "Default Address Selection for Internet 284 Protocol version 6 (IPv6)", RFC 3484, February 2003. 286 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 287 Discovery (ND) Trust Models and Threats", RFC 3756, 288 May 2004. 290 6.2. Informative References 292 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 293 Autoconfiguration", RFC 2462, December 1998. 295 Appendix A. Acknowledgments 297 The authors gratefully acknowledge the contributions of Jim Bound, 298 Spencer Dawkins, Tony Hain, Mika Liljeberg, Erik Nordmark, Pekka 299 Savola, and Ronald van der Pol. 301 Appendix B. Changes from draft-ietf-v6ops-onlinkassumption-03 303 o Clarified that the scenario described in the background section 304 (section 2) is considered a misconfiguration. 306 o In section 3.2, specified the section number of RFC1122 that 307 specifies the 3 minute TCP retransmission period. 309 o Clarified section 3.3 (Multi-interface Ambiguity) to make explicit 310 that it's talking about an interface selection problem, and not an 311 address selection problem. The change also clarifies that the 312 third behavior eliminates the problematic ambiguity of the 313 described scenario. 315 o Modified section 5 (Security Considerations) to state that the 316 removal of the on-link assumption addresses all security concerns 317 described in section 3.4. 319 o Changed Jim Paugh's (co-author) organization and mailing address. 321 Appendix C. Changes from draft-ietf-v6ops-onlinkassumption-02 323 o Changed abstract to reflect the historical nature of this 324 document. 326 o Changed the introduction to stress that this is historical 327 information documenting the removal of the on-link assumption from 328 the ND spec. 330 o Added text to the introduction stating that the assumption is a 331 problem for nodes with IPv6 on by default. 333 o Added mention to RFC1122 in section 3.2. 335 o Changed use of the term multi-homed nodes to "nodes that are 336 attached to multiple links". 338 o Changed section 4 from "Proposed Changes" to "Changes" and 339 adjusted included text to reflect that the changes have been made. 341 Appendix D. Changes from draft-ietf-v6ops-onlinkassumption-01 343 o Added text in the Introduction stating that rfc2461bis has removed 344 the on-link assumption, and that this memo gives the historical 345 reference and background for its removal. 347 o Stated in Section 2 that users may not have sufficient privileges 348 or knowledge to manually configure addresses or routers in order 349 to work-around the lack of an on-link assumption. 351 o Removed implementation details of the on-link assumption from 352 Section 3.1. 354 o Miscellaneous editorial changes. 356 Appendix E. Changes from draft-ietf-v6ops-onlinkassumption-00 358 o Clarified in the abstract and introduction that the problem is 359 with systems that are IPv6 enabled but have no off-link 360 connectivity. 362 o In Section 3.3, clarified that soliciting on all links could have 363 ambiguous results. 365 o The old Security Considerations section was moved to Section 3.4, 366 and the new Security Considerations section refers to that new 367 section. 369 o Miscellaneous editorial changes. 371 Authors' Addresses 373 Sebastien Roy 374 Sun Microsystems, Inc. 375 1 Network Drive 376 UBUR02-212 377 Burlington, MA 01803 379 Email: sebastien.roy@sun.com 381 Alain Durand 382 Comcast Corporation 383 1500 Market Street 384 Philadelphia, PA 09102 386 Email: alain_durand@cable.comcast.com 388 James Paugh 389 Nominum, Inc. 390 2385 Bay Road 391 Redwood City, CA 94063 393 Email: jim.paugh@nominum.com 395 Intellectual Property Statement 397 The IETF takes no position regarding the validity or scope of any 398 Intellectual Property Rights or other rights that might be claimed to 399 pertain to the implementation or use of the technology described in 400 this document or the extent to which any license under such rights 401 might or might not be available; nor does it represent that it has 402 made any independent effort to identify any such rights. Information 403 on the procedures with respect to rights in RFC documents can be 404 found in BCP 78 and BCP 79. 406 Copies of IPR disclosures made to the IETF Secretariat and any 407 assurances of licenses to be made available, or the result of an 408 attempt made to obtain a general license or permission for the use of 409 such proprietary rights by implementers or users of this 410 specification can be obtained from the IETF on-line IPR repository at 411 http://www.ietf.org/ipr. 413 The IETF invites any interested party to bring to its attention any 414 copyrights, patents or patent applications, or other proprietary 415 rights that may cover technology that may be required to implement 416 this standard. Please address the information to the IETF at 417 ietf-ipr@ietf.org. 419 Disclaimer of Validity 421 This document and the information contained herein are provided on an 422 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 423 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 424 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 425 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 426 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 427 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 429 Copyright Statement 431 Copyright (C) The Internet Society (2006). This document is subject 432 to the rights, licenses and restrictions contained in BCP 78, and 433 except as set forth therein, the authors retain all their rights. 435 Acknowledgment 437 Funding for the RFC Editor function is currently provided by the 438 Internet Society.