idnits 2.17.1 draft-chakrabarti-nordmark-6man-efficient-nd-07.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 (February 27, 2015) is 3346 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) == Missing Reference: 'SLLAO' is mentioned on line 1215, but not defined == Unused Reference: 'RFC4941' is defined on line 1524, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-6man-resilient-rs-04 == Outdated reference: A later version (-16) exists of draft-ietf-6man-default-iids-02 == Outdated reference: A later version (-01) exists of draft-yourtchenko-6man-dad-issues-00 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man WG S. Chakrabarti 3 Internet-Draft Ericsson 4 Updates: 4861 (if approved) E. Nordmark 5 Intended status: Standards Track Arista Networks 6 Expires: August 31, 2015 P. Thubert 7 Cisco Systems 8 M. Wasserman 9 Painless Security 10 February 27, 2015 12 IPv6 Neighbor Discovery Optimizations for Wired and Wireless Networks 13 draft-chakrabarti-nordmark-6man-efficient-nd-07 15 Abstract 17 IPv6 Neighbor Discovery (RFC 4861 going back to RFC 1970) was defined 18 at a time when link-local multicast was as reliable and with the same 19 network cost (send a packet on a yellow-coax Ethernet) as unicast and 20 where the hosts were assumed to be always on and connected. 22 Since 1996 we've seen a significant change with both an introduction 23 of wireless networks and battery operated devices, which poses 24 significant challenges for the old assumptions. We are also seeing 25 datacenter networks where virtual machines are not always on and 26 connected, and scaling of multicast can be challenging. 28 This specification contains extensions to IPv6 Neighbor Discovery 29 which remove most use of multicast and make sleeping hosts more 30 efficient. The specification includes a default mixed mode where a 31 link can have an arbitrary mix of hosts and/or routers - some 32 implementing legacy Neighbor Discovery and some implementing the 33 optimizations in this specification. The optimizations provide 34 incremental benefits to hosts as soon as the first updated routers 35 are deployed on a link. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on August 31, 2015. 54 Copyright Notice 56 Copyright (c) 2015 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2. Goals and Requirements . . . . . . . . . . . . . . . . . . . . 6 73 2.1. Mixed-Mode Operations . . . . . . . . . . . . . . . . . . 7 74 3. Changes to ND state management . . . . . . . . . . . . . . . . 7 75 4. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 8 76 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 77 5.1. Proxying to handle Mixed mode . . . . . . . . . . . . . . 11 78 6. New Neighbor Discovery Options and Messages . . . . . . . . . 11 79 6.1. Router Advertisement flag for NEARs . . . . . . . . . . . 11 80 6.2. Address Registration Option (ARO) . . . . . . . . . . . . 12 81 6.3. Registrar Address Option (RAO) . . . . . . . . . . . . . . 14 82 7. Conceptual Data Structures . . . . . . . . . . . . . . . . . . 15 83 8. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 16 84 8.1. Host and/or Interface Initialization . . . . . . . . . . . 16 85 8.2. Host Receiving Router Advertisements . . . . . . . . . . . 16 86 8.3. Timing out Registrar List entries . . . . . . . . . . . . 17 87 8.4. Sending AROs . . . . . . . . . . . . . . . . . . . . . . . 17 88 8.5. Receiving Neighbor Advertisements . . . . . . . . . . . . 18 89 8.6. Host Management of the TID . . . . . . . . . . . . . . . . 18 90 8.7. Refreshing a Registration . . . . . . . . . . . . . . . . 18 91 8.8. De-registering . . . . . . . . . . . . . . . . . . . . . . 19 92 8.9. Refreshing RA information . . . . . . . . . . . . . . . . 19 93 8.10. Sleep and Wakeup . . . . . . . . . . . . . . . . . . . . . 21 94 8.11. Receiving Redirects . . . . . . . . . . . . . . . . . . . 21 95 8.12. Movement Detection . . . . . . . . . . . . . . . . . . . . 21 96 9. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 21 97 9.1. Router and/or Interface Initialization . . . . . . . . . . 22 98 9.2. Receiving Router Solicitations . . . . . . . . . . . . . . 22 99 9.3. Periodic Multicast RA for legacy hosts . . . . . . . . . . 23 100 9.4. Multicast RA when new information . . . . . . . . . . . . 23 101 9.5. Receiving ARO . . . . . . . . . . . . . . . . . . . . . . 23 102 9.6. NCE Management in NEARs . . . . . . . . . . . . . . . . . 23 103 9.7. Sending non-zero status in ARO . . . . . . . . . . . . . . 24 104 9.8. Timing out Registered NCEs . . . . . . . . . . . . . . . . 24 105 9.9. Router Advertisement Consistency . . . . . . . . . . . . . 25 106 9.10. Sending Redirects . . . . . . . . . . . . . . . . . . . . 25 107 9.11. Providing Information to Routing Protocols . . . . . . . . 25 108 9.12. Creating Legacy NCEs . . . . . . . . . . . . . . . . . . . 25 109 9.13. Proxy Address Resolution and DAD for Legacy Hosts . . . . 25 110 10. Handling ND DoS Attack . . . . . . . . . . . . . . . . . . . . 26 111 11. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 27 112 12. Interaction with other protocols . . . . . . . . . . . . . . . 28 113 12.1. Detecting Network Attachment (DNA) . . . . . . . . . . . . 28 114 12.2. DHCPv6 Interaction . . . . . . . . . . . . . . . . . . . . 28 115 12.3. Other use of Multicast . . . . . . . . . . . . . . . . . . 29 116 12.4. VRRP Interaction . . . . . . . . . . . . . . . . . . . . . 29 118 13. Updated Neighbor Discovery Constants . . . . . . . . . . . . . 29 119 14. Security Considerations . . . . . . . . . . . . . . . . . . . 30 120 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 121 16. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 30 122 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 123 18. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 32 124 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 125 19.1. Normative References . . . . . . . . . . . . . . . . . . . 33 126 19.2. Informative References . . . . . . . . . . . . . . . . . . 33 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 129 1. Introduction 131 IPv6 Neighbor Discovery [RFC4861] was defined at a time when local 132 area networks had different properties than today. A common link was 133 the yellow-coax shared wire Ethernet, where a link-layer multicast 134 and unicast worked the same - send the packet on the wire and the 135 interested receivers will pick it up. Thus the network cost 136 (ignoring any processing cost on the receivers that might not 137 completely filter out Ethernet multicast addresses that they did not 138 want) and the reliability of sending a link-layer unicast and 139 multicast was the same. Furthermore, the hosts at the time was 140 always on and connected. Powering on and off the workstation/PC 141 hosts at the time was slow and disruptive process. 143 Under the above assumptions it was quite efficient to maintain the 144 shared state of the link such as the prefixes and their lifetimes 145 using periodic multicast Router Advertisement messages. It was also 146 efficient to use multicast Neighbor Solicitations for address 147 resolution as a slight improvement over the broadcast use in ARP. 148 And finally, checking for a potential duplicate IPv6 address using 149 broadcast was efficient and believed to be likely to be robust. 151 Since then we've seen a tremendous change with the wide-spread 152 deployment of WiFi and other wireless network technologies. WiFi is 153 a case in point in that it provides the same network service 154 abstraction as Ethernet and is often bridged with Ethernets, meaning 155 that the Neighbor Discovery software on hosts and routers might be 156 unaware that WiFi is being used. Yet the performance and reliability 157 of multicast is quite different than for unicast on WiFi (see for 158 instance [I-D.vyncke-6man-mcast-not-efficient]). Similarly 3GPP and 159 M2M networks and devices will benefit from a standard specification 160 for optimized Neighbor discovery. Even wired networks have evolved 161 substantially with modern switch fabrics using explicit packet 162 replication logic to handle multicast packets. 164 The assumptions about the reliability of a single multicast message 165 for duplicate address detection has also shown to be not correct, due 166 to a set of issues listed in [I-D.yourtchenko-6man-dad-issues]. 168 The hosts and usage patterns has undergone radical changes as well. 169 Hosts go to sleep when not in use to save on battery power [RFC6574] 170 or to be more energy efficient even with mains power. The 171 expectation is that waking up doesn't take much time and power 172 otherwise the benefits of sleeping are greatly reduced. Initially 173 sleeping hosts were esoteric sensor nodes, but this sleeping hosts 174 have become mainstream in smartphones. 176 Some of the above trends were observed early (e.g., Ohta-san 177 commented on Neighbor Discovery being inefficient on WiFi a long time 178 back) but the issues were not broadly understood. The issues were 179 raised in the 6LowPAN context where the desire was to run IPv6 over 180 low-power radio networks and battery operated devices. That lead to 181 defining a set of optimizations [RFC6775] for that specific category 182 of links. However, the trends are not limited to such specific link 183 types. 185 This document applies what we have learned from 6LowPAN to all link 186 types. That includes reusing existing support from base Neighbor 187 Discovery (such as Redirect messages) and reusing from 6LowPAN-ND 188 (Address Registration Option). There are additions above and beyond 189 that to improve the robustness with redundant routers and to support 190 mixed mode. 192 The optimizations are done in a way to provide incremental benefits. 193 As soon as there is at least one router on a link which supports 194 these optimizations, then the updated hosts on the link can sleep 195 better, while co-existing on the same link with unmodified hosts. 197 2. Goals and Requirements 199 The goal is to remove as much Neighbor Discovery multicast traffic on 200 the link as possible, and handle Duplicate Address Detection (DAD) 201 without requiring the hosts to always be awake. While not an 202 explicit goal, it turned out that the issues in 203 [I-D.yourtchenko-6man-dad-issues] that are about robustness/ 204 correctness are also addressed as a side effect of supporting sleepy 205 hosts. 207 The optimization will be highly effective for links and nodes which 208 do not support multicast and for multicast networks without MLD 209 snooping switches. Moreover, in the MLD-snooping networks the MLD 210 switches will deal with less number of multicasts. 212 The requirements handle are: 214 Remove the use of multicast for DAD and Address Resolution (no 215 multicast NS messages), and remove periodic multicast RAs. Some 216 multicast RS and RA are needed to handle the arrival of new hosts 217 and routers on the link since they need to bootstrap to find each 218 other. 220 Remove the need for hosts to always be awake to defend their 221 addresses by responding to any DAD probes. 223 Ensure that the protocol is robust against single points of 224 failure and uses soft state which is automatically rebuilt after a 225 state loss. 227 A router which does not support legacy hosts will always maintain 228 a complete set of Neighbor Cache Entries (NCEs) for all hosts on 229 the link. Hence there is no need for it to send Neighbor 230 Solicitations. Thus it can avoid the problem specified in 231 [RFC6583]. 233 The optimized solution SHOULD be independent of the addresses 234 allocation mechanism. In addition to supporting SLAAC [RFC4862] 235 and DHCPv6 [RFC3315] it SHOULD also work with hosts with 'Privacy 236 Extensions for Stateless Address Autoconfiguration in 237 IPv6'[RFC4941] and with stable IPv6 private addresses 238 [I-D.ietf-6man-stable-privacy-addresses] thus it handles the 239 recommendations in [I-D.ietf-6man-default-iids]. 241 2.1. Mixed-Mode Operations 243 Mixed-Mode operation is the protocol behavior when the IPv6 subnet is 244 composed of legacy IPv6 Neighbor Discovery compliant nodes and 245 efficiency-aware IPv6 nodes implementing this specification. 247 The mixed-mode model SHOULD support arbitrary combinations of legacy 248 [RFC4861] hosts and/or routers with new hosts and/or routers on a 249 link. The introduction of one new router SHOULD provide improved 250 services to a new host, allowing the new host to avoid multicast and 251 not requiring the host to be awake to defend its IPv6 addresses using 252 DAD. 254 This document assumes that an implementation will have configuration 255 knobs to determine whether it is running in legacy IPv6 ND [RFC4861] 256 or Efficiency Aware only mode (no-legacy mode) or both (Mixed mode). 258 3. Changes to ND state management 260 These optimizations change some fundamental aspects of Neighbor 261 Discovery. Firstly, it moves the distributed address resolution 262 state (each node responding to a multicast NS for its own addresses) 263 to a set of routers which maintain a list of Address Registrations 264 for the hosts. Secondly, the information distributed in Router 265 Advertisements changes from being periodically flooded by the routers 266 to explicit requests from the hosts for refreshed information using 267 unicast Router Solicitations. 269 4. Definition Of Terms 271 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 272 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 273 document are to be interpreted as described in [RFC2119]. 275 IPv6 ND-efficiency-aware Router (NEAR): 276 A router that implements the optimizations specified in this 277 document. This router should be able to handle both legacy IPv6 278 nodes and nodes that sends registration request. 280 Efficiency-Aware Host (EAH): 281 The EAH is the host which implements the host functionality for 282 optimized Neighbor Discovery mentioned in this document. At least 283 initially implementations are likely to have a fallback to legacy 284 Neighbor Discovery when no NEAR is on the link. 286 Legacy IPv6 Host: 287 A IPv6 host that implements [RFC4861] without the extensions in 288 this document. 290 Legacy IPv6 Router: 291 A IPv6 router that implements [RFC4861] without the extensions in 292 this document. 294 Mixed mode 295 A NEAR supports both legacy hosts and EAH, with a configuration 296 knob to disable the support for legacy hosts. Some routers on the 297 link can be legacy and some can be NEAR. 299 No-legacy mode 300 A mode configured on a NEAR to not support any legacy [RFC4861] 301 hosts or routers. Opposite of mixed mode. 303 IPv6 Address Registrar 304 Normally the default router(s) on the link will act as IPv6 305 Address Registrars tracking all the EAHs. But in some cases it is 306 more efficient to use a different set of routers as Address 307 Registrars. The hosts are informed of the address registrars 308 using router advertisement messages, and register with the 309 available registrars. 311 EUI-64: 312 It is the IEEE defined 64-bit extended unique identifier formed by 313 concatenation of 24-bit or 36-bit company id value by IEEE 314 Registration Authority and the extension identifier within that 315 company-id assignment. The extension identifiers are 40-bit (for 316 24-bit company-id) or 28-bit (for the 36-bit company-id) 317 respectively. The protocol supports EUI-64 for compatibility with 318 [RFC6775]. 320 DUID 321 It is a DHCP Unique ID of a device [RFC3315]. The DUID is assumed 322 to be stable in a given IPv6 subnet. A device which does not have 323 an EUI-64 can form and use a DUID in its address registrations. 325 NCE 326 Neighbor Cache Entry. It is a conceptual data structure 327 introduced in section 5.1 of [RFC4861] and further elaborated in 328 [RFC6775]. 330 TID 331 The Transaction ID is a device generated sequence number used for 332 registration. This number is used to allow a host to have 333 concurrent registrations with different routers, while also being 334 able to robustly replace a registration with a new one. It 335 facilitates interoperability with protocols like RPL [RFC6550] 336 which use a TID internally to handle host movement. 338 5. Protocol Overview 340 In a nutshell, the following basic optimizations are made from the 341 original IPv6 Neighbor Discovery protocol [RFC4861]: 343 o Adds Node Registration with the default router(s). 345 o Address Resolution and DAD uses the registered addresses instead 346 of multicast Neighbor Solicitation messages for non-link-local 347 IPv6 addresses. 349 o Does not require unsolicited periodic Router Advertisements. 351 o Supports mixed-mode operation where legacy IPv6 hosts and routers 352 and NEARs and EAHs can co-exist on the same link. This support 353 can be configured off. 355 When a host powers on it behaves conforms to legacy ND [RFC4861] by 356 multicasting up to MAX_RTR_SOLICITATIONS Router Solicitations and 357 receives Router Advertisements. The additional information in the 358 Router Advertisements by the NEARs is used by the EAH to build a list 359 of IPv6 Address Registrars. As the host is forming its IPv6 360 addresses (using any of the many stateless and stateful IPv6 address 361 allocation mechanism) then, instead of using a multicast DAD message, 362 it unicasts an Neighbor Solicitation with the new Address 363 Registration Option (ARO) to the Registrars. Assuming an IPv6 364 addresses are not duplicate the EAH receives a Neighbor Advertisement 365 with the ARO option from the NEARs. The EAH refreshes the registered 366 addresses before they expire, thereby removing the need for the EAH 367 to be awake to defend its addresses using DAD as specified in 368 [RFC4862] as the NEARs will handle DAD. 370 The routers on the link advertise the prefixes without setting the L 371 flag. Thus only the IPv6 link-local addresses are considered on- 372 link. Thus the hosts will send packets to a default router, and the 373 default routers maintain all the registrations. Hence a router will 374 know the link-layer addresses of all the registered hosts. This 375 enables the router to forward the packet (without needing any Address 376 Resolution with the multicast Neighbor Solicitation), and also to 377 send a Redirect to the originating host informing the host of the 378 link-layer address. 380 Instead of relying on periodic multicast RAs to refresh the lifetimes 381 of prefixes etc., the hosts ask for refreshed information by 382 unicasting a Router Solicitation before the information expires. 383 Note that [I-D.nordmark-6man-rs-refresh] make that behavior more 384 explicit by having the routers advertise a timeout. 386 The periodic multicast RAs may be used to provide new information 387 such as additional prefixes, radical reduction in the preferred 388 and/or valid lifetime for a prefix. A host does not know to ask for 389 such information. Thus a router that wishes to quickly disseminate 390 such change can resort to a few multicast RAs, or wait for the hosts 391 to request a refresh using a Router Solicitation. 393 The routers can crash and loose all their state, including the 394 Address Registrations. On router initialization the router will 395 multicast a few initial RAs. The protocol has a Router Epoch 396 mechanism which is used by the hosts to detect that the router has 397 lost state. In that case the hosts will immediately re-register 398 allowing the router to quickly rebuild its Address Registration 399 state. 401 Normally it is sufficient for the hosts to register with all the 402 default routers on the link. However, in some cases such as 403 simplistic VRRP deployment the hosts should register with all the 404 VRRP routers even though they only know of one virtual router IPv6 405 address. And in other cases it would be more efficient to only 406 register with one router even though there are multiple default 407 routers. The RAs can contain a Registrar Address Option to 408 explicitly tell the hosts where to register. 410 Sleepy hosts are supported by this Neighbor Discovery procedures as 411 they are not woken up periodically by Router Advertisement multicast 412 messages or Neighbor Solicitation multicast messages. Sleepy nodes 413 may wake up in its own schedule and send unicast registration refresh 414 messages before the registration lifetime expiration. The 415 recommended procedure on wakeup is to unicast a Neighbor Solicitation 416 to the default router(s), which serves as DNA check [RFC6059] that 417 the host is on the same link, performs NUD against the router, and 418 includes the Address Registration Option to refresh the registration. 420 5.1. Proxying to handle Mixed mode 422 When there are one or more legacy routers on the link then the 423 recommendation is to configure those to advertise the prefixes with 424 L=0 just as the NEARs. That results in the hosts sending all packets 425 to a default router unless/until they receive a Redirect. However, 426 the legacy routers do not maintain the address registrations. Thus 427 even though all the hosts send the packets to the routers, the legacy 428 routers might in turn need to perform Address Resolution by 429 multicasting a Neighbor Solicitation per [RFC4861]. In addition, 430 legacy hosts and legacy routers will perform DAD as specified in 431 [RFC4862] that is, by sending a multicast NS and waiting for a NS or 432 NA which indicates a conflict. A EAH will not receive and respond to 433 such messages. 435 If the NEARs have been configured to operate in mixed-mode, then they 436 will respond to multicast NS messages from legacy nodes for both DAD 437 and Address Resolution. They will respond with the Target Link Layer 438 Address being that of the registered host, so that subsequent 439 communication will not go via the routers. (Implementations of 440 "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] might proxy using 441 their own MAC address as TLLA, but that is outside of the scope of 442 this document.) 444 6. New Neighbor Discovery Options and Messages 446 This specification introduces a new flag in the RAs, reuses and 447 extends the ARO option from [RFC6775] and introduces a new Registrar 448 Address option. 450 6.1. Router Advertisement flag for NEARs 452 A new Router Advertisement flag is needed in order to distinguish a 453 router advertisement sent by a NEAR, which will trigger an EAH to 454 register with the NEAR. This flag is ignored by the legacy IPv6 455 hosts. 457 The current flags field in RA is reproduced here with the added 'E' 458 bit. 460 0 1 2 3 4 5 6 7 461 +-+-+-+-+-+-+-+-+ 462 |M|O|H|Prf|P|E|R| 463 +-+-+-+-+-+-+-+-+ 465 The 'E' bit is set to 1 in a RA sent by a NEAR. In all other cases 466 the E bit MUST be 0. 468 6.2. Address Registration Option (ARO) 470 The Address Registration Option was defined in [RFC6775] for the 471 purposes of 6LowPAN and this document extends it in a backwards 472 compatible way by using some of the reserved fields. The extensions 473 are to handle different unique identifiers than EUI-64 (this document 474 specifies how to use DHCP Unique Identifiers with the ability do use 475 other identifier namespaces in the future) and a Transaction Id. 477 The Unique Interface Identifier is used by the NEARs to distinguish 478 between a refresh of an existing registration and a different host 479 trying to register an IPv6 address which is already registered by 480 some other host. Thus the requirement is that the unique id is 481 unique per link, but due to the potential for host mobility across 482 links and subnets it should be globally unique. Both an EUI-64 and a 483 DUID satisfies that requirement. 485 The TID is used by the NEARs to handle the case when due to packet 486 loss one NEAR might have a old registration and another NEAR has a 487 newer registration. The TID allows them to determine which is more 488 recent. The TID also facilitates the interaction with RPL [RFC6550]. 490 An Address Registration Option can be included in unicast Neighbor 491 Solicitation (NS) messages sent by hosts. Thus it can be included in 492 the unicast NS messages that a host sends as part of Neighbor 493 Unreachability Detection to determine that it can still reach the 494 default router(s). The ARO is used by the receiving router to 495 reliably maintain its Neighbor Cache. The same option is included in 496 corresponding Neighbor Advertisement (NA) messages with a Status 497 field indicating the success or failure of the registration. 499 When the ARO is sent by a host then, for links which have link-layer 500 addresses, a SLLA option MUST be included. The address that is 501 registered is the IPv6 source address of the Neighbor Solicitation 502 message. Typically a host would have several addresses to register, 503 with each one being registered using a separate NS containing an ARO. 504 (This approach facilitates applying SeND [RFC3971].) 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Type | Length | Status | Reserved | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Res | IDS |T| TID | Registration Lifetime | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | | 513 ~ Unique Interface Identifier (variable length) ~ 514 | | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 Fields: 519 Type: 33 [RFC6775] 521 Length: 8-bit unsigned integer. The length of the option 522 (including the type and length fields) in units of 8 523 bytes. The value 0 is invalid. 525 Status: 8-bit unsigned integer. Indicates the status of a 526 registration in the NA response. MUST be set to 0 in 527 NS messages. See [RFC6775]. 529 Reserved: 8 bits. This field is unused. It MUST be initialized 530 to zero by the sender and MUST be ignored by the 531 receiver. 533 Res: 4 bits. This field is unused. It MUST be initialized 534 to zero by the sender and MUST be ignored by the 535 receiver. 537 IDS: 3 bits. Identifier name Space. Indicates whether the 538 Unique Interface Identifier is a DUID or or a IEEE 539 assigned EUI-64 with room to define additional name 540 spaces. 542 T bit: One bit flag. Set if the TID octet is valid. 544 TID: 8-bit integer. It is a transaction id maintained by 545 the host and used by the NEARs to determine the most 546 recent registration. 548 Registration Lifetime: 16-bit unsigned integer. The amount of time 549 in a unit of 60 seconds that the router should retain 550 the Neighbor Cache entry for the sender of the NS that 551 includes this option. A value of zero means to remove 552 the registration. 554 Unique Interface Identifier: Variable length in multiples of 8 555 bytes. If the IDS=000, then it is an 8 byte (64 bit) 556 unmodified EUI-64. If IDS=0011 then it is a variable 557 length DUID. A DUID MUST be zero padded to a multiple 558 of 8 bytes. 560 When a node includes ARO option in a Neighbor Solicitation it MUST, 561 on links that have link-layer addresses, also include a SLLA option. 562 That option is needed so that the registrar can record the link-layer 563 address on success and send back an error if the address is a 564 duplicate. 566 6.3. Registrar Address Option (RAO) 568 Normally the Registrars are the Default Routers. However, there are 569 cases (like some approaches to handle VRRP, or coordinated separate 570 routers) where there is a need to have different (and either more or 571 less) Registrars than Default Routers. Furthermore, to robustly 572 handle NEAR state state loss this option carries a Router Epoch which 573 triggers the EAHs to re-register on a router epoch change. The RAO 574 contains the information for both of those. 576 0 1 2 3 577 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 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Type | Length | Num Addresses | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Reserved | Router Epoch | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | | 584 ~ IPv6 registrar addresses ~ 585 | (Num Addresses) | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | | 588 ~ Reserved for future extensions ~ 589 | | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 Fields: 594 Type: TBD (IANA) 596 Length: 8-bit unsigned integer. The length of the option 597 (including the type and length fields) in units of 8 598 bytes. The value 0 is invalid. 600 Num Addresses 16-bit unsigned integer. Set to zero if there are no 601 addresses i.e., when the option is used to only carry 602 the router epoch. NumAdressses*2 + 1 must not exceed 603 the Length. 605 Reserved 16-bit unused field. It MUST be initialized to zero 606 by the sender and MUST be ignored by the receiver. 608 Router epoch 16-bit integer. A router MUST pick a new epoch after 609 a state loss, either by keeping the epoch in stable 610 storage and incrementing it, or picking a good random 611 number. 613 IPv6 registrar addresses Zero or more IPv6 addresses, typically of 614 link-local scope. 616 The receiver MUST silently ignore any data after the IPv6 registrar 617 addresses field (such data is present when the Length is greater than 618 NumAdressses*2 + 1). 620 The Registrar Addresses are subject to the same lifetime as the 621 Default Router Lifetime (thus there is no explicit lifetime field in 622 the RAO). 624 7. Conceptual Data Structures 626 In addition to the Conceptual Data structures in [RFC4861] a EAH 627 needs to maintain the new Registrar List for each interface. The 628 Registrar List contains the set of IP addresses to which the host 629 needs to send Address Registrations. Each IP address has a Router 630 Epoch (used to determine when a router might have lost state). Also, 631 the host MAY use this data structure to track when it needs to 632 refresh its registrations with the registrar. 634 The use of explicit registrations with lifetimes plus the desire to 635 not multicast Neighbor Solicitation messages for hosts imply that we 636 manage the Neighbor Cache entries slightly differently than in 637 [RFC4861]. This results in two different types of NCEs and the types 638 specify how those entries can be removed: 640 Legacy: Entries that are subject to the normal rules in 641 [RFC4861] that allow for garbage collection 642 when low on memory. Legacy entries are created 643 only when there is no duplicate NCE. The 644 legacy entries are converted to the registered 645 entries upon successful processing of ARO. 646 Legacy type can be considered as union of 647 garbage-collectible and Tentative Type NCEs 648 described in [RFC6775]. 650 Registered: Entries that have an explicit registered 651 lifetime and are kept until this lifetime 652 expires or they are explicitly unregistered. 654 Note that the type of the NCE is orthogonal to the states specified 655 in [RFC4861]. There can only be one type of NCE for an IP address at 656 a time. 658 8. Host Behavior 660 A EAH follows [RFC4861] and applicable parts of [RFC6775] as 661 specified in this section./ 663 A EAH implementation MAY be able to fall back to [RFC4861] host 664 behavior if there is no NEAR on the link. 666 8.1. Host and/or Interface Initialization 668 A host multicasts Router Solicitation at system startup or interface 669 initialization as specified in [RFC4861] and its updates such as 670 [I-D.ietf-6man-resilient-rs]. If the interface initialization is due 671 to potential host movement or a wakeup from sleep then the host 672 initially sends a unicast Neighbor Solicitation to the default 673 router(s). 675 Unlike RFC4861 the RS MUST (on link layers which have addresses) 676 include a SLLA option, which is used by the router to unicast the RA. 678 The host is not required to join the solicited-node multicast 679 address(es) but it MUST join the all-nodes multicast address. 681 8.2. Host Receiving Router Advertisements 683 The RA is validated and processed as specified in [RFC4861] with 684 additional behavior for RAO and the Registrar List as follows. 686 When a RA is received without a RAO (but with the E flag set), or the 687 RAO contains no Registrar Addresses, then the IPv6 source address is 688 added/updated in the Registrar List. When a RA is received with a 689 RAO then the IPv6 Registrar Addresses in that option are added/ 690 updated in the data structure. 692 If those Registrar List (or entries) already exist and the Router 693 Epoch in the RAO differs from the Router Epoch in the Registrar List 694 entry, or if the entry does not exist, then the host will initiate 695 sending NS messages with ARO options to the new/updated Registration 696 List entries. Note that if the RA contains no RAO (but the E flag is 697 set) then for the purposes of the epoch comparison one should use a 698 zero Router Epoch. 700 However, if the Default Router Lifetime in the RA is zero, then any 701 matching Registration List entry (or entries) are instead deleted 702 from the Registration List. It is OPTIONAL for the host to de- 703 register when an entry is deleted from the Registration List. 705 The host can form its IPv6 address using any available mechanism - 706 SLAAC, DHCPv6, temporary addresses, etc - as the registration 707 mechanism is orthogonal and independent of the address allocation. 708 The Address Registration procedure replaces the DAD procedure in 709 [RFC4862]. 711 8.3. Timing out Registrar List entries 713 The lifetime for the Registrar List entries are taken from the 714 Default Router Lifetime in the RA. When an entry is removed the host 715 MAY send AROs with a zero Registration Lifetime to the removed 716 Registrar Addresses. 718 8.4. Sending AROs 720 When a host has formed a new IPv6 address, or when the host learns of 721 a new NEAR and has existing IPv6 addresses, then it would register 722 the new things (could be new addresses to all the existing 723 Registrars, or the all the IPv6 addresses with the new Registrar. 724 IPv6 link-local addresses are registered as well as the global 725 addresses and ULAs. 727 If the EAH has a TID then it sets the T-bit and includes the TID in 728 the ARO. When the host registers its addresses with multiple 729 Registrars it uses the same TID. However, if the host has moved 730 (lost its network attachment and determines it is attached to a 731 different link using e.g., DNA [RFC6059]), then it will increment the 732 TID value and use the new value for subsequent registrations. 734 The host places its Unique Interface Identifier (whether it is a DUID 735 or EUI-64) in the ARO. This identifier is typically kept in stable 736 storage so that the host can use the same identifier over time. It 737 MUST use the same identifier when it re-registers its address, since 738 otherwise all those will be returned as duplicates. 740 The NS which includes the ARO option MUST include a SLLA option on 741 link layers that have link-layer addresses. 743 The EAH retransmits NS messages with ARO as specified in [RFC6775] 744 until it receives a NA message from the Registrar containing an ARO. 745 The number of such retransmissions SHOULD be configurable. 747 8.5. Receiving Neighbor Advertisements 749 The Neighbor Advertisement are validated and processed as specified 750 in [RFC4861] for example to handle Neighbor Unreachability Detection 751 (NUD). In addition, the host processes any received ARO as follows. 753 If the ARO has status code 0 (Success), then the host updates the 754 information in the Registrar List to know when it next needs to 755 refresh the registered address with this Registrar. No further 756 processing is needed of the ARO. 758 If the ARO has status code 1 (Duplicate), then the host can not use 759 the IPv6 address. The host follows the address allocation protocol 760 it used to pick a new address - be that DHCPv6, temporary addresses, 761 etc. 763 If the ARO has a status code 2 (Neighbor Cache Full) in response to 764 its registration request from a Registrar, then the node SHOULD 765 continue to register the address with other Registrars (when 766 available). 768 TBD: What about other not yet defined status code values? 770 8.6. Host Management of the TID 772 It is RECOMMENDED that the EAH MAY maintain a sequence counter (TID) 773 in stable storage according to section 7 of [RFC6550]. The TID is 774 used to resolve conflicts between different registrations issues by 775 the same host for the same IPv6 address. Conflicts can be due to 776 different link-layer addresses, but it can also be due to registering 777 with different NEARs/Registrars and those routers connect use 778 protocols like RPL for routing, and RPL uses a TID to handle movement 779 vs. multi-homing. 781 Thus the same TID should be used if the host is registering its 782 addresses with multiple Registrars at the same time. But if the host 783 might have moved to a different attachment point, then it should 784 increment its TID for subsequent registrations. 786 8.7. Refreshing a Registration 788 A host SHOULD send a Registration message in order to renew its 789 registration before its registration lifetime expires in order to 790 continue its connectivity with the network. 792 This specification does not constrain the implementation. One 793 possible implementation strategy is to attempt re-register at 1/3rd 794 of the registration lifetime, and if no response try again at 2/3rd 795 of the lifetime, etc. Another possible strategy is to wait until the 796 end of the registration lifetime and then do the same relatively 797 rapid retransmissions as for the initial registration [RFC6775]. In 798 all cases the host SHOULD apply a random factor to its re- 799 registration timeout to avoid self-synchronizing behavior across lots 800 of hosts. Sleeping hosts would re-register when they are waking up 801 to do other work. 803 8.8. De-registering 805 If anytime, the node decides that it does not need a particular 806 default router's service anymore, the it SHOULD send a de- 807 registration message to that NEAR/Registrar. Similarly if the host 808 stops using a particular IPv6 address, then it SHOULD de-register 809 that address with all the Registrars it had registered with. This 810 applies even if the host was using the IPv6 address, then went to 811 sleep, and then picked a different set of IPv6 addresses. In such a 812 case it is preferred if the host de-registers before going to sleep. 813 A mobile host SHOULD first de-register its addresses before it moves 814 away from the subnet (if the mobile host can know that in advance of 815 moving.) 817 De-registration is performed by unicasting a Neighbor Solicitation 818 with an ARO where the Registration Lifetime is set to zero. Such an 819 ARO should have an incremented TID. De-registration AROs are 820 retransmitted just like other AROs as specified above. 822 8.9. Refreshing RA information 824 The EAH is responsible for asking the routers for updates to the 825 information contained in the Router Advertisements, since the NEARs 826 will not multicast such updates. That is done by sending unicast RSs 827 to the router(s) which will result in unicast RAs. However, 828 significant care is required in determining when the RSs should be 829 transmitted. 831 As part of normal operation the Default Routers, Prefixes, and other 832 RA information have lifetimes, and there are a few common cases: 834 1. The advertised lifetimes are constant i.e., the routers keep on 835 advancing the time when the information will expire. 837 2. The routers decrement the advertised lifetimes in real time i.e., 838 the information is set to expire at a determined time and 839 subsequent RAs have lower and lower lifetimes. 841 3. The routers forcibly expire some information by advertising it 842 with a zero lifetime for a while, and then stop advertising it. 844 4. A router crashes or is silently removed from the network and as a 845 result there are no more updates. For example, that default 846 router will expire and there is little benefit in trying to 847 refresh it by sending lots of RSs. 849 The host's logic for refreshing the information needs to be careful 850 to not send a large number of RSs, in particular if there is 851 information that is supposed to expire at a fixed time i.e., the 852 lifetime decrements in real time. 854 A host MUST NOT try to refresh information because its lifetime is 855 near zero, since that would cause unnecessary RSs. Instead the 856 refresh needs to be based on when the information was most recently 857 received from the router. A lifetime of 10 minutes that was heard 858 from the router 10 minutes ago might be normal as part of expiring 859 some information. But a remaining lifetime of 10 minutes for a 860 prefix that was last heard 24 hours ago with a lifetime of 24 hours 861 means that a refresh is in order. 863 It is RECOMMENDED that the host track the expiry time (the wall clock 864 time when some information will expire) and when it receives an RA 865 with that information it SHOULD check whether the expiry time is 866 moving forward, or appears to be frozen in time. That can tell the 867 difference between he first two cases above, and avoid unnecessary 868 RSs as some information naturally expires. Furthermore it is 869 RECOMMENDED that the host track which information was received from 870 which router, so that it can see when a router used to provide the 871 information no longer provides it. That helps to see if the third 872 case above might be in play. Finally, if a router has not responded 873 to a few (e.g., MAX_RTR_SOLICITATIONS) attempts to get a refresh, 874 then the router might be unreachable or dead, and there is little 875 benefit in sending further RSs to that router. When the router comes 876 back it will multicast a few RAs. 878 When the hosts determines that case 1 above is likely, then it should 879 pick a reasonable time to ask for refreshes. The exact refresh 880 behavior is not mandated by this specification, but the same 881 implementation strategies as for refreshing address registrations in 882 Section 8.7 can be considered. 884 A example simple implementation approach is to only base the 885 refreshing on the default router lifetime (thus ignore prefix and 886 other lifetime), and pick a refresh time which is 1/3 of the default 887 router lifetime. If no RA is received, a subsequent refresh can be 888 done at 2/3 of the default router lifetime. If that does not result 889 in a RA, then MAX_INITIAL_RTR_ADVERTISEMENTS can be sent as the 890 router lifetime is about to expire. Note that a default router 891 lifetime of zero MUST NOT result in sending a RS refresh based on a 892 timeout of zero. 894 If the host is unable to refresh the information and as a result ends 895 up with an empty default router list, or all the default routers are 896 marked as UNREACHABLE by NUD, then the host MAY switch to sending 897 initial multicast Router Solicitations as in Section 8.1. 899 Note that [I-D.nordmark-6man-rs-refresh] make that behavior more 900 explicit by having the routers advertise a timeout. 902 8.10. Sleep and Wakeup 904 The protocol allows the sleepy nodes to complete its sleep schedule 905 without waking up due to periodic Router Advertisement messages or 906 due to Multicast Neighbor Solicitation for address resolution. The 907 node registration lifetime SHOULD be related with its sleep interval 908 period in order to avoid waking up in the middle of sleep for 909 registration refresh. Depending on the application, the registration 910 lifetime SHOULD be equal to or integral multiple of a node's sleep 911 interval period. 913 When a host wakes up it can combine movement detecting (DNA), NUD, 914 and refreshing its Address Registration by sending a unicast NS with 915 an ARO to its existing default router(s). 917 8.11. Receiving Redirects 919 An EAH handles Redirect messages as specified in [RFC4861]. 921 8.12. Movement Detection 923 When a host moves from one subnet to another its IPv6 prefix changes 924 and the movement detection is determined according to the existing 925 IPv6 movement detection described in [RFC6059]. 927 9. Router Behavior 929 A NEAR follows [RFC4861] and applicable parts of [RFC6775] as follows 930 in this section. 932 A NEAR SHOULD support legacy hosts and mixed mode as specified in 933 this section by being able to proxy Address Resolution and DAD. The 934 NEAR SHOULD implement a knob to be able to disable this behavior. 935 That knob can either be set to "mixed-mode" or to "no-legacy-mode". 937 The RECOMMENDED default mode of operation for the NEAR is Mixed-mode. 939 A NEAR should be configured to advertise prefixes without the on-link 940 (L-bit) unset. Furthermore, any legacy routers attached to the same 941 link as a NEAR should be configured the same way. That reduces the 942 cases in mixed mode when multicast NS messages are needed between 943 legacy hosts and routers. 945 9.1. Router and/or Interface Initialization 947 A NEAR multicasts some initial Router Advertisements 948 (MAX_INITIAL_RTR_ADVERTISEMENTS) at system startup or interface 949 initialization as specified in [RFC4861] and its updates. 951 The NEAR MUST join the all-nodes and all-routers multicast addresses. 952 In mixed mode it MUST also join the solicited-node multicast 953 address(es) for its addresses and also for all the Registered NCEs. 955 A NEAR picks a new Router Epoch if it has lost the Registered NCEs, 956 which is typically the case for router initialization. Either the 957 Router Epoch can be stored in stable storage and incremented on each 958 router initialization, or the NEAR can pick a good random number on 959 router initialization. The effect of occasionally picking the same 960 Router Epoch as before the state loss is that it will take longer for 961 the router to build up its state of Registered NCEs. 963 9.2. Receiving Router Solicitations 965 Periodic RAs SHOULD be avoided. Only solicited RAs are RECOMMENDED. 966 An RA MUST contain the Source Link-layer Address option containing 967 Router's link-layer address (this is optional in [RFC4861]. An RA 968 MUST carry any Prefix information option with L bit being unset, so 969 that hosts do not multicast any NS messages as part of address 970 resolution. A new flag (E-flag) is introduced in the RA which the 971 hosts use to distinguish a NEAR from a legacy router. 973 Unlike [RFC4861] which suggests multicast Router Advertisements, this 974 specification optimizes the exchange by always unicasting RAs in 975 response to RSs. This is possible since the RS always includes a 976 SLLA option, which is used by the router to unicast the RA. 978 If the NEAR has been configured to send an explicit set of IPv6 979 Registrar Addresses, or implements a Router Epoch, then the NEAR 980 includes a RAO in all its RAs. 982 9.3. Periodic Multicast RA for legacy hosts 984 The NEAR MUST NOT send periodic RA in no-legacy mode. In mixed mode 985 the NEAR needs to send periodic multicast RAs as specified in 986 [RFC4861] to support legacy hosts. 988 9.4. Multicast RA when new information 990 When a router has new information to share (new prefixes, prefixes 991 that should be immediately deprecated, etc) it MAY multicast up to 992 MAX_INITIAL_RTR_ADVERTISEMENTS number of Router Advertisements. Note 993 that such new information is not likely to reach sleeping hosts until 994 those hosts refresh by sending a RS. 996 9.5. Receiving ARO 998 The NEAR follows the logic in [RFC6775] for managing the NCEs and 999 responding to NS messages with the ARO option. The slight 1000 modification is that instead of using an EUI-64 as the key to check 1001 for duplicates, the NEAR uses the IDS value plus the variable length 1002 Unique Interface Identifier value as the key. In addition the NEAR 1003 checks the new TID field as follows. 1005 The TID field is used together with age of a registration for 1006 arbitration between two routers to ensure freshness of the 1007 registration of a given target address. Same value of TID indicates 1008 that both states of registration are valid. In case of a mismatch 1009 between comparable TIDs, the most recent TID wins. The TIDs are 1010 compared as specified in section 7 of [RFC6550]. 1012 9.6. NCE Management in NEARs 1014 When a host interacts with a router by sending Router Solicitations 1015 that does not match with the existing NCE entry of any type, a Legacy 1016 NCE is first created. Once a node successfully registers with a 1017 Router the result is a Registered NCE. As Routers send RAs to legacy 1018 hosts, or receive multicast NS messages from other Routers the result 1019 is Legacy NCEs. 1021 A Router Solicitation might be received from a host that has not yet 1022 registered its address with the router or from a legacy [RFC4861] 1023 host in the Mixed-mode operation. 1025 The router MUST NOT modify an existing Registered Neighbor Cache 1026 entry based on the SLLA option from the Router Solicitation. Thus, a 1027 router SHOULD create a tentative Legacy Neighbor Cache entry based on 1028 SLLA option when there is no match with the existing NCE. Such a 1029 legacy Neighbor Cache entry SHOULD be timed out in 1030 TENTATIVE_LEGACY_NCE_LIFETIME seconds unless a registration converts 1031 it into a Registered NCE. 1033 However, in 'Mixed-mode' operation, the router does not require to 1034 keep track of TENTATIVE_LEGACY_NCE_LIFETIME as it does not know if 1035 the RS request is from a legacy host or from a EAH. However, it 1036 creates the legacy type of NCE and updates it to a registered NCE if 1037 the ARO NS request arrives corresponding to the Legacy NCE. 1038 Successful processing of ARO will complete the NCE creation phase. 1040 If ARO did not result in a duplicate address being detected, and the 1041 registration life-time is non-zero, the router creates or updates the 1042 Registered NCE for the IPv6 address. If the Neighbor Cache is full 1043 and new entries need to be created, then the router SHOULD respond 1044 with a NA with status field set to 2. For successful creation of 1045 NCE, the router SHOULD include a copy of ARO and send NA to the 1046 requester with the status field 0. A TLLA (Target Link Layer) Option 1047 is not required with this NA. 1049 Typically for efficiency-aware routers (NEAR), the Registration 1050 Lifetime and IDS plus Unique Interface Identifier are recorded in the 1051 Neighbor Cache Entry along with the existing information described in 1052 [RFC4861]. The registered NCE are meant to be ready and reachable 1053 for communication and no address resolution is required in the link. 1054 An EAH will renew its registration to Registered NCE at the router. 1055 However the router may perform NUD towards the EAH hosts as per 1056 [RFC4861]. Should NUD fail the NEAR MUST NOT remove the Registered 1057 NCE. Instead it marks it as UNREACHABLE. 1059 9.7. Sending non-zero status in ARO 1061 If the Registration fails (due to it being a duplicate or the 1062 Neighbor Cache being full), then the NEAR will send an NA with ARO 1063 having a non-zero status. However, it needs to send that back to the 1064 originator of the failing ARO, and that host and link-layer address 1065 will not be present in the Neighbor Cache. 1067 The NEAR forms a NA with ARO, and then forms the link-layer address 1068 by using the content of the SLLA option in the NS, bypassing the 1069 Neighbor Cache to send this error. 1071 9.8. Timing out Registered NCEs 1073 The router SHOULD NOT garbage collect Registered Neighbor Cache 1074 entries since they need to retain them until the Registration 1075 Lifetime expires. If a NEAR receives a NS message from the same host 1076 one with ARO and another without ARO then the NS message with ARO 1077 gets the precedence and the NS without ARO is ignored. 1079 Similarly, if Neighbor Unreachability Detection on the router 1080 determines that the host is UNREACHABLE (based on the logic in 1081 [RFC4861]), the Neighbor Cache entry SHOULD NOT be deleted but be 1082 retained until the Registration Lifetime expires. If an ARO arrives 1083 for an NCE that is in UNREACHABLE state, that NCE should be marked as 1084 STALE. 1086 The NEAR router SHOULD deny registration to a new registration 1087 request with the status code 2 when it reaches the maximum capacity 1088 for handling the neighbor cache. 1090 9.9. Router Advertisement Consistency 1092 The NEAR follows section 6.2.7 in [RFC4861] by receiving RAs from 1093 other routers (NEAR and legacy) on the link. In addition to the 1094 checks in that section it verifies that the prefixes to not have the 1095 L flag set, and that the Registrar Address options are consistent. 1096 Two RAOs are inconsistent if they contain the have a different Router 1097 Epoch and have some IPv6 Registration Addresses in common. 1099 9.10. Sending Redirects 1101 A NEAR sends redirects (with target=destination) to inform the hosts 1102 of the link-layer address of the nodes on the link. 1104 This can be disabled on specific link types for instance, radio link 1105 technologies with hidden terminal issues. 1107 9.11. Providing Information to Routing Protocols 1109 If there is a routing protocols like RPL which wants visibility into 1110 the location of each IPv6 address, then this can be retrieved from 1111 the Registered NCEs on the NEAR. 1113 9.12. Creating Legacy NCEs 1115 In mixed-mode a NEAR will create Legacy NCEs when receiving RA, RS, 1116 and NS messages based on the source of those packets. When not it 1117 mixed-mode it needs to create Legacy NCEs for other routers by 1118 looking at those packets. 1120 9.13. Proxy Address Resolution and DAD for Legacy Hosts 1122 This section applies in mixed mode. It does not apply in no-legacy 1123 mode. 1125 A NEAR in mixed mode MUST join all solicited-node for all Registered 1126 NCEs. 1128 The NEAR SHOULD continue to support the legacy IPv6 Neighbor 1129 Solicitation requests in the mixed mode. The NEAR router SHOULD act 1130 as the ND proxy on behalf of EAH hosts for the legacy nodes' NS 1131 requests for EAH. This form of proxying is to respond with a NA that 1132 has a TLLAO taken from the Registered NCE for the target. Thus it is 1133 unlike ND Proxy as specified in [RFC4389].(Implementations of 1134 "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] might proxy using 1135 their own MAC address as TLLA, but that is outside of the scope of 1136 this document.) 1138 In the context of this specification, proxy means: 1140 o Responding to DAD probes for a registered NCE. A DAD probe from a 1141 legacy host would not contain any ARO, hence the NEAR will assume 1142 it is always a duplicate if the IPv6 target address has a 1143 Registered NCE. 1145 o Defending a registered address using NA messages with and ARO 1146 option and the Override bit set if the ARO option in the NS 1147 indicates either a different node (different IDS+Unique Interface 1148 Id) or a older registration (when comparing the TID). 1150 o Advertising a registered address using NA messages, asynchronously 1151 or as a response to a Neighbor Solicitation messages. 1153 o Looking up a destination on the link using Neighbor Solicitation 1154 messages in order to deliver packets arriving for the EAH. 1156 The NEAR SHOULD also support DAD from a EAH for IPv6 address that 1157 might be in use by a legacy node. Thus when a NEAR in mixed-mode 1158 received an ARO for a new address it SHOULD perform DAD as specified 1159 in [RFC4862] by sending a multicast DAD message. Once that times out 1160 the NEAR can respond to the ARO. If a legacy host responds to the 1161 DAD probe, then the NEAR will respond to the ARO with Status=1 1162 (Duplicate Address). 1164 10. Handling ND DoS Attack 1166 IETF community has discussed possible issues with /64 DoS attacks on 1167 the ND networks when an attacker host can send thousands of packets 1168 to the router with an on-link destination address or sending RS 1169 messages to initiate a Neighbor Solicitation from the neighboring 1170 router which will create a number of INCOMPLETE NCE entries for non- 1171 existent nodes in the network resulting in table overflow and denial 1172 of service of the existing communications. 1174 The efficiency-aware behavior documented in this specification avoids 1175 the ND DoS attacks by: 1177 o Having the hosts register with the default router(s). 1179 o Having the hosts send their packets via the default router(s). 1181 o Not resolving addresses for the routing solicitor by mandating 1182 SLLA option along with RS 1184 o Checking for duplicates in NCE before the registration 1186 o On-link IPv6-destinations on a particular link must be registered 1187 else these packets are not resolved and extra NCEs are not created 1189 In order to get maximal benefits from the ND-DoS protection from 1190 Address Registrations, the hosts and routers on the link need to be 1191 upgraded to NEARs and EAHs, respectively. With some legacy hosts the 1192 routers will still need to create INCOMPLETE NCEs and send NSs, which 1193 keeps the DoS opportunity open. However, with fewer legacy hosts the 1194 lower rate limits can be applied on creation of INCOMPLETE NCEs. 1196 11. Bootstrapping 1198 The bootstrapping mechanism described here is applicable for the 1199 efficiency-aware hosts and routers. At the start, the host uses its 1200 link-local address to send Router Solicitation and then it sends the 1201 Address Registration Option as described in this document in order to 1202 verify the IPv6 address. Note that on wakeup from sleep and after 1203 potential movement to a different link the host initially sends a 1204 unicast Neighbor Solicitation to the default router(s). 1206 The following step 3 and 4 SHOULD be repeated for all the IPv6 1207 addresses that are used for communications. 1209 Node Router 1211 0. |[Forms LL IPv6 addr] | 1213 1. | ---------- Router Solicitation --------> | 1215 | [SLLAO] | 1217 2. | <-------- Router Advertisement --------- | 1219 | [PIO + SLLAO] | 1220 | | 1222 3. | ----- Address Registration (NS) --------> | 1224 | [ARO + SLLAO] | 1226 4. | <-------- Neighbor Advertisement ------- | 1228 | [ARO with Status code] | 1230 5. ====> Address Assignment Complete 1232 Figure 1: Neighbor Discovery Address Registration and bootstrapping 1234 12. Interaction with other protocols 1236 12.1. Detecting Network Attachment (DNA) 1238 IPv6 DNA [RFC6059] uses unicast NS probes and link-layer indications 1239 to detect movement of its network attachments. That is consistent 1240 with the mechanism in this specification to unicast a NS when a host 1241 wakes up - this document recommends adding the ARO to that NS 1242 message. 1244 Thus the ND optimization solution will work seamlessly with DNA 1245 implementations and no change is required in DNA solution because of 1246 Neighbor Discovery updates. It is a deployment and configuration 1247 consideration as to run the network in mixed mode or efficient-mode. 1249 12.2. DHCPv6 Interaction 1251 The protocol mechanisms in this document are orthogonal to the 1252 address assignment mechanism in use. If DHCPv6 is used for address 1253 assignment by an EAH then, if there are one or more NEARs on the 1254 subnet, the EAH will replace the DAD check specified in [RFC3315] 1255 with Address Registration as specified in this document. 1257 12.3. Other use of Multicast 1259 Although the solution described in this document prevents unnecessary 1260 multicast messages in the IPv6 ND procedure, it does not affect 1261 normal IPv6 multicast packets nor the ability of nodes to join and 1262 leave the multicast group or forwarding multicast traffic or 1263 responding to multicast queries. 1265 12.4. VRRP Interaction 1267 A VRRP set of routers can operate with efficient-nd in two different 1268 ways: 1270 o Provide the illusion to hosts that they are a single router for 1271 the purposes of registrations. No RAO is needed in that case. 1272 But the pair needs some mechanism to synchronize their neighbor 1273 caches. Such a mechanism is out of scope of this document. 1275 o Have the hosts register with each router independently. In that 1276 case the VRRP router includes the RAO with the individual IP 1277 addresses of the routers in the pair. No synchronization of the 1278 neighbor caches are needed in that case. 1280 13. Updated Neighbor Discovery Constants 1282 This section discusses the updated default values of ND constants 1283 based on [RFC4861] section 10. New and changed constants are listed 1284 only for efficiency-aware-nd implementation. These values SHOULD be 1285 configurable and tunable to fit implementations and deployment. 1287 Router Constants: 1289 MAX_RTR_ADVERTISEMENTS(NEW) 3 transmissions 1291 MIN_DELAY_BETWEEN_RAS(CHANGED) 1 second 1293 TENTATIVE_LEGACY_NCE_LIFETIME(NEW) 30 seconds 1295 Host Constants: 1297 MAX_RTR_SOLICITATION_INTERVAL(NEW) 60 seconds 1299 Also refer to [RFC6583] , [RFC7048] and [RFC6775] for further tuning 1300 of ND constants. 1302 14. Security Considerations 1304 These optimizations are not known to introduce any new threats 1305 against Neighbor Discovery beyond what is already documented for IPv6 1306 [RFC3756]. 1308 Section 11.2 of [RFC4861] applies to this document as well. 1310 This mechanism minimizes the possibility of ND /64 DoS attacks in 1311 efficiency-aware mode. See Section 10. 1313 The mechanisms in this document work with SeND [RFC3971] in the no- 1314 legacy mode. In the mixed mode operation when a NEAR needs to 1315 respond to a legacy host sending a NS for a EAH, then SeND would not 1316 automatically fit. Potentially proxy SeND [RFC6496] could be used, 1317 but that would require explicit awareness and setup between the proxy 1318 and the proxied EAHs which seems impractical. 1320 The mechanisms in this specification are orthogonal to the address 1321 allocation thus works as well with SLAAC and DHCPv6 as the various 1322 privacy-enhanced address allocation specifications. In particular, 1323 using an EUI-64 for the Unique Interface Identifier in this protocol 1324 does not require or assume that the IPv6 addresses will be formed 1325 using the modified EUI-64 format. 1327 The mechanism uses a Unique Interface Identifier for the purposes of 1328 telling apart a re-registration from the same host and a duplicate/ 1329 conflicting registration from a different host. That unique ID is 1330 not globally visible. Currently the protocol supports DHCPv6 DUID 1331 and EUI-64 format for this I-D, but other formats which facilitate 1332 non-linkability (such as strong random numbers large enough to be 1333 unlikely to cause collisions) can be defined. 1335 15. IANA Considerations 1337 A new flag (E-bit) in RA has been introduced. IANA assignment of the 1338 E-bit flag is required upon approval of this document. 1340 This document needs a new Neighbor Discovery option type for the RAO. 1342 16. Changelog 1344 Changes from draft-chakrabarti-nordmark-energy-aware-nd-06: 1346 o Added references to dad-issues and rs-refresh. 1348 Changes from draft-chakrabarti-nordmark-energy-aware-nd-05: 1350 o Fixed typos. 1352 o Clarified that on interface initialization after sleep or 1353 potential movement the host unicasts a NS to the default 1354 router(s). 1356 o Simplified the example timer handling for refreshing RA 1357 information. 1359 o Added handling of DAD from EAH to legacy node that was included in 1360 -04 and lost in the -05 edits. 1362 Changes from draft-chakrabarti-nordmark-energy-aware-nd-04: 1364 o Significantly simplified the description of the protocol. 1366 o Added clarification on problem statement 1368 o Clarified that privacy and temporary addresses will be supported 1370 o Added an IDS field in the ARO to allow a DHCP Unique ID (DUID) as 1371 an alternative to EUI-64, with room to define other (pseudo) 1372 unique identifiers. 1374 o Allowed router redirects for NEAR. 1376 o Addressed some of comments made in the 6man list. 1378 o Added RAO to handle VRRP and similar cases when the default router 1379 list and registrar list needs to be different. 1381 o Added Router Epoch to cause re-registration on NEAR state loss. 1383 o Specified considerations for when to refresh address 1384 registrations. 1386 o Specified considerations for when to refresh RA information. 1388 17. Acknowledgements 1390 The primary idea of this document are from 6LoWPAN Neighbor Discovery 1391 document [RFC6775] and the discussions from the 6lowpan working group 1392 members, chairs Carsten Bormann and Geoff Mulligan and through our 1393 discussions with Zach Shelby, editor of the [RFC6775]. 1395 The inspiration of such a IPv6 generic document came from Margaret 1396 Wasserman who saw a need for such a document at the IOT workshop at 1397 Prague IETF. 1399 The authors acknowledge the ND denial of service issues and key 1400 causes mentioned in the draft-halpern-6man-nddos-mitigation document 1401 by Joel Halpern. Thanks to Joel Halpern for pinpointing the problems 1402 that are now addressed in the NCE management discussion in this 1403 document. 1405 The authors like to thank Dave Thaler, Stuart Cheshire, Jari Arkko, 1406 Ylva Jading, Niklas J. Johnsson, Reda Nedjar, Purvi Shah, Jaume Rius 1407 Riu, Fredrik Garneij, Andrew Yourtchenko, Jouni Korhonen, Suresh 1408 Krishnan, Brian Haberman, Anders Brandt, Mark Smith, Lorenzo Colitti, 1409 David Miles, Eric Vyncke, Mark ZZZ Smith, Mikael Abrahammsson, Eric 1410 Levy-Abignoli, and Carsten Bormann for their useful comments and 1411 suggestions on this work. 1413 18. Open Issues 1415 The known open issues are: 1417 o IPv6 link-local addresses are always on-link and in this version 1418 of the document that results in multicast NS messages. The 1419 technique used in 6LowPAN-ND is too restrictive (extract the link- 1420 layer address from the IID). Should we send link-locals to 1421 routers and depend on Redirect? 1423 o If the Router Epoch is critical then we will see a RAO in all the 1424 RAs sent by NEARs. In such a case we don't need the E-bit in the 1425 RA. 1427 o Editorial: Add Comparison with 6lowpan-nd and 4861? 1429 o Editorial: Verify and update the description in this document to 1430 make it complete removing the need to read 6LowPAN-ND. 1432 o When a router has new information for the RA, currently it takes a 1433 while to disseminate that to sleeping nodes as this depends on 1434 when the hosts send a RS. We could potentially improve this is we 1435 could have an "information epoch number" in the ARO sent in the 1436 NA. But that only helps if the registrations are refreshed more 1437 frequently that the RA information. 1439 o Future? Currently if a router changes its information, a sleeping 1440 host would not find out when it wakes up and sends the NS with 1441 ARO. That could be improved if we fit the Router Epoch in NA/ARO. 1443 But there is no room for 16 bits. 1445 o A separate but related problem is with unused NCEs due to frequent 1446 IPv6 address change e.g., hosts which pick a different set of 1447 addresses each time they wake up. This document recommends that 1448 they be de-registered by the host. That could be made simpler by 1449 introducing some Host Epoch counter in the NS/ARO. 1451 19. References 1453 19.1. Normative References 1455 [I-D.ietf-6man-resilient-rs] 1456 Krishnan, S., Anipko, D., and D. Thaler, "Packet loss 1457 resiliency for Router Solicitations", 1458 draft-ietf-6man-resilient-rs-04 (work in progress), 1459 October 2014. 1461 [I-D.nordmark-6man-rs-refresh] 1462 Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6 1463 Neighbor Discovery Optional Unicast RS/RA Refresh", 1464 draft-nordmark-6man-rs-refresh-01 (work in progress), 1465 October 2014. 1467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1468 Requirement Levels", BCP 14, RFC 2119, March 1997. 1470 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1471 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1472 September 2007. 1474 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1475 "Neighbor Discovery Optimization for IPv6 over Low-Power 1476 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 1477 November 2012. 1479 19.2. Informative References 1481 [I-D.ietf-6man-default-iids] 1482 Gont, F., Cooper, A., Thaler, D., and W. Will, 1483 "Recommendation on Stable IPv6 Interface Identifiers", 1484 draft-ietf-6man-default-iids-02 (work in progress), 1485 January 2015. 1487 [I-D.ietf-6man-stable-privacy-addresses] 1488 Gont, F., "A Method for Generating Semantically Opaque 1489 Interface Identifiers with IPv6 Stateless Address 1490 Autoconfiguration (SLAAC)", 1491 draft-ietf-6man-stable-privacy-addresses-17 (work in 1492 progress), January 2014. 1494 [I-D.vyncke-6man-mcast-not-efficient] 1495 Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A. 1496 Yourtchenko, "Why Network-Layer Multicast is Not Always 1497 Efficient At Datalink Layer", 1498 draft-vyncke-6man-mcast-not-efficient-01 (work in 1499 progress), February 2014. 1501 [I-D.yourtchenko-6man-dad-issues] 1502 Yourtchenko, A., "A survey of issues related to IPv6 1503 Duplicate Address Detection", 1504 draft-yourtchenko-6man-dad-issues-00 (work in progress), 1505 October 2014. 1507 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1508 and M. Carney, "Dynamic Host Configuration Protocol for 1509 IPv6 (DHCPv6)", RFC 3315, July 2003. 1511 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 1512 Discovery (ND) Trust Models and Threats", RFC 3756, 1513 May 2004. 1515 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1516 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1518 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1519 Proxies (ND Proxy)", RFC 4389, April 2006. 1521 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1522 Address Autoconfiguration", RFC 4862, September 2007. 1524 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1525 Extensions for Stateless Address Autoconfiguration in 1526 IPv6", RFC 4941, September 2007. 1528 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 1529 Detecting Network Attachment in IPv6", RFC 6059, 1530 November 2010. 1532 [RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia- 1533 Martinez, "Secure Proxy ND Support for SEcure Neighbor 1534 Discovery (SEND)", RFC 6496, February 2012. 1536 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1537 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1539 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1540 Lossy Networks", RFC 6550, March 2012. 1542 [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object 1543 Workshop", RFC 6574, April 2012. 1545 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 1546 Neighbor Discovery Problems", RFC 6583, March 2012. 1548 [RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability 1549 Detection Is Too Impatient", RFC 7048, January 2014. 1551 Authors' Addresses 1553 Samita Chakrabarti 1554 Ericsson 1555 San Jose, CA 1556 USA 1558 Email: samita.chakrabarti@ericsson.com 1560 Erik Nordmark 1561 Arista Networks 1562 Santa Clara, CA 1563 USA 1565 Email: nordmark@arista.com 1567 Pascal Thubert 1568 Cisco Systems 1570 Email: pthubert@cisco.com 1572 Margaret Wasserman 1573 Painless Security 1575 Email: mrw@painless-security.com