idnits 2.17.1 draft-ietf-6man-ipv6-subnet-model-01.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 314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 338. 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 115: '...mented IPv6 host MUST adhere to the fo...' RFC 2119 keyword, line 121: '...al configuration MUST NOT implicitely ...' RFC 2119 keyword, line 143: '...d Lifetime expires, the host MUST then...' RFC 2119 keyword, line 147: '... 5. Newer implementations, which are compliant with [RFC4861] MUST...' RFC 2119 keyword, line 153: '... 1. The host MUST NOT assume that ...' (1 more instance...) 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 (July 10, 2008) is 5767 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: January 11, 2009 E. Nordmark 6 Sun Microsystems 7 July 10, 2008 9 IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes 10 draft-ietf-6man-ipv6-subnet-model-01 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 January 11, 2009. 37 Abstract 39 IPv6 specifies a model of a subnet that is different than the IPv4 40 subnet model. The subtlety of the differences has resulted in 41 incorrect implementations that do not interoperate. This document 42 spells out the most important difference; that an IPv6 address isn't 43 automatically associated with an IPv6 on-link prefix. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Host Behavior and Rules . . . . . . . . . . . . . . . . . . . . 4 49 3. Observed Incorrect Implementation Behavior . . . . . . . . . . 5 50 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 52 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 53 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 54 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 56 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 57 Appendix A. CHANGE HISTORY . . . . . . . . . . . . . . . . . . . . 7 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 59 Intellectual Property and Copyright Statements . . . . . . . . . . 9 61 1. Introduction 63 IPv4 implementations typically associate a netmask with an address 64 when an IPv4 address is assigned to an interface. That netmask 65 together with the IPv4 address designates an on-link prefix. 66 Addresses that are covered by this prefix are viewed as on-link i.e., 67 traffic to these addresses is not sent to a router. See section 68 3.3.1 in [RFC1122]. Prior to the deployment of CIDR, an address's 69 netmask could be derived directly from the address. In the absence 70 of specifying a specific netmask when assigning a address, some 71 implementations would fall back to deriving the netmask from the 72 class of the address. 74 The behavior of IPv6 as specified in Neighbor Discovery [RFC4861] is 75 quite different. The on-link determination is separate from the 76 address assignment. A host can have IPv6 addresses without any 77 related on-link prefixes or have on-link prefixes that are not 78 related to any IPv6 addresses that are assigned to the host. Any 79 assigned address on an interface should initially be considered as 80 having no internal structure as shown in [RFC4291]. 82 In IPv6, by default, a host treats only the link-local prefix as on- 83 link. 85 The reception of a Prefix Information Option (PIO) with the L-bit set 86 [RFC4861] and a non-zero valid lifetime creates an entry (or updates 87 the valid lifetime for an existing entry) in the Prefix List. All 88 the prefixes that are on the Prefix List, i.e., have not yet timed 89 out, are on-link. 91 The on-link definition in the Terminology section of [RFC4861] 92 defines the complete list of cases where an address is considered on- 93 link. Note, in particular, that Redirect Messages can also indicate 94 an address is off-link. Individual address entries can be expired by 95 the Neighbor Unreachability Detection mechanism. 97 A host only performs address resolution for IPv6 addresses that are 98 on-link. Packets to any other address are sent to a default router. 99 If there is no default router, then the node should send an ICMPv6 100 Destination Unreachable indication as specified in [RFC4861] - more 101 details are provided in the Host Behavior Rules section. (Note that 102 RFC 4861 changed the behavior when the Default Router List is empty. 103 The behavior in the old version of Neighbor Discovery [RFC2461] was 104 different when there were no default routers.) 106 Failure of host implementations to correctly implement the IPv6 107 subnet model can result in lack of IPv6 connectivity. See the 108 Observed Incorrect Implementation Behavior section for details. 110 Host behavior is clarified in the Host Behavior Rules section. 111 Finally, this document mainly restates and clarifies [RFC4861]. 113 2. Host Behavior and Rules 115 A correctly implemented IPv6 host MUST adhere to the following rules: 117 1. By default only the link-local prefix is on-link. 119 2. The configuration of an IPv6 address, whether through IPv6 120 stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315], 121 or manual configuration MUST NOT implicitely cause a prefix 122 derived from that address to be treated as on-link. A host 123 considers a prefix to be on-link only through explicit means, 124 such as those specified in the on-link definition in the 125 Terminology section of [RFC4861] or via manual configuration. 126 Note that the requirement for manually configured addresses is 127 not explicitly mentioned in [RFC4861]. 129 3. If on-link determination persists across IPv6 interface 130 initializations, then lack of IPv6 connectivity can result. For 131 example, a host receives an RA from a router with on-link prefix 132 A. The host reboots. During the reboot, the router sends out 133 prefix A with on-link bit set and a zero lifetime to indicate a 134 renumbering. The host misses the renumbering. The host comes 135 online. Then, the router sends an RA with no PIO. The host uses 136 cached on-link prefix A and issues NS's instead of sending 137 traffic to a default router. The "Observed Incorrect 138 Implementation Behavior" section below describes how this can 139 result in lack of IPv6 connectivity. 141 4. In the absence of other sources of on-link information, including 142 Redirects, if the RA advertises a prefix with the on-link(L) bit 143 set and later the Valid Lifetime expires, the host MUST then 144 consider addresses of the prefix to be off-link, as specified by 145 the PIO paragraph of section 6.3.4 of [RFC4861]. 147 5. Newer implementations, which are compliant with [RFC4861] MUST 148 adhere to the following rules. Older implementations, which are 149 compliant with [RFC2461] but not [RFC4861] may remain as is. If 150 the Default Router List is empty and there is no other source of 151 on-link information about any address or prefix: 153 1. The host MUST NOT assume that all destinations are on-link. 155 2. The host MUST NOT perform address resolution for non-link- 156 local addresses. 158 3. Since the host cannot assume the destination is on-link, and 159 off-link traffic cannot be sent to a default router (since 160 the Default Router List is empty), address resolution cannot 161 be performed. This case is specified in the last paragraph 162 of section 4 of [RFC4943]: when there is no route to 163 destination, the host should send an ICMPv6 Destination 164 Unreachable indication (for example, a locally delivered 165 error message) as specified in the Terminology section of 166 [RFC4861]. 168 On-link information concerning particular addresses and prefixes 169 can make those specific addresses and prefixes on-link, but does 170 not change the default behavior mentioned above for addresses and 171 prefixes not specified. [RFC4943] provides justification for 172 these rules. 174 3. Observed Incorrect Implementation Behavior 176 One incorrect implementation behavior illustrates the severe 177 consequences when the IPv6 subnet model is not understood by the 178 implementers of several popular host operating systems. In an access 179 concentrator network ([RFC4388]), a host receives a Router 180 Advertisement Message with no on-link prefix advertised. The host 181 incorrectly assumes the prefix is on-link and performs address 182 resolution when the host should send all non-link-local traffic to a 183 default router. Neither the router nor any other host will respond 184 to the address resolution, preventing this host from sending IPv6 185 traffic. 187 4. Conclusion 189 This document clarifies and summarizes the relationship between links 190 and subnet prefixes described in [RFC4861]. Configuration of an IPv6 191 address does not imply the existence of corresponding on-link 192 prefixes. One should also look at API considerations for prefix 193 length as described in last paragraph of section 4.2 of [RFC4903]. 195 5. Security Considerations 197 This document mainly restates and clarifies [RFC4861]. It does not 198 introduce any new security issues. 200 6. IANA Considerations 202 None. 204 7. Acknowledgements 206 Thanks (in alphabetical order) to Adeel Ahmed, Jari Arkko, Ralph 207 Droms, Alun Evans, Dave Forster, Prashanth Krishnamurthy, Suresh 208 Krishnan, Josh Littlefield, Thomas Narten, Madhu Sudan, Jinmei 209 Tatuya, Dave Thaler, Bernie Volz, and Vlad Yasevich for their 210 consistent input, ideas and review during the production of this 211 document. 213 8. References 215 8.1. Normative References 217 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 218 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 219 September 2007. 221 8.2. Informative References 223 [RFC1122] Braden, R., "Requirements for Internet Hosts - 224 Communication Layers", STD 3, RFC 1122, October 1989. 226 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 227 Discovery for IP Version 6 (IPv6)", RFC 2461, 228 December 1998. 230 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 231 and M. Carney, "Dynamic Host Configuration Protocol for 232 IPv6 (DHCPv6)", RFC 3315, July 2003. 234 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 235 Architecture", RFC 4291, February 2006. 237 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 238 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 240 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 241 Address Autoconfiguration", RFC 4862, September 2007. 243 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 244 June 2007. 246 [RFC4943] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor 247 Discovery On-Link Assumption Considered Harmful", 248 RFC 4943, September 2007. 250 Appendix A. CHANGE HISTORY 252 [NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION UPON PUBLICATION.] 254 Changes in draft-ietf-6man-ipv6-subnet-model-01.txt since -00.txt 255 are: 257 o Changed Introduction section to remove any mention of src address 258 of ND message as a means for on-link determination. Also reworded 259 first paragrpah of Introduction section. 261 o Reworded bullet 2 of section 2 and added text to clarify on-link 262 definition. 264 o Added text to bullet 3 of section 2 to make explicit that this is 265 a new rule. 267 o Reworded bullet 5 of section 2 to clearly explain where ICMPv6 268 Destination Unreachable is sent to. 270 Authors' Addresses 272 Hemant Singh 273 Cisco Systems, Inc. 274 1414 Massachusetts Ave. 275 Boxborough, MA 01719 276 USA 278 Phone: +1 978 936 1622 279 Email: shemant@cisco.com 280 URI: http://www.cisco.com/ 281 Wes Beebee 282 Cisco Systems, Inc. 283 1414 Massachusetts Ave. 284 Boxborough, MA 01719 285 USA 287 Phone: +1 978 936 2030 288 Email: wbeebee@cisco.com 289 URI: http://www.cisco.com/ 291 Erik Nordmark 292 Sun Microsystems 293 17 Network Circle 294 Menlo Park, CA 94025 295 USA 297 Phone: +1 650 786 2921 298 Email: erik.nordmark@sun.com 300 Full Copyright Statement 302 Copyright (C) The IETF Trust (2008). 304 This document is subject to the rights, licenses and restrictions 305 contained in BCP 78, and except as set forth therein, the authors 306 retain all their rights. 308 This document and the information contained herein are provided on an 309 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 310 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 311 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 312 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 313 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 314 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 316 Intellectual Property 318 The IETF takes no position regarding the validity or scope of any 319 Intellectual Property Rights or other rights that might be claimed to 320 pertain to the implementation or use of the technology described in 321 this document or the extent to which any license under such rights 322 might or might not be available; nor does it represent that it has 323 made any independent effort to identify any such rights. Information 324 on the procedures with respect to rights in RFC documents can be 325 found in BCP 78 and BCP 79. 327 Copies of IPR disclosures made to the IETF Secretariat and any 328 assurances of licenses to be made available, or the result of an 329 attempt made to obtain a general license or permission for the use of 330 such proprietary rights by implementers or users of this 331 specification can be obtained from the IETF on-line IPR repository at 332 http://www.ietf.org/ipr. 334 The IETF invites any interested party to bring to its attention any 335 copyrights, patents or patent applications, or other proprietary 336 rights that may cover technology that may be required to implement 337 this standard. Please address the information to the IETF at 338 ietf-ipr@ietf.org.