idnits 2.17.1 draft-chakrabarti-nordmark-6man-efficient-nd-04.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The efficiency-aware default router MUST not send periodic RA unless it is configured to support both legacy IPv6 and efficiency-aware hosts. If the Router is configured for efficiency-aware hosts support, it MUST send Router Advertisements with E-bit flag ON and MUST NOT set 'L' bit in the advertisements. (Using the creation date from RFC4861, updated by this document, for RFC5378 checks: 2004-07-16) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2013) is 3838 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: 'RFC4861' is mentioned on line 235, but not defined == Missing Reference: 'RFC4919' is mentioned on line 317, but not defined == Missing Reference: 'RFC 3775' is mentioned on line 957, but not defined ** Obsolete undefined reference: RFC 3775 (Obsoleted by RFC 6275) == Missing Reference: 'SLLAO' is mentioned on line 981, but not defined == Missing Reference: 'RFC 3756' is mentioned on line 1190, but not defined == Unused Reference: 'LOWPANG' is defined on line 1260, but no explicit reference was found in the text == Unused Reference: 'IPV6' is defined on line 1266, but no explicit reference was found in the text == Unused Reference: 'SEND' is defined on line 1280, but no explicit reference was found in the text == Unused Reference: 'AUTOADHOC' is defined on line 1283, but no explicit reference was found in the text == Unused Reference: 'NDDOS-halpern' is defined on line 1287, but no explicit reference was found in the text == Unused Reference: 'IEEE' is defined on line 1303, but no explicit reference was found in the text == Unused Reference: 'PD' is defined on line 1306, but no explicit reference was found in the text == Unused Reference: 'IPV6M' is defined on line 1320, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 4919 (ref. 'LOWPANG') -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) == Outdated reference: A later version (-07) exists of draft-ietf-6man-impatient-nud-05 == Outdated reference: A later version (-06) exists of draft-ietf-6man-resilient-rs-01 Summary: 3 errors (**), 0 flaws (~~), 17 warnings (==), 4 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: April 25, 2014 P. Thubert 7 Cisco Systems 8 M. Wasserman 9 Painless Security 10 October 22, 2013 12 Wired and Wireless IPv6 Neighbor Discovery Optimizations 13 draft-chakrabarti-nordmark-6man-efficient-nd-04 15 Abstract 17 IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for 18 neighbor's address resolution, unreachability detection, address 19 autoconfiguration, router advertisement and solicitation. With the 20 progress of Internet adoption on various industries including home, 21 wireless, M2M and cellular networks there is a desire for optimizing 22 the legacy IPv6 Neighbor Discovery protocol. This document describes 23 a method of optimization by reducing multicast messages and 24 introducing an IPv6 address Registration mechanism. The optimization 25 of IPv6 Neighbor Discovery protocol is useful for Wirless and low- 26 power IPv6 networks and as well as Data Centers and Home Networks. 27 The solution is capable of handling existing legacy IPv6 nodes in the 28 network with local mobility. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 25, 2014. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Problem Areas . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2. Overview of the basic ND Optimization . . . . . . . . . . 5 66 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 6 67 3. Assumptions for efficiency-aware Neighbor Discovery . . . . . 8 68 4. The set of Requirements for efficiency and optimization . . . 8 69 5. Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 9 70 6. Applicability Statement . . . . . . . . . . . . . . . . . . . 10 71 7. New Neighbor Discovery Options and Messages . . . . . . . . . 10 72 7.1. Address Registration Option . . . . . . . . . . . . . . . 10 73 7.2. Refresh and De-registration . . . . . . . . . . . . . . . 12 74 7.3. A New Router Advertisement Flag . . . . . . . . . . . . . 13 75 7.4. The Transaction Identification(TID) . . . . . . . . . . . 13 76 8. Efficiency-aware Neighbor Discovery Messages . . . . . . . . . 14 77 9. Efficiency-aware Host Behavior . . . . . . . . . . . . . . . . 15 78 10. The Efficiency Aware Default Router (NEAR) Behavior . . . . . 16 79 10.1. Router Configuration Modes . . . . . . . . . . . . . . . . 17 80 10.2. Movement Detection . . . . . . . . . . . . . . . . . . . . 17 81 10.2.1. Registration ownership . . . . . . . . . . . . . . . 18 82 11. NCE Management in efficiency-aware Routers . . . . . . . . . . 18 83 11.1. Handling ND DOS Attack . . . . . . . . . . . . . . . . . . 20 84 12. Mixed-Mode Operations . . . . . . . . . . . . . . . . . . . . 21 85 13. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 22 86 14. Handling Sleepy Nodes . . . . . . . . . . . . . . . . . . . . 23 87 15. Duplicate Address Detection . . . . . . . . . . . . . . . . . 23 88 16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 24 89 17. Other Considerations . . . . . . . . . . . . . . . . . . . . . 24 90 17.1. Detecting Network Attachment(DNA) . . . . . . . . . . . . 24 91 17.2. Proxying for Efficiency-Aware hosts . . . . . . . . . . . 25 92 17.3. DHCPv6 Interaction . . . . . . . . . . . . . . . . . . . . 25 93 18. VRRP Interaction . . . . . . . . . . . . . . . . . . . . . . . 26 94 19. RPL Implications . . . . . . . . . . . . . . . . . . . . . . . 26 95 20. Updated Neighbor Discovery Constants . . . . . . . . . . . . . 26 96 21. Security Considerations . . . . . . . . . . . . . . . . . . . 27 97 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 98 23. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 27 99 24. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 100 25. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 101 25.1. Normative References . . . . . . . . . . . . . . . . . . . 28 102 25.2. Informative References . . . . . . . . . . . . . . . . . . 28 103 Appendix A. Usecase Analysis . . . . . . . . . . . . . . . . . . 30 104 A.1. Data Center Routers on the link . . . . . . . . . . . . . 30 105 A.2. Edge Routers and Home Networks . . . . . . . . . . . . . . 30 106 A.3. M2M Networks . . . . . . . . . . . . . . . . . . . . . . . 30 107 A.4. Wi-fi Networks . . . . . . . . . . . . . . . . . . . . . . 31 108 A.5. 3GPP Networks . . . . . . . . . . . . . . . . . . . . . . 31 109 A.6. Industrial Networks . . . . . . . . . . . . . . . . . . . 31 110 A.7. Set and forget offline network . . . . . . . . . . . . . . 31 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 113 1. Introduction 115 Conceptually, IPv6 multicast messages are supposed to avoid broadcast 116 messages, but in practice, the multicast operation at the link level 117 is that of a broadcast nevertheless. This did not matter much at the 118 time ND [ND] was originally designed, when an Ethernet network was 119 more or less a single shared wire, but since then, large scale switch 120 fabrics, low power sleeping devices, mobile wireless/cellular devices 121 and virtual machines have changed the landscape dramatically. 123 In a modern switch fabric, a number of intermediate devices (such as 124 switches, routers and security middle boxes) host IPv6 State 125 Maintaining Entities (SMEs) holding information such as the location 126 of an IPv6 address or its mapping with a MAC address. Such 127 intermediate devices include Wireless Controllers that terminate a 128 overlay tunnel and rapidly re-enable reachability for mobile 129 devices(L2/L3), Network edge devices performing subscriber access, 130 network devices that protect the ownership of an IPv6 address, 131 Overlay networks in data centers, Home Networks for IPv6 clients. 133 In general, there is a need for enhancing the IPv6 ND [ND] to make it 134 less chatty and flexible to work with different types of networking 135 elements, physical and virtual networks and at the same time 136 maintaining the IPv6 states to avoid duplicates or denial of 137 services. 139 1.1. Problem Areas 141 Specifically, the following are the issues with the IPv6 deployment 142 in many wireless and high-density IPv6 subnets today: 143 o The periodic RA messages in IPv6 ND [ND], and NS/NA messages 144 require all IPv6 nodes in the link to be in listening mode even 145 when they are in idle cycle. It requires energy for the sleepy 146 nodes which may otherwise be sleeping during the idle period. 147 Non-sleepy nodes also spends more energy since they are in 148 continuous listening mode. With the explosion of Internet-of- 149 things and machine to machine communication, more and more devices 150 would be using IPv6 addresses in the near future. 151 o With WIFI, a multicast message will consume the wireless link on 152 all Access Points around a switched fabric and will be transmitted 153 at the lowest speed possible in order to ensure the maximum 154 reception by all wireless nodes. This means that in an 155 environment where bandwidth is scarce, a single multicast packet 156 may consume the bandwidth for hundreds of unicast packets. Sadly, 157 IPv6 ND is a major source of multicast messages in wireless 158 devices, since such messages are triggered each time a wireless 159 device changes its point of attachment. 161 o In a datacenter, where VM mobility and VM address reslution also 162 trigger storms of IPv6 ND multicast messages, which become a major 163 hassle as the number of VM may scale to the tens of thousands in a 164 large Data Center. At the IETF, a WG discusses such problems with 165 Address Resolution in Massive Datacenters (ARMD). 167 The following paragraph elaborates the source of all the multicast 168 messages in IPv6 ND. 170 Following power-on and initialization of the network in IPv6 Ethernet 171 networks, a node joins the solicited-node multicast address on the 172 interface and then performs duplicate address detection (DAD) for the 173 acquired link-local address by sending a solicited-node multicast 174 message to the link. After that it sends multicast router 175 solicitation (RS) messages to the all-router address to solicit 176 router advertisements. Once the host receives a valid router 177 advertisement (RA) with the "A" flag, it autoconfigures the IPv6 178 address with the advertised prefix in the router advertisement (RA). 179 Besides this, the IPv6 routers usually send router advertisements 180 periodically on the network. RAs are sent to the all-node multicast 181 address. The minimum RA interval range can be 3sec to 600sec 182 depending on applications. Nodes send Neighbor Solicitation (NS) and 183 Neighbor Advertisement (NA) messages to resolve the IPv6 address of 184 the destination on the link. These NS/NA messages are also often 185 multicast messages and it is assumed that the node is on the same 186 link and relies on the fact that the destination node is always 187 powered and generally available. 189 1.2. Overview of the basic ND Optimization 191 In a nutshell, the following basic optimizations are made from the 192 original IPv6 Neighbor Discovery protocol [ND]: 193 o Adds Node Registration at the default subnet-router 194 o Introduces a EUI-64 identifier for identification during 195 initiation 196 o Does not require unsolicited periodic Router Advertisements 197 o No multicast messages required for address resolution and DAD for 198 non-link-local IP addresses 199 o Introduces a short-lived temporary NCE entry for unregistered 200 nodes that turns into a regular NCE upon registration 201 o Supports mixed mode operations where legacy IPv6 nodes and 202 enahnced optimized routers can co-exist during the transition 203 period. 205 EUI-64 identifiers are recommended as unique Interface Identifiers, 206 however if the network is isolated from the Internet, uniqueness of 207 the identifiers may be obtained by other mechanisms such as a random 208 number generator with lowest collision rate. Although, the ND 209 optimization [6LOWPAN-ND] applies to 6LoWPAN [LOWPAN] networks, the 210 concept is mostly applicable to power-aware IPv6 networks. 211 Therefore, this document generalizes the address registration and 212 multicast reduction in [6LOWPAN-ND] to all IPv6 links. 214 Thus optimizing the regular IPv6 Neighbor Discovery [ND] to minimize 215 total number of related signaling messages without losing generality 216 of Neighbor Discovery, autoconfiguration and reliable host-router 217 communication, are desirable in any modern IPv6 networks such as 218 Home, Enterprise networks, Data Centers and Operator's Cellular/ 219 Wireless networks. 221 The optimization will be highly effective for links and nodes which 222 do not support multicast and as well as for a multicast network 223 without MLD snooping switches. Moreover, in the MLD-snooping 224 networks the MLD switches will deal with less number of multicasts. 226 The goal of this document is to provide an efficient Neighbor 227 Discovery Protocol in classic IPv6 subnets in wireless/wired links. 228 In the process, the node registration method is also deemed to be 229 useful for preventing Neighbor Discovery denial of service ( ND DOS) 230 attacks. 232 The proposed changes can be used in two different ways. In one case 233 all the hosts and routers on a link implement the new mechanisms, 234 which gives the maximum benefits. In another case the link has a 235 mixture of new hosts and/or routers and legacy [RFC4861] hosts and 236 routers, operating in a mixed-mode providing some of the benefits. 238 In the following sections the document describes the basic operations 239 of registration methods, optimization of Neighbor Discovery messages, 240 interoperability with legacy IPv6 implementations and provides a 241 section on use-case scenarios where it can be typically applicable. 242 This document also describes an optional feature for enabling node 243 mobility in the LLN network using backbone routers(BBR) or multiple 244 default subnet routers. This optional feature generates a sequence 245 ID by the host in the registration message for deploying some routing 246 protocols (example: RPL [RFC6550]) with reliability in the LLN. 248 2. Definition Of Terms 250 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 251 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 252 document are to be interpreted as described in [RFC2119]. 254 multi-level Subnets: 255 A wireless link determined by one IPv6 off-link prefix in a 256 network where in order to reach a destination with same prefix a 257 packet may have to travel through one or more 'intermediate' 258 routers which relay the packet to the next 'intermediate' router 259 or the host in its own. 260 Border Router(BR): 261 A border router is typically located at the junction of Internet 262 and Home Network. An IPv6 router with one interface connected to 263 an IPv6 subnet and other interface connecting to a non-classic 264 IPv6 interface such as 6LoWPAN interface. A Border router is 265 usually the gateway between the IPv6 network and Internet. 266 Backbone: 267 This is an IPv6 transit link that interconnects 2 or more Low 268 Power Lossy Networks (LLNs). It is expected to be deployed as a 269 high speed backbone in order to federate a potentially large set 270 of LLN nodes. Also referred to as a LLN backbone or Backbone 271 network in this document. 272 Backbone Router: 273 An IPv6 router that federates the LLN using a transit link as a 274 backbone. A BBR acts as a 6LoWPAN Border Router (6LBR) and an 275 Efficiency Aware Default Router (NEAR). 276 Efficiency-Aware Network: 277 An Efficiency-Aware network is composed of network elements that 278 are sensitive to energy usage or number of signaling messages in 279 the network. An efficiency-aware network may also contain links 280 that do not support multicast or it does not have MLD snooping 281 capabilities and yet the network likes to communicate most 282 efficiently with minimum number of signaling messages. Data 283 center networks with virtual machines, cellular IPv6 networks, any 284 IPv6 networks with energy-sensitive nodes are examples of 285 Efficiency-Aware networks. 286 IPv6 ND-efficiency-aware Router(NEAR): 287 The default Router of the single hop IPv6 subnet. This router 288 implements the optimizations specified in this document. This 289 router should be able to handle both legacy IPv6 nodes and nodes 290 that sends registration request. 291 Efficiency-Aware Host(EAH): 292 A host in a IPv6 network is considered a IPv6 node without routing 293 and forwarding capability. The EAH is the host which implements 294 the host functionality for optimized Neighbor Discovery mentioned 295 in this document. 296 Legacy IPv6 Host: 297 A host in a IPv6 network is considered a IPv6 node without routing 298 and forwarding capability and implements RFC 4861 host functions. 300 Legacy IPv6 Router: 301 An IPv6 Router which implements RFC 4861 Neighbor Discovery 302 protocols. 303 EUI-64: 304 It is the IEEE defined 64-bit extended unique identifier formed by 305 concatenation of 24-bit or 36-bit company id value by IEEE 306 Registration Authority and the extension identifier within that 307 company-id assignment. The extension identifiers are 40-bit (for 308 24-bit company-id) or 28-bit (for the 36-bit company-id) 309 respectively. 310 LLN: 311 It is a low power and lossy network where nodes are typically 312 constrained in system resources and energy, for instance battery 313 powered nodes. Alternately LLN could be a network of line-powered 314 nodes with radio links with lossy characteristics. Wifi, ZigBee, 315 Celular networks are examples of such a network. 316 Extended LLN: 317 This is the aggregation of multiple LLNs as defined in [RFC4919] 318 interconnected by a Backbone Link via Backbone Routers and forming 319 a single IPv6 link. 321 3. Assumptions for efficiency-aware Neighbor Discovery 323 o The efficiency-aware nodes in the network carry unique interface 324 ID in the network in order to form the auto-configured IPv6 325 address uniquely. An EUI-64 interface ID required for global 326 communication. 327 o All nodes are single IPv6-hop away from their default router in 328 the subnet. 329 o /64-bit IPv6 prefix is used for Stateless Auto-address 330 configuration (SLAAC). The IPv6 Prefix may be distributed with 331 Router Advertisement (RA) from the default router to all the nodes 332 in that link. 333 o The efficiency-aware node MAY maintain a sequence counter in 334 permanent memory according to section 7 of RFC 6550. 336 4. The set of Requirements for efficiency and optimization 338 o Node Registration: Node initiated Registration and address 339 allocation is done in order to avoid periodic multicast Router 340 Advertisement messages and often Neighbor Address resolution can 341 be skipped as all packets go via the default router which now 342 knows about all the registered nodes. Node Registration enables 343 reduction of all-node and solicited-node multicast messages in the 344 subnet. 346 o Address allocation of registered nodes [ND] are performed using 347 IPv6 Autoconfiguration [AUTOCONF]. 348 o Host initiated Registration and Refresh is done by sending a 349 Router Solicitation and then a Neighbor Solicitation Message using 350 Address Registration Option (described below). 351 o The node registration may replace the requirement of doing 352 Duplicate Address Detection. 353 o Sleepy hosts are supported by this Neighbor Discovery procedures 354 as they are not woken up periodically by Router Advertisement 355 multicast messages or Neighbor Solicitation multicast messages. 356 Sleepy nodes may wake up in its own schedule and send unicast 357 registration refresh messages when needed. 358 o Since this document requires formation of an IPv6 address with an 359 unique 64-bit Interface ID(EUI-64) is required for global IPv6 360 addresses, if the network is an isolated one and uses ULA [ULA] as 361 its IPv6 address then the deployment should make sure that each 362 MAC address in that network has unique address and can provide a 363 unique 64-bit ID for each node in the network. 364 o A /64-bit Prefix is required to form the IPv6 address. 365 o MTU requirement is same as IPv6 network. 367 5. Basic Operations 369 In the efficient-nd IPv6 Network, the NEAR routers are the default 370 routers for the efficiency-aware hosts (EAH). During the startup or 371 joining the network the host does not wait for the Router 372 Advertisements as the NEAR routers do not perform periodic multicast 373 RA as per RFC 4861. Instead, the EAH sends a multicast RS to find 374 out a NEAR router in the network. The RS message is the same as in 375 RFC 4861. The advertising routers in the link responds to the RS 376 message with RA with Prefix Information Option and any other options 377 configured in the network. If EAH hosts will look for a RA from a 378 NEAR (E-flag) and choose a NEAR as its default router and 379 consequently sends a unicast Neighbor Solicitation Message with ARO 380 option in order to register itself with the default router. The EAH 381 does not do Duplicate Address Detection or NS Resolution of 382 addresses. NEAR maintains a binding of registered nodes and 383 registration life-time information along with the neighbor Cache 384 information. The NEAR is responsible for forwarding all the messages 385 from its EAH including on-link messages from one EAH to another. For 386 details of protocol operations please see the sections below. 388 When a IPv6 network consists of both legacy hosts and EAH, and if the 389 NEAR is configured for 'mixed mode' operation, it should be able to 390 handle Address Registration Option(ARO) requests and send periodic 391 RA. Thus it should be able to serve both efficiency-aware hosts and 392 legacy hosts. Similarly, a legacy host compatible EAH falls back to 393 RFC 4861 host behavior if a NEAR is not present in the link. See the 394 section on 'Mixed Mode Operations' for details below. 396 6. Applicability Statement 398 This document aims to guide implementers to choose an appropriate 399 IPv6 neighbor discovery and Address configuration procedures suitable 400 for any efficient IPv6 network. These optimizations are equally 401 useful for the energy-sensitive, non-multicast links and for 402 classical IPv6 networks i.e. home networks, Data-Center IPv6 overlay 403 networks where saving Neighbor Discovery messages will reduce cost 404 and increase bandwidth availability. 406 The address registration mechanism and associated extension to the 407 Neighbor Discovery protocol allow a low-power host to move between 408 the LLN and the classic IPv6 networks as well as movement from one 409 Border Router registration area to another while staying within the 410 same IPv6 subnet. 412 Note that the specification allows 'Mixed-mode' operation in the 413 efficiency-aware nodes for backward compatibility and transitioning 414 to a complete efficiency-aware network of hosts and routers. Though 415 the efficiency-aware only nodes will minimize the ND signaling and 416 DOS attacks in the LAN. 418 Applicability of this solution is limited to the legacy IPv6 nodes 419 and subnets and it optimizes the generic IPv6 signaling activities at 420 network layer. However, further optimization at the application 421 layers are possible for increased efficiency based on particular use- 422 cases and applications. 424 7. New Neighbor Discovery Options and Messages 426 This section will discuss the registration and de-registration 427 procedure of the hosts in the network. 429 7.1. Address Registration Option 431 The Address Registration Option(ARO) is useful for avoiding Duplicate 432 Address Detection messages since it requires a unique EUI-64 ID for 433 registration. The address registration is used for maintaining 434 reachability of the node or host by the router. This option is 435 almost the same ARO as in [6LOWPAN-ND]. A Transaction ID field and a 436 corresponding bit have been introduced in order to detect duplicate 437 address registration and local mobility of a node. 439 The routers keep track of host IP addresses that are directly 440 reachable and their corresponding link-layer addresses. This is 441 useful for lossy and lowpower networks(LLN) and as well as wired IPv6 442 networks. An Address Registration Option (ARO) can be included in 443 unicast Neighbor Solicitation (NS) messages sent by hosts. Thus it 444 can be included in the unicast NS messages that a host sends as part 445 of Neighbor Unreachability Detection to determine that it can still 446 reach a default router. The ARO is used by the receiving router to 447 reliably maintain its Neighbor Cache. The same option is included in 448 corresponding Neighbor Advertisement (NA) messages with a Status 449 field indicating the success or failure of the registration. This 450 option is always host initiated. 452 The ARO is required for reliability and power saving. The lifetime 453 field provides flexibility to the host to register an address which 454 should be usable (the reachability information may be propagated to 455 the routing protocols) during its intended sleep schedule of nodes 456 that switches to frequent sleep mode. 458 The sender of the NS also includes the EUI-64 of the interface it is 459 registering an address from. This is used as a unique ID for the 460 detection of duplicate addresses. It is used to tell the difference 461 between the same node re-registering its address and a different node 462 (with a different EUI-64) registering an address that is already in 463 use by someone else. The EUI-64 is also used to deliver an NA 464 carrying an error Status code to the EUI-64 based link-local IPv6 465 address of the host. 467 When the ARO is used by hosts and SLLA option MUST be included [ 468 except for the point-to-point links (example: IP-in-IP tunnel)] and 469 the target address for to-be registered node MUST be the IPv6 source 470 address of the Neighbor Solicitation message. 472 Note that a node should be able to register with a default router 473 with multiple IPv6 addresses (including privacy addresses). 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Type | Length = 2 | Status | Reserved | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Reservd |T| TID | Registration Lifetime | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | | 483 + EUI-64 or equivalent + 484 | | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Fields: 487 Type: 33 ( See [6LOWPAN-ND] ) 488 Length: 8-bit unsigned integer. The length of the option in 489 units of 8 bytes. Always 2. 490 Status: 8-bit unsigned integer. Indicates the status of a 491 registration in the NA response. MUST be set to 0 in 492 NS messages. See below. 493 Reserved: This field is unused. It MUST be initialized to zero 494 by the sender and MUST be ignored by the receiver. 495 TID: 8-bit integer. It is a transaction id maintained by 496 the host and incremented with each registration. it is 497 recommended that the node maintains a persistent 498 storage for TID. TID is used as a sequence counter to 499 detect the most recent registration request from a 500 host and its mobility within the same subnet across 501 multiple default Border Routers. Its operation 502 follows section 7 of RPL [RFC6550] for sequence 503 counters. 504 Registration Lifetime: 16-bit unsigned integer. The amount of time 505 in a unit of 60 seconds that the router should retain 506 the Neighbor Cache entry for the sender of the NS that 507 includes this option. 508 EUI-64: 64 bits. This field is used to uniquely identify the 509 interface of the registered address by including the 510 EUI-64 identifier assigned to it unmodified. 511 T bit: One bit flag. Set if the TID octet is present for 512 processing. 514 The Status values used in Neighbor Advertisements are: 516 +--------+--------------------------------------------+ 517 | Status | Description | 518 +--------+--------------------------------------------+ 519 | 0 | Success | 520 | 1 | Duplicate Address | 521 | 2 | Neighbor Cache Full | 522 | 3 | Registration Ownership Response | 523 | 4-255 | Allocated using Standards Action [RFC2434] | 524 +--------+--------------------------------------------+ 526 Table 1 528 7.2. Refresh and De-registration 530 A host SHOULD send a Registration message in order to renew its 531 registration before its registration lifetime expires in order to 532 continue its connectivity with the network. If anytime, the node 533 decides that it does not need the default router's service anymore, 534 it MUST send a de-registration message - i,e, a registration message 535 with lifetime being set to zero. A mobile host SHOULD first de- 536 register with the default router before it moves away from the 537 subnet. 539 7.3. A New Router Advertisement Flag 541 A new Router Advertisement flag [RF] is needed in order to 542 distinguish a router advertisement from a efficiency-aware default 543 router or a legacy IPv6 router. This flag is ignored by the legacy 544 IPv6 hosts. EAH hosts use this flag in order to discover a NEAR 545 router if it receives multiple RA from both legacy and NEAR routers. 547 0 1 2 3 4 5 6 7 548 +-+-+-+-+-+-+-+-+ 549 |M|O|H|Prf|P|E|R| 550 +-+-+-+-+-+-+-+-+ 552 The 'E' bit above MUST be 1 when a IPv6 router implements and 553 configures the efficiency-aware Router behavior for Neighbor 554 Discovery as per this document. All other cases the E bit MUST be 0. 556 The legacy IPv6 hosts will ignore the E bit in RA advertisement. All 557 EAH MUST look for E bit in RA in order to determine the efficiency- 558 aware support in the default router in the link. 560 7.4. The Transaction Identification(TID) 562 The TID field is used together with age of a registration for 563 arbitration between two routers (default or backbone) to ensure 564 freshness and ownership of the registration of a given target 565 address. Same value of TID indicates that both states of 566 registration are valid. In case of a mismatch between comparable 567 TIDs, the most recent TID wins. The TID definition used in section 568 6.4.1 of RFC 6550 for DAOSequence number would be applicable for here 569 for TID in ARO message. 571 It is 8 bit field. TID is generated by the host at the time of a new 572 registraton request. 574 This document assumes that an implementation will have configuration 575 knobs to determine whether it is running in classical IPv6 ND [ND] or 576 Efficiency Aware ND (this document) mode or both(Mixed mode). 578 8. Efficiency-aware Neighbor Discovery Messages 580 Router Advertisement(RA): Periodic RAs SHOULD be avoided. Only 581 solicited RAs are RECOMMENDED. An RA MUST 582 contain the Source Link-layer Address option 583 containing Router's link-layer address (this 584 is optional in [ND]. An RA MUST carry Prefix 585 information option with L bit being unset, so 586 that hosts do not multicast any NS messages 587 as part of address resolution. A new flag 588 (E-flag) is introduced in the RA in order to 589 characterize the efficiency-aware mode 590 support. Unlike RFC4861 which suggests 591 multicast Router Advertisements, this 592 specification optimizes the exchange by 593 always unicasting RAs in response to RS. 594 This is possible since the RS always includes 595 a SLLA option, which is used by the router to 596 unicast the RA. 597 Router Solicitation(RS): Upon system startup, the node sends a 598 multicast or link broadcast (when multicast 599 is not supported at the link-layer) RS to 600 find out the available routers in the link. 601 An RS may be sent at other times as described 602 in section 6.3.7 of RFC 4861. A Router 603 Solicitation MUST carry Source Link-layer 604 Address option except for the point-to-point 605 links. Since no periodic RAs are allowed in 606 the efficiency-aware IPv6 network, the host 607 may send periodic unicast RS to the routers. 608 The time-periods for the RS varies on the 609 deployment scenarios and the Default Router 610 Lifetime advertised in the RAs. 611 Default Router Selection: Same as in section 6.3.6 of RFC 4861[ND]. 612 Neighbor Solicitation (NS): Neighbor solicitation is used between 613 the hosts and the default-router as part of 614 NUD and registering the host's address(es). 615 An NS message MUST use the Address 616 Registration option in order to accomplish 617 the registration. 618 Neighbor Advertisement (NA): As defined in [ND] and ARO option. 619 Redirect Messages: A router SHOULD NOT send a Redirect message 620 to a host since the link has non-transitive 621 reachability. The host behavior is same as 622 described in section 8.3 of RFC 4861[ND], 623 i,e. a host MUST NOT send or accept redirect 624 messages when in efficiency-aware mode. 626 Same as in RFC 4861[ND] 627 MTU option: As per the RFC 4861. 628 Address Resolution: No NS/NA are sent as the prefixes are treated 629 as off-link. Thus no address resolution is 630 performed at the hosts. The routers keep 631 track of Neighbor Solicitations with Address 632 Registration options(ARO) and create an 633 extended neighbor cache of reachable 634 addresses. The router also knows the nexthop 635 link-local address and corresponding link- 636 layer address when it wants to route a 637 packet. 638 Neighbor Unreachability Detection(NUD): NUD is performed in 639 "forward-progress" fashion as described in 640 section 7.3.1 of RFC 4861[ND]. However, if 641 Address Registration Option is used, the NUD 642 SHOULD be combined with the Re-registration 643 of the node. This way no extra message for 644 NUD is required. 646 9. Efficiency-aware Host Behavior 648 A host sends Router Solicitation at the system startup and also when 649 it suspects that one of its default routers have become 650 unreachable(after NUD fails). The EAH MUST process the E-bit in RA 651 as described in this document. The EAH MUST use ARO option to 652 register with the neighboring NEAR router. 654 A host SHOULD be able to autoconfigure its IPv6 addresses using the 655 IPv6 prefix obtained from Router Advertisement. The host SHOULD form 656 its link-local address from the EUI-64 as specified by IEEE 657 Registration Authority and RFC 2373. If this draft feature is 658 implemented and configured, the host MUST NOT re-direct Neighbor 659 Discovery messages. The host is not required to join the solicited- 660 node multicast address but it MUST join the all-node multicast 661 address. 663 A host always sends packets to (one of) its default router(s). This 664 is accomplished by the routers never setting the 'L' flag in the 665 Prefix options. 667 The EAH host may register with more than one default routers in a 668 subnet but it SHOULD use one default primary router for a source IP- 669 address at a time. 671 If an EAH receives a status code 2 in response to its registration 672 request from a NEAR router, the node MUST be able to choose another 673 router to register with (when available). 675 The host is unable to forward routes or participate in a routing 676 protocol. A legacy IPv6 Host compliant EAH SHOULD be able to fall 677 back to RFC 4861 host behavior if there is no efficiency-aware router 678 (NEAR) in the link. 680 The efficiency-aware host MUST NOT send or accept re-direct messages. 681 It does not join solicited node multicast address. 683 If the EAH is capable of generating TID and configured for this 684 operation, the EAH MUST use the TID field and appropriate associated 685 operation bits in the ARO message during registration and refresh. 687 In some cases, hosts may need to send MAX_RTR_SOLICITATIONS(3) to 688 receive the reply back from the default router. In a lossy link or 689 due to sleepy default router, the hosts may have to send more than 3 690 solicitations [Resilient-RS]. But this can easily increase the 691 number of siganling traffic in the network. Thus it is RECOMMENDED 692 that the EAH nodes start with the default MAX_RTR_SOLICITATION [ND] 693 value in a low power network. 695 However, in some scenarios the packet loss resilient router 696 solicitation method may be applicable [Resilient-RS]. 698 10. The Efficiency Aware Default Router (NEAR) Behavior 700 The main purpose of the default router in the context of this 701 document is to receive and process the registration request, forward 702 packets from one neighbor to the other, informs the routing protocol 703 about the un-availability of the registered nodes if the routing 704 protocol requires this information for the purpose of mobility or 705 fast convergence. A default router (NEAR) behavior may be observed 706 in one or more interfaces of a Border Router(BR). 708 A Border Router normally may have multiple interfaces and connects 709 the nodes in a link like a regular IPv6 subnet(s) or acts as a 710 gateway between separate networks such as Internet and home networks 711 . The Border Router is responsible for distributing one or more /64 712 prefixes to the nodes to identify a packet belonging to the 713 particular network. One or more of the interfaces of the Border 714 Router may be connected with the efficiency-aware hosts or a 715 efficiency-aware router(NEAR). 717 The efficiency-aware default router MUST not send periodic RA unless 718 it is configured to support both legacy IPv6 and efficiency-aware 719 hosts. If the Router is configured for efficiency-aware hosts 720 support, it MUST send Router Advertisements with E-bit flag ON and 721 MUST NOT set 'L' bit in the advertisements. 723 The router SHOULD NOT garbage collect Registered Neighbor Cache 724 entries since they need to retain them until the Registration 725 Lifetime expires. If a NEAR receives a NS message from the same host 726 one with ARO and another without ARO then the NS message with ARO 727 gets the precedence and the NS without ARO is ignored. This behavior 728 protects the router from Denial Of Service attacks. Similarly, if 729 Neighbor Unreachability Detection on the router determines that the 730 host is UNREACHABLE (based on the logic in [ND]), the Neighbor Cache 731 entry SHOULD NOT be deleted but be retained until the Registration 732 Lifetime expires. If an ARO arrives for an NCE that is in 733 UNCREACHABLE state, that NCE should be marked as STALE. 735 A default router keeps a cache for all the nodes' IP addresses, 736 created from the Address Registration processing. 738 The NEAR router SHOULD deny registration to a new registration 739 request with the status code 2 when it reaches the maximum capacity 740 for handling the neighbor cache. 742 10.1. Router Configuration Modes 744 An efficiency-aware Router(NEAR) MUST be able to configure in 745 efficiency-aware-only mode where it will expect all hosts register 746 with the router following RS; thus NEAR will not support legacy 747 hosts. However, it will create legacy NCE for the routers in the 748 network assuming that the routers do not register with it. This mode 749 is able to prevent ND flooding on the link. 751 An efficiency-aware Router(NEAR) SHOULD be able to have configuration 752 knob to configure itself in Mixed-Mode where it will support both 753 efficiency-aware hosts and legacy hosts. However even in mixed-mode 754 the router should check for duplicate entries in the NCE before 755 creating a new ones and it should rate-limit creating new NCE based 756 on requests from the same host MAC address. 758 The RECOMMENDED default mode of operation for the efficiency-aware 759 router is Mixed-mode. Though it cannot reap the full benefit of 760 efficiency related optimization described in this document. 762 10.2. Movement Detection 764 When a host moves from one subnet to another its IPv6 prefix changes 765 and the movement detection is determined according to the existing 766 IPv6 movement detection described in [DNA]. 768 However, if the movement happens across different default routers in 769 the subnet and the node likes to register with one of the default 770 routers closest to its present location, it MUST send another 771 registration request to the new default router. The new default 772 router then first sends a NS to its peers with a link scope multicast 773 message to IPv6 address ff02::2 with the ARO option. 775 10.2.1. Registration ownership 777 The subnet-local-routers check their respective NCE table for the 778 particular registration. If the registration entry exists, the NEAR 779 default router then calculates the 'age' of the registration by 780 subtracting the present time from the registration received time 781 recorded at the NCE. The NEAR router then responds with a NA with 782 ARO option Status being equal to 3 and replaces the 'registration 783 lifetime' field with the 'age' of registration. Upon receiving the 784 NA from the neighboring routers the prospective default router 785 determines its registration ownership. If the other router 786 registration age is higher than its own registration age, then the 787 current router is considered to have the most recent registration 788 ownership. 790 If both routers registration age are zero or within 791 MAX_REG_AGE_DIFFERENCE window, then the TID field is used to 792 determine the ownership. The higher value of TID wins. Note that 793 the registration ownership and local movement detection behavior in 794 NEAR router MUST be optionally configured. The NEAR routers MAY 795 implement this feature. Configuring this option is needed when the 796 NEAR routers are used in a low power and lossy network environment. 798 11. NCE Management in efficiency-aware Routers 800 The use of explicit registrations with lifetimes plus the desire to 801 not multicast Neighbor Solicitation messages for hosts imply that we 802 manage the Neighbor Cache entries slightly differently than in [ND]. 803 This results in two different types of NCEs and the types specify how 804 those entries can be removed: 806 Legacy: Entries that are subject to the normal rules in 807 [ND] that allow for garbage collection when low 808 on memory. Legacy entries are created only 809 when there is no duplicate NCE. In mixed-mode 810 and efficiency-aware mode the legacy entries 811 are converted to the registered entries upon 812 successful processing of ARO. Legacy type can 813 be considered as union of garbage-collectible 814 and Tentative Type NCEs described in 816 [6LOWPAN-ND]. 817 Registered: Entries that have an explicit registered 818 lifetime and are kept until this lifetime 819 expires or they are explicitly unregistered. 821 Note that the type of the NCE is orthogonal to the states specified 822 in [ND]. 824 When a host interacts with a router by sending Router Solicitations 825 that does not match with the existing NCE entry of any type, a Legacy 826 NCE is first created. Once a node successfully registers with a 827 Router the result is a Registered NCE. As Routers send RAs to legacy 828 hosts, or receive multicast NS messages from other Routers the result 829 is Legacy NCEs. There can only be one kind of NCE for an IP address 830 at a time. 832 A Router Solicitation might be received from a host that has not yet 833 registered its address with the router or from a legacy[ND] host in 834 the Mixed-mode of operation. 836 In the 'Efficiency-aware' only mode the router MUST NOT modify an 837 existing Neighbor Cache entry based on the SLLA option from the 838 Router Solicitation. Thus, a router SHOULD create a tentative Legacy 839 Neighbor Cache entry based on SLLA option when there is no match with 840 the existing NCE. Such a legacy Neighbor Cache entry SHOULD be timed 841 out in TENTATIVE_LEGACY_NCE_LIFETIME seconds unless a registration 842 converts it into a Registered NCE. 844 However, in 'Mixed-mode' operation, the router does not require to 845 keep track of TENTATIVE_LEGACY_NCE_LIFETIME as it does not know if 846 the RS request is from a legacy host or the efficiency-aware hosts. 847 However, it creates the legacy type of NCE and updates it to a 848 registered NCE if the ARO NS request arrives corresponding to the 849 legacy NCE. Successful processing of ARO will complete the NCE 850 creation phase. 852 If ARO did not result in a duplicate address being detected, and the 853 registration life-time is non-zero, the router creates and updates 854 the registered NCE for the IPv6 address. If the Neighbor Cache is 855 full and new entries need to be created, then the router SHOULD 856 respond with a NA with status field set to 2. For successful 857 creation of NCE, the router SHOULD include a copy of ARO and send NA 858 to the requestor with the status field 0. A TLLA(Target Link Layer) 859 Option is not required with this NA. 861 Typically for efficiency-aware routers (NEAR), the registration life- 862 time and EUI-64 are recorded in the Neighbor Cache Entry along with 863 the existing information described in [ND]. The registered NCE are 864 meant to be ready and reachable for communication and no address 865 resolution is required in the link. The efficiency-aware hosts will 866 renew their registration to keep maintain the state of reachability 867 of the NCE at the router. However the router may do NUD to the idle 868 or unreachable hosts as per [ND]. 870 In addition, NEAR default routers MUST associate a record of the age 871 of the registration. 'Age' is a simple way to detect movement of a 872 node from local default router to another. 'Age' information SHOULD 873 contain System-time when the registration is first created or last 874 refreshed. This system-time is deducted from the current system-time 875 to determine the "age" of the registration and it is used for age 876 reporting with Neighbor advertisement for selection of registration 877 ownership among the default-router contenders in case of local 878 movement of the host from one default-router to another in the same 879 subnet. 'Age' is always considered zero for a fresh registration or 880 a registration refresh message. 882 11.1. Handling ND DOS Attack 884 IETF community has discussed possible issues with /64 DOS attacks on 885 the ND networks when an attacker host can send thousands of packets 886 to the router with an on-link destination address or sending RS 887 messages to initiate a Neighbor Solicitation from the neighboring 888 router which will create a number of INCOMPLETE NCE entries for non- 889 existent nodes in the network resulting in table overflow and denial 890 of service of the existing communications. 892 The efficiency-aware behavior documented in this specification avoids 893 the ND DOS attacks by: 895 o Having the hosts register with the default router 896 o Having the hosts send their packets via the default router 897 o Not resolving addresses for the Routing Solicitor by mandating 898 SLLA option along with RS 899 o Checking for duplicates in NCE before the registration 900 o Checking against the MAC-address and EUI-64 id is possible now for 901 NCE matches 902 o On-link IPv6-destinations on a particular link must be registered 903 else these packets are not resolved and extra NCEs are not created 905 It is RECOMMENDED that Mixed-mode operation and legacy hosts SHOULD 906 NOT be mixed in the IPv6 link in order to avoid the ND DOS attacks. 907 For the general case of Mixed-mode the router does not create 908 INCOMPLETE NCEs for the registered hosts, but it follows the [ND] 909 steps of NCE states for legacy hosts. 911 12. Mixed-Mode Operations 913 Mixed-Mode operation discusses the protocol behavior where the IPv6 914 subnet is composed with legacy IPv6 Neighbor Discovery compliant 915 nodes and efficiency-aware IPv6 nodes implementing this 916 specification. 918 The mixed-mode model SHOULD support the following configurations in 919 the IPv6 link: 920 o The legacy IPv6 hosts and efficiency-aware-hosts in the network 921 and a NEAR router 922 o legacy IPv6 default-router and efficiency-aware hosts(EAH) in the 923 link 924 o one router is in mixed mode and the link contains both legacy IPv6 925 hosts and EAH 926 o A link contains both efficiency-aware IPv6 router and hosts and 927 legacy IPv6 routers and hosts and each host should be able to 928 communicate with each other. 930 In mixed-mode operation, a NEAR MUST be configured for mixed-mode in 931 order to support the legacy IPv6 hosts in the network. In mixed- 932 mode, the NEAR MUST act as proxy for Neighbor Solicitation for DAD 933 and Address Resolution on behalf of its registered hosts on that 934 link. It should follow the NCE management for the EAH as described 935 in this document and follow RFC 4861 NCE management for the legacy 936 IPv6 hosts. Both in mixed-mode and efficiency-aware mode, the NEAR 937 sets E-bit flag in the RA and does not set 'L' on-link bit. 939 If a NEAR receives NS message from the same host one with ARO and 940 another without ARO then the NS message with ARO gets the precedence. 942 An efficiency-aware Host implementation SHOULD support falling back 943 to legacy IPv6 node behavior when no efficiency-aware routers are 944 available in the network during the startup. If the EAH was 945 operational in efficiency-aware mode and it determines that the NEAR 946 is no longer available, then it should send a RS and find an 947 alternate default router in the link. If no efficiency-aware router 948 is indicated from the RA, then the EAH SHOULD fall back into RFC 4861 949 behavior. On the other hand, in the efficiency-aware mode EAH SHOULD 950 ignore multicast Router Advertisements(RA) sent by the legacy and 951 Mixed-mode routers in the link. 953 In mixed mode operation, the Router SHOULD be able to do local 954 movement detection based on ARO from EAH hosts. For the legacy 955 hosts, the mixed-mode router MAY follow classical IPv6 methods of 956 movement detection and MAY act as ND proxy by sending NA with 'O' 957 bit.[RFC 3775] 958 The routers that are running on efficiency-aware mode or legacy mode 959 SHOULD NOT dynamically switch the mode without flushing the Neighbor 960 Cache Entries. 962 In mixed mode, the NEAR SHOULD have a configurable interval for 963 periodic unsolicited router advertisements based on the media type. 965 13. Bootstrapping 967 The bootstrapping mechanism described here is applicable for the 968 efficiency-aware hosts and routers. At the start, the host uses its 969 link-local address to send Router Solicitation and then it sends the 970 Node Registration message as described in this document in order to 971 form the address. The Duplicate address detection process should be 972 skipped if the network is guaranteed to have unique interface 973 identifiers which is used to form an IPv6 address. 975 Node Router 977 0. |[Forms LL IPv6 addr] | 979 1. | ---------- Router Solicitation --------> | 981 | [SLLAO] | 983 2. | <-------- Router Advertisement --------- | 985 | [PIO + SLLAO] | 986 | | 988 3. | ----- Address Registration (NS) --------> | 990 | [ARO + SLLAO] | 992 4. | <-------- Neighbor Advertisement ------- | 994 | [ARO with Status code] | 996 5. ====> Address Assignment Complete 998 Figure 1: Neighbor Discovery Address Registration and bootstrapping 1000 In the mixed mode operation, it is expected that logically there will 1001 be at least one legacy IPv6 router and another NEAR router present in 1002 the link. The legacy IPv6 router will follow RFC 4861 behavior and 1003 NEAR router will follow the efficiency-aware behavior for 1004 registration, NCE maintenance, forwarding packets from a EAH and it 1005 will also act as a ND proxy for the legacy IPv6 hosts querying to 1006 resolve a EAH node. 1008 A legacy IPv6 host and EAH are not expected to see a difference in 1009 their bootstrapping if both legacy and efficiency-aware 1010 functionalities of rotuers are available in the network. It is 1011 RECOMMENDED that the EAH implementation SHOULD be able to behave like 1012 a legacy IPv6 host if it discovers that no efficiency-aware routing 1013 support is present in the link. 1015 14. Handling Sleepy Nodes 1017 The solution allows the sleepy nodes to complete its sleep schedule 1018 without waking up due to periodic Router Advertisement messages or 1019 due to Multicast Neighbor Solicitation for address resolution. The 1020 node registration lifetime SHOULD be synchronized with its sleep 1021 interval period in order to avoid waking up in the middle of sleep 1022 for registration refresh. Depending on the application, the 1023 registration lifetime SHOULD be equal to or integral multiple of a 1024 node's sleep interval period. 1026 15. Duplicate Address Detection 1028 In efficiency-aware mode, there is no need for Duplicate Address 1029 Detection(DAD) assuming that the deployment ensures unique 64bit 1030 identification availability for each registered host. In the event 1031 of collision of EUI64 field of ARO by two registration requests, the 1032 later request is denied if the first one is a valid request. The 1033 denied EAH node SHOULD pick another alternative IPv6 address to 1034 register to prevent further registration denial. The method of 1035 assignment of alternate IPv6 address is out of scope of this 1036 document. 1038 In some networks there are multiple default routers and the 1039 registering node may move from one default router (where it was 1040 registered before) to another default router in the same subnet. 1041 Thus in order to differentiate between the duplicate request and the 1042 movement, the router checks the 64-bit MAC address and 'age' of the 1043 request. If there is an entry in the node already with 0 < 'age' < 1044 registration-life-time and the TID field of the existing entry and 1045 the new request is same with TID of the new request, it is a 1046 duplicate. 1048 If the default router does not have a registered entry for this host, 1049 it should check whether it is a local movement. Please see 'Mobility 1050 Consideration section' for details. 1052 16. Mobility Considerations 1054 If the hosts move from one subnet to another, they MUST first de- 1055 register and then register themselves in the new subnet or network. 1056 If a node moves away without de-registration and returns to the 1057 network before the registration lifetime expires, its registration is 1058 still considered valid. For run-away nodes the registration expires 1059 after the lifetime expiry or due to unreachablity whichever comes 1060 first. Otherwise, the regular IPv6 Mobility [IPV6M]behavior applies. 1062 In the multiple default router scenario, a node may move from its 1063 current primary default router to a prospective primary default 1064 router. At this point, the default routers use Neighbor 1065 Advertisements(NA) to arbitrate the latest ownership of the 1066 registration of host. The ownership of registration is useful for 1067 the Border Routers if they participate in a routing protocol which 1068 advertises proximity preferences or adjusts its own forwarding 1069 preference based on the host registration. This kind of forwarding 1070 or routing mechanisms are useful for energy efficiency and 1071 performance of the networks. See 'Movement Detection' section for 1072 details. 1074 17. Other Considerations 1076 17.1. Detecting Network Attachment(DNA) 1078 IPv6 DNA[DNA] uses unicast ND probes and link-layer indications to 1079 detect movement of its network attachments. Upon detecting link- 1080 layer indication, it sends a all-routers Solicitation message. When 1081 the node implements this document along with DNA, it MUST send ARO 1082 option with its Neighbor Solicitation unicast message if the 1083 candidate router advertisement indicates that the router is a NEAR 1084 router. If the candiate router is a legacy router then and it is the 1085 only choice then the EAH host SHOULD adapt to the legacy behavior. 1086 However if EAH node implements DNA host capability as well, then it 1087 SHOULD give preference to the NEAR routers in its candidate list of 1088 routers. 1090 Thus the ND optimization solution will work seamlessly with DNA 1091 implementations and no change is required in DNA solution because of 1092 Neighbor Discovery updates. It is a deployment and configuration 1093 consideration as to run the network in mixed mode or efficient-mode. 1095 17.2. Proxying for Efficiency-Aware hosts 1097 The efficient-ND SHOULD continue to support the legacy IPv6 Neighbor 1098 Solicitation requests in the mixed mode. The NEAR router SHOULD act 1099 as the ND proxy on behalf of EAH hosts for the legacy nodes' NS 1100 requests for EAH. 1102 In the context of this specification, proxy ND means: defending a 1103 registered address over the backbone using NA messages with and ARO 1104 option and the Override bit set if the ARO option in the NS indicates 1105 either a different node (different EUI-64) or a older registration 1106 (when comparing the TID). 1108 o advertising a registered address over the backbone using NA 1109 messages, asynchronously or as a response to a Neighbor 1110 Solicitation messages. 1111 o Looking up a destination over the backbone in order to deliver 1112 packets arriving from the EAH host using Neighbor Solicitation 1113 messages. 1114 o Forwarding packets from the EAH over the backbone, and the other 1115 way around at a time if the devide has known sleeping periods or 1116 resides on a different link such as an LLN attached to the 1117 backbone. 1118 Eventually triggering a look-up for a destination EAH that would not 1119 be registered at a given point of time, or as a verification of a 1120 registration. 1122 17.3. DHCPv6 Interaction 1124 Co-existence with DHCP: For classical IPv6, if DHCPv6 or central 1125 address allocation mechanism is used, then Neighbor Discovery 1126 autoconfiguration is not used for global address allocation. 1127 However, link-local duplicate address detection, Neighbor 1128 solicitation, Neighbor unreachability detection are still used. Upon 1129 assignment of the IPv6-address from DHCPv6, a EAH node SHOULD then 1130 register the IP-address with the default router for avoiding 1131 Duplicate address detection and Address Resolution. For Legacy 1132 DHCPv6 nodes there is no change in behavior. NOTE: DHCPv6 Server 1133 MUST be notified by NEAR for its efficiency-aware service interfaces. 1134 DHCPv6 server then SHOULD inform the DHCP requestor node about the 1135 default-rotuer capability during the address assignment period. 1137 Although the solution described in this document prevents unnecesary 1138 multicast messages in the IPv6 ND procedure, it does not affect 1139 normal IPv6 multicast packets and ability of nodes to join and leave 1140 the multicast group or forwarding multicast traffic or responding to 1141 multicast queries. 1143 18. VRRP Interaction 1145 TBD: This section will discuss if efficient ND mixed mode and 1146 efficiency mode require any special consideration with VRRP function. 1148 19. RPL Implications 1150 RPL [RFC6550] does not provide means for duplicate address detection 1151 and in particular does not have a concept of unique identifier. On 1152 the other hand, RPL is designed to discover and resolve conflicts 1153 that arise when a mobile device changes its point of attachment, with 1154 a sequence counter that is owned by the device and incremented at 1155 each new registration, called a DAOSequence. As we extend 6LoWPAN ND 1156 operation over a backbone and scale, there is a similar need to 1157 resolve the latest point of attachment of a device, whether this 1158 device moves at layer 2 over a WIFI infrastructure, or at layer 3 1159 within a RPL DODAG or from a DODAG to another one attached to the 1160 same backbone. In order to cover all cases in a consistent fashion, 1161 this document requires that a sequence counter call TID for 1162 Transaction ID and with the similar rules as the RPL DAOSequence is 1163 added to the ND registration. This document defines the TID 1164 operations and RPL may use the reserved fields for their purpose 1165 inside the LLN. 1167 20. Updated Neighbor Discovery Constants 1169 This section discusses the updated default values of ND constants 1170 based on [ND] section 10. New and changed constants are listed only 1171 for efficiency-aware-nd implementation. These values SHOULD be 1172 configurable and tunable to fit implementations and deployment. 1174 Router Constants: 1175 MAX_RTR_ADVERTISEMENTS(NEW) 3 transmissions 1176 MIN_DELAY_BETWEEN_RAS(CHANGED) 1 second 1177 TENTATIVE_LEGACY_NCE_LIFETIME(NEW) 30 seconds 1178 MAX_REG_AGE_DIFFERENCE(NEW) 50 mseconds 1180 Host Constants: 1181 MAX_RTR_SOLICITATION_INTERVAL(NEW) 60 seconds 1183 Also refer to [ENH-ND] , [IMPAT-ND] and [6LOWPAN-ND] for further 1184 tuning of ND constants. 1186 21. Security Considerations 1188 These optimizations are not known to introduce any new threats 1189 against Neighbor Discovery beyond what is already documented for IPv6 1190 [RFC 3756]. 1192 Section 11.2 of [ND] applies to this document as well. 1194 This mechanism minimizes the possibility of ND /64 DOS attacks in 1195 efficiency-aware mode. See Section 11.1. 1197 22. IANA Considerations 1199 A new flag (E-bit) in RA has been introduced. IANA assignment of the 1200 E-bit flag is required upon approval of this document. 1202 23. Changelog 1204 Changes from draft-chakrabarti-nordmark-energy-aware-nd-02: 1205 o Added clarification that SLLA is not required for ARO in a 1206 point-to-point link 1207 o Clarified that the document is indeed an optimization for legacy 1208 IPv6 ND 1209 o Adressed editorial comments and fixed typoes. Some more 1210 editorial work is needed 1211 o Added another usecase for Z-Wave example. Clarified 3GPP 1212 Networks related comments on existing ND optimizations. 1214 24. Acknowledgements 1216 The primary idea of this document are from 6LoWPAN Neighbor Discovery 1217 document [6LOWPAN-ND] and the discussions from the 6lowpan working 1218 group members, chairs Carsten Bormann and Geoff Mulligan and through 1219 our discussions with Zach Shelby, editor of the [6LOWPAN-ND]. 1221 The inspiration of such a IPv6 generic document came from Margaret 1222 Wasserman who saw a need for such a document at the IOT workshop at 1223 Prague IETF. 1225 The authors acknowledge the ND denial of service issues and key 1226 causes mentioned in the draft-halpern-6man-nddos-mitigation document 1227 by Joel Halpern. Thanks to Joel Halpern for pinpointing the problems 1228 that are now addressed in the NCE management section. 1230 The authors like to thank Dave Thaler, Stuart Cheshire, Jari Arkko, 1231 Ylva Jading, Niklas J. Johnsson, Reda Nedjar, Purvi Shah, Jaume Rius 1232 Riu, Fredrik Garneij, Andrew Yourtchenko, Jouni Korhonen, Suresh 1233 Krishnan, Brian Haberman, Anders Brandt, Mark Smith, Lorenzo Colitti, 1234 David Miles and Carsten Bormann for their useful comments and 1235 suggestions on this work. 1237 25. References 1239 25.1. Normative References 1241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1242 Requirement Levels", BCP 14, RFC 2119, March 1997. 1244 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1245 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1246 October 1998. 1248 [6LOWPAN-ND] 1249 Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1250 "ND Optimizations for 6LoWPAN", RFC 6775, November 2012. 1252 [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1253 "Neighbor Discovery for IP version 6", RFC 4861, 1254 September 2007. 1256 [LOWPAN] Montenegro, G. and N. Kushalnagar, "Transmission of IPv6 1257 Packets over IEEE 802.15.4 networks", RFC 4944, 1258 September 2007. 1260 [LOWPANG] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview, 1261 Assumptions, Problem Statement and Goals", RFC 4919, 1262 August 2007. 1264 25.2. Informative References 1266 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1267 (IPv6), Specification", RFC 2460, December 1998. 1269 [DNA] Krishnan, S. and G. Daley, "Simple Procedures for 1270 Detecting Network Attachments in IPv6", RFC 6059, 1271 November 2010. 1273 [RFC6550] "RPL: IPv6 Routing Protocol for Low-Power and Lossy 1274 Networks", RFC 6550, March 2012. 1276 [AUTOCONF] 1277 Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1278 Autoconfiguration", RFC 4862, September 2007. 1280 [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "Secure 1281 Neighbor Discovery", RFC 3971, March 2005. 1283 [AUTOADHOC] 1284 Baccelli, E. and M. Townsley, "IP Addressing Model in 1285 Adhoc Networks", RFC 5889, September 2010. 1287 [NDDOS-halpern] 1288 Halpern, J., "IP Addressing Model in Adhoc Networks", 1289 draft-halpern-6man-nddos-mitigation-00.txt (work in 1290 progress), October 2011. 1292 [ENH-ND] Kumari, W., Gashinsky, I., Jaeggli, J., and K. 1293 Chittimaneni, "Neighbor Discovery Enhancement for DOS 1294 mitigation", draft-gashinsky-6man-v6nd-enhance-02 (work in 1295 progress), October 2012. 1297 [IMPAT-ND] 1298 Nordmark, E. and I. Gashinsky, "Neighbor Unreachability 1299 Detection is too impatient", 1300 draft-ietf-6man-impatient-nud-05 (work in progress), 1301 October 2012. 1303 [IEEE] IEEE Computer Society, "IEEE Std. 802.15.4-2003", , 1304 October 2003. 1306 [PD] Miwakawya, S., "Requirements for Prefix Delegation", 1307 RFC 3769, June 2004. 1309 [RF] Haberman, B. and B. Hinden, "IPv6 Router Advertisement 1310 Flags option", RFC 5175, March 2008. 1312 [ULA] "Unique Local IPv6 Addresses", RFC 4193. 1314 [Resilient-RS] 1315 Krishnan, S., Anipko, D., and D. Thaler, "Packet loss 1316 resiliency for Router Solicitations", 1317 draft-ietf-6man-resilient-rs-01 (work in progress), 1318 May 2013. 1320 [IPV6M] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1321 in IPv6", RFC 6275, July 2011. 1323 Appendix A. Usecase Analysis 1325 This section provides applicability scenarios where the efficiency- 1326 aware Neighbor Discovery will be most beneficial. Most likely the 1327 usecases will be detailed in a separate document. 1329 A.1. Data Center Routers on the link 1331 Efficiency-aware Routers and hosts are useful in IPv6 networks in the 1332 Data Center as they produce less signaling and also provides ways to 1333 minimize the ND flood of messages. Moreover, this mechanism will 1334 work with data-center nodes which are deliberately in sleep mode for 1335 saving energy. 1337 This solution will work well in Data Center Virtual network and VM 1338 scenarios where number of VLANs are very high and ND signalings are 1339 undesirably high due the multicast messaging and periodic Router 1340 Advertisments and Neighbor Unreachability detections. 1342 A.2. Edge Routers and Home Networks 1344 An Edge Router in the network will also benefit implementing the 1345 efficiency-aware Neighbor Discovery behavior in order to save the 1346 signaling and keeping track of the registered nodes in its domain. A 1347 BNG sits at the operator's edge network and often the BNG has to 1348 handle a large number of home CPEs. If a BNG runs Neighbor Discovery 1349 protocol and acts as the default router for the CPE at home, this 1350 solution will be helpful for reducing the control messages and 1351 improving network performances. 1353 The same solution can be run on CPE or Home Residential Gateways to 1354 assign IPv6 addresses to the wired and wireless home devices without 1355 the problem of ND flooding issues and consuming less power. It 1356 provides mechanism for the sleepy nodes to adjust their registration 1357 lifetime according to their sleep schedules. 1359 A.3. M2M Networks 1361 Any Machine-to-machine(M2M) networks such as IPv6 surveilance 1362 networks, wireless monitoring networks and other m2m networks desire 1363 for efficiency-aware control protocols and dynamic address 1364 allocation. The in-built address allocation and autoconfiguration 1365 mechanism in IPv6 along with the default router capability will be 1366 useful for the simple small-scale networks without having the burden 1367 of DHCPv6 service and Routing Protocols. 1369 A.4. Wi-fi Networks 1371 In Wi-fi networks, a multicast message will consume the wireless link 1372 on all Access Points around a switched fabric and will be transmitted 1373 at the lowest speed possible in order to ensure the maximum reception 1374 by all wireless nodes. This means that in an environment where 1375 bandwidth is scarce, a single multicast packet may consume the 1376 bandwidth for hundreds of unicast packets. 1378 The Wi-fi IPv6 hosts can act as efficiency-aware hosts and register 1379 with their nearest default router with NEAR behavior. This method 1380 reduces multicast operations in the wireless access points or routers 1381 by using this optimization. 1383 A.5. 3GPP Networks 1385 Section 9.2.1.1 of TS23.060 allows periodic RA and TS 123.401 stays 1386 silent about periodic RA while 3GPP TS29.061 recommends large values 1387 for minimum and maximum periodic router advertisements for reduced 1388 periodic mesages. Though RFC6459 describes best practices about IPv6 1389 3GPP systems behavior, this ND optimization standard specification 1390 will be a helpful reference for 3GPP documents. LTE terminals (cell 1391 phones) may also benefit with reduced multicast messages described in 1392 this document in the wireless mode. 1394 A.6. Industrial Networks 1396 RPL [RFC6550] is used for Industrial wireless networks. 1398 A.7. Set and forget offline network 1400 Home control modules designed for networked environments may be 1401 deployed in very simple settings like garden path lighting controlled 1402 by wireless light and motion sensors. Once the network has been 1403 created and sensors have been associated with the light modules, the 1404 installer takes away the configuration tool which was used to set up 1405 the network. Most likely a ULA prefix is used, since multiple hops 1406 may be needed. None of the sensors and light modules has the 1407 capability of handing out fresh prefixes. Thus, for a set-and-forget 1408 style off-line network to work, the nodes must be provided an 1409 infinite prefix lifetime since they have nowhere to ask for a fresh 1410 one. 1412 Authors' Addresses 1414 Samita Chakrabarti 1415 Ericsson 1416 San Jose, CA 1417 USA 1419 Email: samita.chakrabarti@ericsson.com 1421 Erik Nordmark 1422 Arista Networks 1423 San Jose, CA 1424 USA 1426 Email: nordmark@sonic.net 1428 Pascal Thubert 1429 Cisco Systems 1431 Email: pthubert@cisco.com 1433 Margaret Wasserman 1434 Painless Security 1436 Email: mrw@lilacglade.org