idnits 2.17.1 draft-wbeebee-on-link-and-off-link-determination-02.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, updated by RFC 4748 on line 330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 354. 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 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 96: '...er, then such packets MUST be dropped....' RFC 2119 keyword, line 120: '...mented IPv6 host MUST adhere to the fo...' RFC 2119 keyword, line 130: '...nk determination SHOULD NOT persist ac...' RFC 2119 keyword, line 140: '...d Lifetime expires, the host MUST then...' RFC 2119 keyword, line 144: '... 5. Newer implementations, which are compliant with [RFC4861] MUST...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (February 25, 2008) is 5904 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: 2 errors (**), 0 flaws (~~), 1 warning (==), 9 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: August 28, 2008 E. Nordmark 6 Sun Microsystems 7 February 25, 2008 9 IPv6 Subnet Model 10 draft-wbeebee-on-link-and-off-link-determination-02 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 August 28, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 IPv6 specifies a model of a subnet that is different than the IPv4 44 subnet model. The subtlety of the differences has turned out to 45 cause interoperability problems. This note spells out the most 46 important difference; that an IPv6 address isn't automatically 47 associated with an IPv6 on-link subnet prefix. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Host Behavior Rules . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 54 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 55 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 56 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 58 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 59 Appendix A. CHANGE HISTORY . . . . . . . . . . . . . . . . . . . . 6 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 61 Intellectual Property and Copyright Statements . . . . . . . . . . 9 63 1. Introduction 65 In many, if not all, IPv4 implementations when an IPv4 address is 66 assigned to an interface there is always a netmask associated with 67 the address. That netmask together with the IPv4 address designates 68 an on-link prefix. Addresses that match this prefix are viewed as 69 local i.e., traffic to such addresses is not sent to a router. See 70 section 3.3.1 in [RFC1122]. 72 The behavior of IPv6 as specified in Neighbor Discovery [RFC4861] is 73 quite different. The on-link determination is separate from the 74 address assignment. A host can have IPv6 addresses without any 75 corresponding on-link subnet prefixes, and conversely, can have on- 76 link subnet prefixes that are not related to any of the IPv6 77 addresses that are assigned to the hosts. 79 In IPv6, by default, a host treats only the link-local subnet as on- 80 link. 82 The reception of a Prefix Information Option (PIO) with the L-bit set 83 and a non-zero valid lifetime creates (or updates the valid lifetime 84 for an existing entry) in the prefix list. All the prefixes that are 85 on the prefix list, i.e., have not yet timed out, are on-link. 87 In addition to the prefix list, individual addresses are on-link if 88 they are the target of a Redirect Message indicating on-link, or the 89 source of a Neighbor Solicitation or Neighbor Advertisement message. 90 Note that Redirect Messages can also indicate an address is off-link. 91 Individual address entries can be expired by the Neighbor 92 Unreachability Detection mechanism. 94 A host only performs address resolution for IPv6 addresses that are 95 on-link. Packets to any other address are sent to a default router. 96 If there is no default router, then such packets MUST be dropped. 97 (Note that RFC 4861 changed the behavior when the Default Router List 98 is empty. The behavior in the old version of Neighbor Discovery 99 [RFC2461] was different when there were no default routers.) 101 Failure of host implementations to correctly implement this can 102 result in lack of IPv6 connectivity. One example, included in 103 draft-wbeebee-nd-implementation-problems-00 104 [I-D.wbeebee-nd-implementation-problems], follows: a host receives a 105 Router Advertisement Message with no on-link prefix advertised. The 106 host incorrectly decides to perform address resolution when the host 107 should send all traffic to a default router. Neither the router nor 108 any other host may respond to the address resolution, preventing this 109 host from sending IPv6 traffic. 111 Correct implementation of the on-link determination is critically 112 important in some deployments. For instance, with certain layer 2 113 technologies it is not possible or very inefficient for hosts to 114 perform address resolution. It is much more efficient for the hosts 115 to send all packets for non-link-local addresses to one of the 116 default routers, and have the default routers forward those packets. 118 2. Host Behavior Rules 120 A correctly implemented IPv6 host MUST adhere to the following rules: 122 1. By default only the link-local prefix is on-link. 124 2. The configuration of an IPv6 address, whether through IPv6 125 stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315], 126 or manual configuration does not imply that any prefix is on- 127 link. A host is explicitly told that prefixes or addresses are 128 on-link through the means specified in [RFC4861]. 130 3. On-link determination SHOULD NOT persist across IPv6 interface 131 initializations. Note that section 5.7 of [RFC4862] describes 132 the use of stable storage for addresses acquired with stateless 133 address autoconfiguration with a note that the Preferred and 134 Valid Lifetimes must be retained if this approach is used. 135 However no RFC suggests or recommends retaining the on-link 136 prefixes. 138 4. In the absence of other sources of on-link information, including 139 Redirects, if the RA advertises a prefix with the on-link(L) bit 140 set and later the Valid Lifetime expires, the host MUST then 141 consider addresses of the prefix to be off-link, as specified by 142 the PIO paragraph of section 6.3.4 of [RFC4861]. 144 5. Newer implementations, which are compliant with [RFC4861] MUST 145 adhere to the following rules. Older implementations, which are 146 compliant with [RFC2461] but not [RFC4861] may remain as is. If 147 the Default Router List is empty and there is no other source of 148 on-link information about any address or prefix: 150 1. The host MUST NOT assume that all destinations are on-link. 152 2. The host MUST NOT perform address resolution for non-link- 153 local addresses. 155 3. Since the host cannot assume the destination is on-link, and 156 off-link traffic cannot be sent to a default router (since 157 the Default Router List is empty), address resolution cannot 158 be performed. This case is analogous to the behavior 159 specified in the last paragraph of section 7.2.2 of 160 [RFC4861]: when address resolution fails, the host SHOULD 161 send an ICMPv6 Destination Unreachable message. The 162 specified behavior MAY be extended to cover this case where 163 address resolution cannot be performed. 165 On-link information concerning particular addresses and prefixes 166 can make those specific addresses and prefixes on-link, but does 167 not change the default behavior mentioned above for addresses and 168 prefixes not specified. [RFC4943] provides justification for 169 these rules. 171 3. Security Considerations 173 As this document merely restates and clarifies RFC 4861, it does not 174 introduce any new security issues. 176 4. IANA Considerations 178 None. 180 5. Acknowledgements 182 Thanks (in alphabetical order) to Adeel Ahmed, Jari Arkko, Ralph 183 Droms, Alun Evans, Dave Forster, Prashanth Krishnamurthy, Suresh 184 Krishnan, Josh Littlefield, Madhu Sudan, Jinmei Tatuya, Bernie Volz, 185 and Vlad Yasevich for their consistent input, ideas and review during 186 the production of this document. 188 6. References 190 6.1. Normative References 192 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 193 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 194 September 2007. 196 6.2. Informative References 198 [I-D.wbeebee-nd-implementation-problems] 199 Singh, H. and W. Beebee, "Known ND Implementation 200 Problems", draft-wbeebee-nd-implementation-problems-00 201 (work in progress), September 2007. 203 [RFC1122] Braden, R., "Requirements for Internet Hosts - 204 Communication Layers", STD 3, RFC 1122, October 1989. 206 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 207 Discovery for IP Version 6 (IPv6)", RFC 2461, 208 December 1998. 210 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 211 and M. Carney, "Dynamic Host Configuration Protocol for 212 IPv6 (DHCPv6)", RFC 3315, July 2003. 214 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 215 Address Autoconfiguration", RFC 4862, September 2007. 217 [RFC4943] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor 218 Discovery On-Link Assumption Considered Harmful", 219 RFC 4943, September 2007. 221 Appendix A. CHANGE HISTORY 223 [NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION UPON PUBLICATION.] 225 Changes since draft-wbeebee-on-and-off-link-determination-00.txt are: 227 o Made global changes in document to replace RFC 2461 and RFC 2462 228 with RFC 4861 and RFC 4862 respectively. Removed text related to 229 2461bis-11 and 2462bis-08. 231 o Inserted new bullet item to section 2 that explains off-link and 232 on-link default behavior. 234 o On-link behavior has been replaced with on-link determination. 236 o At the end of sections 2.1 and 2.2.1, the last paragraph related 237 to Redirects has been reworded to place more details in the 238 Redirect section. 240 o Section 2.2 has all text removed and then new text has been added. 242 o The Redirect Clarifications section has been rewritten to explain 243 an extra case when the Redirect does not include the Target Link- 244 Layer Address Option. This section has been revised to restrict 245 the scope of the Redirects sent from aggregation routers mentioned 246 to those with on-link destinations. 248 o Jinmei Tatuya has been added to the list of people in the 249 Acknowledged section for his valuable feedback on the -00 draft. 251 o Two bis draft references in the References section have been 252 removed. 254 Changes since draft-wbeebee-on-and-off-link-determination-01.txt are: 256 o Added a new author in Erik Nordmark to the draft. 258 o Changed title of draft from "ND On-link and Off-link 259 Determination" to "IPv6 Subnet Model". Also changed Abstract and 260 Introduction sections to reflect new title. 262 o Changed text of the example in Introduction section from "follows: 263 a host receives an RA with no prefix advertised and incorrectly 264 decides to perform address resolution when the host should have 265 sent all traffic to the default router. The router does not 266 respond to the address resolution and the layer 2 driver of the 267 host stops transmitting IPv6 packets." to "follows: a host 268 receives a Router Advertisement Message with no on-link prefix 269 advertised. The host incorrectly decides to perform address 270 resolution when the host should send all traffic to a default 271 router. Neither the router nor any other host may respond to the 272 address resolution, preventing this host from sending IPv6 273 traffic." 275 o Removed sections 2.1-2.3 - folded information from these sections 276 into Introduction section and bullets of section 2. 278 o Removed sections 3 and 4 - folded subnet model and on-link 279 determination related information from these sections into 280 Introduction section and bullets of section 2. 282 o Made changes to References sections. Removed RFC2472 from 283 Normative References. Moved RFC4861 from Informative to Normative 284 References. Added RFC1122 and RFC3315 to Informative References. 286 Authors' Addresses 288 Hemant Singh 289 Cisco Systems, Inc. 290 1414 Massachusetts Ave. 291 Boxborough, MA 01719 292 USA 294 Phone: +1 978 936 1622 295 Email: shemant@cisco.com 296 URI: http://www.cisco.com/ 297 Wes Beebee 298 Cisco Systems, Inc. 299 1414 Massachusetts Ave. 300 Boxborough, MA 01719 301 USA 303 Phone: +1 978 936 2030 304 Email: wbeebee@cisco.com 305 URI: http://www.cisco.com/ 307 Erik Nordmark 308 Sun Microsystems 309 17 Network Circle 310 Menlo Park, CA 94025 311 USA 313 Phone: +1 650 786 2921 314 Email: erik.nordmark@sun.com 316 Full Copyright Statement 318 Copyright (C) The IETF Trust (2008). 320 This document is subject to the rights, licenses and restrictions 321 contained in BCP 78, and except as set forth therein, the authors 322 retain all their rights. 324 This document and the information contained herein are provided on an 325 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 326 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 327 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 328 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 329 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 330 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 332 Intellectual Property 334 The IETF takes no position regarding the validity or scope of any 335 Intellectual Property Rights or other rights that might be claimed to 336 pertain to the implementation or use of the technology described in 337 this document or the extent to which any license under such rights 338 might or might not be available; nor does it represent that it has 339 made any independent effort to identify any such rights. Information 340 on the procedures with respect to rights in RFC documents can be 341 found in BCP 78 and BCP 79. 343 Copies of IPR disclosures made to the IETF Secretariat and any 344 assurances of licenses to be made available, or the result of an 345 attempt made to obtain a general license or permission for the use of 346 such proprietary rights by implementers or users of this 347 specification can be obtained from the IETF on-line IPR repository at 348 http://www.ietf.org/ipr. 350 The IETF invites any interested party to bring to its attention any 351 copyrights, patents or patent applications, or other proprietary 352 rights that may cover technology that may be required to implement 353 this standard. Please address the information to the IETF at 354 ietf-ipr@ietf.org. 356 Acknowledgment 358 Funding for the RFC Editor function is provided by the IETF 359 Administrative Support Activity (IASA).