idnits 2.17.1 draft-chakrabarti-nordmark-6man-efficient-nd-05.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 14, 2014) is 3717 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 1177, but not defined == Unused Reference: 'RFC2434' is defined on line 1397, but no explicit reference was found in the text == Unused Reference: 'RFC4944' is defined on line 1409, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 1440, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 1450, but no explicit reference was found in the text == Unused Reference: 'RFC4941' is defined on line 1459, but no explicit reference was found in the text == Unused Reference: 'RFC5175' is defined on line 1463, but no explicit reference was found in the text == Unused Reference: 'RFC6275' is defined on line 1470, 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: A later version (-06) exists of draft-ietf-6man-resilient-rs-02 -- 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 (~~), 11 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 18, 2014 P. Thubert 7 Cisco Systems 8 M. Wasserman 9 Painless Security 10 February 14, 2014 12 IPv6 Neighbor Discovery Optimizations for Wired and Wireless Networks 13 draft-chakrabarti-nordmark-6man-efficient-nd-05 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 18, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . 21 98 9.2. Receiving Router Solicitations . . . . . . . . . . . . . . 22 99 9.3. Periodic Multicast RA for legacy hosts . . . . . . . . . . 22 100 9.4. Multicast RA when new information . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . 27 113 12.1. Detecting Network Attachment (DNA) . . . . . . . . . . . . 28 114 12.2. DHCPv6 Interaction . . . . . . . . . . . . . . . . . . . . 28 115 12.3. Other use of Multicast . . . . . . . . . . . . . . . . . . 28 116 12.4. VRRP Interaction . . . . . . . . . . . . . . . . . . . . . 28 118 13. Updated Neighbor Discovery Constants . . . . . . . . . . . . . 29 119 14. Security Considerations . . . . . . . . . . . . . . . . . . . 29 120 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 121 16. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 30 122 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 123 18. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 31 124 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 125 19.1. Normative References . . . . . . . . . . . . . . . . . . . 32 126 19.2. Informative References . . . . . . . . . . . . . . . . . . 32 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 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 natural. 151 Since then we've seen a tremedous 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 hosts and usage patterns has undergone radical changes as well. 165 Hosts go to sleep when not in use to save on battery power [RFC6574] 166 or to be more energy efficient even with mains power. The 167 expectation is that waking up doesn't take much time and power 168 otherwise the benefits of sleeping are greatly reduced. Initially 169 sleeping hosts were esoteric sensor nodes, but this sleeping hosts 170 have become mainstream in smartphones. 172 Some of the above trends were observed early (e.g., Ohta-san 173 commented on Neighbor Discovery being inefficient on WiFi a long time 174 back) but the issues were not broadly understood. The issues were 175 raised in the 6LowPAN context where the desire was to run IPv6 over 176 low-power radio networks and battery operated devices. That lead to 177 defining a set of optimizations [RFC6775] for that specific category 178 of links. However, the trends are not limited to such specific link 179 types. 181 This document applies what we have learned from 6LowPAN to all link 182 types, by reusing existing support from base Neighbor Discovery (such 183 as Redirect) and from 6LowPAN (Address Registration Option) and 184 adding pieces to import the robustness with redundant routers. 186 The optimizations are done in a way to provide incremental benefits. 187 As soon as there is at least one router on a link which supports 188 these optimizations, then the updated hosts on the link can sleep 189 better. 191 2. Goals and Requirements 193 The goal is to remove as much Neighbor Discovery multicast traffic on 194 the link as possible, and handle Duplicate Address Detection (DAD) 195 without requiring the hosts to always be awake. 197 The optimization will be highly effective for links and nodes which 198 do not support multicast and as well as for a multicast network 199 without MLD snooping switches. Moreover, in the MLD-snooping 200 networks the MLD switches will deal with less number of multicasts. 202 The problems that will be addresses are: 204 Remove the use of multicast for DAD and Address Resolution (no 205 multicast NS messages), and remove periodic multicast RAs. Some 206 multicast RS and RA are needed to handle the arrival of new hosts 207 and routers on the link since they need to bootstrap to find each 208 other. 210 Remove the need for hosts to always be awake to defend their 211 addresses by responding to any DAD probes. 213 Ensure that the protocol is robust against single points of 214 failure and uses soft state which is automatically rebuilt after a 215 state loss. 217 A router which does not support legacy hosts will always maintain 218 a complete set of Neighbor Cache Entries (NCEs) for all hosts on 219 the link. Hence there is no need for it to send Neighbor 220 Solicitations. Thus it can avoid the problem specified in 221 [RFC6583]. 223 The optimized solution SHOULD be independent of the addresses 224 allocation mechanism. In addition to supporting SLAAC [RFC4862] 225 and DHCPv6 [RFC3315] it SHOULD also work with hosts with 'Privacy 226 Extensions for Stateless Address Autoconfiguration in 227 IPv6'[RFC4941] and with stable IPv6 private addresses 228 [I-D.ietf-6man-stable-privacy-addresses]. 230 2.1. Mixed-Mode Operations 232 Mixed-Mode operation is the protocol behavior when the IPv6 subnet is 233 composed of legacy IPv6 Neighbor Discovery compliant nodes and 234 efficiency-aware IPv6 nodes implementing this specification. 236 The mixed-mode model SHOULD support arbitrary combinations of legacy 237 [RFC4861] hosts and/or routers with new hosts and/or routers on a 238 link. The introduction of one new router SHOULD provide improved 239 services to a new host, allowing the new host to avoid multicast and 240 not requring the host to be awake to defend its IPv6 addresses using 241 DAD. 243 This document assumes that an implementation will have configuration 244 knobs to determine whether it is running in legacy IPv6 ND [RFC4861] 245 or Efficiency Aware only mode (no-legacy mode) or both (Mixed mode). 247 3. Changes to ND state management 249 These optimizations change some fundamental aspects of Neighbor 250 Discovery. Firstly, it moves the distributed address resolution 251 state (each node responding to a multicast NS for its own addresses) 252 to a set of routers which maintain a list of Address Registrations 253 for the hosts. Secondly, the information distributed in Router 254 Advertisements changes from being periodically flooded by the routers 255 to explicit requests from the hosts for refreshed information using 256 Router Solicitations. 258 4. Definition Of Terms 260 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 261 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 262 document are to be interpreted as described in [RFC2119]. 264 IPv6 ND-efficiency-aware Router (NEAR): 265 A router that implements the optimizations specified in this 266 document. This router should be able to handle both legacy IPv6 267 nodes and nodes that sends registration request. 269 Efficiency-Aware Host (EAH): 270 The EAH is the host which implements the host functionality for 271 optimized Neighbor Discovery mentioned in this document. At least 272 initially implementations are likely to have a fallback to legacy 273 Neighbor Discovery when no NEAR is on the link. 275 Legacy IPv6 Host: 276 A IPv6 host that implements [RFC4861] without the extensions in 277 this dociument. 279 Legacy IPv6 Router: 280 A IPv6 router that implements [RFC4861] without the extensions in 281 this dociument. 283 Mixed mode 284 A NEAR supports both legacy hosts and EAH, with a configuration 285 knob to disable the support for legacy hosts. Some routers on the 286 link can be legacy and some can be NEAR. 288 No-legacy mode 289 A mode configured on a NEAR to not support any legacy [RFC4861] 290 hosts or routers. Opposite of mixed mode. 292 IPv6 Address Registrar 293 Normally the default router(s) on the link will act as IPv6 294 Address Registrars tracking all the EAHs. But in some cases it is 295 more efficient to use a different set of routers as Address 296 Registrars. The hosts are informed of the address registrars 297 using router advertisement messages, and register with the 298 available registrars. 300 EUI-64: 301 It is the IEEE defined 64-bit extended unique identifier formed by 302 concatenation of 24-bit or 36-bit company id value by IEEE 303 Registration Authority and the extension identifier within that 304 company-id assignment. The extension identifiers are 40-bit (for 305 24-bit company-id) or 28-bit (for the 36-bit company-id) 306 respectively. The protocol supports EUI-64 for compatibility with 307 [RFC6775]. 309 DUID 310 It is a DHCP Unique ID of a device [RFC3315]. The DUID is assumed 311 to be stable in a given IPv6 subnet. A device which does not have 312 an EUI-64 can form and use a DUID in its address registrations. 314 NCE 315 Neighbor Cache Entry. It is a conceptual data structure 316 introduced in section 5.1 of [RFC4861] and further elaborated in 317 [RFC6775]. 319 TID 320 The Transaction ID is a device generated sequence number used for 321 registration. This number is used to allow a host to have 322 concurrent registrations with different routers, while also being 323 able to robustly replace a registration with a new one. It 324 facilitates interoperation with protocols like RPL [RFC6550] which 325 use a TID internally to handle host movement. 327 5. Protocol Overview 329 In a nutshell, the following basic optimizations are made from the 330 original IPv6 Neighbor Discovery protocol [RFC4861]: 332 o Adds Node Registration with the default router(s). 334 o Address Resolution and DAD uses the registered addresses instead 335 of multicast Neighbor Solicitation messages for non-link-local 336 IPv6 addresses. 338 o Does not require unsolicited periodic Router Advertisements. 340 o Supports mixed-mode operation where legacy IPv6 hosts and routers 341 and NEARs and EAHs can co-exist on the same link. This support 342 can be configured off. 344 When a host powers on it behaves conforms to legacy ND [RFC4861] by 345 multicasting up to MAX_RTR_SOLICITATIONS Router Solicitations and 346 receives Router Advertisements. The additional information in the 347 Router Advertisements by the NEARs is used by the EAH to build a list 348 of IPv6 Address Registrars. As the host is forming its IPv6 349 addresses (using any of the many statless and stateful IPv6 address 350 allocation mechanism) then, instead of using a multicast DAD message, 351 it unicasts an Neighbor Solicitation with the new Address 352 Registration Option (ARO) to the Registrars. Assuming an IPv6 353 addresses are not duplicate the EAH receives a Neighbor Advertisement 354 with the ARO option from the NEARs. The EAH refreshes the registered 355 addresses before they expire, thereby removing the need for the EAH 356 to be awake to defend its addresses using DAD as specified in 357 [RFC4862] as the NEARs will handle DAD. 359 The routers on the link advertise the prefixes without setting the L 360 flag. Thus only the IPv6 link-local addresses are considered on- 361 link. Thus the hosts will send packets to a default router, and the 362 default routers maintain all the registrations. Hence a router will 363 know the link-layer addresses of all the registered hosts. This 364 enables the router to forward the packet (without needing any Address 365 Resolution with the multicast Neighbor Solicitation), and also to 366 send a Redirect to the originating host informing the host of the 367 link-layer address. 369 Instead of relying on periodic multicast RAs to refresh the lifetimes 370 of prefixes etc, the model in efficiency-aware networks is for the 371 hosts to ask for refreshed information by unicasting a Router 372 Solicitation before the information expires. 374 The periodic multicast RAs are also used to provide new information 375 such as additional prefixes, radical reduction in the preferred 376 and/or valid lifetime for a prefix. A host does not know to ask for 377 such information. Thus a router that wishes to quickly disseminate 378 such change can resort to a few multicast RAs, or wait for the hosts 379 to request a refresh using a Router Solicitation. 381 The routers can crash and loose all their state, including the 382 Address Registrations. On router initialization the router will 383 multicast a few initial RAs. The protocol has a Router Epoch 384 mechanism which is used by the hosts to detect that the router has 385 lost state. In that case the hosts will immediately re-register 386 allowing the router to quickly rebuild its Address Registration 387 state. 389 Normally it is sufficient for the hosts to register with all the 390 default routers on the link. However, in some cases such as 391 simplistic VRRP deployment the hosts should register with all the 392 VRRP routers even though they only know of one virtual router IPv6 393 address. And in other cases it would be more efficient to only 394 register with one router even though there are multiple default 395 routers. The RAs can contain a Registrar Address Option to 396 explicitly tell the hosts where to register. 398 Sleepy hosts are supported by this Neighbor Discovery procedures as 399 they are not woken up periodically by Router Advertisement multicast 400 messages or Neighbor Solicitation multicast messages. Sleepy nodes 401 may wake up in its own schedule and send unicast registration refresh 402 messages before the registration lifetime expiration. The 403 recommended procedure on wakeup is to unicast a Neighbor Solicitation 404 to the default router(s), which serves as DNA check [RFC6059] that 405 the host is on the same link, performs NUD against the router, and 406 includes the Address Registration Option to refresh the registration. 408 5.1. Proxying to handle Mixed mode 410 When there are one or more legacy routers on the link then the 411 recommendation is to configure those to advertise the prefixes with 412 L=0 just as the NEARs. That results in the hosts sending all packets 413 to a default router unless/until they receive a Redirect. However, 414 the legacy routers do not maintain the address registrations. Thus 415 even though all the hosts send the packets to the routers, the legacy 416 routers might in turn need to perform Address Resolution by 417 multicasting a Neighbor Solicitation per [RFC4861]. In addition, 418 legacy hosts and legacy routers will perform DAD as specified in 419 [RFC4862] that is, by sending a multicast NS and waiting for a NS or 420 NA which indicates a conflict. A EAH will not receive and respond to 421 such messages. 423 If the NEARs have been configured to operate in mixed-mode, then they 424 will respond to multicast NS messages from legacy nodes for both DAD 425 and Address Resolution. They will respond with the Target Link Layer 426 Address being that of the registered host, so that subsequent 427 communication will not go via the routers. (Implementations of 428 "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] might proxy using 429 their own MAC address as TLLA, but that is outside of the scope of 430 this document.) 432 6. New Neighbor Discovery Options and Messages 434 This specification introduces a new flag in the RAs, reuses and 435 extends the ARO option from [RFC6775] and introduces a new Registrar 436 Address option. 438 6.1. Router Advertisement flag for NEARs 440 A new Router Advertisement flag is needed in order to distinguish a 441 router advertisement sent by a NEAR, which will trigger an EAH to 442 register with the NEAR. This flag is ignored by the legacy IPv6 443 hosts. 445 The current flags field in RA is reproduced here with the added 'E' 446 bit. 448 0 1 2 3 4 5 6 7 449 +-+-+-+-+-+-+-+-+ 450 |M|O|H|Prf|P|E|R| 451 +-+-+-+-+-+-+-+-+ 453 The 'E' bit is set to 1 in a RA sent by a NEAR. In all other cases 454 the E bit MUST be 0. 456 6.2. Address Registration Option (ARO) 458 The Address Registration Option was defined in [RFC6775] for the 459 purposes of 6LowPAN and this document extends it in a backwards 460 compatible way by using some of the reserved fields. The extensions 461 are to handle different unique identifiers than EUI-64 (this document 462 specifies how to use DHCP Unique Identifiers with the ability do use 463 other identifier namespaces in the future) and a Transaction Id. 465 The Unique Interface Identifier is used by the NEARs to distinguish 466 between a refresh of an existing registration and a different host 467 trying to register an IPv6 address which is already registered by 468 some other host. Thus the requirement is that the unique id is 469 unique per link, but due to the potential for host mobility across 470 links and subnets it should be globally unique. Both an EUI-64 and a 471 DUID satisfies that requirement. 473 The TID is used by the NEARs to handle the case when due to packet 474 loss one NEAR might have a old registration and another NEAR has a 475 newer registration. The TID allows them to determine which is more 476 recent. The TID also facilitates the interaction with RPL. 478 An Address Registration Option can be included in unicast Neighbor 479 Solicitation (NS) messages sent by hosts. Thus it can be included in 480 the unicast NS messages that a host sends as part of Neighbor 481 Unreachability Detection to determine that it can still reach the 482 default router(s). The ARO is used by the receiving router to 483 reliably maintain its Neighbor Cache. The same option is included in 484 corresponding Neighbor Advertisement (NA) messages with a Status 485 field indicating the success or failure of the registration. 487 When the ARO is sent by a host then, for links which have link-layer 488 addresses, a SLLA option MUST be included. The address that is 489 registered is the IPv6 source address of the Neighbor Solicitation 490 message. Typically a host would have several addresses to register, 491 with each one being registered using a separate NS containing an ARO. 492 (This approach facilitates applying SeND [RFC3971].) 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Type | Length | Status | Reserved | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Res | IDS |T| TID | Registration Lifetime | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | | 501 ~ Unique Interface Identifier (variable length) ~ 502 | | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 Fields: 507 Type: 33 [RFC6775] 509 Length: 8-bit unsigned integer. The length of the option 510 (including the type and lenth fields) in units of 8 511 bytes. The value 0 is invalid. 513 Status: 8-bit unsigned integer. Indicates the status of a 514 registration in the NA response. MUST be set to 0 in 515 NS messages. See [RFC6775]. 517 Reserved: 8 bits. This field is unused. It MUST be initialized 518 to zero by the sender and MUST be ignored by the 519 receiver. 521 Res: 4 bits. This field is unused. It MUST be initialized 522 to zero by the sender and MUST be ignored by the 523 receiver. 525 IDS: 3 bits. Identifier name Space. Indicates whether the 526 Unique Interface Identifier is a DUID or or a IEEE 527 assigned EUI-64 with room to define additional name 528 spaces. 530 T bit: One bit flag. Set if the TID octet is valid. 532 TID: 8-bit integer. It is a transaction id maintained by 533 the host and used by the NEARs to determine the most 534 recent registration. 536 Registration Lifetime: 16-bit unsigned integer. The amount of time 537 in a unit of 60 seconds that the router should retain 538 the Neighbor Cache entry for the sender of the NS that 539 includes this option. A value of zero means to remove 540 the registration. 542 Unique Interface Identifier: Variable length in multiples of 8 543 bytes. If the IDS=000, then it is an 8 byte (64 bit) 544 unmodified EUI-64. If IDS=0011 then it is a variable 545 length DUID. A DUID MUST be zero padded to a multiple 546 of 8 bytes. 548 When a node includes ARO option in a Neighbor Solicitation it MUST, 549 on links that have link-layer addresses, also include a SLLA option. 550 That option is needed so that the registrar can record the link-layer 551 address on success and send back an error if the address is a 552 duplicate. 554 6.3. Registrar Address Option (RAO) 556 Normally the Registrars are the Default Routers. However, there are 557 cases (like some approaches to handle VRRP, or coordinated separate 558 routers) where there is a need to have different (and either more or 559 less) Registrars than Default Routers. Furthermore, to robustly 560 handle NEAR state state loss this option carries a Router Epoch which 561 triggers the EAHs to re-register on a router epoch change. The RAO 562 contains the information for both of those. 564 0 1 2 3 565 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 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Type | Length | Num Addresses | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Reserved | Router Epoch | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | | 572 ~ IPv6 registratr addresses ~ 573 | (Num Addresses) | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | | 576 ~ Reserved for future extensions ~ 577 | | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Fields: 582 Type: TBD (IANA) 584 Length: 8-bit unsigned integer. The length of the option 585 (including the type and lenth fields) in units of 8 586 bytes. The value 0 is invalid. 588 Num Addresses 16-bit unsigned integer. Set to zero if there are no 589 addresses i.e., when the option is used to only carry 590 the router epoch. NumAdressses*2 + 1 must not exceed 591 the Length. 593 Reserved 16-bit unused field. It MUST be initialized to zero 594 by the sender and MUST be ignored by the receiver. 596 Router epoch 16-bit integer. A router MUST pick a new epoch after 597 a state loss, either by keeping the epoch in stable 598 storage and incrementing it, or picking a good random 599 number. 601 IPv6 registrar addresses Zero or more IPv6 addresses, typically of 602 link-local scope. 604 The receiver MUST silently ignore any data after the IPv6 registrar 605 addresses field (such data is present when the Length is greater than 606 NumAdressses*2 + 1). 608 The Registrar Addresses have their lifetime be the Default Router 609 Lifetime even when they come from the RAO (thus there is no explicit 610 lifetime in the RAO). 612 7. Conceptual Data Structures 614 In addition to the Conceptual Data structures in [RFC4861] a EAH 615 needs to maintain the new Registrar List for each interface. The 616 Registrar List contains the set of IP addresses to which the host 617 needs to send Address Registrations. Each IP address has a Router 618 Epoch (used to determine when a router might have lost state). Also, 619 the host MAY use this data structure to track when it needs to 620 refresh its registrations with the registrar. 622 The use of explicit registrations with lifetimes plus the desire to 623 not multicast Neighbor Solicitation messages for hosts imply that we 624 manage the Neighbor Cache entries slightly differently than in 625 [RFC4861]. This results in two different types of NCEs and the types 626 specify how those entries can be removed: 628 Legacy: Entries that are subject to the normal rules in 629 [RFC4861] that allow for garbage collection 630 when low on memory. Legacy entries are created 631 only when there is no duplicate NCE. The 632 legacy entries are converted to the registered 633 entries upon successful processing of ARO. 634 Legacy type can be considered as union of 635 garbage-collectible and Tentative Type NCEs 636 described in [RFC6775]. 638 Registered: Entries that have an explicit registered 639 lifetime and are kept until this lifetime 640 expires or they are explicitly unregistered. 642 Note that the type of the NCE is orthogonal to the states specified 643 in [RFC4861]. There can only be one type of NCE for an IP address at 644 a time. 646 8. Host Behavior 648 A EAH follows [RFC4861] and applicable parts of [RFC6775] as follows 649 in this section./ 651 A EAH implementation MAY be able to fall back to [RFC4861] host 652 behavior if there is no NEAR on the link. 654 8.1. Host and/or Interface Initialization 656 A host multicasts Router Solicitation at system startup or interface 657 initialization as specified in [RFC4861] and its updates such as 658 [I-D.ietf-6man-resilient-rs]. 660 Unlike RFC4861 the RS MUST (on link layers which have addresses) 661 include a SLLA option, which is used by the router to unicast the RA. 663 The host is not required to join the solicited-node multicast 664 address(es) but it MUST join the all-nodes multicast address. 666 8.2. Host Receiving Router Advertisements 668 The RA is validated and processed as specified in [RFC4861] with 669 additional behavior for RAO and the Registrar List as follows. 671 When a RA is received without a RAO (but with the E flag set), or the 672 RAO contains no Registrar Addresses, then the IPv6 source address is 673 added/updated in the Registrar List. When a RA is received with a 674 RAO then the IPv6 Registrar Addresses in that option are added/ 675 updated in the data structure. 677 If those Registrar List (or entries) already exist and the Router 678 Epoch in the RAO differs from the Router Epoch in the Registrar List 679 entry, or if the entry does not exist, then the host will initiate 680 sending NS messages with ARO options to the new/updated Registration 681 List entries. Note that if the RA contains no RAO (but the E flag is 682 set) then for the purposes of the epoch comparison one should use a 683 zero Router Epoch. 685 However, if the Default Router Lifetime in the RA is zero, then any 686 matching Registration List entry (or entries) are instead deleted 687 from the Registration List. It is OPTIONAL for the host to de- 688 register when an entry is deleted from the Registration List. 690 The host can form its IPv6 address using any available mechanism - 691 SLAAC, DHCPv6, temporary addresses, etc - as the registration 692 mechanism is orthogonal and independent of the address allocation. 693 The Address Registration procedure replaces the DAD procedure in 694 [RFC4862]. 696 8.3. Timing out Registrar List entries 698 The lifetime for the Registrar List entries are taken from the 699 Default Router Lifetime in the RA. When an entry is removed the host 700 MAY send AROs with a zero Regisration Lifetime to the removed 701 Registrar Addresses. 703 8.4. Sending AROs 705 When a host has formed a new IPv6 address, or when the host learns of 706 a new NEAR and has existing IPv6 addresses, then it would register 707 the new things (could be new addresses to all the existing 708 Registrars, or the all the IPv6 addresses with the new Registrar. 709 IPv6 link-local addresses are registered as well as the gobals and 710 ULA. 712 If the EAH has a TID then it sets the T-bit and includes the TID in 713 the ARO. When the host registers its addresses with multiple 714 Registrars it uses the same TID. However, if the host has moved 715 (lost its network attachment and determines it is attached to a 716 different link using e.g., DNA [RFC6059]), then it will increment the 717 TID value and use the new value for subsequent registrations. 719 The host places its Unique Interface Identifier (whether it is a DUID 720 or EUI-64) in the ARO. This identifier is typically kept in stable 721 storage so that the host can use the same identifier over time. It 722 MUST use the same identifer when it re-registers its address, since 723 otherwise all those will be returned as duplicates. 725 The NS which includes the ARO option MUST include a SLLA option on 726 link layers that have link-layer addresses. 728 The EAH retransmits NS messages with ARO as specified in [RFC6775] 729 until it receives a NA message from the Registrar containing an ARO. 731 The number of such retransmissions SHOULD be configurable. 733 8.5. Receiving Neighbor Advertisements 735 The Neighbor Advertisement are validated and processed as specified 736 in [RFC4861] for example to handle Neighbor Unreachability Detection 737 (NUD). In addition, the host processes any received ARO as follows. 739 If the ARO has status code 0 (Success), then the host updates the 740 information in the Registrar List to know when it next needs to 741 refresh the registered address with this Registrar. No further 742 processing is needed of the ARO. 744 If the ARO has status code 1 (Duplicate), then the host can not use 745 the IPv6 address. The host follows the address allocation protocol 746 it used to pick a new address - be that DHCPv6, tempororary 747 addresses, etc. 749 If the ARO has a status code 2 (Neighbor Cache Full) in response to 750 its registration request from a Registrar, then the node SHOULD 751 continue to register the address with other Registrars (when 752 available). 754 TBD: What about other not yet defined status code values? 756 8.6. Host Management of the TID 758 It is RECOMMENDED that the EAH MAY maintain a sequence counter (TID) 759 instable storage according to section 7 of [RFC6550]. The TID is 760 used to resolve conflicts between different registrations issues by 761 the same host for the same IPv6 address. Conflicts can be due to 762 different link-layer addresses, but it can also be due to registering 763 with different NEARs/Registrars and those routers connect use 764 protocols like RPL for routing, and RPL uses a TID to habdle movement 765 vs. multi-homing. 767 Thus the same TID should be used if the host is registering its 768 addresses with multiple Registrars at the same time. But if the host 769 might have moved to a different attachment point, then it should 770 increment its TID for subsequent registrations. 772 8.7. Refreshing a Registration 774 A host SHOULD send a Registration message in order to renew its 775 registration before its registration lifetime expires in order to 776 continue its connectivity with the network. 778 This specification does not constrain the implementation. One 779 possible implementation strategy is to attempt re-register at 1/3rd 780 of the registration lifetime, and if no response try again at 2/3rd 781 of the lifetime, etc. Another possible strategy is to wait until the 782 end of the registration lifetime and then do the same relatively 783 rapid retransmissions as for the initial registration [RFC6775]. In 784 all cases the host SHOULD apply a random factor to its re- 785 registration timeout to avoid self-synchronizing behavior across lots 786 of hosts. Sleeping hosts would re-register when they are waking up 787 to do other work. 789 8.8. De-registering 791 If anytime, the node decides that it does not need a particular 792 default router's service anymore, the it SHOULD send a de- 793 registration message to that NEAR/Registrar. Similarly if the host 794 stops using a particular IPv6 address, then it SHOULD de-register 795 that address with all the Registrars it had registered with. This 796 applies even if the host was using the IPv6 address, then went to 797 sleep, and then picked a different set of IPv6 addresses. In such a 798 case it is preferred if the host de-registers before going to sleep. 799 A mobile host SHOULD first de-register its addresses before it moves 800 away from the subnet (if the mobile host can know that in advance of 801 moving.) 803 De-registration is performed by unicasting a Neighbor Solicitation 804 with an ARO where the Registration Lifetime is zero to zero. Such an 805 ARO should have an incremented TID. De-registration AROs are 806 retransmitted just like other AROs as specified above. 808 8.9. Refreshing RA information 810 The EAH is responsible for asking the routers for updates to the 811 information contained in the Router Advertisements, since the NEARs 812 will not multicast such updates. That is done by sending unicast RSs 813 to the router(s) which will result in unicast RAs. However, 814 significant care is required in determining when the RSs should be 815 transmitted. 817 As part of normal operation the Default Routers, Prefixes, and other 818 RA information have lifetimes, and there are a few common cases: 820 1. The advertised lifetimes are constant i.e., the routers keep on 821 advancing the time when the information will expire. 823 2. The routers decrement the advertised lifetimes in real time i.e., 824 the information is set to expire at a determined time and 825 subsequent RAs have lower and lower lifetimes. 827 3. The routers forceably expire some information by advertising it 828 with a zero lifetime for a while, and then stop advertising it. 830 4. A router crashes or is silently removed from the network and as a 831 result there are no more updates. For example, that default 832 router will expire and there is little benefit in trying to 833 refresh it by sending lots of RSs. 835 The host's logic for refreshing the information needs to be careful 836 to not send a large number of RSs, in particular if there is 837 information that is supposed to expire at a fixed time i.e., the 838 lifetime decrements in real time. 840 A host MUST NOT try to refresh information because its lifetime is 841 near zero, since that would cause unnecessary RSs. Instead the 842 refresh needs to be based on when the information was most recently 843 received from the router. A lifetime of 10 minutes that was heard 844 from the router 10 minutes ago might be normal as part of expiring 845 some information. But a remaining lifetime of 10 minutes for a 846 prefix that was last heard 24 hours ago with a lifetime of 24 hours 847 means that a refresh is in order. 849 It is RECOMMENDED that the host track the expiry time (the wall clock 850 time when some information will expire) and when it receives an RA 851 with that information check whether the expiry time is moving 852 forward, or appears to be frozen in time. That can tell the 853 difference between he first two cases above, and avoid unneccesary 854 RSs as some information naturally expires. Furthermore it is 855 RECOMMENDED that the host track which information was received from 856 which router, so that it can see when a router used to provide the 857 information no longer provides it. That helps to see if the third 858 case above might be in play. Finally, if a router has not responded 859 to a few (e.g., MAX_RTR_SOLICITATIONS) attempts to get a refresh, 860 then the router might be unreachable or dead, and there is little 861 benefit in sending further RSs to that router. When the router comes 862 back it will multicast a few RAs. 864 When the hosts determines that case 1 above is likely, then it should 865 pick a reasonable time to ask for refreshes. The exact refresh 866 behavior is not mandated by this specification, but the same 867 implemention strategies as for refreshing address registrations in 868 Section 8.7 can be considered. 870 If the host is unable to refresh the information and as a result ends 871 up with an empty default router list, or all the default routers are 872 marked as UNREACHABLE by NUD, then the host MAY switch to sending 873 initial multicast Router Solicitations as in Section 8.1. 875 8.10. Sleep and Wakeup 877 The protocol allows the sleepy nodes to complete its sleep schedule 878 without waking up due to periodic Router Advertisement messages or 879 due to Multicast Neighbor Solicitation for address resolution. The 880 node registration lifetime SHOULD be related with its sleep interval 881 period in order to avoid waking up in the middle of sleep for 882 registration refresh. Depending on the application, the registration 883 lifetime SHOULD be equal to or integral multiple of a node's sleep 884 interval period. 886 When a host wakes up it can combine movement detecting (DNA), NUD, 887 and refreshing its Address Registration by sending a unicast NS with 888 an ARO to its existing default router(s). 890 8.11. Receiving Redirects 892 An EAH handles Redirect messages as specified in [RFC4861]. 894 8.12. Movement Detection 896 When a host moves from one subnet to another its IPv6 prefix changes 897 and the movement detection is determined according to the existing 898 IPv6 movement detection described in [RFC6059]. 900 9. Router Behavior 902 A NEAR follows [RFC4861] and applicable parts of [RFC6775] as follows 903 in this section. 905 A NEAR SHOULD support legacy hosts and mixed mode as specified in 906 this section by being able to proxy Address Resolution and DAD. The 907 NEAR SHOULD implement a knob to be able to disable this behavior. 908 That knob can either be set to "mixed-mode" or to "no-legacy-mode". 910 The RECOMMENDED default mode of operation for the NEAR is Mixed-mode. 912 A NEAR should be configured to advertise prefixes without the on-link 913 (L-bit) unset. Furthermore, any legacy routers attached to the same 914 link as a NEAR should be configured the same way. That reduces the 915 cases in mixed mode when multicast NS messages are needed between 916 legacy hosts and routers. 918 9.1. Router and/or Interface Initialization 920 A NEAR multicasts some initial Router Advertisements at system 921 startup or interface initialization as specified in [RFC4861] and its 922 updates. 924 The NEAR MUST join the all-nodes and all-routers multicast addresses. 925 In mixed mode it MUST also join the solicited-node multicast 926 address(es) for its addresses and also for all the Registered NCEs. 928 A NEAR picks a new Router Epoch if it has lost the Registered NCEs, 929 which is typically the case for router initialization. Either the 930 Router Epoch can be stored in stable storage and incremented on each 931 router initialization, or the NEAR can pick a good random number on 932 router initialization. The effect of occasionally picking the same 933 Router Epoch as before the state loss is that it will take longer for 934 the router to build up its state of Registered NCEs. 936 9.2. Receiving Router Solicitations 938 Periodic RAs SHOULD be avoided. Only solicited RAs are RECOMMENDED. 939 An RA MUST contain the Source Link-layer Address option containing 940 Router's link-layer address (this is optional in [RFC4861]. An RA 941 MUST carry any Prefix information option with L bit being unset, so 942 that hosts do not multicast any NS messages as part of address 943 resolution. A new flag (E-flag) is introduced in the RA which the 944 hosts use to distinguish a NEAR from a legacy router. 946 Unlike [RFC4861] which suggests multicast Router Advertisements, this 947 specification optimizes the exchange by always unicasting RAs in 948 response to RSs. This is possible since the RS always includes a 949 SLLA option, which is used by the router to unicast the RA. 951 If the NEAR has been configured to send an explicit set of IPv6 952 Registrar Addresses, or implements a Router Epoch, then the NEAR 953 includes a RAO in all its RAs. 955 9.3. Periodic Multicast RA for legacy hosts 957 The NEAR MUST NOT send periodic RA in no-legacy mode. In mixed mode 958 the NEAR needs to send periodic multicast RAs as specified in 959 [RFC4861] to support legacy hosts. 961 9.4. Multicast RA when new information 963 When a router has new information to share (new prefixes, prefixes 964 that should be immediately deprecated, etc) it MAY multicast up to 965 MAX_INITIAL_RTR_ADVERTISEMENTS number of Router Advertisements. Note 966 that such new information is not likely to reach sleeping hosts until 967 those hosts refresh by sending a RS. 969 9.5. Receiving ARO 971 The NEAR follows the logic in [RFC6775] for managing the NCEs and 972 responding to NS messages with the ARO option. The slight 973 modification is that instead of using an EUI-64 as the key to check 974 for duplicates, the NEAR uses the IDS value plus the variable length 975 Unique Interface Identifier value as the key. In addition the NEAR 976 checks the new TID field as follows. 978 The TID field is used together with age of a registration for 979 arbitration between two routers to ensure freshness of the 980 registration of a given target address. Same value of TID indicates 981 that both states of registration are valid. In case of a mismatch 982 between comparable TIDs, the most recent TID wins. The TIDs are 983 compared as specified in section 7 of [RFC6550]. 985 9.6. NCE Management in NEARs 987 When a host interacts with a router by sending Router Solicitations 988 that does not match with the existing NCE entry of any type, a Legacy 989 NCE is first created. Once a node successfully registers with a 990 Router the result is a Registered NCE. As Routers send RAs to legacy 991 hosts, or receive multicast NS messages from other Routers the result 992 is Legacy NCEs. 994 A Router Solicitation might be received from a host that has not yet 995 registered its address with the router or from a legacy [RFC4861] 996 host in the Mixed-mode operation. 998 The router MUST NOT modify an existing Registered Neighbor Cache 999 entry based on the SLLA option from the Router Solicitation. Thus, a 1000 router SHOULD create a tentative Legacy Neighbor Cache entry based on 1001 SLLA option when there is no match with the existing NCE. Such a 1002 legacy Neighbor Cache entry SHOULD be timed out in 1003 TENTATIVE_LEGACY_NCE_LIFETIME seconds unless a registration converts 1004 it into a Registered NCE. 1006 However, in 'Mixed-mode' operation, the router does not require to 1007 keep track of TENTATIVE_LEGACY_NCE_LIFETIME as it does not know if 1008 the RS request is from a legacy host or from a EAH. However, it 1009 creates the legacy type of NCE and updates it to a registered NCE if 1010 the ARO NS request arrives corresponding to the Legacy NCE. 1011 Successful processing of ARO will complete the NCE creation phase. 1013 If ARO did not result in a duplicate address being detected, and the 1014 registration life-time is non-zero, the router creates or updates the 1015 Registered NCE for the IPv6 address. If the Neighbor Cache is full 1016 and new entries need to be created, then the router SHOULD respond 1017 with a NA with status field set to 2. For successful creation of 1018 NCE, the router SHOULD include a copy of ARO and send NA to the 1019 requestor with the status field 0. A TLLA (Target Link Layer) Option 1020 is not required with this NA. 1022 Typically for efficiency-aware routers (NEAR), the Registration 1023 Lifetime and IDS plus Unique Interface Identifier are recorded in the 1024 Neighbor Cache Entry along with the existing information described in 1025 [RFC4861]. The registered NCE are meant to be ready and reachable 1026 for communication and no address resolution is required in the link. 1027 An EAH will renew its registration to Registered NCE at the router. 1028 However the router may perform NUD towards the EAH hosts as per 1029 [RFC4861]. Should NUD fail the NEAR MUST NOT remove the Registered 1030 NCE. Instead it marks it as UNREACHABLE. 1032 9.7. Sending non-zero status in ARO 1034 If the Registration fails (due to it being a duplicate or the 1035 Neighbor Cache being full), then the NEAR will send an NA with ARO 1036 having a non-zero status. However, it needs to send that back to the 1037 originator of the failing ARO, and that host and link-layer address 1038 will not be present in the Neighbor Cache. 1040 The NEAR forms a NA with ARO, and then forms the link-layer address 1041 by using the content of the SLLA option in the NS, bypassing the 1042 Neighbor Cache to send this error. 1044 9.8. Timing out Registered NCEs 1046 The router SHOULD NOT garbage collect Registered Neighbor Cache 1047 entries since they need to retain them until the Registration 1048 Lifetime expires. If a NEAR receives a NS message from the same host 1049 one with ARO and another without ARO then the NS message with ARO 1050 gets the precedence and the NS without ARO is ignored. 1052 Similarly, if Neighbor Unreachability Detection on the router 1053 determines that the host is UNREACHABLE (based on the logic in 1054 [RFC4861]), the Neighbor Cache entry SHOULD NOT be deleted but be 1055 retained until the Registration Lifetime expires. If an ARO arrives 1056 for an NCE that is in UNCREACHABLE state, that NCE should be marked 1057 as STALE. 1059 The NEAR router SHOULD deny registration to a new registration 1060 request with the status code 2 when it reaches the maximum capacity 1061 for handling the neighbor cache. 1063 9.9. Router Advertisement Consistency 1065 The NEAR follows section 6.2.7 in [RFC4861] by receiving RAs from 1066 other routers (NEAR and legacy) on the link. In addition to the 1067 checks in that section it verifies that the prefixes to not have the 1068 L flag set, and that the Registrar Address options are consistent. 1069 Two RAOs are inconsistent if they contain the have a different Router 1070 Epoch and have some IPv6 Registration Addresses in common. 1072 9.10. Sending Redirects 1074 A NEAR sends redirects (with target=destination) to inform the hosts 1075 of the link-layer address of the nodes on the link. 1077 This can be disabled on specific link types for instance, radio link 1078 technologies with hidden terminal issues. 1080 9.11. Providing Information to Routing Protocols 1082 If there is a routing protocols like RPL which wants visibility into 1083 the location of each IPv6 address, then this can be retrived from the 1084 Registered NCEs on the NEAR. 1086 9.12. Creating Legacy NCEs 1088 In mixed-mode a NEAR will create Legacy NCEs when receiving RA, RS, 1089 and NS messages based on the source of those packets. When not it 1090 mixed-mode it needs to create Legacy NCEs for other routers by 1091 looking at those packets. 1093 9.13. Proxy Address Resolution and DAD for Legacy Hosts 1095 This section applies in mixed mode. It does not apply in no-legacy 1096 mode. 1098 A NEAR in mixed mode MUST join all solicited-node for all Registered 1099 NCEs. 1101 The efficient-ND SHOULD continue to support the legacy IPv6 Neighbor 1102 Solicitation requests in the mixed mode. The NEAR router SHOULD act 1103 as the ND proxy on behalf of EAH hosts for the legacy nodes' NS 1104 requests for EAH. This form of proxying is to respond with a NA that 1105 has a TLLAO taken from the Registered NCE for the target. Thus it is 1106 unlike ND Proxy as specified in [RFC4389].(Implementations of 1107 "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] might proxy using 1108 their own MAC address as TLLA, but that is outside of the scope of 1109 this document.) 1110 In the context of this specification, proxy means: 1112 o Responding to DAD probes for a registered NCE. A DAD probe from a 1113 legacy host would not contain any ARO, hence the NEAR will assume 1114 it is always a duplicate if the IPv6 target address has a 1115 Registered NCE. 1117 o Defending a registered address using NA messages with and ARO 1118 option and the Override bit set if the ARO option in the NS 1119 indicates either a different node (different IDS+Unique Interface 1120 Id) or a older registration (when comparing the TID). 1122 o Advertising a registered address using NA messages, asynchronously 1123 or as a response to a Neighbor Solicitation messages. 1125 o Looking up a destination on the link using Neighbor Solicitation 1126 messages in order to deliver packets arriving for the EAH. 1128 10. Handling ND DoS Attack 1130 IETF community has discussed possible issues with /64 DoS attacks on 1131 the ND networks when an attacker host can send thousands of packets 1132 to the router with an on-link destination address or sending RS 1133 messages to initiate a Neighbor Solicitation from the neighboring 1134 router which will create a number of INCOMPLETE NCE entries for non- 1135 existent nodes in the network resulting in table overflow and denial 1136 of service of the existing communications. 1138 The efficiency-aware behavior documented in this specification avoids 1139 the ND DoS attacks by: 1141 o Having the hosts register with the default router(s). 1143 o Having the hosts send their packets via the default router(s). 1145 o Not resolving addresses for the routing solicitor by mandating 1146 SLLA option along with RS 1148 o Checking for duplicates in NCE before the registration 1150 o On-link IPv6-destinations on a particular link must be registered 1151 else these packets are not resolved and extra NCEs are not created 1153 In order to get maximal benefits from the ND-DoS protection from 1154 Address Registrations, the hosts and routers on the link need to be 1155 upgraded to NEARs and EAHs, respectively. With some legacy hosts the 1156 routers will still need to create INCOMPLETE NCEs and send NSs, which 1157 keeps the DoS opportunity open. However, with fewer legacy hosts the 1158 lower rate limits can be applied on creation of INCOMPLETE NCEs. 1160 11. Bootstrapping 1162 The bootstrapping mechanism described here is applicable for the 1163 efficiency-aware hosts and routers. At the start, the host uses its 1164 link-local address to send Router Solicitation and then it sends the 1165 Address Registration Option as described in this document in order to 1166 verify the IPv6 address. 1168 The following step 3 and 4 SHOULD be repeated for all the IPv6 1169 addresses that are used for communications. 1171 Node Router 1173 0. |[Forms LL IPv6 addr] | 1175 1. | ---------- Router Solicitation --------> | 1177 | [SLLAO] | 1179 2. | <-------- Router Advertisement --------- | 1181 | [PIO + SLLAO] | 1182 | | 1184 3. | ----- Address Registration (NS) --------> | 1186 | [ARO + SLLAO] | 1188 4. | <-------- Neighbor Advertisement ------- | 1190 | [ARO with Status code] | 1192 5. ====> Address Assignment Complete 1194 Figure 1: Neighbor Discovery Address Registration and bootstrapping 1196 12. Interaction with other protocols 1197 12.1. Detecting Network Attachment (DNA) 1199 IPv6 DNA [RFC6059] uses unicast NS probes and link-layer indications 1200 to detect movement of its network attachments. That is consistent 1201 with the mechanism in this specification to unicast a NS when a host 1202 wakes up - this document recommends adding the ARO to that NS 1203 message. 1205 Thus the ND optimization solution will work seamlessly with DNA 1206 implementations and no change is required in DNA solution because of 1207 Neighbor Discovery updates. It is a deployment and configuration 1208 consideration as to run the network in mixed mode or efficient-mode. 1210 12.2. DHCPv6 Interaction 1212 The protocol mechanisms in this document are orthogonal to the 1213 address assignment mechanism in use. If DHCPv6 is used for address 1214 assignment by an EAH then, if there are one or more NEARs on the 1215 subnet, the EAH will replace the DAD check specified in [RFC3315] 1216 with Address Registration as specified in this document. 1218 12.3. Other use of Multicast 1220 Although the solution described in this document prevents unnecesary 1221 multicast messages in the IPv6 ND procedure, it does not affect 1222 normal IPv6 multicast packets nor the ability of nodes to join and 1223 leave the multicast group or forwarding multicast traffic or 1224 responding to multicast queries. 1226 12.4. VRRP Interaction 1228 A VRRP set of routers can operate with efficient-nd in two different 1229 ways: 1231 o Provide the illusion to hosts that they are a single router for 1232 the purposes of registrations. No RAO is needed in that case. 1233 But the pair needs some mechanism to synchronize their neighbor 1234 caches. Such a mechanism is out of scope of this document. 1236 o Have the hosts register with each router independently. In that 1237 case the VRRP router includes the RAO with the individual IP 1238 addresses of the routers in the pair. No synchronization of the 1239 neighbor caches are needed in that case. 1241 13. Updated Neighbor Discovery Constants 1243 This section discusses the updated default values of ND constants 1244 based on [RFC4861] section 10. New and changed constants are listed 1245 only for efficiency-aware-nd implementation. These values SHOULD be 1246 configurable and tunable to fit implementations and deployment. 1248 Router Constants: 1250 MAX_RTR_ADVERTISEMENTS(NEW) 3 transmissions 1252 MIN_DELAY_BETWEEN_RAS(CHANGED) 1 second 1254 TENTATIVE_LEGACY_NCE_LIFETIME(NEW) 30 seconds 1256 Host Constants: 1258 MAX_RTR_SOLICITATION_INTERVAL(NEW) 60 seconds 1260 Also refer to [RFC6583] , [RFC7048] and [RFC6775] for further tuning 1261 of ND constants. 1263 14. Security Considerations 1265 These optimizations are not known to introduce any new threats 1266 against Neighbor Discovery beyond what is already documented for IPv6 1267 [RFC3756]. 1269 Section 11.2 of [RFC4861] applies to this document as well. 1271 This mechanism minimizes the possibility of ND /64 DoS attacks in 1272 efficiency-aware mode. See Section 10. 1274 The mechanisms in this document work with SeND [RFC3971] in the no- 1275 legacy mode. In the mixed mode operation when a NEAR needs to 1276 respond to a legacy host sending a NS for a EAH, then SeND would not 1277 automatically fit. Potentially proxy SeND [RFC6496] could be used, 1278 but that would require explicit awareness and setup between the proxy 1279 and the proxied EAHs which seems impractical. 1281 The mechanisms in this specification are orthogonal to the address 1282 allocation thus works as well with SLAAC and DHCPv6 as the various 1283 privacy-enhanced address allocation specifications. In particular, 1284 using an EUI-64 for the Unique Interface Identifier in this protocol 1285 does not require or assume that the IPv6 addresses will be formed 1286 using the modified EUI-64 format. 1288 The mechanism uses a Unique Interface Identifier for the purposes of 1289 telling apart a re-registration from the same host and a duplicate/ 1290 conflicting registration from a different host. That unique ID is 1291 not globally visible. Currently the protocol supports DHCPv6 DUID 1292 and EUI-64 format for this I-D, but other formats which facilitate 1293 non-linkability (such as strong random numbers large enough to be 1294 unlikely to cause collisions) can be defined. 1296 15. IANA Considerations 1298 A new flag (E-bit) in RA has been introduced. IANA assignment of the 1299 E-bit flag is required upon approval of this document. 1301 This document needs a new Neighbor Discovery option type for the RAO. 1303 16. Changelog 1305 Changes from draft-chakrabarti-nordmark-energy-aware-nd-04: 1307 o Significantly simplified the description of the protocol. 1309 o Added clarification on problem statement 1311 o Clarified that privacy and temporary addresses will be supported 1313 o Added an IDS field in the ARO to allow a DHCP Unique ID (DUID) as 1314 an alternative to EUI-64, with room to define other (pseudo) 1315 unique identifiers. 1317 o Allowed router redirects for NEAR. 1319 o Addressed some of comments made in the 6man list. 1321 o Added RAO to handle VRRP and similar cases when the default router 1322 list and registrar list needs to be different. 1324 o Added Router Epoch to cause re-registration on NEAR state loss. 1326 o Specified considerations for when to refresh address 1327 registrations. 1329 o Specified considerations for when to refresh RA information. 1331 17. Acknowledgements 1333 The primary idea of this document are from 6LoWPAN Neighbor Discovery 1334 document [RFC6775] and the discussions from the 6lowpan working group 1335 members, chairs Carsten Bormann and Geoff Mulligan and through our 1336 discussions with Zach Shelby, editor of the [RFC6775]. 1338 The inspiration of such a IPv6 generic document came from Margaret 1339 Wasserman who saw a need for such a document at the IOT workshop at 1340 Prague IETF. 1342 The authors acknowledge the ND denial of service issues and key 1343 causes mentioned in the draft-halpern-6man-nddos-mitigation document 1344 by Joel Halpern. Thanks to Joel Halpern for pinpointing the problems 1345 that are now addressed in the NCE management discussion in this 1346 document. 1348 The authors like to thank Dave Thaler, Stuart Cheshire, Jari Arkko, 1349 Ylva Jading, Niklas J. Johnsson, Reda Nedjar, Purvi Shah, Jaume Rius 1350 Riu, Fredrik Garneij, Andrew Yourtchenko, Jouni Korhonen, Suresh 1351 Krishnan, Brian Haberman, Anders Brandt, Mark Smith, Lorenzo Colitti, 1352 David Miles, Eric Vyncke, Mark ZZZ Smith, Mikael Abrahammsson, Eric 1353 Levy-Abignoli, and Carsten Bormann for their useful comments and 1354 suggestions on this work. 1356 18. Open Issues 1358 The known open issues are: 1360 o IPv6 link-local addresses are always on-link and in this version 1361 of the document that results in multicast NS messages. The 1362 techique used in 6LowPAN-ND is too restrictive (extract the link- 1363 layer address from the IID). Should we send link-locals to 1364 routers and depend on Redirect? 1366 o If the Router Epoch is critical then we will see a RAO in all the 1367 RAs sent by NEARs. In such a case we don't need the E-bit in the 1368 RA. 1370 o Editorial: Add Comparison with 6lowpan-nd and 4861? 1372 o When a router has new information for the RA, currently it takes a 1373 while to dissemitate that to sleeping nodes as this depends on 1374 when the hosts send a RS. We could potentially improve this is we 1375 could have an "information epoch number" in the ARO sent in the 1376 NA. But that only helps if the registrations are refreshed more 1377 frequently that the RA information. 1379 o Future? Currently if a router changes its information, a sleeping 1380 host would not find out when it wakes up and sends the NS with 1381 ARO. That could be improved if we fit the Router Epoch in NA/ARO. 1382 But there is no room for 16 bits. 1384 o A separate but related problem is with unused NCEs due to frequent 1385 IPv6 address change e.g., hosts which pick a different set of 1386 addresses each time they wake up. This document recommends that 1387 they be de-registered by the host. That could be made simpler by 1388 introducing some Host Epoch counter in the NS/ARO. 1390 19. References 1392 19.1. Normative References 1394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1395 Requirement Levels", BCP 14, RFC 2119, March 1997. 1397 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1398 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1399 October 1998. 1401 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1402 and M. Carney, "Dynamic Host Configuration Protocol for 1403 IPv6 (DHCPv6)", RFC 3315, July 2003. 1405 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1406 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1407 September 2007. 1409 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1410 "Transmission of IPv6 Packets over IEEE 802.15.4 1411 Networks", RFC 4944, September 2007. 1413 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1414 "Neighbor Discovery Optimization for IPv6 over Low-Power 1415 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 1416 November 2012. 1418 19.2. Informative References 1420 [I-D.ietf-6man-resilient-rs] 1421 Krishnan, S., Anipko, D., and D. Thaler, "Packet loss 1422 resiliency for Router Solicitations", 1423 draft-ietf-6man-resilient-rs-02 (work in progress), 1424 October 2013. 1426 [I-D.ietf-6man-stable-privacy-addresses] 1427 Gont, F., "A Method for Generating Semantically Opaque 1428 Interface Identifiers with IPv6 Stateless Address 1429 Autoconfiguration (SLAAC)", 1430 draft-ietf-6man-stable-privacy-addresses-17 (work in 1431 progress), January 2014. 1433 [I-D.vyncke-6man-mcast-not-efficient] 1434 Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A. 1435 Yourtchenko, "Why Network-Layer Multicast is Not Always 1436 Efficient At Datalink Layer", 1437 draft-vyncke-6man-mcast-not-efficient-01 (work in 1438 progress), February 2014. 1440 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1441 (IPv6) Specification", RFC 2460, December 1998. 1443 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 1444 Discovery (ND) Trust Models and Threats", RFC 3756, 1445 May 2004. 1447 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1448 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1450 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1451 Addresses", RFC 4193, October 2005. 1453 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1454 Proxies (ND Proxy)", RFC 4389, April 2006. 1456 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1457 Address Autoconfiguration", RFC 4862, September 2007. 1459 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1460 Extensions for Stateless Address Autoconfiguration in 1461 IPv6", RFC 4941, September 2007. 1463 [RFC5175] Haberman, B. and R. Hinden, "IPv6 Router Advertisement 1464 Flags Option", RFC 5175, March 2008. 1466 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 1467 Detecting Network Attachment in IPv6", RFC 6059, 1468 November 2010. 1470 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1471 in IPv6", RFC 6275, July 2011. 1473 [RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia- 1474 Martinez, "Secure Proxy ND Support for SEcure Neighbor 1475 Discovery (SEND)", RFC 6496, February 2012. 1477 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1478 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1479 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1480 Lossy Networks", RFC 6550, March 2012. 1482 [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object 1483 Workshop", RFC 6574, April 2012. 1485 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 1486 Neighbor Discovery Problems", RFC 6583, March 2012. 1488 [RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability 1489 Detection Is Too Impatient", RFC 7048, January 2014. 1491 Authors' Addresses 1493 Samita Chakrabarti 1494 Ericsson 1495 San Jose, CA 1496 USA 1498 Email: samita.chakrabarti@ericsson.com 1500 Erik Nordmark 1501 Arista Networks 1502 Santa Clara, CA 1503 USA 1505 Email: nordmark@sonic.net 1507 Pascal Thubert 1508 Cisco Systems 1510 Email: pthubert@cisco.com 1511 Margaret Wasserman 1512 Painless Security 1514 Email: mrw@lilacglade.org