idnits 2.17.1 draft-ietf-v6ops-onlinkassumption-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 6) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages 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 (May 7, 2004) is 7294 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: 'AUTOCONF' is defined on line 251, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3484 (ref. 'ADDRSEL') (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 2461 (ref. 'ND') (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. 'PSREQ' -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. 'AUTOCONF') (Obsoleted by RFC 4862) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Roy 2 Internet-Draft A. Durand 3 Expires: November 5, 2004 J. Paugh 4 Sun Microsystems, Inc. 5 May 7, 2004 7 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful 8 draft-ietf-v6ops-onlinkassumption-02.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on November 5, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This document describes a change to the IPv6 Neighbor Discovery 39 conceptual host sending algorithm. According to the algorithm, when 40 a host's default router list is empty, the host assumes that all 41 destinations are on-link. This is particularly problematic with 42 IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., 43 no default router). This document describes how making this 44 assumption causes problems, and describes how these problems outweigh 45 the benefits of this part of the conceptual sending algorithm. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Background on the On-link Assumption . . . . . . . . . . . . . 3 51 3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3.1 First Rule of Destination Address Selection . . . . . . . 3 53 3.2 Delays Associated with Address Resolution . . . . . . . . 4 54 3.3 Multi-homing Ambiguity . . . . . . . . . . . . . . . . . . 4 55 3.4 Security Related Issues . . . . . . . . . . . . . . . . . 5 56 4. Proposed Changes to RFC2461 . . . . . . . . . . . . . . . . . 5 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 6 60 6.2 Informative References . . . . . . . . . . . . . . . . . . . 6 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 62 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 63 B. Changes from draft-ietf-v6ops-onlinkassumption-01 . . . . . . 7 64 C. Changes from draft-ietf-v6ops-onlinkassumption-00 . . . . . . 8 65 Intellectual Property and Copyright Statements . . . . . . . . 9 67 1. Introduction 69 Neighbor Discovery for IPv6 [ND] defines a conceptual sending 70 algorithm for hosts. This algorithm states that if a host's default 71 router list is empty, then the host assumes that all destinations are 72 on-link. 74 This assumption is problematic with IPv6-capable nodes that do not 75 have off-link IPv6 connectivity. Specifically, it creates problems 76 for destination address selection as defined in [ADDRSEL], and adds 77 connection delays associated with unnecessary address resolution and 78 neighbor unreachability detection. The behavior associated with the 79 assumption is undefined in multihomed scenarios, and has some subtle 80 security implications. All of these issues are discussed in this 81 document. 83 A revision of Neighbor Discovery [NDBIS] is removing the on-link 84 assumption from the specification, but this memo gives historical 85 reference and background to why this is has been a good decision. 87 2. Background on the On-link Assumption 89 This part of Neighbor Discovery's [ND] conceptual sending algorithm 90 was created to facilitate communication on a single link between 91 systems manually configured with different global prefixes. For 92 example, consider the case where two systems on separate links are 93 manually configured with global addresses, and are then plugged in 94 back-to-back. They can still communicate with each other via their 95 global addresses because they'll correctly assume that each is 96 on-link. 98 Without the on-link assumption, the above scenario wouldn't work as 99 seamlessly. One workaround would be to use link-local addresses for 100 this communication. Another is to configure new global addresses 101 using the same /64 prefix on these systems, either by manually 102 configuring such addresses or by placing a router on-link that 103 advertises this prefix, however users may not have appropriate 104 privileges or knowledge to implement this workaround. 106 3. Problems 108 The on-link assumption causes the following problems. 110 3.1 First Rule of Destination Address Selection 112 Default Address Selection for IPv6 [ADDRSEL] defines a destination 113 address selection algorithm that takes an unordered list of 114 destination addresses as input, and produces a sorted list of 115 destination addresses as output. The algorithm consists of 116 destination address sorting rules, the first of which is "Avoid 117 unusable destinations". The idea behind this rule is to place 118 unreachable destinations at the end of the sorted list so that 119 applications will be least likely to try to communicate with those 120 addresses first. 122 The on-link assumption could potentially cause false positives when 123 attempting unreachability determination for this rule. On a network 124 where there is no IPv6 router (all off-link IPv6 destinations are 125 unreachable), the on-link assumption states that destinations are 126 assumed to be on-link. An implementation could interpret that as, if 127 the default router list is empty, then all destinations are 128 reachable. This causes the rule to not necessarily prefer reachable 129 IPv4 destinations over unreachable IPv6 destinations, resulting in 130 unreachable destinations being placed at the front of the sorted 131 list. 133 3.2 Delays Associated with Address Resolution 135 Users expect that applications quickly connect to a given destination 136 regardless of the number of IP addresses assigned to that 137 destination. If a destination name resolves to multiple addresses 138 and the application attempts to communicate to each address until one 139 succeeds, this process shouldn't take an unreasonable amount of time. 140 It is therefore important that the system quickly determine if IPv6 141 destinations are unreachable so that the application can try other 142 destinations when those IPv6 destinations are unreachable. 144 For an IPv6 enabled host deployed on a network that has no IPv6 145 routers, the result of the on-link assumption is that link-layer 146 address resolution must be performed on all IPv6 addresses to which 147 the host sends packets. The Application will not receive 148 acknowledgment of the unreachability of destinations that are not 149 on-link until at least address resolution has failed, which is no 150 less than three seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER) 151 (amplified by transport protocol delays). When the application has a 152 large list of off-link unreachable IPv6 addresses followed by at 153 least one reachable IPv4 address, the delay associated with Neighbor 154 Unreachability Detection (NUD) of each IPv6 addresses before 155 successful communication with the IPv4 address is unacceptable. 157 3.3 Multi-homing Ambiguity 159 There is no defined way to implement this aspect of the sending 160 algorithm on a multi-homed node. From an implementor's point of 161 view, there are three ways to handle sending an IPv6 packet to a 162 destination in the face of the on-link assumption on a multi-homed 163 node: 165 1. Attempt to resolve the destination on a single link. 167 2. Attempt to resolve the destination on every link. 169 3. Drop the packet. 171 If the destination is indeed on-link, the first option might not 172 succeed since the wrong link could be picked. The second option 173 might succeed in reaching a destination (assuming that one is 174 reachable) but is more complex to implement, and isn't guaranteed to 175 pick the correct destination. For example, there is still ambiguity 176 about which link to use if more than one node answers the 177 solicitations on multiple links. Dropping the packet is equivalent 178 to not making the on-link assumption at all. In other words, if 179 there is no route to the destination, don't attempt to send the 180 packet. 182 3.4 Security Related Issues 184 The on-link assumption discussed here introduces a security 185 vulnerability to the Neighbor Discovery protocol described in section 186 4.2.2 of IPv6 Neighbor Discovery Trust Models and Threats [PSREQ] 187 titled "Default router is 'killed'". There is a threat that a host's 188 router can be maliciously killed in order to cause the host to start 189 sending all packets on-link. The attacker can then spoof off-link 190 nodes by sending packets on the same link as the host. The 191 vulnerability is discussed in detail in [PSREQ]. 193 Another security related side-effect of the on-link assumption has to 194 do with virtual private networks (VPN's). It has been observed that 195 some commercially available VPN software solutions that don't support 196 IPv6 send IPv6 packets to the local media in the clear (their 197 security policy doesn't simply drop IPv6 packets). Consider a 198 scenario where a system has a single Ethernet interface with VPN 199 software that encrypts and encapsulates certain packets. The system 200 attempts to send a packet to an IPv6 destination that it obtained by 201 doing a DNS lookup, and the packet ends up going in the clear to the 202 local media. A malicious second party could then spoof the 203 destination on-link. 205 4. Proposed Changes to RFC2461 207 This document suggests the following changes to the Neighbor 208 Discovery [ND] specification: 210 The last sentence of the second paragraph of section 5.2 211 ("Conceptual Sending Algorithm") should be removed. This sentence 212 is currently, "If the Default Router List is empty, the sender 213 assumes that the destination is on-link. 215 Bullet item 3) in section 6.3.6 ("Default Router Selection") 216 should be removed. The item currently reads, "If the Default 217 Router List is empty, assume that all destinations are on-link as 218 specified in Section 5.2." 220 The result of these changes is that destinations are considered 221 unreachable when there is no routing information for that destination 222 (through a default router or otherwise). Instead of attempting 223 link-layer address resolution when sending to such a destination, a 224 node should send an ICMPv6 Destination Unreachable message (code 0 - 225 no route to destination) message up the stack. 227 5. Security Considerations 229 The removal of the on-link assumption from Neighbor Discovery removes 230 some security related vulnerabilities of the protocol as described in 231 Section 3.4. 233 6. References 235 6.1 Normative References 237 [ADDRSEL] Draves, R., "Default Address Selection for Internet 238 Protocol version 6 (IPv6)", RFC 3484, February 2003. 240 [ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 241 Discovery for IP Version 6 (IPv6)", RFC 2461, December 242 1998. 244 [PSREQ] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 245 Discovery trust models and threats", October 2003. 247 draft-ietf-send-psreq-04 249 6.2 Informative References 251 [AUTOCONF] 252 Thomson, S. and T. Narten, "IPv6 Stateless Address 253 Autoconfiguration", RFC 2462, December 1998. 255 [NDBIS] Narten, T., Nordmark, E., Simpson, W., Soliman, H. and J. 256 Tatuya, "Neighbor Discovery for IP Version 6 (IPv6)", 257 February 2004. 259 Authors' Addresses 261 Sebastien Roy 262 Sun Microsystems, Inc. 263 1 Network Drive 264 UBUR02-212 265 Burlington, MA 01801 267 EMail: sebastien.roy@sun.com 269 Alain Durand 270 Sun Microsystems, Inc. 271 17 Network Circle 272 UMPK17-202 273 Menlo Park, CA 94025 275 EMail: alain.durand@sun.com 277 James Paugh 278 Sun Microsystems, Inc. 279 17 Network Circle 280 UMPK17-202 281 Menlo Park, CA 94025 283 EMail: james.paugh@sun.com 285 Appendix A. Acknowledgments 287 The authors gratefully acknowledge the contributions of Jim Bound, 288 Tony Hain, Mika Liljeberg, Erik Nordmark, Pekka Savola, and Ronald 289 van der Pol. 291 Appendix B. Changes from draft-ietf-v6ops-onlinkassumption-01 293 o Added text in the Introduction stating that rfc2461bis has removed 294 the on-link assumption, and that this memo gives the historical 295 reference and background for its removal. 297 o Stated in Section 2 that users may not have sufficient privileges 298 or knowledge to manually configure addresses or routers in order 299 to work-around the lack of an on-link assumption. 301 o Removed implementation details of the on-link assumption from 302 Section 3.1. 304 o Miscellaneous editorial changes. 306 Appendix C. Changes from draft-ietf-v6ops-onlinkassumption-00 308 o Clarified in the abstract and introduction that the problem is 309 with systems that are IPv6 enabled but have no off-link 310 connectivity. 312 o In Section 3.3, clarified that soliciting on all links could have 313 ambiguous results. 315 o The old Security Considerations section was moved to Section 3.4, 316 and the new Security Considerations section refers to that new 317 section. 319 o Miscellaneous editorial changes. 321 Intellectual Property Statement 323 The IETF takes no position regarding the validity or scope of any 324 intellectual property or other rights that might be claimed to 325 pertain to the implementation or use of the technology described in 326 this document or the extent to which any license under such rights 327 might or might not be available; neither does it represent that it 328 has made any effort to identify any such rights. Information on the 329 IETF's procedures with respect to rights in standards-track and 330 standards-related documentation can be found in BCP-11. Copies of 331 claims of rights made available for publication and any assurances of 332 licenses to be made available, or the result of an attempt made to 333 obtain a general license or permission for the use of such 334 proprietary rights by implementors or users of this specification can 335 be obtained from the IETF Secretariat. 337 The IETF invites any interested party to bring to its attention any 338 copyrights, patents or patent applications, or other proprietary 339 rights which may cover technology that may be required to practice 340 this standard. Please address the information to the IETF Executive 341 Director. 343 Full Copyright Statement 345 Copyright (C) The Internet Society (2004). All Rights Reserved. 347 This document and translations of it may be copied and furnished to 348 others, and derivative works that comment on or otherwise explain it 349 or assist in its implementation may be prepared, copied, published 350 and distributed, in whole or in part, without restriction of any 351 kind, provided that the above copyright notice and this paragraph are 352 included on all such copies and derivative works. However, this 353 document itself may not be modified in any way, such as by removing 354 the copyright notice or references to the Internet Society or other 355 Internet organizations, except as needed for the purpose of 356 developing Internet standards in which case the procedures for 357 copyrights defined in the Internet Standards process must be 358 followed, or as required to translate it into languages other than 359 English. 361 The limited permissions granted above are perpetual and will not be 362 revoked by the Internet Society or its successors or assignees. 364 This document and the information contained herein is provided on an 365 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 366 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 367 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 368 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 369 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 371 Acknowledgment 373 Funding for the RFC Editor function is currently provided by the 374 Internet Society.