idnits 2.17.1 draft-ietf-v6ops-onlinkassumption-03.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 376. ** 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 (April 2005) is 6949 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 274, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-02 ** 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: October 3, 2005 A. Durand 5 Comcast Corporation 6 J. Paugh 7 April 2005 9 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful 10 draft-ietf-v6ops-onlinkassumption-03.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on October 3, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document describes the historical and background information 44 behind the removal of the "on-link assumption" from the conceptual 45 host sending algorithm defined in Neighbor Discovery for IP Version 6 46 (IPv6). According to the algorithm as originally described, when a 47 host's default router list is empty, the host assumes that all 48 destinations are on-link. This is particularly problematic with 49 IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., 50 no default router). This document describes how making this 51 assumption causes problems, and describes how these problems outweigh 52 the benefits of this part of the conceptual sending algorithm. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Background on the On-link Assumption . . . . . . . . . . . . . 3 58 3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1 First Rule of Destination Address Selection . . . . . . . 3 60 3.2 Delays Associated with Address Resolution . . . . . . . . 4 61 3.3 Multi-interface Ambiguity . . . . . . . . . . . . . . . . 5 62 3.4 Security Related Issues . . . . . . . . . . . . . . . . . 5 63 4. Changes to RFC2461 . . . . . . . . . . . . . . . . . . . . . . 6 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 6.1 Normative References . . . . . . . . . . . . . . . . . . . 6 67 6.2 Informative References . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 69 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 70 B. Changes from draft-ietf-v6ops-onlinkassumption-02 . . . . . . 7 71 C. Changes from draft-ietf-v6ops-onlinkassumption-01 . . . . . . 8 72 D. Changes from draft-ietf-v6ops-onlinkassumption-00 . . . . . . 8 73 Intellectual Property and Copyright Statements . . . . . . . . 9 75 1. Introduction 77 Neighbor Discovery for IPv6 [I-D.ietf-ipv6-2461bis] defines a 78 conceptual sending algorithm for hosts. The version of the algorithm 79 described in [RFC2461] states that if a host's default router list is 80 empty, then the host assumes that all destinations are on-link. This 81 memo documents the removal of this assumption in the updated Neighbor 82 Discovery specification [I-D.ietf-ipv6-2461bis], and describes the 83 reasons why this assumption was removed. 85 This assumption is problematic with IPv6-capable nodes that do not 86 have off-link IPv6 connectivity. This is typical when systems that 87 have IPv6 enabled on their network interfaces (either on by default 88 or administratively configured that way) are attached to networks 89 that have no IPv6 services such as off-link routing. Such systems 90 will resolve DNS names to AAAA and A records, and may attempt to 91 connect to unreachable IPv6 off-link nodes. 93 The on-link assumption creates problems for destination address 94 selection as defined in [RFC3484], and adds connection delays 95 associated with unnecessary address resolution and neighbor 96 unreachability detection. The behavior associated with the 97 assumption is undefined on multi-interface nodes, and has some subtle 98 security implications. All of these issues are discussed in this 99 document. 101 2. Background on the On-link Assumption 103 This part of Neighbor Discovery's [RFC2461] conceptual sending 104 algorithm was created to facilitate communication on a single link 105 between systems manually configured with different global prefixes. 106 For example, consider the case where two systems on separate links 107 are manually configured with global addresses, and are then plugged 108 in back-to-back. They can still communicate with each other via 109 their global addresses because they'll correctly assume that each is 110 on-link. 112 Without the on-link assumption, the above scenario wouldn't work, and 113 the systems would need to be configured to share a common prefix such 114 as the link-local prefix. 116 3. Problems 118 The on-link assumption causes the following problems. 120 3.1 First Rule of Destination Address Selection 122 Default Address Selection for IPv6 [RFC3484] defines a destination 123 address selection algorithm that takes an unordered list of 124 destination addresses as input, and produces a sorted list of 125 destination addresses as output. The algorithm consists of 126 destination address sorting rules, the first of which is "Avoid 127 unusable destinations". The idea behind this rule is to place 128 unreachable destinations at the end of the sorted list so that 129 applications will be least likely to try to communicate with those 130 addresses first. 132 The on-link assumption could potentially cause false positives when 133 attempting unreachability determination for this rule. On a network 134 where there is no IPv6 router (all off-link IPv6 destinations are 135 unreachable), the on-link assumption states that destinations are 136 assumed to be on-link. An implementation could interpret that as, if 137 the default router list is empty, then all destinations are reachable 138 on-link. This may cause the rule to prefer an unreachable IPv6 139 destination over a reachable IPv4 destination. 141 3.2 Delays Associated with Address Resolution 143 Users expect that applications quickly connect to a given destination 144 regardless of the number of IP addresses assigned to that 145 destination. If a destination name resolves to multiple addresses 146 and the application attempts to communicate to each address until one 147 succeeds, this process shouldn't take an unreasonable amount of time. 148 It is therefore important that the system quickly determine if IPv6 149 destinations are unreachable so that the application can try other 150 destinations when those IPv6 destinations are unreachable. 152 For an IPv6 enabled host deployed on a network that has no IPv6 153 routers, the result of the on-link assumption is that link-layer 154 address resolution must be performed on all IPv6 addresses to which 155 the host sends packets. The Application will not receive 156 acknowledgment of the unreachability of destinations that are not on- 157 link until at least address resolution has failed, which is no less 158 than three seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER). This is 159 greatly amplified by transport protocol delays. For example, 160 [RFC1122] requires that TCP retransmit for at least 3 minutes before 161 aborting the connection attempt. 163 When the application has a large list of off-link unreachable IPv6 164 addresses followed by at least one reachable IPv4 address, the delay 165 associated with Neighbor Unreachability Detection (NUD) of each IPv6 166 addresses before successful communication with the IPv4 address is 167 unacceptable. 169 3.3 Multi-interface Ambiguity 171 There is no defined way to implement this aspect of the sending 172 algorithm on a node that is attached to multiple links. From an 173 implementor's point of view, there are three ways to handle sending 174 an IPv6 packet to a destination in the face of the on-link assumption 175 on a multi-interface node: 177 1. Attempt to resolve the destination on a single link. 179 2. Attempt to resolve the destination on every link. 181 3. Drop the packet. 183 If the destination is indeed on-link, the first option might not 184 succeed since the wrong link could be picked. The second option 185 might succeed in reaching a destination (assuming that one is 186 reachable) but is more complex to implement, and isn't guaranteed to 187 pick the correct destination. For example, there is still ambiguity 188 about which link to use if more than one node answers the 189 solicitations on multiple links. Dropping the packet is equivalent 190 to not making the on-link assumption at all. In other words, if 191 there is no route to the destination, don't attempt to send the 192 packet. 194 3.4 Security Related Issues 196 The on-link assumption discussed here introduces a security 197 vulnerability to the Neighbor Discovery protocol described in section 198 4.2.2 of IPv6 Neighbor Discovery Trust Models and Threats [RFC3756] 199 titled "Default router is 'killed'". There is a threat that a host's 200 router can be maliciously killed in order to cause the host to start 201 sending all packets on-link. The attacker can then spoof off-link 202 nodes by sending packets on the same link as the host. The 203 vulnerability is discussed in detail in [RFC3756]. 205 Another security related side-effect of the on-link assumption has to 206 do with virtual private networks (VPN's). It has been observed that 207 some commercially available VPN software solutions that don't support 208 IPv6 send IPv6 packets to the local media in the clear (their 209 security policy doesn't simply drop IPv6 packets). Consider a 210 scenario where a system has a single Ethernet interface with VPN 211 software that encrypts and encapsulates certain packets. The system 212 attempts to send a packet to an IPv6 destination that it obtained by 213 doing a DNS lookup, and the packet ends up going in the clear to the 214 local media. A malicious third party could then spoof the 215 destination on-link. 217 4. Changes to RFC2461 219 The following changes have been made to the Neighbor Discovery 220 specification between [RFC2461] and [I-D.ietf-ipv6-2461bis]: 222 The last sentence of the second paragraph of section 5.2 223 ("Conceptual Sending Algorithm") was removed. This sentence was, 224 "If the Default Router List is empty, the sender assumes that the 225 destination is on-link." 227 Bullet item 3) in section 6.3.6 ("Default Router Selection") was 228 removed. The item read, "If the Default Router List is empty, 229 assume that all destinations are on-link as specified in Section 230 5.2." 232 APPENDIX A was modified to remove on-link assumption related text 233 in bullet item 1) under the discussion on what happens when a 234 multihomed host fails to receive Router Advertisements. 236 The result of these changes is that destinations are considered 237 unreachable when there is no routing information for that destination 238 (through a default router or otherwise). Instead of attempting link- 239 layer address resolution when sending to such a destination, a node 240 should send an ICMPv6 Destination Unreachable message (code 0 - no 241 route to destination) message up the stack. 243 5. Security Considerations 245 The removal of the on-link assumption from Neighbor Discovery removes 246 some security related vulnerabilities of the protocol as described in 247 Section 3.4. 249 6. References 251 6.1 Normative References 253 [I-D.ietf-ipv6-2461bis] 254 Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 255 draft-ietf-ipv6-2461bis-02 (work in progress), 256 February 2005. 258 [RFC1122] Braden, R., "Requirements for Internet Hosts - 259 Communication Layers", STD 3, RFC 1122, October 1989. 261 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 262 Discovery for IP Version 6 (IPv6)", RFC 2461, 263 December 1998. 265 [RFC3484] Draves, R., "Default Address Selection for Internet 266 Protocol version 6 (IPv6)", RFC 3484, February 2003. 268 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 269 Discovery (ND) Trust Models and Threats", RFC 3756, 270 May 2004. 272 6.2 Informative References 274 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 275 Autoconfiguration", RFC 2462, December 1998. 277 Authors' Addresses 279 Sebastien Roy 280 Sun Microsystems, Inc. 281 1 Network Drive 282 UBUR02-212 283 Burlington, MA 01801 285 Email: sebastien.roy@sun.com 287 Alain Durand 288 Comcast Corporation 289 1500 Market St. 290 Philadelphia, PA 09102 292 Email: alain_durand@cable.comcast.com 294 James Paugh 296 Email: jpaugh@speakeasy.net 298 Appendix A. Acknowledgments 300 The authors gratefully acknowledge the contributions of Jim Bound, 301 Tony Hain, Mika Liljeberg, Erik Nordmark, Pekka Savola, and Ronald 302 van der Pol. 304 Appendix B. Changes from draft-ietf-v6ops-onlinkassumption-02 306 o Changed abstract to reflect the historical nature of this 307 document. 309 o Changed the introduction to stress that this is historical 310 information documenting the removal of the on-link assumption from 311 the ND spec. 313 o Added text to the introduction stating that the assumption is a 314 problem for nodes with IPv6 on by default. 316 o Added mention to RFC1122 in section 3.2. 318 o Changed use of the term multi-homed nodes to "nodes that are 319 attached to multiple links". 321 o Changed section 4 from "Proposed Changes" to "Changes" and 322 adjusted included text to reflect that the changes have been made. 324 Appendix C. Changes from draft-ietf-v6ops-onlinkassumption-01 326 o Added text in the Introduction stating that rfc2461bis has removed 327 the on-link assumption, and that this memo gives the historical 328 reference and background for its removal. 330 o Stated in Section 2 that users may not have sufficient privileges 331 or knowledge to manually configure addresses or routers in order 332 to work-around the lack of an on-link assumption. 334 o Removed implementation details of the on-link assumption from 335 Section 3.1. 337 o Miscellaneous editorial changes. 339 Appendix D. Changes from draft-ietf-v6ops-onlinkassumption-00 341 o Clarified in the abstract and introduction that the problem is 342 with systems that are IPv6 enabled but have no off-link 343 connectivity. 345 o In Section 3.3, clarified that soliciting on all links could have 346 ambiguous results. 348 o The old Security Considerations section was moved to Section 3.4, 349 and the new Security Considerations section refers to that new 350 section. 352 o Miscellaneous editorial changes. 354 Intellectual Property Statement 356 The IETF takes no position regarding the validity or scope of any 357 Intellectual Property Rights or other rights that might be claimed to 358 pertain to the implementation or use of the technology described in 359 this document or the extent to which any license under such rights 360 might or might not be available; nor does it represent that it has 361 made any independent effort to identify any such rights. Information 362 on the procedures with respect to rights in RFC documents can be 363 found in BCP 78 and BCP 79. 365 Copies of IPR disclosures made to the IETF Secretariat and any 366 assurances of licenses to be made available, or the result of an 367 attempt made to obtain a general license or permission for the use of 368 such proprietary rights by implementers or users of this 369 specification can be obtained from the IETF on-line IPR repository at 370 http://www.ietf.org/ipr. 372 The IETF invites any interested party to bring to its attention any 373 copyrights, patents or patent applications, or other proprietary 374 rights that may cover technology that may be required to implement 375 this standard. Please address the information to the IETF at 376 ietf-ipr@ietf.org. 378 Disclaimer of Validity 380 This document and the information contained herein are provided on an 381 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 382 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 383 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 384 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 385 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 386 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 388 Copyright Statement 390 Copyright (C) The Internet Society (2005). This document is subject 391 to the rights, licenses and restrictions contained in BCP 78, and 392 except as set forth therein, the authors retain all their rights. 394 Acknowledgment 396 Funding for the RFC Editor function is currently provided by the 397 Internet Society.