idnits 2.17.1 draft-nordmark-6man-rs-refresh-01.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 draft header indicates that this document updates RFC4861, but the abstract doesn't seem to directly say this. It does mention RFC4861 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (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 (October 27, 2014) is 3462 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: 'RFC2460' is defined on line 435, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-6man-resilient-rs-04 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man WG E. Nordmark 3 Internet-Draft Arista Networks 4 Updates: 4861 (if approved) A. Yourtchenko 5 Intended status: Standards Track Cisco 6 Expires: April 30, 2015 S. Krishnan 7 Ericsson 8 October 27, 2014 10 IPv6 Neighbor Discovery Optional Unicast RS/RA Refresh 11 draft-nordmark-6man-rs-refresh-01 13 Abstract 15 IPv6 Neighbor Discovery relies on periodic multicast Router 16 Advertisement messages to update timer values and to distribute new 17 information (such as new prefixes) to hosts. On some links the use 18 of periodic multicast messages to all host becomes expensive, and in 19 some cases it results in hosts waking up frequently. Many 20 implementations of RFC 4861 also use multicast for solicited Router 21 Advertisement messages, even though that behavior is optional. 23 This specification provides an optional mechanism for hosts and 24 routers where instead of periodic multicast Router Advertisements the 25 hosts are instructed (by the routers) to use unicast Router 26 Solicitations to request refreshed Router Advertisements. This 27 mechanism is enabled by configuring the router to include a new 28 option in the Router Advertisement in order to allow the network 29 administrator to choose host behavior based on whether periodic 30 multicast are more efficient on their link or not. The routers can 31 also tell whether the hosts are capable of the new behavior through a 32 new flag in the Router Solicitations. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 30, 2015. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Goals and Requirements . . . . . . . . . . . . . . . . . . . . 5 69 3. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 5 70 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 71 5. New Neighbor Discovery Flags and Options . . . . . . . . . . . 6 72 5.1. Introducing a Router Solicitation Flag . . . . . . . . . . 6 73 5.2. Refresh Time option . . . . . . . . . . . . . . . . . . . 6 74 6. Conceptual Data Structures . . . . . . . . . . . . . . . . . . 7 75 7. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 76 7.1. Sleep and Wakeup . . . . . . . . . . . . . . . . . . . . . 8 77 7.2. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 8. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 79 8.1. Router and/or Interface Initialization . . . . . . . . . . 9 80 8.2. Periodic Multicast RA for unmodified hosts . . . . . . . . 9 81 8.3. Unsolicited RAs to share new information . . . . . . . . . 9 82 9. Router Advertisement Consistency . . . . . . . . . . . . . . . 10 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 85 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 86 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 14.1. Normative References . . . . . . . . . . . . . . . . . . . 11 89 14.2. Informative References . . . . . . . . . . . . . . . . . . 11 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 92 1. Introduction 94 IPv6 Neighbor Discovery [RFC4861] was defined at a time when local 95 area networks had different properties than today. A common link was 96 the yellow-coax shared wire Ethernet, where a link-layer multicast 97 and unicast worked the same - send the packet on the wire and the 98 interested receivers will pick it up. Thus the network cost 99 (ignoring any processing cost on the receivers that might not 100 completely filter out Ethernet multicast addresses that they did not 101 want) and the reliability of sending a link-layer unicast and 102 multicast was the same. Furthermore, the hosts at the time was 103 always on and connected. Powering on and off the workstation/PC 104 hosts at the time was slow and disruptive process. 106 Under the above assumptions it was quite efficient to maintain the 107 shared state of the link such as the prefixes and their lifetimes 108 using periodic multicast Router Advertisement messages. It was also 109 efficient to use multicast Neighbor Solicitations for address 110 resolution as a slight improvement over the broadcast use in ARP. 111 And finally, checking for a potential duplicate IPv6 address using 112 multicast was efficient and natural. 114 There are still links, such a satellite links, where periodic 115 multicast advertisements is the most efficient and reliable approach 116 to keep the hosts up to date. However other links have different 117 performance and reliability for multicast than for unicast (see for 118 instance [I-D.vyncke-6man-mcast-not-efficient] which discusses WiFi 119 links). Cellular networks which employ paging and support sleeping 120 hosts have different issues (see e.g., 121 [I-D.garneij-6man-nd-m2m-issues] that would benefit from having the 122 hosts wake up and request information from the routers instead of the 123 routers periodically multicasting the information. 125 Since different links types and deployments have different needs, 126 this specification provides mechanism by which the routers can 127 determine whether all the hosts support the RS refresh, and the hosts 128 only employ the RS refresh when instructed by the routers using an 129 option in the Router Advertisement. 131 The operator retains the option to use unsolicited multicast Router 132 Advertisement to announce new or removed information. That can be 133 useful for uncommon cases while allowing using a higher refresh time 134 for normal network operations. 136 The specification does not assume that all hosts on the link 137 implement the new capability. As soon as there are router(s) on a 138 link which supports these optimizations, then the updated hosts on 139 the link can sleep better, while co-existing on the same link with 140 unmodified hosts. 142 2. Goals and Requirements 144 The key goal is to allow the operator to choose whether unicast RS 145 refresh is more efficient than periodic multicast RAs, while 146 preserving the timely and scalable reconfiguration capabilities that 147 a periodic RA model provides. 149 In addition, an operator might want to be notified whether the link 150 includes hosts that do not support the new mechanism. Potential 151 router implementations can react dynamically to that information, or 152 can log events to system management when hosts appear which do not 153 implement this new capability. 155 The assumption is that host which implement this specification also 156 implement [I-D.ietf-6man-resilient-rs] as that ensures resiliency to 157 packet loss at host initialization. 159 3. Definition Of Terms 161 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in [RFC2119]. 165 4. Protocol Overview 167 The hosts include a new flag in the Router Solicitation message, 168 which allows the routers to report to system management whether there 169 are hosts that do not support the RS refresh on the link. 171 If the network administrator has configured the routers to send the 172 new Refresh Timer option, then the option will be included in all the 173 Router Advertisements. This option includes the time interval when 174 the hosts should unicast Router Solicitations. 176 The host maintains the value of the Refresh Timer option (RTO) by 177 recording it in the default router list. A value of zero can be used 178 to indicate that a router did not include a Refresh Timer option. 180 The host calculates a timeout after it has received a RTO - either 181 per router or per link. If it is maintained per link then the host 182 SHOULD use the minimum Refresh Timer it has received from the routers 183 on the link. The timeout is a random value uniformly distributed 184 between 0.5 and 1.5 times the Refresh Timer value (in order to avoid 185 synchronization of the timers across hosts. [TBD: Add SYNC reference 186 from RFC 4861.] When this timer fires the host sends one unicast 187 Router Solicitation to the router (if maintained per router) or to 188 all the routers in the default router list for link (if maintained 189 per link.) 191 5. New Neighbor Discovery Flags and Options 193 This specification introduces a option used in the RAs which both 194 indicates that the router can handle RS refresh using unicast RA, and 195 a flag for the RS that indicates to the router that the host will do 196 RS refresh if the router so wishes. 198 5.1. Introducing a Router Solicitation Flag 200 A node which implements this specification sets the R flag in all the 201 Router Solicitation messages it sends. That allows the router to 202 determine whether there are legacy hosts on the link. 204 0 1 2 3 205 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Type | Code | Checksum | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 |R| Reserved | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 New fields: 214 R-flag: When set indicates that the sending node is capable of 215 doing unicast RS refresh. 217 Reserved: Field is reduced from 32 bits to 31 bits. It MUST be 218 initialized to zero by the sender and MUST be ignored 219 by the receiver. 221 5.2. Refresh Time option 223 A router which implements this specification can be configured to 224 operate without periodic multicast Router Advertisements. When the 225 operator configures this mode of operation, then the router MUST 226 include this new option in the RA. 228 0 1 2 3 229 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Type | Length=1 | Refresh Time | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Reserved | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 Fields: 238 Type: TBD ND option code value (IANA) 240 Length: 8-bit unsigned integer. The length of the option 241 (including the type and length fields) in units of 8 242 bytes. The value 0 is invalid. Value is 1 for this 243 option. 245 Refresh Time: 16-bit unsigned integer. Units is seconds. The all- 246 ones value (65535) means infinite. 248 Reserved: 32 bits. This field is unused. It MUST be 249 initialized to zero by the sender and MUST be ignored 250 by the receiver. 252 6. Conceptual Data Structures 254 In addition to the Conceptual Data structures in [RFC4861] a host 255 records the received RTO value in the default router list. It also 256 maintains a timeout - either per link or per default router. 258 7. Host Behavior 260 See Protocol Overview section above. 262 A host implementing this specification SHOULD also implement 263 [I-D.ietf-6man-resilient-rs]. That ensures that a router that has 264 been configured to not send periodic RA messages will always receive 265 an RS from the host as the host initializes. 267 If there is no RTO in the received Router Advertisements, then the 268 host behavior does not change. However, if RTOs start appearing in 269 RAs after the initial RAs, the host SHOULD start performing RS 270 refresh. As the last router that included RTO options time out from 271 the default router list, the host SHOULD stop sending RS refresh 272 messages. 274 The host MUST join the all-nodes multicast address as in [RFC4861] 275 since the routers MAY send multicast RAs for important changes. 277 Some links might have routers with different configuration where some 278 router includes RTO in the RA and others do not. Hosts MAY make the 279 simplifying assumption that if any router on the link includes RTO 280 then the host can use RS refresh to all the routers in the default 281 router list. Also, the routers might advertise different refresh 282 time, and hosts MAY use the minimum of the time received from any 283 router that remains in the default router list. Note that section 284 Section 9 says that routers SHOULD report such inconsistencies to 285 system management. 287 7.1. Sleep and Wakeup 289 The protocol allows the sleepy nodes to complete its sleep schedule 290 without waking up due to multicast Router Advertisement messages and 291 the host is not required to wake up solely for the purposes of 292 performing RS refresh. This assumes that sleepy nodes perform a RS 293 refresh when they wake up. If hosts do wake up due to multicast RAs, 294 then the host only needs to perform a refresh on wakeup if the 295 Refresh timeout has expired while the host was sleeping. 297 7.2. Movement 299 When a host wakes up it can combine movement detecting (DNA), NUD, 300 and refreshing its prefixes etc by sending a unicast RS to each of 301 its existing default router(s). If it receives unicast RA from a 302 router, then it can mark the router as REACHABLE. 304 Note that DNA [RFC6059] specifies using NS messages since many IPv6 305 routers delay (and multicast) solicited RAs and DNA wants to avoid 306 that delay. Routers which implement this specification SHOULD 307 unicast solicited RAs, hence if a router included the RTO then the 308 host can use RS for DNA. For non-RTO routers the host MAY choose to 309 use NS for DNA as in [RFC6059]. 311 8. Router Behavior 313 See Protocol Overview section. 315 A router implementing this specification (and including RTO in the 316 RAs) SHOULD also respond to unicast RS messages (that do not have an 317 unspecified source address) with unicast RAs. If a RS message has an 318 unspecified source address then the host MAY respond with a RA 319 unicast at layer 2 (sent to the link-layer source address of the RS), 320 or it MAY follow the rate-limited multicast RA procedure in 322 [RFC4861]. 324 The RECOMMENDED default configuration for routers is to have RTO 325 disabled. 327 8.1. Router and/or Interface Initialization 329 This specification does not change the initialization procedure. 330 Thus a router multicasts some initial Router Advertisements 331 (MAX_INITIAL_RTR_ADVERTISEMENTS) at system startup or interface 332 initialization as specified in [RFC4861] and its updates. 334 8.2. Periodic Multicast RA for unmodified hosts 336 By default a router MUST send periodic multicast RAs as specified in 337 [RFC4861]. A router can be configured to omit those, which can be 338 used in particular deployments. If they are omitted, then there MUST 339 be a mechanism to prevent or detect the existence of unmodified hosts 340 on the link. That be be performed at deployment time (e.g., only 341 hosts which are known to support RTO are configured with the layer 2 342 security keys), or the routers detect any RSs which do not include 343 the R-flag and report this to system management, or dynamically 344 enable periodic multicast RAs when observing at least one RS without 345 the R-flag. 347 Note that such dynamic detection is not bullet proof. If a host does 348 not implement RS refresh nor implements resilient RS 349 [I-D.ietf-6man-resilient-rs], then the host might receive a multicast 350 RA (from router initialization or the periodic multicast RAs) without 351 the router ever receiving a RS from the host. Such a host would 352 function as long as the routers are sending periodic multicast RAs. 354 8.3. Unsolicited RAs to share new information 356 When a router has new information to share (new prefixes, prefixes 357 that should be immediately deprecated, etc) it MAY multicast up to 358 MAX_INITIAL_RTR_ADVERTISEMENTS number of Router Advertisements. 360 On links where multicast is expensive the router MAY instead unicast 361 up to MAX_INITIAL_RTR_ADVERTISEMENTS number of Router Advertisements 362 to the hosts in its neighbor cache. 364 . Note that such new information is not likely to reach sleeping 365 hosts until those hosts refresh by sending a RS. 367 9. Router Advertisement Consistency 369 The routers follows section 6.2.7 in [RFC4861] by receiving RAs from 370 other routers on the link. In addition to the checks in that 371 section, the routers SHOULD verify that the RTO have the same Refresh 372 Time, and report to system management if they differ. While the host 373 will pick the lowest time and operate correctly, it is not useful to 374 use different Refresh Times for different routers. 376 10. Security Considerations 378 These optimizations are not known to introduce any new threats 379 against Neighbor Discovery beyond what is already documented for IPv6 380 [RFC3756]. 382 Section 11.2 of [RFC4861] applies to this document as well. 384 The mechanisms in this document work with SeND [RFC3971]. 386 11. IANA Considerations 388 A new flag (R-flag) in the Router Solicitation message has been 389 introduced by carving out a bit from the Reserved field. There is 390 currently no IANA registry for RS flags. Perhaps one should be 391 created? 393 This document needs a new Neighbor Discovery option type for the RTO. 395 12. Acknowledgements 397 The original idea came up in a discussion with Suresh Krishnan. 398 Comments from Erik Kline and Samita Chakrabarti have helped improve 399 the document. 401 This document has been discussed in the efficient-nd design team. 403 13. Open Issues 405 Should we make the Refresh Time 32 bits instead of 16? 16 bits 406 implies maximum of 18 hours and in some deployments a refresh time 407 measured in days might be desirable. 409 Should we update the DNA procedures [RFC6059]? We can use a 410 unicast RS with this approach since that will result in an 411 immediate unicast RA which would include any updated prefixes. 412 Note that a RS can not have an unspecified source and a SLLAO, 413 hence some care would be needed in the interaction with DAD. 415 Would it be worth-while to try to remove unchanged information 416 from the refreshed RAs? If so it could be done by including some 417 epoch number in the RS and RA, and if the RS contains the current 418 epoch then the RA would not need to include any options except the 419 epoch number indicating that none of the options are the same as 420 before. 422 14. References 424 14.1. Normative References 426 [I-D.ietf-6man-resilient-rs] 427 Krishnan, S., Anipko, D., and D. Thaler, "Packet loss 428 resiliency for Router Solicitations", 429 draft-ietf-6man-resilient-rs-04 (work in progress), 430 October 2014. 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, March 1997. 435 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 436 (IPv6) Specification", RFC 2460, December 1998. 438 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 439 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 440 September 2007. 442 14.2. Informative References 444 [I-D.garneij-6man-nd-m2m-issues] 445 Garneij, F., Chakrabarti, S., and S. Krishnan, "Impact of 446 IPv6 Neighbor Discovery on Cellular M2M Networks", 447 draft-garneij-6man-nd-m2m-issues-00 (work in progress), 448 July 2014. 450 [I-D.vyncke-6man-mcast-not-efficient] 451 Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A. 452 Yourtchenko, "Why Network-Layer Multicast is Not Always 453 Efficient At Datalink Layer", 454 draft-vyncke-6man-mcast-not-efficient-01 (work in 455 progress), February 2014. 457 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 458 Discovery (ND) Trust Models and Threats", RFC 3756, 459 May 2004. 461 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 462 Neighbor Discovery (SEND)", RFC 3971, March 2005. 464 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 465 Detecting Network Attachment in IPv6", RFC 6059, 466 November 2010. 468 Authors' Addresses 470 Erik Nordmark 471 Arista Networks 472 Santa Clara, CA 473 USA 475 Email: nordmark@acm.org 477 Andrew Yourtchenko 478 Cisco 479 7a de Kleetlaan 480 Diegem, 1831 481 Belgium 483 Phone: +32 2 704 5494 484 Email: ayourtch@cisco.com 486 Suresh Krishnan 487 Ericsson 488 8400 Decarie Blvd. 489 Town of Mount Royal, QC 490 Canada 492 Phone: +1 514 345 7900 x42871 493 Email: suresh.krishnan@ericsson.com