idnits 2.17.1 draft-smith-6man-link-locals-off-link-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 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.) -- The draft header indicates that this document updates RFC4861, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5942, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4861, updated by this document, for RFC5378 checks: 2004-07-16) -- 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 (August 16, 2015) is 3173 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Smith 3 Internet-Draft IMOT 4 Updates: 4861, 5942 (if approved) August 16, 2015 5 Intended status: Standards Track 6 Expires: February 17, 2016 8 Indicating Link-Local Unicast Destinations are Off-Link 9 draft-smith-6man-link-locals-off-link-00 11 Abstract 13 Certain link-layers limit reachability for one set of nodes, while 14 permitting full reachability for a different set of nodes, for 15 unicast, multicast and broadcast traffic. If IPv6 hosts are members 16 of the first set of nodes, and IPv6 routers are members of the 17 second, Link-Local traffic between IPv6 hosts will fail, due to the 18 default on-link assumption for Link-Local destinations. This memo 19 describes the use of a Link-Local Prefix Information Option to 20 indicate to these hosts that Link-Local destinations are "off-link", 21 and are reachable via their default router(s). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 17, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 59 2. Constrained Broadcast Multi-Access (CBMA) Links . . . . . . . 3 60 3. IPv6 over CBMA Links . . . . . . . . . . . . . . . . . . . . 3 61 4. Link-Local traffic over CBMA Links . . . . . . . . . . . . . 4 62 5. Indicating Link-Local Destinations are Off-Link . . . . . . . 5 63 5.1. Link-Local Router Advertisement Prefix Information Option 5 64 5.2. Host Link-Local Prefix Information Option Processing . . 5 65 5.2.1. Upon Receipt of a Link-Local PIO . . . . . . . . . . 5 66 5.2.1.1. Validation . . . . . . . . . . . . . . . . . . . 5 67 5.2.1.2. Processing . . . . . . . . . . . . . . . . . . . 6 68 5.2.2. Upon Expiry of Link-Local Off-Link Information . . . 6 69 6. Updates to RFC4861 . . . . . . . . . . . . . . . . . . . . . 6 70 7. Updates to RFC5942 . . . . . . . . . . . . . . . . . . . . . 7 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 73 10. Change Log [RFC Editor please remove] . . . . . . . . . . . . 8 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 11.2. Informative References . . . . . . . . . . . . . . . . . 8 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 Certain link-layers limit reachability for one set of nodes, while 82 permitting full reachability for a different set of nodes, for 83 unicast, multicast and broadcast traffic. If IPv6 hosts are members 84 of the first set of nodes, and IPv6 routers are members of the 85 second, Link-Local traffic between IPv6 hosts will fail, due to the 86 default on-link assumption for Link-Local destinations. This memo 87 describes the use of a Link-Local Prefix Information Option to 88 indicate to these hosts that Link-Local destinations are "off-link", 89 and are reachable via their default router(s). 91 1.1. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 2. Constrained Broadcast Multi-Access (CBMA) Links 99 A variety of multi-access link-layers operate or can be configured to 100 constrain layer 2 reachability between attached nodes. Typically, 101 one set of nodes can reach all other attached nodes, while a second 102 disjoint set of nodes are only able to reach members of the first 103 set. Members of the second set are isolated from each other. These 104 constraints are applied to link-layer unicast, multicast and 105 broadcast traffic. 107 Examples of these types of links are Broadband Forum TR-101 VLANs 108 following the N:1 forwarding model, IEEE 802.11 Wifi Networks with 109 station isolation switched on, and "Private VLANs" [RFC5517]. 111 This memo uses the more general term "Constrained Broadcast Multi- 112 Access" (CBMA) to describe these types of links. These types of 113 links are distinct from Non-Broadcast Multi-Access (NBMA) links. 115 3. IPv6 over CBMA Links 117 When IPv6 is operated over a CBMA link, one or more IPv6 routers 118 would be selected as the link-layer nodes that can reach all other 119 nodes, while IPv6 hosts would be selected as the link-layer nodes 120 limited to only being able to reach the IPv6 routers. 122 Unless informed otherwise via Router Advertisement Prefix Information 123 Options (PIOs) with the L or on-link flag switched on [RFC4861], IPv6 124 hosts are to consider all non-Link-local destinations off-link, 125 including destination addresses that fall within the prefix their own 126 addresses are assigned from [RFC5942]. Unicast destination addresses 127 attached to the same link will be reached by hosts sending their 128 packets towards one of their default routers, which will then forward 129 the packets back over the same link towards the final destinations. 131 This "hair-pin" or "trombone" forwarding between IPv6 hosts attached 132 to the same link, via one or more default routers, allows the 133 router(s) to be used to perform functions in addition to standard 134 IPv6 forwarding, such as traffic inspection for security purposes or 135 per-host traffic accounting. Security examples might be to prevent 136 unauthorised nodes emitting Router Advertisements or acting as 137 unauthorised DHCPv6 servers. 139 Note that multicast IPv6 traffic is normally sent to all link-layer 140 reachable nodes, possibly limited to interested hosts using MLD 141 Snooping [RFC4541]. On a CBMA link, IPv6 hosts' multicasts will be 142 further limited to only reaching the IPv6 routers. These IPv6 143 routers may choose to drop this multicast traffic if they're not 144 interested in it or perform proxy functions for other hosts attached 145 to the link (e.g., DAD Proxy [RFC6957]). 147 The author is not aware of a more general method of multicast 148 forwarding that could be used by the routers to allow all hosts 149 attached to the CBMA link to receive other CBMA link hosts' 150 multicasts should they pass any multicast security policies applied 151 by the CBMA router(s). 153 (When hosts receive multicasts over an interface, do they check if 154 the multicast source address is one of their own, and ignore the 155 multicast if so (as distinct from multicasts looped back locally 156 within the host, enabled by a socket API call)? If so, the CBMA 157 routers could send multicasts back onto the CBMA link (after passing 158 other security checks), and the originating host would ignore them. 159 Perhaps hosts could perform this sort of source address checking if 160 they receive the Link-Local Prefix Information Option, described 161 below, while it remains valid. There isn't a forwarding loop in the 162 link-layer, it is just that originating hosts would receive their own 163 multicasts that need to be ignored. Only one of the routers on the 164 CBMA link would send multicasts back onto the link; the router with 165 the lowest value Link-Local address could be the one, using the set 166 of routers' RA and RS Link-Local source addresses to choose (similar 167 to a multicast router querier election)). The non-elected router 168 would not forward multicast traffic it receives back onto the CBMA 169 link. 171 4. Link-Local traffic over CBMA Links 173 Due to the on-link assumption for Link-Local unicast destinations 174 [RFC5942], attempts to send Link-Local traffic to other hosts 175 attached to the CBMA link will fail, as the inter-host reachability 176 has been constrained by the CBMA link. The only Link-Local 177 destinations reachable by the hosts are the Link-Local addresses of 178 the default routers. 180 This limited Link-Local reachability can be detrimental to the 181 operation of IPv6 applications, as IPv6 applications are permitted to 182 use Link-Local addresses for their connectivity [RFC4007], and if 183 multiple scopes of addresses are available for the application to 184 use, Link-Local addresses will be preferred over all others with 185 exception to the loopback address, due to the general rule of 186 preferring addresses with the smaller scopes [RFC6724]. 188 If hosts could be informed that Link-Local destinations are to also 189 be considered "off-link", reachability to all Link-Local destinations 190 on the CBMA link would be restored. Hosts would send traffic to all 191 Link-Local destinations via their default router(s), with the chosen 192 default router then forwarding the traffic back onto the CBMA link 193 [RFC4007] towards the final Link-Local destination. 195 5. Indicating Link-Local Destinations are Off-Link 197 5.1. Link-Local Router Advertisement Prefix Information Option 199 To signal to hosts that they should consider Link-Local destinations 200 "off-link", a router sends a Link-Local Prefix Information Option in 201 its Router Advertisements [RFC4861], with the following PIO field 202 values: 204 o Prefix Length: 10 [RFC4291] 206 o L or On-Link Flag: 0 (Off) 208 o A or Autonomous Address-Configuration Flag: 0 (Off) 210 o Valid Lifetime: Length of time Link-Local destinations are to be 211 considered off-link 213 o Preferred Lifetime: 0xffffffff (representing infinity) [RFC4862] 215 o Prefix: fe80:: [RFC4291] 217 5.2. Host Link-Local Prefix Information Option Processing 219 5.2.1. Upon Receipt of a Link-Local PIO 221 5.2.1.1. Validation 223 When a host receives a Link-Local Prefix Information Option, it MUST 224 perform the following validation steps: 226 1. Verifies the Prefix field value is fe80::. If not, this is not a 227 LL PIO, and should be processed as a conventional PIO. 229 2. Verifies the Prefix Length field value is 10. If not, ignores 230 the LL PIO. 232 3. Verifies the L or On-Link Flag value is 0. If not, ignores the 233 LL PIO. 235 4. Ignores the A or Autonomous Address-Configuration Flag value, as 236 Link-Local addresses always use Autonomous Address-Configuration, 237 and are formed when an interface becomes enabled [RFC4862]. 239 5. Verifies the Preferred Lifetime field value is Infinity 240 (0xffffffff). If not, ignores the LL PIO. 242 If any of the above validation steps fail, in addition to ignoring 243 the LL PIO, an implementation MAY choose to log an informational or 244 debugging severity level system message about the malformed LL PIO, 245 appropriately rate limited. 247 5.2.1.2. Processing 249 Once the LL PIO has been successfully validated, the Link-Local 250 prefix is removed from the host's Prefix List [RFC5942]. A count 251 down to zero timer is started with the LL PIO's Valid Lifetime value. 253 While the timer is still running, the host sends all Link-Local 254 destined traffic for the interface it received the LL PIO on to 255 either the router it received the LL PIO from, or to any of the 256 default routers on the link, achieving an amount of load-sharing 257 [RFC4311]. 259 As Link-Local destinations are now being reached via the host's 260 default router(s), Neighbor Cache entries for Link-Local 261 destinations, excepting Link-Local entries with the IsRouter flag set 262 [RFC4861], should be removed immediately, regardless of their 263 resolution state. Any active related Neighbor Unreachability 264 Detection procedures should also be terminated. 266 5.2.2. Upon Expiry of Link-Local Off-Link Information 268 If Link-Local "Off-Link" information expires, as it has not been 269 refreshed by receiving a LL PIO from any of the link's routers, the 270 Link-Local prefix is returned to the host's Prefix List for the 271 corresponding interface, meaning that Link-Local destinations return 272 to being considered on-link. Subsequent transmissions to Link-Local 273 destinations should trigger Neighbor Discovery [RFC4861], despite the 274 link possibly continuing to be a CBMA-type link. 276 6. Updates to RFC4861 278 The following statement in Section 6.3.4 of Neighbor Discovery in 279 IPv6 [RFC4861]: 281 "Note, however, that a Prefix Information option with the on-link 282 flag set to zero conveys no information concerning on-link 283 determination and MUST NOT be interpreted to mean that addresses 284 covered by the prefix are off-link." 286 is replaced by 287 "Note, however, that a Prefix Information option with the on-link 288 flag set to zero conveys no information concerning on-link 289 determination and MUST NOT be interpreted to mean that addresses 290 covered by the prefix are off-link, with exception to a Prefix 291 Information Option for the Link-Local prefix. The Link-Local prefix 292 is considered on-link by default [RFC5942]." 294 "The reception of a Prefix Information option for the Link-Local 295 prefix, with the L-bit set to 0, MUST be interpreted by a host as 296 meaning that Link-Local destinations are to considered off-link, and 297 are to be reached by one of the host's available default routers, 298 while the Prefix Information option information for the Link-Local 299 prefix remains valid [draft-smith-6man-link-locals-off-link]." 301 The following statement in Section 6.3.4 of Neighbor Discovery in 302 IPv6 [RFC4861]: 304 "If the prefix is the link-local prefix, silently ignore the Prefix 305 Information option." 307 is removed. 309 7. Updates to RFC5942 311 The following statement in the Introduction of IPv6 Subnet Model: The 312 Relationship between Links and Subnet Prefixes [RFC5942]: 314 "In IPv6, by default, a host treats only the link-local prefix as on- 315 link." 317 is replaced by 319 "In IPv6, by default, a host treats only the link-local prefix as on- 320 link, unless updated by a Prefix Information option for the link- 321 local prefix, indicating the link-local prefix is to be considered 322 off-link [draft-smith-6man-link-locals-off-link]." 324 The following statement in the Section 3 of IPv6 Subnet Model: The 325 Relationship between Links and Subnet Prefixes [RFC5942]: 327 "(The link-local prefix is effectively considered a permanent entry 328 on the Prefix List.)" 330 is deleted. 332 8. Security Considerations 334 The security benefit of operating IPv6 over a CBMA link-layer is the 335 insertion of an IPv6 traffic forwarding device between each host and 336 all other possible destinations, including those attached to the same 337 CBMA link. This allows the forwarding device to be used to perform 338 security functions on all CBMA attached host originated traffic, in 339 addition to performing normal IPv6 forwarding. 341 Allowing Link-Local source and destination addresses to be used in an 342 IPv6 over CBMA network does not reduce this security benefit. 344 9. Acknowledgements 346 Thanks to Chris Chaundy for asking the author about the on-link 347 status of the Link-Local prefix when the author was describing the 348 purpose of the L-bit in Prefix Information Options. Chris's question 349 prompted the thinking behind and writing of this memo. 351 Review and comments were provided by YOUR NAME HERE! 353 This memo was prepared using the xml2rfc tool. 355 10. Change Log [RFC Editor please remove] 357 draft-smith-6man-link-locals-off-link-00, initial version, 2015-08-16 359 11. References 361 11.1. Normative References 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, 365 DOI 10.17487/RFC2119, March 1997, 366 . 368 11.2. Informative References 370 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 371 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 372 DOI 10.17487/RFC4007, March 2005, 373 . 375 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 376 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 377 2006, . 379 [RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load 380 Sharing", RFC 4311, DOI 10.17487/RFC4311, November 2005, 381 . 383 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 384 "Considerations for Internet Group Management Protocol 385 (IGMP) and Multicast Listener Discovery (MLD) Snooping 386 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 387 . 389 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 390 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 391 DOI 10.17487/RFC4861, September 2007, 392 . 394 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 395 Address Autoconfiguration", RFC 4862, 396 DOI 10.17487/RFC4862, September 2007, 397 . 399 [RFC5517] HomChaudhuri, S. and M. Foschiano, "Cisco Systems' Private 400 VLANs: Scalable Security in a Multi-Client Environment", 401 RFC 5517, DOI 10.17487/RFC5517, February 2010, 402 . 404 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 405 Model: The Relationship between Links and Subnet 406 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 407 . 409 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 410 "Default Address Selection for Internet Protocol Version 6 411 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 412 . 414 [RFC6957] Costa, F., Combes, J-M., Ed., Pougnard, X., and H. Li, 415 "Duplicate Address Detection Proxy", RFC 6957, 416 DOI 10.17487/RFC6957, June 2013, 417 . 419 Author's Address 420 Mark Smith 421 In My Own Time 422 PO BOX 521 423 HEIDELBERG, VIC 3084 424 AU 426 Email: markzzzsmith@gmail.com