idnits 2.17.1 draft-ietf-v6ops-onlinkassumption-00.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 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 (October 20, 2003) is 7491 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 232, 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) ** Downref: Normative reference to an Informational draft: draft-ietf-send-psreq (ref. 'PSREQ') -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. 'AUTOCONF') (Obsoleted by RFC 4862) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Roy 3 Internet-Draft A. Durand 4 Expires: April 19, 2004 J. Paugh 5 Sun Microsystems, Inc. 6 October 20, 2003 8 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful 9 draft-ietf-v6ops-onlinkassumption-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 19, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document proposes a change to the IPv6 Neighbor Discovery 40 conceptual host sending algorithm. According to the algorithm, when 41 a host's default router list is empty, the host assumes that all 42 destinations are on-link. This document describes how making this 43 assumption causes problems, and describes how these problems outweigh 44 the benefits of this part of the conceptual sending algorithm. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 3.1 First Rule of Destination Address Selection . . . . . . . . . 5 52 3.2 Delays Associated with Address Resolution . . . . . . . . . . 5 53 3.3 Multi-homing Ambiguity . . . . . . . . . . . . . . . . . . . . 6 54 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 56 Normative References . . . . . . . . . . . . . . . . . . . . . 9 57 Informative References . . . . . . . . . . . . . . . . . . . . 10 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 59 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 60 Intellectual Property and Copyright Statements . . . . . . . . 12 62 1. Introduction 64 Neighbor Discovery for IPv6 [ND] defines a conceptual sending 65 algorithm for hosts. This algorithm states that if a host's default 66 router list is empty, then the host assumes that all destinations are 67 on-link. 69 This assumption creates problems for destination address selection as 70 defined in [ADDRSEL], and adds connection delays associated with 71 unnecessary address resolution and neighbor unreachability detection. 72 The behavior associated with the assumption is undefined in 73 multihomed scenarios, and has some subtle security implications. All 74 of these issues are discussed in this document. 76 2. Background 78 This part of Neighbor Discovery's [ND] conceptual sending algorithm 79 was created to facilitate communication on a single link between 80 systems manually configured with different global prefixes. For 81 example, two systems that are manually configured with global 82 addresses while on separate links are then plugged in back-to-back. 83 They can still communicate with each other via their global addresses 84 because they'll correctly assume that each is on-link. 86 Without the on-link assumption, the above scenario wouldn't work as 87 seamlessly. One workaround would be to use link-local addresses for 88 this communication. Another is to configure new global addresses 89 using the same /64 prefix on these systems, either by manually 90 configuring such addresses, or by placing a router on-link that 91 advertises this prefix. 93 3. Problems 95 The on-link assumption causes the following problems. 97 3.1 First Rule of Destination Address Selection 99 Default Address Selection for IPv6 [ADDRSEL] defines a destination 100 address selection algorithm that takes an unordered list of 101 destination addresses as input, and produces a sorted list of 102 destination addresses as output. The algorithm consists of 103 destination address sorting rules, the first of which is "Avoid 104 unusable destinations". The idea behind this rule is to place 105 unreachable destinations at the end of the sorted list so that 106 applications will be least likely to try to communicate with those 107 addresses first. 109 The unreachability determination for a destination as it pertains to 110 this rule is an implementation detail. One implementable method is 111 to do a simple forwarding table lookup on the destination, and to 112 deem the destination as reachable if the lookup succeeds. The 113 Neighbor Discovery on-link assumption makes this method somewhat 114 irrelevant, however, as an implementation of the assumption could 115 simply be to insert an IPv6 default on-link route into the system's 116 forwarding table when the default router list is empty. The 117 side-effect is that the rule would always determine that all IPv6 118 destinations are reachable. 120 On a network where there is no IPv6 router (all off-link IPv6 121 destinations are unreachable) and there is off-link IPv4 122 connectivity, the on-link assumption causes the rule to not 123 necessarily prefer reachable IPv4 destinations over unreachable IPv6 124 destinations. This results in unreachable destinations being placed 125 at the front of the sorted list. 127 3.2 Delays Associated with Address Resolution 129 Users expect that applications quickly connect to a given destination 130 regardless of the number of IP addresses assigned to that 131 destination. If a destination name resolves to multiple addresses 132 and the application attempts to communicate to each address until one 133 succeeds, this process shouldn't take an unreasonable amount of time. 134 It is therefore important that the system quickly determine if IPv6 135 destinations are unreachable so that the application can try other 136 destinations when those IPv6 destinations are unreachable. 138 For an IPv6 enabled host deployed on a network that has no IPv6 139 routers, the result of the on-link assumption is that link-layer 140 address resolution must be performed on all IPv6 addresses to which 141 the host sends packets. The Application will not receive 142 acknowledgment of the unreachability of destinations that are not 143 on-link until at least address resolution has failed, which is no 144 less than three seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER) 145 (amplified by transport protocol delays). When the application has a 146 large list of off-link unreachable IPv6 addresses followed by at 147 least one reachable IPv4 address, the delay associated with NUD of 148 each IPv6 addresses before successful communication with the IPv4 149 address is unacceptable. 151 3.3 Multi-homing Ambiguity 153 There is no defined way to implement this aspect of the sending 154 algorithm on a multi-homed node. From an implementor's point of 155 view, there are three ways to handle sending an IPv6 packet to a 156 destination in the face of the on-link assumption on a multi-homed 157 node: 159 1. Attempt to resolve the destination on a single link. 161 2. Attempt to resolve the destination on every link. 163 3. Drop the packet. 165 If the destination is indeed on-link, the first option may not 166 succeed since the wrong link could be picked. The second option 167 would always succeed in reaching the destination (assuming that it's 168 reachable) but is more complex to implement. Dropping the packet is 169 equivalent to not making the on-link assumption at all. In other 170 words, if there is no route to the destination, don't attempt to send 171 the packet. 173 4. Conclusion 175 This document suggests the following changes to the Neighbor 176 Discovery [ND] specification: 178 The last sentence of the second paragraph of section 5.2 179 ("Conceptual Sending Algorithm") should be removed. This sentence 180 is currently, "If the Default Router List is empty, the sender 181 assumes that the destination is on-link. 183 Bullet item 3) in section 6.3.6 ("Default Router Selection") 184 should be removed. The item currently reads, "If the Default 185 Router List is empty, assume that all destinations are on-link as 186 specified in Section 5.2." 188 The result of these changes is that destinations are considered 189 unreachable when there is no routing information for that destination 190 (through a default router or otherwise). Instead of attempting 191 link-layer address resolution when sending to such a destination, a 192 node should send an ICMPv6 Destination Unreachable message (code 0 - 193 no route to destination) message up the stack. 195 5. Security Considerations 197 The on-link assumption discussed here introduces a security 198 vulnerability to the Neighbor Discovery protocol described in section 199 4.2.2 of IPv6 Neighbor Discovery Trust Models and Threats [PSREQ] 200 titled "Default router is 'killed'". There is a threat that a host's 201 router can be maliciously killed in order to cause the host to start 202 sending all packets on-link. The attacker can then spoof off-link 203 nodes by sending packets on the same link as the host. The 204 vulnerability is discussed in detail in [PSREQ]. 206 Another security related side-effect of the on-link assumption has to 207 do with VPN's. It has been observed that some commercially available 208 VPN software solutions that don't support IPv6 send IPv6 packets to 209 the local media in the clear (their security policy doesn't simply 210 drop IPv6 packets). Consider a scenario where a system has a single 211 Ethernet interface with VPN software that encrypts and encapsulates 212 certain packets. The system attempts to send a packet to an IPv6 213 destination that it obtained by doing a DNS lookup, and the packet 214 ends up going in the clear to the local media. A malicious second 215 party could then spoof the destination on-link. 217 Normative References 219 [ADDRSEL] Draves, R., "Default Address Selection for Internet 220 Protocol version 6 (IPv6)", RFC 3484, February 2003. 222 [ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 223 Discovery for IP Version 6 (IPv6)", RFC 2461, December 224 1998. 226 [PSREQ] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 227 Discovery trust models and threats", 228 draft-ietf-send-psreq-04, October 2003. 230 Informative References 232 [AUTOCONF] 233 Thomson, S. and T. Narten, "IPv6 Stateless Address 234 Autoconfiguration", RFC 2462, December 1998. 236 Authors' Addresses 238 Sebastien Roy 239 Sun Microsystems, Inc. 240 1 Network Drive 241 UBUR02-212 242 Burlington, MA 01801 244 EMail: sebastien.roy@sun.com 246 Alain Durand 247 Sun Microsystems, Inc. 248 17 Network Circle 249 UMPK17-202 250 Menlo Park, CA 94025 252 EMail: alain.durand@sun.com 254 James Paugh 255 Sun Microsystems, Inc. 256 17 Network Circle 257 UMPK17-202 258 Menlo Park, CA 94025 260 EMail: james.paugh@sun.com 262 Appendix A. Acknowledgments 264 The authors gratefully acknowledge the contributions of Jim Bound, 265 Mika Liljeberg, Erik Nordmark, Pekka Savola, and Ronald van der Pol. 267 Intellectual Property Statement 269 The IETF takes no position regarding the validity or scope of any 270 intellectual property or other rights that might be claimed to 271 pertain to the implementation or use of the technology described in 272 this document or the extent to which any license under such rights 273 might or might not be available; neither does it represent that it 274 has made any effort to identify any such rights. Information on the 275 IETF's procedures with respect to rights in standards-track and 276 standards-related documentation can be found in BCP-11. Copies of 277 claims of rights made available for publication and any assurances of 278 licenses to be made available, or the result of an attempt made to 279 obtain a general license or permission for the use of such 280 proprietary rights by implementors or users of this specification can 281 be obtained from the IETF Secretariat. 283 The IETF invites any interested party to bring to its attention any 284 copyrights, patents or patent applications, or other proprietary 285 rights which may cover technology that may be required to practice 286 this standard. Please address the information to the IETF Executive 287 Director. 289 Full Copyright Statement 291 Copyright (C) The Internet Society (2003). All Rights Reserved. 293 This document and translations of it may be copied and furnished to 294 others, and derivative works that comment on or otherwise explain it 295 or assist in its implementation may be prepared, copied, published 296 and distributed, in whole or in part, without restriction of any 297 kind, provided that the above copyright notice and this paragraph are 298 included on all such copies and derivative works. However, this 299 document itself may not be modified in any way, such as by removing 300 the copyright notice or references to the Internet Society or other 301 Internet organizations, except as needed for the purpose of 302 developing Internet standards in which case the procedures for 303 copyrights defined in the Internet Standards process must be 304 followed, or as required to translate it into languages other than 305 English. 307 The limited permissions granted above are perpetual and will not be 308 revoked by the Internet Society or its successors or assignees. 310 This document and the information contained herein is provided on an 311 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 312 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 313 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 314 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 315 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 317 Acknowledgment 319 Funding for the RFC Editor function is currently provided by the 320 Internet Society.