idnits 2.17.1 draft-ietf-6man-rs-refresh-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 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. -- The draft header indicates that this document updates RFC6059, 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 == 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 (May 19, 2015) is 3264 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 508, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 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,6059 (if approved) A. Yourtchenko 5 Intended status: Standards Track Cisco 6 Expires: November 20, 2015 S. Krishnan 7 Ericsson 8 May 19, 2015 10 IPv6 Neighbor Discovery Optional RS/RA Refresh 11 draft-ietf-6man-rs-refresh-00 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 Router Solicitations to 26 request refreshed Router Advertisements. This mechanism is enabled 27 by configuring the router to include a new option in the Router 28 Advertisement in order to allow the network administrator to choose 29 host behavior based on whether periodic multicast are more efficient 30 on their link or not. The routers can also tell whether the hosts 31 are capable of the new behavior through a new flag in the Router 32 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 November 20, 2015. 50 Copyright Notice 52 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . 7 74 6. Conceptual Data Structures . . . . . . . . . . . . . . . . . . 7 75 7. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 8 76 7.1. Sleep and Wakeup . . . . . . . . . . . . . . . . . . . . . 9 77 7.2. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 8. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 9 79 8.1. Router and/or Interface Initialization . . . . . . . . . . 10 80 8.2. Periodic Multicast RA for unmodified hosts . . . . . . . . 10 81 8.3. Unsolicited RAs to share new information . . . . . . . . . 10 82 9. Router Advertisement Consistency . . . . . . . . . . . . . . . 11 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 85 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 86 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 15.1. Normative References . . . . . . . . . . . . . . . . . . . 12 90 15.2. Informative References . . . . . . . . . . . . . . . . . . 13 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 93 1. Introduction 95 IPv6 Neighbor Discovery [RFC4861] was defined at a time when local 96 area networks had different properties than today. A common link was 97 the yellow-coax shared wire Ethernet, where a link-layer multicast 98 and unicast worked the same - send the packet on the wire and the 99 interested receivers will pick it up. Thus the network cost 100 (ignoring any processing cost on the receivers that might not 101 completely filter out Ethernet multicast addresses that they did not 102 want) and the reliability of sending a link-layer unicast and 103 multicast was the same. Furthermore, the hosts at the time was 104 always on and connected. Powering on and off the workstation/PC 105 hosts at the time was slow and disruptive process. 107 Under the above assumptions it was quite efficient to maintain the 108 shared state of the link such as the prefixes and their lifetimes 109 using periodic multicast Router Advertisement messages. It was also 110 efficient to use multicast Neighbor Solicitations for address 111 resolution as a slight improvement over the broadcast use in ARP. 112 And finally, checking for a potential duplicate IPv6 address using 113 multicast was efficient and natural. 115 There are still links, such a satellite links, where periodic 116 multicast advertisements is the most efficient and reliable approach 117 to keep the hosts up to date. However other links have different 118 performance and reliability for multicast than for unicast (see for 119 instance [I-D.vyncke-6man-mcast-not-efficient] which discusses WiFi 120 links). On some of those links the performance and reliability is 121 dependent on the direction e.g., with host to network multicast 122 having the same characteristics as unicast, but network to host being 123 different. Cellular networks which employ paging and support 124 sleeping hosts have different issues (see e.g., 125 [I-D.garneij-6man-nd-m2m-issues] that would benefit from having the 126 hosts wake up and request information from the routers instead of the 127 routers periodically multicasting the information. 129 Since different links types and deployments have different needs, 130 this specification provides mechanism by which the routers can 131 determine whether all the hosts support the RS refresh, and the hosts 132 only employ the RS refresh when instructed by the routers using an 133 option in the Router Advertisement. 135 The operator retains the option to use unsolicited multicast Router 136 Advertisement to announce new or removed information. That can be 137 useful for uncommon cases while allowing using a higher refresh time 138 for normal network operations. 140 Hosts that sleep without waking up due to multicast Router 141 Advertisements need to send a RS refresh when they wake up in order 142 to receive configuration changes that took place while the host was 143 sleeping. 145 The specification does not assume that all hosts on the link 146 implement the new capability. As soon as there are router(s) on a 147 link which supports these optimizations, then the updated hosts on 148 the link can sleep better, while co-existing on the same link with 149 unmodified hosts. 151 2. Goals and Requirements 153 The key goal is to allow the operator to choose whether RS refresh is 154 more efficient than periodic multicast RAs, while preserving the 155 timely and scalable reconfiguration capabilities that a periodic RA 156 model provides. 158 The approach should allow for hosts that sleep on a schedule i.e., 159 that do not wake up due to unsolicited RA messages. 161 In general a link can have multiple routers hence the RS messages 162 should be multicast to find new routers. But for networks which do 163 not there operator should be able to choose unicast RS behavior. 165 In addition, an operator might want to be notified whether the link 166 includes hosts that do not support the new mechanism. Potential 167 router implementations can react dynamically to that information, or 168 can log events to system management when hosts appear which do not 169 implement this new capability. 171 The assumption is that host which implement this specification also 172 implement [I-D.ietf-6man-resilient-rs] as that ensures resiliency to 173 packet loss. 175 3. Definition Of Terms 177 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in [RFC2119]. 181 4. Protocol Overview 183 The hosts include a new flag in the Router Solicitation message, 184 which allows the routers to report to system management whether there 185 are hosts that do not support the RS refresh on the link. 187 If the network administrator has configured the routers to send the 188 new Refresh Time option, then the option will be included in all the 189 Router Advertisements. This option includes the time interval when 190 the hosts should send Router Solicitations refresh messages. 192 The host maintains the value of the Refresh Time option (RTO) by 193 recording it in the default router list. A value of zero can be used 194 to indicate that a router did not include a Refresh Time option. 196 The host calculates a timeout after it has received a RTO - either 197 per router or per link. If it is maintained per link then the host 198 SHOULD use the minimum Refresh Time it has received from the routers 199 on the link. The timeout is a random value uniformly distributed 200 between 0.5 and 1.5 times the Refresh Time value (in order to avoid 201 synchronization of the timers across hosts [SYNC].) When this timer 202 fires the host sends one Router Solicitation. 204 5. New Neighbor Discovery Flags and Options 206 This specification introduces a new option used in the RAs which both 207 indicates that the router can handle RS refresh by immediately 208 responding with a unicast RA, and a flag for the RS that indicates to 209 the router that the host will do RS refresh if the router so wishes. 211 5.1. Introducing a Router Solicitation Flag 213 A node which implements this specification sets the R flag in all the 214 Router Solicitation messages it sends. That allows the router to 215 determine whether there are legacy hosts on the link. 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Type | Code | Checksum | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 |R| Reserved | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 New fields: 227 R-flag: When set indicates that the sending node is capable of 228 doing unicast RS refresh. 230 Reserved: Field is reduced from 32 bits to 31 bits. It MUST be 231 initialized to zero by the sender and MUST be ignored 232 by the receiver. 234 5.2. Refresh Time option 236 A router which implements this specification can be configured to 237 instruct hosts to use RS refresh. When the operator configures this 238 mode of operation, then the router MUST include this new option in 239 the RA. If the operator has a single router (or single VRRP router) 240 on the link, then the operator MAY set the Unicast flag in the 241 option. 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Type | Length=1 | Refresh Time | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 |U| Reserved | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Fields: 253 Type: TBD ND option code value (IANA) 255 Length: 8-bit unsigned integer. The length of the option 256 (including the type and length fields) in units of 8 257 bytes. The value 0 is invalid. Value is 1 for this 258 option. 260 Refresh Time: 16-bit unsigned integer. Units is seconds. The value 261 zero is invalid and make the receiver ignore the 262 option. 264 U-flag: 1 bit flag to indicate that the host should unicast 265 the RS refresh. 267 Reserved: 31 bits. This field is unused. It MUST be 268 initialized to zero by the sender and MUST be ignored 269 by the receiver. 271 6. Conceptual Data Structures 273 In addition to the Conceptual Data structures in [RFC4861] a host 274 records the received Refresh Time value and the Unicast flag in the 275 default router list. It also maintains a timeout - either per link 276 or per default router. If the timeout is per link it is set to the 277 minimum of the received Refresh Time values. 279 7. Host Behavior 281 See Protocol Overview section above. 283 A host implementing this specification SHOULD also implement 284 [I-D.ietf-6man-resilient-rs]. That ensures that if there is packet 285 loss and/or the periodic router advertisements are very infrequent, 286 the host will always receive a timely RA as part of its 287 initialization. 289 If there is no RTO in the received Router Advertisements or there is 290 an RTO with a zero Refresh Time, then the host behavior does not 291 change. However, if RTOs start appearing in RAs after the initial 292 RAs, the host SHOULD start performing RS refresh. As the last router 293 that included RTO options time out from the default router list, the 294 host SHOULD stop sending RS refresh messages. 296 The host MUST join the all-nodes multicast address as in [RFC4861] 297 since the routers MAY send multicast RAs for important changes. 299 Some links might have routers with different configuration where some 300 router includes RTO in the RA and others do not. Hosts MAY make the 301 simplifying assumption that if any router on the link includes RTO 302 then the host can use RS refresh to all the routers in the default 303 router list. Also, the routers might advertise different Refresh 304 Time, and hosts MAY use the minimum of the time received from any 305 router that remains in the default router list, or use a separate 306 timer for each router in the default router list. Note that 307 Section 9 says that routers SHOULD report such inconsistencies to 308 system management. 310 A RTO option with a Refresh Time value of zero is silently ignored, 311 that is, the RA is handled the same way as if it did not contain an 312 RTO option. 314 If the U-flag is zero for at least one of the routers in the default 315 router list, then the host will send each refresh RS to the all- 316 routers multicast address. Otherwise the host will unicast the RS 317 refresh to each router in the default router list. The host can 318 either maintain the Refresh Time and Unicast flag per router or per 319 link. If they are maintained per router then the host MUST NOT 320 multicast an RS for every default router list entry but instead 321 multicast once when the minimum (across the default router list for 322 the interface) Refresh Time expires. If they are maintained per 323 link, then the host would determine an effective Unicast bit for the 324 link; set if all the routers which sent RTO set the Unicast bit. 326 If there is no response to a refresh RS, the host follows the same 327 retransmit behavior as in resilient-rs [I-D.ietf-6man-resilient-rs]. 329 7.1. Sleep and Wakeup 331 The protocol allows the sleepy nodes to complete its sleep schedule 332 without waking up due to multicast Router Advertisement messages and 333 the host is not required to wake up solely for the purposes of 334 performing RS refresh. Such a host SHOULD send a RS refresh upon 335 wakeup even if the Refresh Time has not yet expired, in order to 336 receive any updated RA information. 338 Hosts that do wake up due to multicast RAs only needs to perform a 339 refresh on wakeup if the Refresh timeout has expired while the host 340 was sleeping. 342 7.2. Movement 344 When a host wakes up or thinks it might have moved to a different 345 link (new L2 association, lost and required L2 connectivity, etc) it 346 can combine DNA (Detecting Network Attachment - DNA [RFC6059]), NUD, 347 and refreshing its prefixes etc by sending a unicast RS to each of 348 its existing RTO default router(s). If it receives unicast RA from a 349 router, then it can mark the router as REACHABLE. 351 Note that DNA specifies using NS messages since many IPv6 routers 352 delay (and multicast) solicited RAs and DNA wants to avoid that 353 delay. Routers which implement this specification and send RTO 354 SHOULD unicast solicited RAs, hence if a router included the RTO then 355 the host can use RS for DNA without incurring additional delay. Thus 356 the host would not need to use a unicast NS as part of DNA for RTO 357 routers. For non-RTO routers the host MAY choose to use NS for DNA 358 as in [RFC6059]. 360 8. Router Behavior 362 See Protocol Overview section. 364 A router implementing this specification (and including the RTO in 365 the RAs) SHOULD also respond to unicast RS messages (that do not have 366 an unspecified source address) with unicast RAs. If a RS message has 367 an unspecified source address then the router MAY respond with a RA 368 unicast at layer 2 (sent to the link-layer source address of the RS), 369 or it MAY follow the rate-limited multicast RA procedure in 370 [RFC4861]. 372 The RECOMMENDED default configuration for routers is to have RTO 373 disabled. When RTO is enabled the RECOMMENDED default configuration 374 is to have the Unicast flag disabled. 376 8.1. Router and/or Interface Initialization 378 This specification does not change the initialization procedure. 379 Thus a router multicasts some initial Router Advertisements 380 (MAX_INITIAL_RTR_ADVERTISEMENTS) at system startup or interface 381 initialization as specified in [RFC4861] and its updates. 383 8.2. Periodic Multicast RA for unmodified hosts 385 By default a router MUST send periodic multicast RAs as specified in 386 [RFC4861]. A router can be configured to omit those, which can be 387 used in particular deployments. If they are omitted, then there MUST 388 be a mechanism to prevent or detect the existence of unmodified hosts 389 on the link. That could be performed at deployment time (e.g., only 390 hosts which are known to support RTO are configured with the layer 2 391 security keys), or the routers could either detect any RSs which do 392 not include the R-flag and report this to system management or 393 dynamically enable periodic multicast RAs when observing at least one 394 RS without the R-flag. 396 Note that such dynamic detection of "legacy" hosts is not bullet 397 proof, in particular when there is packet loss on the link. If a 398 host does not implement resilient RS [I-D.ietf-6man-resilient-rs], 399 then the host might receive a multicast RA (from router 400 initialization or the periodic multicast RAs) without the router ever 401 receiving a RS from the host. Such a host would function as long as 402 the routers are sending periodic multicast RAs. However, hosts 403 without resilent RS do not operate well in the presence of packet 404 loss. They might be without service (no default router and no 405 prefixes) for one or more multiples of the RA advertisement interval 406 (MaxRtrAdvInterval), which currently can be as high as 30 minutes. 408 8.3. Unsolicited RAs to share new information 410 When a router has new information to share (new prefixes, prefixes 411 that should be immediately deprecated, etc) it MAY multicast up to 412 MAX_INITIAL_RTR_ADVERTISEMENTS number of Router Advertisements. 414 On links where multicast is expensive the router MAY instead unicast 415 up to MAX_INITIAL_RTR_ADVERTISEMENTS number of Router Advertisements 416 to the hosts in its neighbor cache. 418 Note that such new information is not likely to reach hosts sleeping 419 on a schedule until those hosts refresh by sending a RS. However, as 420 such hosts are recommended to send a RS refresh when they wake up, 421 they will receive the updated information and not use the potentially 422 stale information to send packets. 424 9. Router Advertisement Consistency 426 The routers follows section 6.2.7 in [RFC4861] by receiving RAs from 427 other routers on the link. In addition to the checks in that 428 section, the routers SHOULD verify that the RTO have the same Refresh 429 Time, and report to system management if they differ. While the host 430 will pick the lowest time and operate correctly, it is not useful to 431 use different Refresh Times for different routers. 433 10. Security Considerations 435 These optimizations are not known to introduce any new threats 436 against Neighbor Discovery beyond what is already documented for IPv6 437 [RFC3756]. 439 Section 11.2 of [RFC4861] applies to this document as well. 441 The mechanisms in this document work with SeND [RFC3971]. 443 11. IANA Considerations 445 A new flag (R-flag) in the Router Solicitation message has been 446 introduced by carving out a bit from the Reserved field. There is 447 currently no IANA registry for RS flags. Perhaps one should be 448 created? 450 This document needs a new Neighbor Discovery option type for the RTO. 452 12. Acknowledgements 454 The original idea came up in a discussion with Suresh Krishnan. 455 Comments from Samita Chakrabarti, Lorenzo Colitti, and Erik Kline 456 have helped improve the document. 458 This document has been discussed in the efficient-nd design team. 460 13. Open Issues 462 Should we remove the notion of not sending any periodic RAs and 463 the associated detection of "legacy" hosts in Section 8.2? Would 464 periodic RAs every 30 minutes place too much load on the network 465 even if the hosts on a sleep schedule do not wake up? 467 Would it be worth-while to try to remove unchanged information 468 from the refreshed RAs? If so it could be done by including some 469 epoch number in the RS and RA, and if the RS contains the current 470 epoch then the RA would not need to include any options except the 471 epoch number indicating that none of the options are the same as 472 before. This is difficult with multicast RS refresh... 474 14. Change Log 476 Changes since draft-nordmark-6man-rs-refresh-01 of the draft: 478 o Made Refresh Time zero be reserved and RTOs with this value 479 ignored by the receiver. 481 o Removed notion that all-ones refresh time means infinite lifetime. 482 It now means 65535 seconds. 484 o Changed default to be multicast RS refresh, with the option to 485 specify unicast in the RTO. This enables discovering new routers 486 on the link. 488 o Clarified the normative behavior for hosts that sleep on a 489 schedule. 491 o Clarified the updated DNA behavior. 493 o Editorial fixes. 495 15. References 497 15.1. Normative References 499 [I-D.ietf-6man-resilient-rs] 500 Krishnan, S., Anipko, D., and D. Thaler, "Packet loss 501 resiliency for Router Solicitations", 502 draft-ietf-6man-resilient-rs-06 (work in progress), 503 April 2015. 505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 506 Requirement Levels", BCP 14, RFC 2119, March 1997. 508 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 509 (IPv6) Specification", RFC 2460, December 1998. 511 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 512 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 513 September 2007. 515 15.2. Informative References 517 [I-D.garneij-6man-nd-m2m-issues] 518 Garneij, F., Chakrabarti, S., and S. Krishnan, "Impact of 519 IPv6 Neighbor Discovery on Cellular M2M Networks", 520 draft-garneij-6man-nd-m2m-issues-00 (work in progress), 521 July 2014. 523 [I-D.vyncke-6man-mcast-not-efficient] 524 Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A. 525 Yourtchenko, "Why Network-Layer Multicast is Not Always 526 Efficient At Datalink Layer", 527 draft-vyncke-6man-mcast-not-efficient-01 (work in 528 progress), February 2014. 530 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 531 Discovery (ND) Trust Models and Threats", RFC 3756, 532 May 2004. 534 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 535 Neighbor Discovery (SEND)", RFC 3971, March 2005. 537 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 538 Detecting Network Attachment in IPv6", RFC 6059, 539 November 2010. 541 [SYNC] Floyd, S. and V. Jacobson, "The Synchronization of 542 Periodic Routing Messages", IEEE/ACM Transactions on 543 Networking , April 1994, 544 . 546 Authors' Addresses 548 Erik Nordmark 549 Arista Networks 550 Santa Clara, CA 551 USA 553 Email: nordmark@acm.org 554 Andrew Yourtchenko 555 Cisco 556 7a de Kleetlaan 557 Diegem, 1831 558 Belgium 560 Phone: +32 2 704 5494 561 Email: ayourtch@cisco.com 563 Suresh Krishnan 564 Ericsson 565 8400 Decarie Blvd. 566 Town of Mount Royal, QC 567 Canada 569 Phone: +1 514 345 7900 x42871 570 Email: suresh.krishnan@ericsson.com