idnits 2.17.1 draft-ietf-6man-ipv6-subnet-model-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4861]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 173: '...first-hop router, so the Redirect MUST...' RFC 2119 keyword, line 207: '...lready exist, the node SHOULD create a...' RFC 2119 keyword, line 212: '...nd the entry's reachability state MUST...' RFC 2119 keyword, line 240: '...ress option, then the recipient SHOULD...' RFC 2119 keyword, line 287: '...mented IPv6 host MUST adhere to the fo...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 6, 2009) is 5524 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) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Singh 3 Internet-Draft W. Beebee 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: September 7, 2009 E. Nordmark 6 Sun Microsystems 7 March 6, 2009 9 IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes 10 draft-ietf-6man-ipv6-subnet-model-03 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on September 7, 2009. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 IPv6 specifies a model of a subnet that is different than the IPv4 59 subnet model. The subtlety of the differences has resulted in 60 incorrect implementations that do not interoperate. This document 61 spells out the most important difference; that an IPv6 address isn't 62 automatically associated with an IPv6 on-link prefix. This document 63 also updates (partially due to security concerns caused by incorrect 64 implementations) a part of the definition of on-link from [RFC4861]. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Host Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4. Observed Incorrect Implementation Behavior . . . . . . . . . . 9 72 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 10.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 IPv4 implementations typically associate a netmask with an address 85 when an IPv4 address is assigned to an interface. That netmask 86 together with the IPv4 address designates an on-link prefix. 87 Addresses that are covered by this prefix are viewed as on-link i.e., 88 traffic to these addresses is not sent to a router. See section 89 3.3.1 in [RFC1122]. Prior to the deployment of Classless Inter- 90 Domain Routing (CIDR), an address's netmask could be derived directly 91 from the address. In the absence of specifying a specific netmask 92 when assigning a address, some implementations would fall back to 93 deriving the netmask from the class of the address. 95 The behavior of IPv6 as specified in Neighbor Discovery [RFC4861] is 96 quite different. The on-link determination is separate from the 97 address assignment. A host can have IPv6 addresses without any 98 related on-link prefixes or have on-link prefixes that are not 99 related to any IPv6 addresses that are assigned to the host. Any 100 assigned address on an interface should initially be considered as 101 having no internal structure as shown in [RFC4291]. 103 In IPv6, by default, a host treats only the link-local prefix as on- 104 link. 106 The reception of a Prefix Information Option (PIO) with the L-bit set 107 [RFC4861] and a non-zero valid lifetime creates (or updates) an entry 108 in the Prefix List. All the prefixes that are on the Prefix List, 109 i.e., have not yet timed out, are considered to be on-link. 111 The on-link definition in the Terminology section of [RFC4861], as 112 modified by this document, defines the complete list of cases where 113 an address is considered on-link. Individual address entries can be 114 expired by the Neighbor Unreachability Detection mechanism. 116 A host only performs address resolution for IPv6 addresses that are 117 on-link. Packets to any other address are sent to a default router. 118 If there is no default router, then the node should send an ICMPv6 119 Destination Unreachable indication as specified in [RFC4861] - more 120 details are provided in the Host Behavior and Rules section. (Note 121 that [RFC4861] changed the behavior when the Default Router List is 122 empty. The behavior in the old version of Neighbor Discovery 123 [RFC2461] was different when there were no default routers.) 125 Failure of host implementations to correctly implement the IPv6 126 subnet model can result in lack of IPv6 connectivity. See the 127 Observed Incorrect Implementation Behavior section for details. 129 Host behavior is clarified in the Host Behavior and Rules section. 131 2. Host Behavior 133 1. The original ND specification [RFC4861] was unclear in its usage 134 of the term on-link in a few places. In IPv6, an address is 135 considered to be on-link (with respect to a specific link), if 136 the address has been assigned to an interface attached to that 137 link. Any node attached to the link can send a datagram directly 138 to an on-link address without forwarding the datagram through a 139 router. In IPv6, there are two ways to indicate an address is 140 on-link. First, a host maintains a Prefix List that identifies 141 ranges of addresses that are to be considered on-link. Second, 142 Redirects can identify individual destinations that are on-link; 143 such Redirects update the Destination Cache. 145 The Prefix List is populated via the following means: 147 * Receipt of a Valid RA that specifies a prefix with the L-bit 148 set. Such a prefix is considered on-link for a period 149 specified in the Valid Lifetime and is added to the Prefix 150 List. (The link-local prefix is effectively considered a 151 permanent entry on the Prefix List.) 153 * Indication of an on-link prefix (which may be a /128) via 154 manual configuration, or some other yet-to-be specified 155 configuration mechanism. 157 A Redirect can also signal whether an address is on-link. If a 158 host originates a packet, but the first-hop router routes the 159 received packet back out onto the same link, the router also 160 sends the host a Redirect. If the Target and Destination Address 161 of the Redirect are the same, the Target Address is to be treated 162 as on-link as specified in Section 8 of [RFC4861]. That is, the 163 host updates its Destination Cache (but not its Prefix List -- 164 though the impact is similar). 166 2. Note that Redirects cannot signal that an address is off-link. 167 In section 8.1 of [RFC4861], a Redirect message is silently 168 discarded if it does not have an IP source address that is the 169 same as the current first-hop router for the specified ICMP 170 Destination Address. An ICMP Destination Address on the same 171 link would have no current first-hop router. Any Redirect 172 message received could not have an IP source address that is the 173 same as the current (null) first-hop router, so the Redirect MUST 174 be dropped. 176 3. IPv6 also defines the term "neighbor" and "link" to refer to 177 nodes attached to the same link and that can send packets 178 directly to each other. Received ND packets that pass the 179 required validation tests can only come from a neighbor attached 180 to the link on which the ND packet was received. Unfortunately, 181 [RFC4861] is imprecise in its definition of on-link and states 182 that a node considers an address to be on-link if: 184 - a Neighbor Advertisement message is received for the 185 (target) address, or 187 - any Neighbor Discovery message is received from the address. 189 Neither of these tests are acceptable definitions for an address 190 to be considered as on-link as defined above, and this document 191 deprecates and removes both of them from the formal definition of 192 on-link. Neither of these tests should be used as justification 193 for modifying the Prefix List or Destination Cache for an 194 address. 196 The conceptual sending algorithm of [RFC4861] defines a Prefix 197 List and Neighbor Cache. The combination of Prefix List and 198 Neighbor Cache form what many implementations consider to be the 199 "IP routing table" for a host. Note that the Neighbor Cache is a 200 separate data structure referenced by the Destination Cache, but 201 entries in the Neighbor Cache are not necessarily in the 202 Destination Cache. It is quite possible (and intentional) that 203 entries be added to the Neighbor Cache for addresses that would 204 not be considered on-link as-defined above. For example, upon 205 receipt of a valid NS, Section 7.2.3 of [RFC4861] states: 207 If an entry does not already exist, the node SHOULD create a 208 new one and set its reachability state to STALE as specified 209 in Section 7.3.3. If an entry already exists, and the cached 210 link-layer address differs from the one in the received Source 211 Link-Layer option, the cached address should be replaced by 212 the received address, and the entry's reachability state MUST 213 be set to STALE. 215 The intention of the above feature is to add an address to the 216 Neighbor Cache, even though it might not be considered on- link 217 per the Prefix List. The benefit of such a step is to have the 218 receiver populate the Neighbor Cache with an address it will 219 almost certainly be sending packets to shortly, thus avoiding the 220 need for an additional round of ND to perform address resolution. 221 But because there is no validation of the address being added to 222 the Neighbor Cache, an intruder could spoof the address and cause 223 a receiver to add an address for a remote site to its Neighbor 224 Cache. This vulnerability is a specific instance of the broad 225 set of attacks that are possible by an on-link neighbor 226 [RFC3756].This causes no problems in practice, so long as the 227 entry only exists in the Neighbor Cache and the address is not 228 considered to be on-link by the IP forwarding code (i.e., the 229 address is not added to the Prefix List and is not marked as on- 230 link in the Destination Cache). 232 4. After the update to the on-link definition in [RFC4861], certain 233 text from section 7.2.3 of [RFC4861] may appear, upon a cursory 234 examination, to be inconsistent with the updated definition of 235 on-link because the text does not ensure that the source address 236 is already deemed on-link through other methods: 238 If the Source Address is not the unspecified address and, on- 239 link layers that have addresses, the solicitation includes a 240 Source Link-Layer Address option, then the recipient SHOULD 241 create or update the Neighbor Cache entry for the IP Source 242 Address of the solicitation. 244 Similarly, the following text from section 6.2.5 of [RFC4861] 245 may also seem inconsistent: If there is no existing Neighbor 246 Cache entry for the solicitation's sender, the router creates 247 one, installs the link- layer address and sets its 248 reachability state to STALE as specified in Section 7.3.3. 250 However, the text in the aforementioned sections of [RFC4861], 251 upon closer inspection, is actually consistent with the 252 deprecation of the last two bullets of the on-link definition 253 because there are two different ways in which on-link 254 determination can affect the state of ND: through updating the 255 Prefix List or the Neighbor Cache. Through deprecating the last 256 two bullets of the on-link definition, the Prefix List is 257 explicitly not to be changed when a node receives an NS, NA, or 258 RS. The Neighbor Cache can still be updated through receipt of 259 an NS, NA, or RS. 261 5. [RFC4861] is written from the perspective of a host with a single 262 interface on which Neighbor Discovery is run. All ND traffic 263 (whether sent or received) traverses the single interface. On 264 hosts with multiple interfaces, care must be taken to ensure that 265 the scope of ND processing from one link stays local to that 266 link. That is, when responding to a NS, the NA would be sent out 267 on the same link on which it was received. Likewise, a host 268 would not respond to a received NS for an an address assigned to 269 an interface on a different link. Although implementions may 270 choose to implement Neighbor Discovery using a single data 271 structure that merges the Neighbor Caches of all interfaces, an 272 implementation's behavior must be consistent with the above 273 model. 275 6. Note that the receipt of a link-local IPv6 multicast packet which 276 is not an ND packet indicates direct reachability on a link, but 277 is not specifically treated by [RFC4861]. 279 7. Note that the receipt of a packet with the Hop Limit field 280 unchanged (the Hop Limit could be specified in a packet-type 281 specific document) which is not an ND packet indicates direct 282 reachability on a link, but is not specifically treated by 283 [RFC4861]. 285 3. Host Rules 287 A correctly implemented IPv6 host MUST adhere to the following rules: 289 1. The assignment of an IPv6 address, whether through IPv6 stateless 290 address autoconfiguration [RFC4862], DHCPv6 [RFC3315], or manual 291 configuration MUST NOT implicitly cause a prefix derived from 292 that address to be treated as on-link and added to the Prefix 293 List. A host considers a prefix to be on-link only through 294 explicit means, such as those specified in the on-link definition 295 in the Terminology section of [RFC4861], as modified by this 296 document, or via manual configuration. Note that the requirement 297 for manually configured addresses is not explicitly mentioned in 298 [RFC4861]. 300 2. In the absence of other sources of on-link information, including 301 Redirects, if the RA advertises a prefix with the on-link(L) bit 302 set and later the Valid Lifetime expires, the host MUST then 303 consider addresses of the prefix to be off-link, as specified by 304 the PIO paragraph of section 6.3.4 of [RFC4861]. 306 3. Newer implementations, which are compliant with [RFC4861] MUST 307 adhere to the following rules. Older implementations, which are 308 compliant with [RFC2461] but not [RFC4861] may remain as is. If 309 the Default Router List is empty and there is no other source of 310 on-link information about any address or prefix: 312 1. The host MUST NOT assume that all destinations are on-link. 314 2. The host MUST NOT perform address resolution for non-link- 315 local addresses. 317 3. Since the host cannot assume the destination is on-link, and 318 off-link traffic cannot be sent to a default router (since 319 the Default Router List is empty), address resolution cannot 320 be performed. This case is specified in the last paragraph 321 of section 4 of [RFC4943]: when there is no route to 322 destination, the host should send an ICMPv6 Destination 323 Unreachable indication (for example, a locally delivered 324 error message) as specified in the Terminology section of 325 [RFC4861]. 327 On-link information concerning particular addresses and prefixes 328 can make those specific addresses and prefixes on-link, but does 329 not change the default behavior mentioned above for addresses and 330 prefixes not specified. [RFC4943] provides justification for 331 these rules. 333 Using cached on-link determination information without first 334 verifying that the information is still valid after IPv6 interface 335 re-initialization may lead to lack of IPv6 network connectivity. For 336 example, a host receives an RA from a router with on-link prefix A. 337 The host powers down. During the power off, the router sends out 338 prefix A with on-link bit set and a zero lifetime to indicate a 339 renumbering. The host misses the renumbering. The host powers on 340 and comes online. Then, the router sends an RA with no PIO. The 341 host uses cached on-link prefix A and issues NS's instead of sending 342 traffic to a default router. The "Observed Incorrect Implementation 343 Behavior" section below describes how this can result in lack of IPv6 344 connectivity. 346 4. Observed Incorrect Implementation Behavior 348 One incorrect implementation behavior illustrates the severe 349 consequences when the IPv6 subnet model is not understood by the 350 implementers of several popular host operating systems. In an access 351 concentrator network ([RFC4388]), a host receives a Router 352 Advertisement Message with no on-link prefix advertised. The host 353 incorrectly assumes an invented prefix is on-link and performs 354 address resolution when the host should send all non-link-local 355 traffic to a default router. Neither the router nor any other host 356 will respond to the address resolution, preventing this host from 357 sending IPv6 traffic. 359 5. Conclusion 361 This document clarifies and summarizes the relationship between links 362 and subnet prefixes described in [RFC4861]. Configuration of an IPv6 363 address does not imply the existence of corresponding on-link 364 prefixes. One should also look at API considerations for prefix 365 length as described in last paragraph of section 4.2 of [RFC4903]. 366 This document also updates the definition of on-link from [RFC4861] 367 by retracting the last two bullets. 369 6. Security Considerations 371 This document addresses a security concern present in [RFC4861]. As 372 a result, the last bullet of the on-link definition in [RFC4861] has 373 been retracted. 375 7. IANA Considerations 377 None. 379 8. Contributors 381 Thomas Narten contributed significant text and provided substantial 382 guidance to the production of this document. 384 9. Acknowledgements 386 Thanks (in alphabetical order) to Adeel Ahmed, Jari Arkko, Ralph 387 Droms, Alun Evans, Dave Forster, Prashanth Krishnamurthy, Suresh 388 Krishnan, Josh Littlefield, David Miles, Madhu Sudan, Jinmei Tatuya, 389 Dave Thaler, Bernie Volz, and Vlad Yasevich for their consistent 390 input, ideas and review during the production of this document. The 391 security problem related to an NS message that provides one reason 392 for invalidating a part of the on-link definition was found by David 393 Miles. Jinmei Tatuya found the security problem to also exist with 394 an RS message. 396 10. References 398 10.1. Normative References 400 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 401 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 402 September 2007. 404 10.2. Informative References 406 [RFC1122] Braden, R., "Requirements for Internet Hosts - 407 Communication Layers", STD 3, RFC 1122, October 1989. 409 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 410 Discovery for IP Version 6 (IPv6)", RFC 2461, 411 December 1998. 413 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 414 and M. Carney, "Dynamic Host Configuration Protocol for 415 IPv6 (DHCPv6)", RFC 3315, July 2003. 417 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 418 Discovery (ND) Trust Models and Threats", RFC 3756, 419 May 2004. 421 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 422 Architecture", RFC 4291, February 2006. 424 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 425 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 427 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 428 Address Autoconfiguration", RFC 4862, September 2007. 430 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 431 June 2007. 433 [RFC4943] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor 434 Discovery On-Link Assumption Considered Harmful", 435 RFC 4943, September 2007. 437 Authors' Addresses 439 Hemant Singh 440 Cisco Systems, Inc. 441 1414 Massachusetts Ave. 442 Boxborough, MA 01719 443 USA 445 Phone: +1 978 936 1622 446 Email: shemant@cisco.com 447 URI: http://www.cisco.com/ 449 Wes Beebee 450 Cisco Systems, Inc. 451 1414 Massachusetts Ave. 452 Boxborough, MA 01719 453 USA 455 Phone: +1 978 936 2030 456 Email: wbeebee@cisco.com 457 URI: http://www.cisco.com/ 459 Erik Nordmark 460 Sun Microsystems 461 17 Network Circle 462 Menlo Park, CA 94025 463 USA 465 Phone: +1 650 786 2921 466 Email: erik.nordmark@sun.com