idnits 2.17.00 (12 Aug 2021) /tmp/idnits51625/draft-chakrabarti-nordmark-6man-efficient-nd-06.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 (July 4, 2014) is 2878 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 1203, but not defined == Unused Reference: 'RFC2434' is defined on line 1441, but no explicit reference was found in the text == Unused Reference: 'RFC4944' is defined on line 1453, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 1487, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 1497, but no explicit reference was found in the text == Unused Reference: 'RFC4941' is defined on line 1506, but no explicit reference was found in the text == Unused Reference: 'RFC5175' is defined on line 1510, but no explicit reference was found in the text == Unused Reference: 'RFC6275' is defined on line 1517, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: draft-ietf-6man-default-iids has been published as RFC 8064 == Outdated reference: draft-ietf-6man-resilient-rs has been published as RFC 7559 == Outdated reference: draft-ietf-6man-stable-privacy-addresses has been published as RFC 7217 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 2 errors (**), 0 flaws (~~), 13 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: January 5, 2015 P. Thubert 7 Cisco Systems 8 M. Wasserman 9 Painless Security 10 July 4, 2014 12 IPv6 Neighbor Discovery Optimizations for Wired and Wireless Networks 13 draft-chakrabarti-nordmark-6man-efficient-nd-06 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 January 5, 2015. 54 Copyright Notice 56 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Goals and Requirements . . . . . . . . . . . . . . . . . . . 5 73 2.1. Mixed-Mode Operations . . . . . . . . . . . . . . . . . . 5 74 3. Changes to ND state management . . . . . . . . . . . . . . . 6 75 4. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 6 76 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 77 5.1. Proxying to handle Mixed mode . . . . . . . . . . . . . . 9 78 6. New Neighbor Discovery Options and Messages . . . . . . . . . 10 79 6.1. Router Advertisement flag for NEARs . . . . . . . . . . . 10 80 6.2. Address Registration Option (ARO) . . . . . . . . . . . . 10 81 6.3. Registrar Address Option (RAO) . . . . . . . . . . . . . 12 82 7. Conceptual Data Structures . . . . . . . . . . . . . . . . . 14 83 8. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 14 84 8.1. Host and/or Interface Initialization . . . . . . . . . . 14 85 8.2. Host Receiving Router Advertisements . . . . . . . . . . 15 86 8.3. Timing out Registrar List entries . . . . . . . . . . . . 15 87 8.4. Sending AROs . . . . . . . . . . . . . . . . . . . . . . 16 88 8.5. Receiving Neighbor Advertisements . . . . . . . . . . . . 16 89 8.6. Host Management of the TID . . . . . . . . . . . . . . . 17 90 8.7. Refreshing a Registration . . . . . . . . . . . . . . . . 17 91 8.8. De-registering . . . . . . . . . . . . . . . . . . . . . 17 92 8.9. Refreshing RA information . . . . . . . . . . . . . . . . 18 93 8.10. Sleep and Wakeup . . . . . . . . . . . . . . . . . . . . 19 94 8.11. Receiving Redirects . . . . . . . . . . . . . . . . . . . 20 95 8.12. Movement Detection . . . . . . . . . . . . . . . . . . . 20 96 9. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 20 97 9.1. Router and/or Interface Initialization . . . . . . . . . 20 98 9.2. Receiving Router Solicitations . . . . . . . . . . . . . 21 99 9.3. Periodic Multicast RA for legacy hosts . . . . . . . . . 21 100 9.4. Multicast RA when new information . . . . . . . . . . . . 21 101 9.5. Receiving ARO . . . . . . . . . . . . . . . . . . . . . . 21 102 9.6. NCE Management in NEARs . . . . . . . . . . . . . . . . . 22 103 9.7. Sending non-zero status in ARO . . . . . . . . . . . . . 23 104 9.8. Timing out Registered NCEs . . . . . . . . . . . . . . . 23 105 9.9. Router Advertisement Consistency . . . . . . . . . . . . 23 106 9.10. Sending Redirects . . . . . . . . . . . . . . . . . . . . 24 107 9.11. Providing Information to Routing Protocols . . . . . . . 24 108 9.12. Creating Legacy NCEs . . . . . . . . . . . . . . . . . . 24 109 9.13. Proxy Address Resolution and DAD for Legacy Hosts . . . . 24 110 10. Handling ND DoS Attack . . . . . . . . . . . . . . . . . . . 25 111 11. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 26 112 12. Interaction with other protocols . . . . . . . . . . . . . . 26 113 12.1. Detecting Network Attachment (DNA) . . . . . . . . . . . 26 114 12.2. DHCPv6 Interaction . . . . . . . . . . . . . . . . . . . 27 115 12.3. Other use of Multicast . . . . . . . . . . . . . . . . . 27 116 12.4. VRRP Interaction . . . . . . . . . . . . . . . . . . . . 27 117 13. Updated Neighbor Discovery Constants . . . . . . . . . . . . 27 118 14. Security Considerations . . . . . . . . . . . . . . . . . . . 28 119 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 120 16. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 29 121 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 122 18. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 30 123 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 124 19.1. Normative References . . . . . . . . . . . . . . . . . . 31 125 19.2. Informative References . . . . . . . . . . . . . . . . . 31 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 128 1. Introduction 130 IPv6 Neighbor Discovery [RFC4861] was defined at a time when local 131 area networks had different properties than today. A common link was 132 the yellow-coax shared wire Ethernet, where a link-layer multicast 133 and unicast worked the same - send the packet on the wire and the 134 interested receivers will pick it up. Thus the network cost 135 (ignoring any processing cost on the receivers that might not 136 completely filter out Ethernet multicast addresses that they did not 137 want) and the reliability of sending a link-layer unicast and 138 multicast was the same. Furthermore, the hosts at the time was 139 always on and connected. Powering on and off the workstation/PC 140 hosts at the time was slow and disruptive process. 142 Under the above assumptions it was quite efficient to maintain the 143 shared state of the link such as the prefixes and their lifetimes 144 using periodic multicast Router Advertisement messages. It was also 145 efficient to use multicast Neighbor Solicitations for address 146 resolution as a slight improvement over the broadcast use in ARP. 147 And finally, checking for a potential duplicate IPv6 address using 148 broadcast was efficient and natural. 150 Since then we've seen a tremendous change with the wide-spread 151 deployment of WiFi and other wireless network technologies. WiFi is 152 a case in point in that it provides the same network service 153 abstraction as Ethernet and is often bridged with Ethernets, meaning 154 that the Neighbor Discovery software on hosts and routers might be 155 unaware that WiFi is being used. Yet the performance and reliability 156 of multicast is quite different than for unicast on WiFi (see for 157 instance [I-D.vyncke-6man-mcast-not-efficient]). Similarly 3GPP and 158 M2M networks and devices will benefit from a standard specification 159 for optimized Neighbor discovery. Even wired networks have evolved 160 substantially with modern switch fabrics using explicit packet 161 replication logic to handle multicast packets. 163 The hosts and usage patterns has undergone radical changes as well. 164 Hosts go to sleep when not in use to save on battery power [RFC6574] 165 or to be more energy efficient even with mains power. The 166 expectation is that waking up doesn't take much time and power 167 otherwise the benefits of sleeping are greatly reduced. Initially 168 sleeping hosts were esoteric sensor nodes, but this sleeping hosts 169 have become mainstream in smartphones. 171 Some of the above trends were observed early (e.g., Ohta-san 172 commented on Neighbor Discovery being inefficient on WiFi a long time 173 back) but the issues were not broadly understood. The issues were 174 raised in the 6LowPAN context where the desire was to run IPv6 over 175 low-power radio networks and battery operated devices. That lead to 176 defining a set of optimizations [RFC6775] for that specific category 177 of links. However, the trends are not limited to such specific link 178 types. 180 This document applies what we have learned from 6LowPAN to all link 181 types. That includes reusing existing support from base Neighbor 182 Discovery (such as Redirect messages) and reusing from 6LowPAN-ND 183 (Address Registration Option). There are additions above and beyond 184 that to improve the robustness with redundant routers and to support 185 mixed mode. 187 The optimizations are done in a way to provide incremental benefits. 188 As soon as there is at least one router on a link which supports 189 these optimizations, then the updated hosts on the link can sleep 190 better, while co-existing on the same link with unmodified hosts. 192 2. Goals and Requirements 194 The goal is to remove as much Neighbor Discovery multicast traffic on 195 the link as possible, and handle Duplicate Address Detection (DAD) 196 without requiring the hosts to always be awake. 198 The optimization will be highly effective for links and nodes which 199 do not support multicast and for multicast networks without MLD 200 snooping switches. Moreover, in the MLD-snooping networks the MLD 201 switches will deal with less number of multicasts. 203 The requirements handle are: 205 Remove the use of multicast for DAD and Address Resolution (no 206 multicast NS messages), and remove periodic multicast RAs. Some 207 multicast RS and RA are needed to handle the arrival of new hosts 208 and routers on the link since they need to bootstrap to find each 209 other. 211 Remove the need for hosts to always be awake to defend their 212 addresses by responding to any DAD probes. 214 Ensure that the protocol is robust against single points of 215 failure and uses soft state which is automatically rebuilt after a 216 state loss. 218 A router which does not support legacy hosts will always maintain 219 a complete set of Neighbor Cache Entries (NCEs) for all hosts on 220 the link. Hence there is no need for it to send Neighbor 221 Solicitations. Thus it can avoid the problem specified in 222 [RFC6583]. 224 The optimized solution SHOULD be independent of the addresses 225 allocation mechanism. In addition to supporting SLAAC [RFC4862] 226 and DHCPv6 [RFC3315] it SHOULD also work with hosts with 'Privacy 227 Extensions for Stateless Address Autoconfiguration in 228 IPv6'[RFC4941] and with stable IPv6 private addresses 229 [I-D.ietf-6man-stable-privacy-addresses] thus it handles the 230 recommendations in [I-D.ietf-6man-default-iids]. 232 2.1. Mixed-Mode Operations 234 Mixed-Mode operation is the protocol behavior when the IPv6 subnet is 235 composed of legacy IPv6 Neighbor Discovery compliant nodes and 236 efficiency-aware IPv6 nodes implementing this specification. 238 The mixed-mode model SHOULD support arbitrary combinations of legacy 239 [RFC4861] hosts and/or routers with new hosts and/or routers on a 240 link. The introduction of one new router SHOULD provide improved 241 services to a new host, allowing the new host to avoid multicast and 242 not requiring the host to be awake to defend its IPv6 addresses using 243 DAD. 245 This document assumes that an implementation will have configuration 246 knobs to determine whether it is running in legacy IPv6 ND [RFC4861] 247 or Efficiency Aware only mode (no-legacy mode) or both (Mixed mode). 249 3. Changes to ND state management 251 These optimizations change some fundamental aspects of Neighbor 252 Discovery. Firstly, it moves the distributed address resolution 253 state (each node responding to a multicast NS for its own addresses) 254 to a set of routers which maintain a list of Address Registrations 255 for the hosts. Secondly, the information distributed in Router 256 Advertisements changes from being periodically flooded by the routers 257 to explicit requests from the hosts for refreshed information using 258 unicast Router Solicitations. 260 4. Definition Of Terms 262 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 263 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 264 document are to be interpreted as described in [RFC2119]. 266 IPv6 ND-efficiency-aware Router (NEAR): 267 A router that implements the optimizations specified in this 268 document. This router should be able to handle both legacy IPv6 269 nodes and nodes that sends registration request. 271 Efficiency-Aware Host (EAH): 272 The EAH is the host which implements the host functionality for 273 optimized Neighbor Discovery mentioned in this document. At least 274 initially implementations are likely to have a fallback to legacy 275 Neighbor Discovery when no NEAR is on the link. 277 Legacy IPv6 Host: 278 A IPv6 host that implements [RFC4861] without the extensions in 279 this document. 281 Legacy IPv6 Router: 282 A IPv6 router that implements [RFC4861] without the extensions in 283 this document. 285 Mixed mode 286 A NEAR supports both legacy hosts and EAH, with a configuration 287 knob to disable the support for legacy hosts. Some routers on the 288 link can be legacy and some can be NEAR. 290 No-legacy mode 291 A mode configured on a NEAR to not support any legacy [RFC4861] 292 hosts or routers. Opposite of mixed mode. 294 IPv6 Address Registrar 295 Normally the default router(s) on the link will act as IPv6 296 Address Registrars tracking all the EAHs. But in some cases it is 297 more efficient to use a different set of routers as Address 298 Registrars. The hosts are informed of the address registrars 299 using router advertisement messages, and register with the 300 available registrars. 302 EUI-64: 303 It is the IEEE defined 64-bit extended unique identifier formed by 304 concatenation of 24-bit or 36-bit company id value by IEEE 305 Registration Authority and the extension identifier within that 306 company-id assignment. The extension identifiers are 40-bit (for 307 24-bit company-id) or 28-bit (for the 36-bit company-id) 308 respectively. The protocol supports EUI-64 for compatibility with 309 [RFC6775]. 311 DUID 312 It is a DHCP Unique ID of a device [RFC3315]. The DUID is assumed 313 to be stable in a given IPv6 subnet. A device which does not have 314 an EUI-64 can form and use a DUID in its address registrations. 316 NCE 317 Neighbor Cache Entry. It is a conceptual data structure 318 introduced in section 5.1 of [RFC4861] and further elaborated in 319 [RFC6775]. 321 TID 322 The Transaction ID is a device generated sequence number used for 323 registration. This number is used to allow a host to have 324 concurrent registrations with different routers, while also being 325 able to robustly replace a registration with a new one. It 326 facilitates interoperability with protocols like RPL [RFC6550] 327 which use a TID internally to handle host movement. 329 5. Protocol Overview 331 In a nutshell, the following basic optimizations are made from the 332 original IPv6 Neighbor Discovery protocol [RFC4861]: 334 o Adds Node Registration with the default router(s). 336 o Address Resolution and DAD uses the registered addresses instead 337 of multicast Neighbor Solicitation messages for non-link-local 338 IPv6 addresses. 340 o Does not require unsolicited periodic Router Advertisements. 342 o Supports mixed-mode operation where legacy IPv6 hosts and routers 343 and NEARs and EAHs can co-exist on the same link. This support 344 can be configured off. 346 When a host powers on it behaves conforms to legacy ND [RFC4861] by 347 multicasting up to MAX_RTR_SOLICITATIONS Router Solicitations and 348 receives Router Advertisements. The additional information in the 349 Router Advertisements by the NEARs is used by the EAH to build a list 350 of IPv6 Address Registrars. As the host is forming its IPv6 351 addresses (using any of the many stateless and stateful IPv6 address 352 allocation mechanism) then, instead of using a multicast DAD message, 353 it unicasts an Neighbor Solicitation with the new Address 354 Registration Option (ARO) to the Registrars. Assuming an IPv6 355 addresses are not duplicate the EAH receives a Neighbor Advertisement 356 with the ARO option from the NEARs. The EAH refreshes the registered 357 addresses before they expire, thereby removing the need for the EAH 358 to be awake to defend its addresses using DAD as specified in 359 [RFC4862] as the NEARs will handle DAD. 361 The routers on the link advertise the prefixes without setting the L 362 flag. Thus only the IPv6 link-local addresses are considered on- 363 link. Thus the hosts will send packets to a default router, and the 364 default routers maintain all the registrations. Hence a router will 365 know the link-layer addresses of all the registered hosts. This 366 enables the router to forward the packet (without needing any Address 367 Resolution with the multicast Neighbor Solicitation), and also to 368 send a Redirect to the originating host informing the host of the 369 link-layer address. 371 Instead of relying on periodic multicast RAs to refresh the lifetimes 372 of prefixes etc., the hosts ask for refreshed information by 373 unicasting a Router Solicitation before the information expires. 375 The periodic multicast RAs may be used to provide new information 376 such as additional prefixes, radical reduction in the preferred and/ 377 or valid lifetime for a prefix. A host does not know to ask for such 378 information. Thus a router that wishes to quickly disseminate such 379 change can resort to a few multicast RAs, or wait for the hosts to 380 request a refresh using a Router Solicitation. 382 The routers can crash and loose all their state, including the 383 Address Registrations. On router initialization the router will 384 multicast a few initial RAs. The protocol has a Router Epoch 385 mechanism which is used by the hosts to detect that the router has 386 lost state. In that case the hosts will immediately re-register 387 allowing the router to quickly rebuild its Address Registration 388 state. 390 Normally it is sufficient for the hosts to register with all the 391 default routers on the link. However, in some cases such as 392 simplistic VRRP deployment the hosts should register with all the 393 VRRP routers even though they only know of one virtual router IPv6 394 address. And in other cases it would be more efficient to only 395 register with one router even though there are multiple default 396 routers. The RAs can contain a Registrar Address Option to 397 explicitly tell the hosts where to register. 399 Sleepy hosts are supported by this Neighbor Discovery procedures as 400 they are not woken up periodically by Router Advertisement multicast 401 messages or Neighbor Solicitation multicast messages. Sleepy nodes 402 may wake up in its own schedule and send unicast registration refresh 403 messages before the registration lifetime expiration. The 404 recommended procedure on wakeup is to unicast a Neighbor Solicitation 405 to the default router(s), which serves as DNA check [RFC6059] that 406 the host is on the same link, performs NUD against the router, and 407 includes the Address Registration Option to refresh the registration. 409 5.1. Proxying to handle Mixed mode 411 When there are one or more legacy routers on the link then the 412 recommendation is to configure those to advertise the prefixes with 413 L=0 just as the NEARs. That results in the hosts sending all packets 414 to a default router unless/until they receive a Redirect. However, 415 the legacy routers do not maintain the address registrations. Thus 416 even though all the hosts send the packets to the routers, the legacy 417 routers might in turn need to perform Address Resolution by 418 multicasting a Neighbor Solicitation per [RFC4861]. In addition, 419 legacy hosts and legacy routers will perform DAD as specified in 420 [RFC4862] that is, by sending a multicast NS and waiting for a NS or 421 NA which indicates a conflict. A EAH will not receive and respond to 422 such messages. 424 If the NEARs have been configured to operate in mixed-mode, then they 425 will respond to multicast NS messages from legacy nodes for both DAD 426 and Address Resolution. They will respond with the Target Link Layer 427 Address being that of the registered host, so that subsequent 428 communication will not go via the routers. (Implementations of 429 "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] might proxy using 430 their own MAC address as TLLA, but that is outside of the scope of 431 this document.) 433 6. New Neighbor Discovery Options and Messages 435 This specification introduces a new flag in the RAs, reuses and 436 extends the ARO option from [RFC6775] and introduces a new Registrar 437 Address option. 439 6.1. Router Advertisement flag for NEARs 441 A new Router Advertisement flag is needed in order to distinguish a 442 router advertisement sent by a NEAR, which will trigger an EAH to 443 register with the NEAR. This flag is ignored by the legacy IPv6 444 hosts. 446 The current flags field in RA is reproduced here with the added 'E' 447 bit. 449 0 1 2 3 4 5 6 7 450 +-+-+-+-+-+-+-+-+ 451 |M|O|H|Prf|P|E|R| 452 +-+-+-+-+-+-+-+-+ 454 The 'E' bit is set to 1 in a RA sent by a NEAR. In all other cases 455 the E bit MUST be 0. 457 6.2. Address Registration Option (ARO) 459 The Address Registration Option was defined in [RFC6775] for the 460 purposes of 6LowPAN and this document extends it in a backwards 461 compatible way by using some of the reserved fields. The extensions 462 are to handle different unique identifiers than EUI-64 (this document 463 specifies how to use DHCP Unique Identifiers with the ability do use 464 other identifier namespaces in the future) and a Transaction Id. 466 The Unique Interface Identifier is used by the NEARs to distinguish 467 between a refresh of an existing registration and a different host 468 trying to register an IPv6 address which is already registered by 469 some other host. Thus the requirement is that the unique id is 470 unique per link, but due to the potential for host mobility across 471 links and subnets it should be globally unique. Both an EUI-64 and a 472 DUID satisfies that requirement. 474 The TID is used by the NEARs to handle the case when due to packet 475 loss one NEAR might have a old registration and another NEAR has a 476 newer registration. The TID allows them to determine which is more 477 recent. The TID also facilitates the interaction with RPL [RFC6550]. 479 An Address Registration Option can be included in unicast Neighbor 480 Solicitation (NS) messages sent by hosts. Thus it can be included in 481 the unicast NS messages that a host sends as part of Neighbor 482 Unreachability Detection to determine that it can still reach the 483 default router(s). The ARO is used by the receiving router to 484 reliably maintain its Neighbor Cache. The same option is included in 485 corresponding Neighbor Advertisement (NA) messages with a Status 486 field indicating the success or failure of the registration. 488 When the ARO is sent by a host then, for links which have link-layer 489 addresses, a SLLA option MUST be included. The address that is 490 registered is the IPv6 source address of the Neighbor Solicitation 491 message. Typically a host would have several addresses to register, 492 with each one being registered using a separate NS containing an ARO. 493 (This approach facilitates applying SeND [RFC3971].) 495 0 1 2 3 496 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 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Type | Length | Status | Reserved | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Res | IDS |T| TID | Registration Lifetime | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | | 503 ~ Unique Interface Identifier (variable length) ~ 504 | | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 Fields: 509 Type: 33 [RFC6775] 511 Length: 8-bit unsigned integer. The length of the option 512 (including the type and length fields) in units of 8 513 bytes. The value 0 is invalid. 515 Status: 8-bit unsigned integer. Indicates the status of a 516 registration in the NA response. MUST be set to 0 in 517 NS messages. See [RFC6775]. 519 Reserved: 8 bits. This field is unused. It MUST be initialized 520 to zero by the sender and MUST be ignored by the 521 receiver. 523 Res: 4 bits. This field is unused. It MUST be initialized 524 to zero by the sender and MUST be ignored by the 525 receiver. 527 IDS: 3 bits. Identifier name Space. Indicates whether the 528 Unique Interface Identifier is a DUID or or a IEEE 529 assigned EUI-64 with room to define additional name 530 spaces. 532 T bit: One bit flag. Set if the TID octet is valid. 534 TID: 8-bit integer. It is a transaction id maintained by 535 the host and used by the NEARs to determine the most 536 recent registration. 538 Registration Lifetime: 16-bit unsigned integer. The amount of time 539 in a unit of 60 seconds that the router should retain 540 the Neighbor Cache entry for the sender of the NS that 541 includes this option. A value of zero means to remove 542 the registration. 544 Unique Interface Identifier: Variable length in multiples of 8 545 bytes. If the IDS=000, then it is an 8 byte (64 bit) 546 unmodified EUI-64. If IDS=0011 then it is a variable 547 length DUID. A DUID MUST be zero padded to a multiple 548 of 8 bytes. 550 When a node includes ARO option in a Neighbor Solicitation it MUST, 551 on links that have link-layer addresses, also include a SLLA option. 552 That option is needed so that the registrar can record the link-layer 553 address on success and send back an error if the address is a 554 duplicate. 556 6.3. Registrar Address Option (RAO) 558 Normally the Registrars are the Default Routers. However, there are 559 cases (like some approaches to handle VRRP, or coordinated separate 560 routers) where there is a need to have different (and either more or 561 less) Registrars than Default Routers. Furthermore, to robustly 562 handle NEAR state state loss this option carries a Router Epoch which 563 triggers the EAHs to re-register on a router epoch change. The RAO 564 contains the information for both of those. 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Type | Length | Num Addresses | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Reserved | Router Epoch | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | | 574 ~ IPv6 registrar addresses ~ 575 | (Num Addresses) | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | | 578 ~ Reserved for future extensions ~ 579 | | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 Fields: 584 Type: TBD (IANA) 586 Length: 8-bit unsigned integer. The length of the option 587 (including the type and length fields) in units of 8 588 bytes. The value 0 is invalid. 590 Num Addresses 16-bit unsigned integer. Set to zero if there are no 591 addresses i.e., when the option is used to only carry 592 the router epoch. NumAdressses*2 + 1 must not exceed 593 the Length. 595 Reserved 16-bit unused field. It MUST be initialized to zero 596 by the sender and MUST be ignored by the receiver. 598 Router epoch 16-bit integer. A router MUST pick a new epoch after 599 a state loss, either by keeping the epoch in stable 600 storage and incrementing it, or picking a good random 601 number. 603 IPv6 registrar addresses Zero or more IPv6 addresses, typically of 604 link-local scope. 606 The receiver MUST silently ignore any data after the IPv6 registrar 607 addresses field (such data is present when the Length is greater than 608 NumAdressses*2 + 1). 610 The Registrar Addresses are subject to the same lifetime as the 611 Default Router Lifetime (thus there is no explicit lifetime field in 612 the RAO). 614 7. Conceptual Data Structures 616 In addition to the Conceptual Data structures in [RFC4861] a EAH 617 needs to maintain the new Registrar List for each interface. The 618 Registrar List contains the set of IP addresses to which the host 619 needs to send Address Registrations. Each IP address has a Router 620 Epoch (used to determine when a router might have lost state). Also, 621 the host MAY use this data structure to track when it needs to 622 refresh its registrations with the registrar. 624 The use of explicit registrations with lifetimes plus the desire to 625 not multicast Neighbor Solicitation messages for hosts imply that we 626 manage the Neighbor Cache entries slightly differently than in 627 [RFC4861]. This results in two different types of NCEs and the types 628 specify how those entries can be removed: 630 Legacy: Entries that are subject to the normal rules in 631 [RFC4861] that allow for garbage collection 632 when low on memory. Legacy entries are created 633 only when there is no duplicate NCE. The 634 legacy entries are converted to the registered 635 entries upon successful processing of ARO. 636 Legacy type can be considered as union of 637 garbage-collectible and Tentative Type NCEs 638 described in [RFC6775]. 640 Registered: Entries that have an explicit registered 641 lifetime and are kept until this lifetime 642 expires or they are explicitly unregistered. 644 Note that the type of the NCE is orthogonal to the states specified 645 in [RFC4861]. There can only be one type of NCE for an IP address at 646 a time. 648 8. Host Behavior 650 A EAH follows [RFC4861] and applicable parts of [RFC6775] as 651 specified in this section./ 653 A EAH implementation MAY be able to fall back to [RFC4861] host 654 behavior if there is no NEAR on the link. 656 8.1. Host and/or Interface Initialization 658 A host multicasts Router Solicitation at system startup or interface 659 initialization as specified in [RFC4861] and its updates such as 660 [I-D.ietf-6man-resilient-rs]. If the interface initialization is due 661 to potential host movement or a wakeup from sleep then the host 662 initially sends a unicast Neighbor Solicitation to the default 663 router(s). 665 Unlike RFC4861 the RS MUST (on link layers which have addresses) 666 include a SLLA option, which is used by the router to unicast the RA. 668 The host is not required to join the solicited-node multicast 669 address(es) but it MUST join the all-nodes multicast address. 671 8.2. Host Receiving Router Advertisements 673 The RA is validated and processed as specified in [RFC4861] with 674 additional behavior for RAO and the Registrar List as follows. 676 When a RA is received without a RAO (but with the E flag set), or the 677 RAO contains no Registrar Addresses, then the IPv6 source address is 678 added/updated in the Registrar List. When a RA is received with a 679 RAO then the IPv6 Registrar Addresses in that option are added/ 680 updated in the data structure. 682 If those Registrar List (or entries) already exist and the Router 683 Epoch in the RAO differs from the Router Epoch in the Registrar List 684 entry, or if the entry does not exist, then the host will initiate 685 sending NS messages with ARO options to the new/updated Registration 686 List entries. Note that if the RA contains no RAO (but the E flag is 687 set) then for the purposes of the epoch comparison one should use a 688 zero Router Epoch. 690 However, if the Default Router Lifetime in the RA is zero, then any 691 matching Registration List entry (or entries) are instead deleted 692 from the Registration List. It is OPTIONAL for the host to de- 693 register when an entry is deleted from the Registration List. 695 The host can form its IPv6 address using any available mechanism - 696 SLAAC, DHCPv6, temporary addresses, etc - as the registration 697 mechanism is orthogonal and independent of the address allocation. 698 The Address Registration procedure replaces the DAD procedure in 699 [RFC4862]. 701 8.3. Timing out Registrar List entries 703 The lifetime for the Registrar List entries are taken from the 704 Default Router Lifetime in the RA. When an entry is removed the host 705 MAY send AROs with a zero Registration Lifetime to the removed 706 Registrar Addresses. 708 8.4. Sending AROs 710 When a host has formed a new IPv6 address, or when the host learns of 711 a new NEAR and has existing IPv6 addresses, then it would register 712 the new things (could be new addresses to all the existing 713 Registrars, or the all the IPv6 addresses with the new Registrar. 714 IPv6 link-local addresses are registered as well as the global 715 addresses and ULAs. 717 If the EAH has a TID then it sets the T-bit and includes the TID in 718 the ARO. When the host registers its addresses with multiple 719 Registrars it uses the same TID. However, if the host has moved 720 (lost its network attachment and determines it is attached to a 721 different link using e.g., DNA [RFC6059]), then it will increment the 722 TID value and use the new value for subsequent registrations. 724 The host places its Unique Interface Identifier (whether it is a DUID 725 or EUI-64) in the ARO. This identifier is typically kept in stable 726 storage so that the host can use the same identifier over time. It 727 MUST use the same identifier when it re-registers its address, since 728 otherwise all those will be returned as duplicates. 730 The NS which includes the ARO option MUST include a SLLA option on 731 link layers that have link-layer addresses. 733 The EAH retransmits NS messages with ARO as specified in [RFC6775] 734 until it receives a NA message from the Registrar containing an ARO. 735 The number of such retransmissions SHOULD be configurable. 737 8.5. Receiving Neighbor Advertisements 739 The Neighbor Advertisement are validated and processed as specified 740 in [RFC4861] for example to handle Neighbor Unreachability Detection 741 (NUD). In addition, the host processes any received ARO as follows. 743 If the ARO has status code 0 (Success), then the host updates the 744 information in the Registrar List to know when it next needs to 745 refresh the registered address with this Registrar. No further 746 processing is needed of the ARO. 748 If the ARO has status code 1 (Duplicate), then the host can not use 749 the IPv6 address. The host follows the address allocation protocol 750 it used to pick a new address - be that DHCPv6, temporary addresses, 751 etc. 753 If the ARO has a status code 2 (Neighbor Cache Full) in response to 754 its registration request from a Registrar, then the node SHOULD 755 continue to register the address with other Registrars (when 756 available). 758 TBD: What about other not yet defined status code values? 760 8.6. Host Management of the TID 762 It is RECOMMENDED that the EAH MAY maintain a sequence counter (TID) 763 in stable storage according to section 7 of [RFC6550]. The TID is 764 used to resolve conflicts between different registrations issues by 765 the same host for the same IPv6 address. Conflicts can be due to 766 different link-layer addresses, but it can also be due to registering 767 with different NEARs/Registrars and those routers connect use 768 protocols like RPL for routing, and RPL uses a TID to handle movement 769 vs. multi-homing. 771 Thus the same TID should be used if the host is registering its 772 addresses with multiple Registrars at the same time. But if the host 773 might have moved to a different attachment point, then it should 774 increment its TID for subsequent registrations. 776 8.7. Refreshing a Registration 778 A host SHOULD send a Registration message in order to renew its 779 registration before its registration lifetime expires in order to 780 continue its connectivity with the network. 782 This specification does not constrain the implementation. One 783 possible implementation strategy is to attempt re-register at 1/3rd 784 of the registration lifetime, and if no response try again at 2/3rd 785 of the lifetime, etc. Another possible strategy is to wait until the 786 end of the registration lifetime and then do the same relatively 787 rapid retransmissions as for the initial registration [RFC6775]. In 788 all cases the host SHOULD apply a random factor to its re- 789 registration timeout to avoid self-synchronizing behavior across lots 790 of hosts. Sleeping hosts would re-register when they are waking up 791 to do other work. 793 8.8. De-registering 795 If anytime, the node decides that it does not need a particular 796 default router's service anymore, the it SHOULD send a de- 797 registration message to that NEAR/Registrar. Similarly if the host 798 stops using a particular IPv6 address, then it SHOULD de-register 799 that address with all the Registrars it had registered with. This 800 applies even if the host was using the IPv6 address, then went to 801 sleep, and then picked a different set of IPv6 addresses. In such a 802 case it is preferred if the host de-registers before going to sleep. 804 A mobile host SHOULD first de-register its addresses before it moves 805 away from the subnet (if the mobile host can know that in advance of 806 moving.) 808 De-registration is performed by unicasting a Neighbor Solicitation 809 with an ARO where the Registration Lifetime is set to zero. Such an 810 ARO should have an incremented TID. De-registration AROs are 811 retransmitted just like other AROs as specified above. 813 8.9. Refreshing RA information 815 The EAH is responsible for asking the routers for updates to the 816 information contained in the Router Advertisements, since the NEARs 817 will not multicast such updates. That is done by sending unicast RSs 818 to the router(s) which will result in unicast RAs. However, 819 significant care is required in determining when the RSs should be 820 transmitted. 822 As part of normal operation the Default Routers, Prefixes, and other 823 RA information have lifetimes, and there are a few common cases: 825 1. The advertised lifetimes are constant i.e., the routers keep on 826 advancing the time when the information will expire. 828 2. The routers decrement the advertised lifetimes in real time i.e., 829 the information is set to expire at a determined time and 830 subsequent RAs have lower and lower lifetimes. 832 3. The routers forcibly expire some information by advertising it 833 with a zero lifetime for a while, and then stop advertising it. 835 4. A router crashes or is silently removed from the network and as a 836 result there are no more updates. For example, that default 837 router will expire and there is little benefit in trying to 838 refresh it by sending lots of RSs. 840 The host's logic for refreshing the information needs to be careful 841 to not send a large number of RSs, in particular if there is 842 information that is supposed to expire at a fixed time i.e., the 843 lifetime decrements in real time. 845 A host MUST NOT try to refresh information because its lifetime is 846 near zero, since that would cause unnecessary RSs. Instead the 847 refresh needs to be based on when the information was most recently 848 received from the router. A lifetime of 10 minutes that was heard 849 from the router 10 minutes ago might be normal as part of expiring 850 some information. But a remaining lifetime of 10 minutes for a 851 prefix that was last heard 24 hours ago with a lifetime of 24 hours 852 means that a refresh is in order. 854 It is RECOMMENDED that the host track the expiry time (the wall clock 855 time when some information will expire) and when it receives an RA 856 with that information it SHOULD check whether the expiry time is 857 moving forward, or appears to be frozen in time. That can tell the 858 difference between he first two cases above, and avoid unnecessary 859 RSs as some information naturally expires. Furthermore it is 860 RECOMMENDED that the host track which information was received from 861 which router, so that it can see when a router used to provide the 862 information no longer provides it. That helps to see if the third 863 case above might be in play. Finally, if a router has not responded 864 to a few (e.g., MAX_RTR_SOLICITATIONS) attempts to get a refresh, 865 then the router might be unreachable or dead, and there is little 866 benefit in sending further RSs to that router. When the router comes 867 back it will multicast a few RAs. 869 When the hosts determines that case 1 above is likely, then it should 870 pick a reasonable time to ask for refreshes. The exact refresh 871 behavior is not mandated by this specification, but the same 872 implementation strategies as for refreshing address registrations in 873 Section 8.7 can be considered. 875 A example simple implementation approach is to only base the 876 refreshing on the default router lifetime (thus ignore prefix and 877 other lifetime), and pick a refresh time which is 1/3 of the default 878 router lifetime. If no RA is received, a subsequent refresh can be 879 done at 2/3 of the default router lifetime. If that does not result 880 in a RA, then MAX_INITIAL_RTR_ADVERTISEMENTS can be sent as the 881 router lifetime is about to expire. Note that a default router 882 lifetime of zero MUST NOT result in sending a RS refresh based on a 883 timeout of zero. 885 If the host is unable to refresh the information and as a result ends 886 up with an empty default router list, or all the default routers are 887 marked as UNREACHABLE by NUD, then the host MAY switch to sending 888 initial multicast Router Solicitations as in Section 8.1. 890 8.10. Sleep and Wakeup 892 The protocol allows the sleepy nodes to complete its sleep schedule 893 without waking up due to periodic Router Advertisement messages or 894 due to Multicast Neighbor Solicitation for address resolution. The 895 node registration lifetime SHOULD be related with its sleep interval 896 period in order to avoid waking up in the middle of sleep for 897 registration refresh. Depending on the application, the registration 898 lifetime SHOULD be equal to or integral multiple of a node's sleep 899 interval period. 901 When a host wakes up it can combine movement detecting (DNA), NUD, 902 and refreshing its Address Registration by sending a unicast NS with 903 an ARO to its existing default router(s). 905 8.11. Receiving Redirects 907 An EAH handles Redirect messages as specified in [RFC4861]. 909 8.12. Movement Detection 911 When a host moves from one subnet to another its IPv6 prefix changes 912 and the movement detection is determined according to the existing 913 IPv6 movement detection described in [RFC6059]. 915 9. Router Behavior 917 A NEAR follows [RFC4861] and applicable parts of [RFC6775] as follows 918 in this section. 920 A NEAR SHOULD support legacy hosts and mixed mode as specified in 921 this section by being able to proxy Address Resolution and DAD. The 922 NEAR SHOULD implement a knob to be able to disable this behavior. 923 That knob can either be set to "mixed-mode" or to "no-legacy-mode". 925 The RECOMMENDED default mode of operation for the NEAR is Mixed-mode. 927 A NEAR should be configured to advertise prefixes without the on-link 928 (L-bit) unset. Furthermore, any legacy routers attached to the same 929 link as a NEAR should be configured the same way. That reduces the 930 cases in mixed mode when multicast NS messages are needed between 931 legacy hosts and routers. 933 9.1. Router and/or Interface Initialization 935 A NEAR multicasts some initial Router Advertisements 936 (MAX_INITIAL_RTR_ADVERTISEMENTS) at system startup or interface 937 initialization as specified in [RFC4861] and its updates. 939 The NEAR MUST join the all-nodes and all-routers multicast addresses. 940 In mixed mode it MUST also join the solicited-node multicast 941 address(es) for its addresses and also for all the Registered NCEs. 943 A NEAR picks a new Router Epoch if it has lost the Registered NCEs, 944 which is typically the case for router initialization. Either the 945 Router Epoch can be stored in stable storage and incremented on each 946 router initialization, or the NEAR can pick a good random number on 947 router initialization. The effect of occasionally picking the same 948 Router Epoch as before the state loss is that it will take longer for 949 the router to build up its state of Registered NCEs. 951 9.2. Receiving Router Solicitations 953 Periodic RAs SHOULD be avoided. Only solicited RAs are RECOMMENDED. 954 An RA MUST contain the Source Link-layer Address option containing 955 Router's link-layer address (this is optional in [RFC4861]. An RA 956 MUST carry any Prefix information option with L bit being unset, so 957 that hosts do not multicast any NS messages as part of address 958 resolution. A new flag (E-flag) is introduced in the RA which the 959 hosts use to distinguish a NEAR from a legacy router. 961 Unlike [RFC4861] which suggests multicast Router Advertisements, this 962 specification optimizes the exchange by always unicasting RAs in 963 response to RSs. This is possible since the RS always includes a 964 SLLA option, which is used by the router to unicast the RA. 966 If the NEAR has been configured to send an explicit set of IPv6 967 Registrar Addresses, or implements a Router Epoch, then the NEAR 968 includes a RAO in all its RAs. 970 9.3. Periodic Multicast RA for legacy hosts 972 The NEAR MUST NOT send periodic RA in no-legacy mode. In mixed mode 973 the NEAR needs to send periodic multicast RAs as specified in 974 [RFC4861] to support legacy hosts. 976 9.4. Multicast RA when new information 978 When a router has new information to share (new prefixes, prefixes 979 that should be immediately deprecated, etc) it MAY multicast up to 980 MAX_INITIAL_RTR_ADVERTISEMENTS number of Router Advertisements. Note 981 that such new information is not likely to reach sleeping hosts until 982 those hosts refresh by sending a RS. 984 9.5. Receiving ARO 986 The NEAR follows the logic in [RFC6775] for managing the NCEs and 987 responding to NS messages with the ARO option. The slight 988 modification is that instead of using an EUI-64 as the key to check 989 for duplicates, the NEAR uses the IDS value plus the variable length 990 Unique Interface Identifier value as the key. In addition the NEAR 991 checks the new TID field as follows. 993 The TID field is used together with age of a registration for 994 arbitration between two routers to ensure freshness of the 995 registration of a given target address. Same value of TID indicates 996 that both states of registration are valid. In case of a mismatch 997 between comparable TIDs, the most recent TID wins. The TIDs are 998 compared as specified in section 7 of [RFC6550]. 1000 9.6. NCE Management in NEARs 1002 When a host interacts with a router by sending Router Solicitations 1003 that does not match with the existing NCE entry of any type, a Legacy 1004 NCE is first created. Once a node successfully registers with a 1005 Router the result is a Registered NCE. As Routers send RAs to legacy 1006 hosts, or receive multicast NS messages from other Routers the result 1007 is Legacy NCEs. 1009 A Router Solicitation might be received from a host that has not yet 1010 registered its address with the router or from a legacy [RFC4861] 1011 host in the Mixed-mode operation. 1013 The router MUST NOT modify an existing Registered Neighbor Cache 1014 entry based on the SLLA option from the Router Solicitation. Thus, a 1015 router SHOULD create a tentative Legacy Neighbor Cache entry based on 1016 SLLA option when there is no match with the existing NCE. Such a 1017 legacy Neighbor Cache entry SHOULD be timed out in 1018 TENTATIVE_LEGACY_NCE_LIFETIME seconds unless a registration converts 1019 it into a Registered NCE. 1021 However, in 'Mixed-mode' operation, the router does not require to 1022 keep track of TENTATIVE_LEGACY_NCE_LIFETIME as it does not know if 1023 the RS request is from a legacy host or from a EAH. However, it 1024 creates the legacy type of NCE and updates it to a registered NCE if 1025 the ARO NS request arrives corresponding to the Legacy NCE. 1026 Successful processing of ARO will complete the NCE creation phase. 1028 If ARO did not result in a duplicate address being detected, and the 1029 registration life-time is non-zero, the router creates or updates the 1030 Registered NCE for the IPv6 address. If the Neighbor Cache is full 1031 and new entries need to be created, then the router SHOULD respond 1032 with a NA with status field set to 2. For successful creation of 1033 NCE, the router SHOULD include a copy of ARO and send NA to the 1034 requester with the status field 0. A TLLA (Target Link Layer) Option 1035 is not required with this NA. 1037 Typically for efficiency-aware routers (NEAR), the Registration 1038 Lifetime and IDS plus Unique Interface Identifier are recorded in the 1039 Neighbor Cache Entry along with the existing information described in 1040 [RFC4861]. The registered NCE are meant to be ready and reachable 1041 for communication and no address resolution is required in the link. 1042 An EAH will renew its registration to Registered NCE at the router. 1043 However the router may perform NUD towards the EAH hosts as per 1044 [RFC4861]. Should NUD fail the NEAR MUST NOT remove the Registered 1045 NCE. Instead it marks it as UNREACHABLE. 1047 9.7. Sending non-zero status in ARO 1049 If the Registration fails (due to it being a duplicate or the 1050 Neighbor Cache being full), then the NEAR will send an NA with ARO 1051 having a non-zero status. However, it needs to send that back to the 1052 originator of the failing ARO, and that host and link-layer address 1053 will not be present in the Neighbor Cache. 1055 The NEAR forms a NA with ARO, and then forms the link-layer address 1056 by using the content of the SLLA option in the NS, bypassing the 1057 Neighbor Cache to send this error. 1059 9.8. Timing out Registered NCEs 1061 The router SHOULD NOT garbage collect Registered Neighbor Cache 1062 entries since they need to retain them until the Registration 1063 Lifetime expires. If a NEAR receives a NS message from the same host 1064 one with ARO and another without ARO then the NS message with ARO 1065 gets the precedence and the NS without ARO is ignored. 1067 Similarly, if Neighbor Unreachability Detection on the router 1068 determines that the host is UNREACHABLE (based on the logic in 1069 [RFC4861]), the Neighbor Cache entry SHOULD NOT be deleted but be 1070 retained until the Registration Lifetime expires. If an ARO arrives 1071 for an NCE that is in UNREACHABLE state, that NCE should be marked as 1072 STALE. 1074 The NEAR router SHOULD deny registration to a new registration 1075 request with the status code 2 when it reaches the maximum capacity 1076 for handling the neighbor cache. 1078 9.9. Router Advertisement Consistency 1080 The NEAR follows section 6.2.7 in [RFC4861] by receiving RAs from 1081 other routers (NEAR and legacy) on the link. In addition to the 1082 checks in that section it verifies that the prefixes to not have the 1083 L flag set, and that the Registrar Address options are consistent. 1084 Two RAOs are inconsistent if they contain the have a different Router 1085 Epoch and have some IPv6 Registration Addresses in common. 1087 9.10. Sending Redirects 1089 A NEAR sends redirects (with target=destination) to inform the hosts 1090 of the link-layer address of the nodes on the link. 1092 This can be disabled on specific link types for instance, radio link 1093 technologies with hidden terminal issues. 1095 9.11. Providing Information to Routing Protocols 1097 If there is a routing protocols like RPL which wants visibility into 1098 the location of each IPv6 address, then this can be retrieved from 1099 the Registered NCEs on the NEAR. 1101 9.12. Creating Legacy NCEs 1103 In mixed-mode a NEAR will create Legacy NCEs when receiving RA, RS, 1104 and NS messages based on the source of those packets. When not it 1105 mixed-mode it needs to create Legacy NCEs for other routers by 1106 looking at those packets. 1108 9.13. Proxy Address Resolution and DAD for Legacy Hosts 1110 This section applies in mixed mode. It does not apply in no-legacy 1111 mode. 1113 A NEAR in mixed mode MUST join all solicited-node for all Registered 1114 NCEs. 1116 The NEAR SHOULD continue to support the legacy IPv6 Neighbor 1117 Solicitation requests in the mixed mode. The NEAR router SHOULD act 1118 as the ND proxy on behalf of EAH hosts for the legacy nodes' NS 1119 requests for EAH. This form of proxying is to respond with a NA that 1120 has a TLLAO taken from the Registered NCE for the target. Thus it is 1121 unlike ND Proxy as specified in [RFC4389].(Implementations of 1122 "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] might proxy using 1123 their own MAC address as TLLA, but that is outside of the scope of 1124 this document.) 1126 In the context of this specification, proxy means: 1128 o Responding to DAD probes for a registered NCE. A DAD probe from a 1129 legacy host would not contain any ARO, hence the NEAR will assume 1130 it is always a duplicate if the IPv6 target address has a 1131 Registered NCE. 1133 o Defending a registered address using NA messages with and ARO 1134 option and the Override bit set if the ARO option in the NS 1135 indicates either a different node (different IDS+Unique Interface 1136 Id) or a older registration (when comparing the TID). 1138 o Advertising a registered address using NA messages, asynchronously 1139 or as a response to a Neighbor Solicitation messages. 1141 o Looking up a destination on the link using Neighbor Solicitation 1142 messages in order to deliver packets arriving for the EAH. 1144 The NEAR SHOULD also support DAD from a EAH for IPv6 address that 1145 might be in use by a legacy node. Thus when a NEAR in mixed-mode 1146 received an ARO for a new address it SHOULD perform DAD as specified 1147 in [RFC4862] by sending a multicast DAD message. Once that times out 1148 the NEAR can respond to the ARO. If a legacy host responds to the 1149 DAD probe, then the NEAR will respond to the ARO with Status=1 1150 (Duplicate Address). 1152 10. Handling ND DoS Attack 1154 IETF community has discussed possible issues with /64 DoS attacks on 1155 the ND networks when an attacker host can send thousands of packets 1156 to the router with an on-link destination address or sending RS 1157 messages to initiate a Neighbor Solicitation from the neighboring 1158 router which will create a number of INCOMPLETE NCE entries for non- 1159 existent nodes in the network resulting in table overflow and denial 1160 of service of the existing communications. 1162 The efficiency-aware behavior documented in this specification avoids 1163 the ND DoS attacks by: 1165 o Having the hosts register with the default router(s). 1167 o Having the hosts send their packets via the default router(s). 1169 o Not resolving addresses for the routing solicitor by mandating 1170 SLLA option along with RS 1172 o Checking for duplicates in NCE before the registration 1174 o On-link IPv6-destinations on a particular link must be registered 1175 else these packets are not resolved and extra NCEs are not created 1177 In order to get maximal benefits from the ND-DoS protection from 1178 Address Registrations, the hosts and routers on the link need to be 1179 upgraded to NEARs and EAHs, respectively. With some legacy hosts the 1180 routers will still need to create INCOMPLETE NCEs and send NSs, which 1181 keeps the DoS opportunity open. However, with fewer legacy hosts the 1182 lower rate limits can be applied on creation of INCOMPLETE NCEs. 1184 11. Bootstrapping 1186 The bootstrapping mechanism described here is applicable for the 1187 efficiency-aware hosts and routers. At the start, the host uses its 1188 link-local address to send Router Solicitation and then it sends the 1189 Address Registration Option as described in this document in order to 1190 verify the IPv6 address. Note that on wakeup from sleep and after 1191 potential movement to a different link the host initially sends a 1192 unicast Neighbor Solicitation to the default router(s). 1194 The following step 3 and 4 SHOULD be repeated for all the IPv6 1195 addresses that are used for communications. 1197 Node Router 1199 0. |[Forms LL IPv6 addr] | 1201 1. | ---------- Router Solicitation --------> | 1203 | [SLLAO] | 1205 2. | <-------- Router Advertisement --------- | 1207 | [PIO + SLLAO] | 1208 | | 1210 3. | ----- Address Registration (NS) --------> | 1212 | [ARO + SLLAO] | 1214 4. | <-------- Neighbor Advertisement ------- | 1216 | [ARO with Status code] | 1218 5. ====> Address Assignment Complete 1220 Figure 1: Neighbor Discovery Address Registration and bootstrapping 1222 12. Interaction with other protocols 1224 12.1. Detecting Network Attachment (DNA) 1226 IPv6 DNA [RFC6059] uses unicast NS probes and link-layer indications 1227 to detect movement of its network attachments. That is consistent 1228 with the mechanism in this specification to unicast a NS when a host 1229 wakes up - this document recommends adding the ARO to that NS 1230 message. 1232 Thus the ND optimization solution will work seamlessly with DNA 1233 implementations and no change is required in DNA solution because of 1234 Neighbor Discovery updates. It is a deployment and configuration 1235 consideration as to run the network in mixed mode or efficient-mode. 1237 12.2. DHCPv6 Interaction 1239 The protocol mechanisms in this document are orthogonal to the 1240 address assignment mechanism in use. If DHCPv6 is used for address 1241 assignment by an EAH then, if there are one or more NEARs on the 1242 subnet, the EAH will replace the DAD check specified in [RFC3315] 1243 with Address Registration as specified in this document. 1245 12.3. Other use of Multicast 1247 Although the solution described in this document prevents unnecessary 1248 multicast messages in the IPv6 ND procedure, it does not affect 1249 normal IPv6 multicast packets nor the ability of nodes to join and 1250 leave the multicast group or forwarding multicast traffic or 1251 responding to multicast queries. 1253 12.4. VRRP Interaction 1255 A VRRP set of routers can operate with efficient-nd in two different 1256 ways: 1258 o Provide the illusion to hosts that they are a single router for 1259 the purposes of registrations. No RAO is needed in that case. 1260 But the pair needs some mechanism to synchronize their neighbor 1261 caches. Such a mechanism is out of scope of this document. 1263 o Have the hosts register with each router independently. In that 1264 case the VRRP router includes the RAO with the individual IP 1265 addresses of the routers in the pair. No synchronization of the 1266 neighbor caches are needed in that case. 1268 13. Updated Neighbor Discovery Constants 1270 This section discusses the updated default values of ND constants 1271 based on [RFC4861] section 10. New and changed constants are listed 1272 only for efficiency-aware-nd implementation. These values SHOULD be 1273 configurable and tunable to fit implementations and deployment. 1275 Router Constants: 1277 MAX_RTR_ADVERTISEMENTS(NEW) 3 transmissions 1279 MIN_DELAY_BETWEEN_RAS(CHANGED) 1 second 1281 TENTATIVE_LEGACY_NCE_LIFETIME(NEW) 30 seconds 1283 Host Constants: 1285 MAX_RTR_SOLICITATION_INTERVAL(NEW) 60 seconds 1287 Also refer to [RFC6583] , [RFC7048] and [RFC6775] for further tuning 1288 of ND constants. 1290 14. Security Considerations 1292 These optimizations are not known to introduce any new threats 1293 against Neighbor Discovery beyond what is already documented for IPv6 1294 [RFC3756]. 1296 Section 11.2 of [RFC4861] applies to this document as well. 1298 This mechanism minimizes the possibility of ND /64 DoS attacks in 1299 efficiency-aware mode. See Section 10. 1301 The mechanisms in this document work with SeND [RFC3971] in the no- 1302 legacy mode. In the mixed mode operation when a NEAR needs to 1303 respond to a legacy host sending a NS for a EAH, then SeND would not 1304 automatically fit. Potentially proxy SeND [RFC6496] could be used, 1305 but that would require explicit awareness and setup between the proxy 1306 and the proxied EAHs which seems impractical. 1308 The mechanisms in this specification are orthogonal to the address 1309 allocation thus works as well with SLAAC and DHCPv6 as the various 1310 privacy-enhanced address allocation specifications. In particular, 1311 using an EUI-64 for the Unique Interface Identifier in this protocol 1312 does not require or assume that the IPv6 addresses will be formed 1313 using the modified EUI-64 format. 1315 The mechanism uses a Unique Interface Identifier for the purposes of 1316 telling apart a re-registration from the same host and a duplicate/ 1317 conflicting registration from a different host. That unique ID is 1318 not globally visible. Currently the protocol supports DHCPv6 DUID 1319 and EUI-64 format for this I-D, but other formats which facilitate 1320 non-linkability (such as strong random numbers large enough to be 1321 unlikely to cause collisions) can be defined. 1323 15. IANA Considerations 1325 A new flag (E-bit) in RA has been introduced. IANA assignment of the 1326 E-bit flag is required upon approval of this document. 1328 This document needs a new Neighbor Discovery option type for the RAO. 1330 16. Changelog 1332 Changes from draft-chakrabarti-nordmark-energy-aware-nd-05: 1334 o Fixed typos. 1336 o Clarified that on interface initialization after sleep or 1337 potential movement the host unicasts a NS to the default 1338 router(s). 1340 o Simplified the example timer handling for refreshing RA 1341 information. 1343 o Added handling of DAD from EAH to legacy node that was included in 1344 -04 and lost in the -05 edits. 1346 Changes from draft-chakrabarti-nordmark-energy-aware-nd-04: 1348 o Significantly simplified the description of the protocol. 1350 o Added clarification on problem statement 1352 o Clarified that privacy and temporary addresses will be supported 1354 o Added an IDS field in the ARO to allow a DHCP Unique ID (DUID) as 1355 an alternative to EUI-64, with room to define other (pseudo) 1356 unique identifiers. 1358 o Allowed router redirects for NEAR. 1360 o Addressed some of comments made in the 6man list. 1362 o Added RAO to handle VRRP and similar cases when the default router 1363 list and registrar list needs to be different. 1365 o Added Router Epoch to cause re-registration on NEAR state loss. 1367 o Specified considerations for when to refresh address 1368 registrations. 1370 o Specified considerations for when to refresh RA information. 1372 17. Acknowledgements 1374 The primary idea of this document are from 6LoWPAN Neighbor Discovery 1375 document [RFC6775] and the discussions from the 6lowpan working group 1376 members, chairs Carsten Bormann and Geoff Mulligan and through our 1377 discussions with Zach Shelby, editor of the [RFC6775]. 1379 The inspiration of such a IPv6 generic document came from Margaret 1380 Wasserman who saw a need for such a document at the IOT workshop at 1381 Prague IETF. 1383 The authors acknowledge the ND denial of service issues and key 1384 causes mentioned in the draft-halpern-6man-nddos-mitigation document 1385 by Joel Halpern. Thanks to Joel Halpern for pinpointing the problems 1386 that are now addressed in the NCE management discussion in this 1387 document. 1389 The authors like to thank Dave Thaler, Stuart Cheshire, Jari Arkko, 1390 Ylva Jading, Niklas J. Johnsson, Reda Nedjar, Purvi Shah, Jaume Rius 1391 Riu, Fredrik Garneij, Andrew Yourtchenko, Jouni Korhonen, Suresh 1392 Krishnan, Brian Haberman, Anders Brandt, Mark Smith, Lorenzo Colitti, 1393 David Miles, Eric Vyncke, Mark ZZZ Smith, Mikael Abrahammsson, Eric 1394 Levy-Abignoli, and Carsten Bormann for their useful comments and 1395 suggestions on this work. 1397 18. Open Issues 1399 The known open issues are: 1401 o IPv6 link-local addresses are always on-link and in this version 1402 of the document that results in multicast NS messages. The 1403 technique used in 6LowPAN-ND is too restrictive (extract the link- 1404 layer address from the IID). Should we send link-locals to 1405 routers and depend on Redirect? 1407 o If the Router Epoch is critical then we will see a RAO in all the 1408 RAs sent by NEARs. In such a case we don't need the E-bit in the 1409 RA. 1411 o Editorial: Add Comparison with 6lowpan-nd and 4861? 1413 o Editorial: Verify and update the description in this document to 1414 make it complete removing the need to read 6LowPAN-ND. 1416 o When a router has new information for the RA, currently it takes a 1417 while to disseminate that to sleeping nodes as this depends on 1418 when the hosts send a RS. We could potentially improve this is we 1419 could have an "information epoch number" in the ARO sent in the 1420 NA. But that only helps if the registrations are refreshed more 1421 frequently that the RA information. 1423 o Future? Currently if a router changes its information, a sleeping 1424 host would not find out when it wakes up and sends the NS with 1425 ARO. That could be improved if we fit the Router Epoch in NA/ARO. 1426 But there is no room for 16 bits. 1428 o A separate but related problem is with unused NCEs due to frequent 1429 IPv6 address change e.g., hosts which pick a different set of 1430 addresses each time they wake up. This document recommends that 1431 they be de-registered by the host. That could be made simpler by 1432 introducing some Host Epoch counter in the NS/ARO. 1434 19. References 1436 19.1. Normative References 1438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1439 Requirement Levels", BCP 14, RFC 2119, March 1997. 1441 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1442 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1443 October 1998. 1445 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1446 and M. Carney, "Dynamic Host Configuration Protocol for 1447 IPv6 (DHCPv6)", RFC 3315, July 2003. 1449 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1450 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1451 September 2007. 1453 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1454 "Transmission of IPv6 Packets over IEEE 802.15.4 1455 Networks", RFC 4944, September 2007. 1457 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1458 "Neighbor Discovery Optimization for IPv6 over Low-Power 1459 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 1460 November 2012. 1462 19.2. Informative References 1464 [I-D.ietf-6man-default-iids] 1465 Gont, F., Cooper, A., Thaler, D., and W. Will, 1466 "Recommendation on Stable IPv6 Interface Identifiers", 1467 draft-ietf-6man-default-iids-00 (work in progress), 1468 January 2014. 1470 [I-D.ietf-6man-resilient-rs] 1471 Krishnan, S., Anipko, D., and D. Thaler, "Packet loss 1472 resiliency for Router Solicitations", draft-ietf-6man- 1473 resilient-rs-03 (work in progress), April 2014. 1475 [I-D.ietf-6man-stable-privacy-addresses] 1476 Gont, F., "A Method for Generating Semantically Opaque 1477 Interface Identifiers with IPv6 Stateless Address 1478 Autoconfiguration (SLAAC)", draft-ietf-6man-stable- 1479 privacy-addresses-17 (work in progress), January 2014. 1481 [I-D.vyncke-6man-mcast-not-efficient] 1482 Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A. 1483 Yourtchenko, "Why Network-Layer Multicast is Not Always 1484 Efficient At Datalink Layer", draft-vyncke-6man-mcast-not- 1485 efficient-01 (work in progress), February 2014. 1487 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1488 (IPv6) Specification", RFC 2460, December 1998. 1490 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 1491 Discovery (ND) Trust Models and Threats", RFC 3756, May 1492 2004. 1494 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1495 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1497 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1498 Addresses", RFC 4193, October 2005. 1500 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1501 Proxies (ND Proxy)", RFC 4389, April 2006. 1503 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1504 Address Autoconfiguration", RFC 4862, September 2007. 1506 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1507 Extensions for Stateless Address Autoconfiguration in 1508 IPv6", RFC 4941, September 2007. 1510 [RFC5175] Haberman, B. and R. Hinden, "IPv6 Router Advertisement 1511 Flags Option", RFC 5175, March 2008. 1513 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 1514 Detecting Network Attachment in IPv6", RFC 6059, November 1515 2010. 1517 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1518 in IPv6", RFC 6275, July 2011. 1520 [RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia- 1521 Martinez, "Secure Proxy ND Support for SEcure Neighbor 1522 Discovery (SEND)", RFC 6496, February 2012. 1524 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1525 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1526 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1527 Lossy Networks", RFC 6550, March 2012. 1529 [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object 1530 Workshop", RFC 6574, April 2012. 1532 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 1533 Neighbor Discovery Problems", RFC 6583, March 2012. 1535 [RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability 1536 Detection Is Too Impatient", RFC 7048, January 2014. 1538 Authors' Addresses 1540 Samita Chakrabarti 1541 Ericsson 1542 San Jose, CA 1543 USA 1545 Email: samita.chakrabarti@ericsson.com 1547 Erik Nordmark 1548 Arista Networks 1549 Santa Clara, CA 1550 USA 1552 Email: nordmark@sonic.net 1554 Pascal Thubert 1555 Cisco Systems 1557 Email: pthubert@cisco.com 1558 Margaret Wasserman 1559 Painless Security 1561 Email: mrw@lilacglade.org