idnits 2.17.1 draft-chakrabarti-nordmark-6man-efficient-nd-02.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 (July 15, 2013) is 3928 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 219, but not defined == Missing Reference: 'RFC4919' is mentioned on line 301, but not defined == Missing Reference: 'SLLAO' is mentioned on line 937, but not defined == Missing Reference: 'RFC 3756' is mentioned on line 1140, but not defined == Unused Reference: 'LOWPANG' is defined on line 1208, but no explicit reference was found in the text == Unused Reference: 'IPV6' is defined on line 1214, but no explicit reference was found in the text == Unused Reference: 'SEND' is defined on line 1228, but no explicit reference was found in the text == Unused Reference: 'AUTOADHOC' is defined on line 1231, but no explicit reference was found in the text == Unused Reference: 'NDDOS-halpern' is defined on line 1235, but no explicit reference was found in the text == Unused Reference: 'IEEE' is defined on line 1251, but no explicit reference was found in the text == Unused Reference: 'PD' is defined on line 1254, but no explicit reference was found in the text == Unused Reference: 'IPV6M' is defined on line 1262, 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 Summary: 2 errors (**), 0 flaws (~~), 15 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 P. Thubert 6 Expires: January 16, 2014 Cisco Systems 7 M. Wasserman 8 Painless Security 9 July 15, 2013 11 Efficiency aware IPv6 Neighbor Discovery Optimizations 12 draft-chakrabarti-nordmark-6man-efficient-nd-02 14 Abstract 16 IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for 17 neighbor's address resolution, unreachability detection, address 18 autoconfiguration, router advertisement and solicitation. With the 19 progress of Internet adoption on various industries including home, 20 wireless, M2M and cellular networks there is a desire for optimizing 21 the legacy IPv6 Neighbor Discovery protocol. This document describes 22 a method of optimization by reducing multicast messages and 23 introducing an IPv6 address Registration mechanism. Efficient IPv6 24 Neighbor Discovery protocol is useful for energy-efficient and low- 25 power IPv6 networks and as well as Data Center and Home Networks. 26 The solution is capable of handling existing legacy IPv6 nodes in the 27 network with local mobility. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 16, 2014. 46 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. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2. Overview of the 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 . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . 12 75 7.4. The Transaction Identification(TID) . . . . . . . . . . . 13 76 8. Efficiency-aware Neighbor Discovery Messages . . . . . . . . . 13 77 9. Efficiency-aware Host Behavior . . . . . . . . . . . . . . . . 15 78 10. The Energy Aware Default Router (NEAR) Behavior . . . . . . . 15 79 10.1. Router Configuration Modes . . . . . . . . . . . . . . . . 16 80 10.2. Movement Detection . . . . . . . . . . . . . . . . . . . . 17 81 10.2.1. Registration ownership . . . . . . . . . . . . . . . 17 82 11. NCE Management in efficiency-aware Routers . . . . . . . . . . 17 83 11.1. Handling ND DOS Attack . . . . . . . . . . . . . . . . . . 19 84 12. Mixed-Mode Operations . . . . . . . . . . . . . . . . . . . . 20 85 13. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 21 86 14. Handling Sleepy Nodes . . . . . . . . . . . . . . . . . . . . 22 87 15. Duplicate Address Detection . . . . . . . . . . . . . . . . . 23 88 16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 23 89 17. Other Considerations . . . . . . . . . . . . . . . . . . . . . 24 90 17.1. Detecting Network Attachment(DNA) . . . . . . . . . . . . 24 91 17.2. Proxying for Efficiency-Aware hosts . . . . . . . . . . . 24 92 17.3. DHCPv6 Interaction . . . . . . . . . . . . . . . . . . . . 25 93 18. RPL Implications . . . . . . . . . . . . . . . . . . . . . . . 25 94 19. Updated Neighbor Discovery Constants . . . . . . . . . . . . . 26 95 20. Security Considerations . . . . . . . . . . . . . . . . . . . 26 96 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 97 22. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 26 98 23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 99 24. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 100 24.1. Normative References . . . . . . . . . . . . . . . . . . . 27 101 24.2. Informative References . . . . . . . . . . . . . . . . . . 28 102 Appendix A. Usecase Analysis . . . . . . . . . . . . . . . . . . 29 103 A.1. Data Center Routers on the link . . . . . . . . . . . . . 29 104 A.2. Edge Routers and Home Networks . . . . . . . . . . . . . . 29 105 A.3. M2M Networks . . . . . . . . . . . . . . . . . . . . . . . 29 106 A.4. Wi-fi Networks . . . . . . . . . . . . . . . . . . . . . . 30 107 A.5. 3GPP Networks . . . . . . . . . . . . . . . . . . . . . . 30 108 A.6. Industrial Networks . . . . . . . . . . . . . . . . . . . 30 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 111 1. Introduction 113 Conceptually, IPv6 multicast messages are supposed to avoid broadcast 114 messages, but in practice, the multicast operation at the link level 115 is that of a broadcast nevertheless. This did not matter much at the 116 time ND [ND] was originally designed, when an Ethernet network was 117 more or less a single shared wire, but since then, large scale switch 118 fabrics, low power sleeping devices, mobile wireless/cellular devices 119 and virtual machines have changed the landscape dramatically. 121 In a modern switch fabric, a number of intermediate devices (such as 122 switches, routers and security middle boxes) host IPv6 State 123 Maintaining Entities (SMEs) holding information such as the location 124 of an IPv6 address or its mapping with a MAC address. Such 125 intermediate devices include Wireless Controllers that terminate a 126 overlay tunnel and rapidly re-enable reachability for mobile 127 devices(L2/L3), Network edge devices performing subscriber access, 128 network devices that protect the ownership of an IPv6 address, 129 Overlay networks in data centers, Home Networks for IPv6 clients. 131 In general, there is a need for enhancing the IPv6 ND [ND] to make it 132 less chatty and flexible to work with different types of networking 133 elements, physical and virtual networks and at the same time 134 maintaining the IPv6 states to avoid duplicates or denial of 135 services. 137 1.1. Background 139 IPv6 ND [ND] is based on multicast signaling messages on the local 140 link in order to avoid broadcast messages. Following power-on and 141 initialization of the network in IPv6 Ethernet networks, a node joins 142 the solicited-node multicast address on the interface and then 143 performs duplicate address detection (DAD) for the acquired link- 144 local address by sending a solicited-node multicast message to the 145 link. After that it sends multicast router solicitation (RS) 146 messages to the all-router address to solicit router advertisements. 147 Once the host receives a valid router advertisement (RA) with the "A" 148 flag, it autoconfigures the IPv6 address with the advertised prefix 149 in the router advertisement (RA). Besides this, the IPv6 routers 150 usually send router advertisements periodically on the network. RAs 151 are sent to the all-node multicast address. The minimum RA interval 152 range can be 3sec to 600sec depending on applications. Nodes send 153 Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages 154 to resolve the IPv6 address of the destination on the link. These 155 NS/NA messages are also often multicast messages and it is assumed 156 that the node is on the same link and relies on the fact that the 157 destination node is always powered and generally available. 159 The periodic RA messages in IPv6 ND [ND], and NS/NA messages require 160 all IPv6 nodes in the link to be in listening mode even when they are 161 in idle cycle. It requires energy for the sleepy nodes which may 162 otherwise be sleeping during the idle period. Non-sleepy nodes also 163 spends more energy since they are in continuous listening mode. With 164 the explosion of Internet-of-things and machine to machine 165 communication, more and more devices would be using IPv6 addresses in 166 the near future. Since Neighbor Discovery is at the heart of IPv6 167 protocol, there is a need to make this protocol more efficient. 169 1.2. Overview of the ND Optimization 171 IPv6 Neighbor Discovery Optimization for 6LoWPAN [6LOWPAN-ND] 172 addresses many of the concerns described above by optimizing the 173 Router advertisement, minimizing periodic multicast packets in the 174 network and introducing two new options - one for node registration 175 and another for prefix dissemination in a network where all nodes in 176 the network are uniquely identified by their 64-bit Interface 177 Identifier. EUI-64 identifiers are recommended as unique Interface 178 Identifiers, however if the network is isolated from the Internet, 179 uniqueness of the identifiers may be obtained by other mechanisms 180 such as a random number generator with lowest collision rate. 181 Although, the ND optimization [6LOWPAN-ND] applies to 6LoWPAN 182 [LOWPAN] network, the concept is mostly applicable to a power-aware 183 IPv6 network. Therefore, this document generalizes the address 184 registration and multicast reduction in [6LOWPAN-ND] to all IPv6 185 links. 187 Thus optimizing the regular IPv6 Neighbor Discovery [ND] to minimize 188 total number of related signaling messages without losing generality 189 of Neighbor Discovery, autoconfiguration and reliable host-router 190 communication, are desirable in any modern IPv6 networks such as 191 Home, Enterprise networks, Data Centers and Operator's Cellular/ 192 Wireless networks. 194 The optimization will be highly effective for links and nodes which 195 do not support multicast and as well as for a multicast network 196 without MLD snooping switches. Moreover, in the MLD-snooping 197 networks the MLD switches will deal with less number of multicasts. 199 The goal of this document is to provide an efficient Neighbor 200 Discovery Protocol in classic IPv6 subnets and links. Research 201 indicates that often networked-nodes require more energy than stand- 202 alone nodes because a node's energy usage depends on network messages 203 it receives and responds. While reducing energy consumption is 204 essential for battery operated nodes in some machines, saving energy 205 actually a cost factor in business in general as the explosion of 206 more device usage is leading to usage of more servers and network 207 infrastructure in all sectors of the society and business. Thus this 208 document introduces the node registration concept discussed in 209 6LoWPAN [LOWPAN], without handling the 'multi-level subnets' 210 scenarios that are not the typical usecases in classic IPv6 subnets. 212 In the process, the node registration method is also deemed to be 213 useful for preventing Neighbor Discovery denial of service ( ND DOS) 214 attacks. 216 The proposed changes can be used in two different ways. In one case 217 all the hosts and routers on a link implement the new mechanisms, 218 which gives the maximum benefits. In another case the link has a 219 mixture of new hosts and/or routers and legacy [RFC4861] hosts and 220 routers, operating in a mixed-mode providing some of the benefits. 222 In the following sections the document describes the basic operations 223 of registration methods, optimization of Neighbor Discovery messages, 224 interoperability with legacy IPv6 implementations and provides a 225 section on use-case scenarios where it can be typically applicable. 226 This document also describes an optional feature for node mobility in 227 the LLN network using backbone routers(BBR) or multiple default 228 subnet routers. This optional feature in generating a sequence ID by 229 the host in the registration message will be helpful for deploying 230 RPL[RFC6550] with reliability in the LLN. 232 2. Definition Of Terms 234 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 235 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 236 document are to be interpreted as described in [RFC2119]. 238 multi-level Subnets: 239 It is a wireless link determined by one IPv6 off-link prefix in a 240 network where in order to reach a destination with same prefix a 241 packet may have to travel through one more 'intermediate' routers 242 which relays the packet to the next 'intermediate' router or the 243 host in its own. 244 Border Router(BR): 245 A border router is typically located at the junction Internet and 246 Home Network. An IPv6 router with one interface connected to IPv6 247 subnet and other interface connecting to a non-classic IPv6 248 interface such as 6LoWPAN interface. Border router is usually the 249 gateway to the IPv6 network or Internet. 251 Backbone: 252 This is an IPv6 transit link that interconnects 2 or more Low 253 Power Lossy Networks (LLNs). It is expected to be deployed as a 254 high speed backbone in order to federate a potentially large set 255 of LLN nodes. Also referred to as a LLN backbone or Backbone 256 network. 257 Backbone Router: 258 An IPv6 router that federates the LLN using a transit link as a 259 backbone. A BBR acts as a 6LoWPAN Border Routers (6LBR) and an 260 Energy Aware Default Router (NEAR). 261 Efficiency-Aware Network: 262 An Efficiency-Aware network is composed of network elements that 263 are sensitive to energy usage or number of signaling messages in 264 the network. An efficiency-aware network may also contain links 265 that do not support multicast or it does not have MLD snooping 266 capabilities and yet the network likes to communicate most 267 efficiently with minimum number of signaling messages. Data 268 center networks with virtual machines, cellular IPv6 networks, any 269 IPv6 networks with energy-sensitive nodes are examples of 270 Efficiency-Aware networks. 271 IPv6 ND-efficiency-aware Router(NEAR): 272 It is the default Router of the single hop IPv6 subnet. This 273 router implements the optimizations specified in this document. 274 This router should be able to handle both legacy IPv6 nodes and 275 nodes that sends registration request. 276 Efficiency-Aware Host(EAH): 277 A host in a IPv6 network is considered a IPv6 node without routing 278 and forwarding capability. The EAH is the host which implements 279 the host functionality for optimized Neighbor Discovery mentioned 280 in this document. 281 Legacy IPv6 Host: 282 A host in a IPv6 network is considered a IPv6 node without routing 283 and forwarding capability and implements RFC 4861 host functions. 284 Legacy IPv6 Router: 285 An IPv6 Router which implements RFC 4861 Neighbor Discovery 286 protocols. 287 EUI-64: 288 It is the IEEE defined 64-bit extended unique identifier formed by 289 concatenation of 24-bit or 36-bit company id value by IEEE 290 Registration Authority and the extension identifier within that 291 company-id assignment. The extension identifiers are 40-bit (for 292 24-bit company-id) or 28-bit (for the 36-bit company-id) 293 respectively. 294 LLN: 295 It is a low power and lossy network where nodes are typically 296 constrained in system resources and energy, for instance battery 297 powered nodes. Alternately LLN could be a network of line-powered 298 nodes with radio links with lossy characteristics. Wifi, ZigBee, 299 Celular networks are examples of such a network. 300 Extended LLN: 301 This is the aggregation of multiple LLNs as defined in [RFC4919] 302 interconnected by a Backbone Link via Backbone Routers and forming 303 a single IPv6 link. 305 3. Assumptions for efficiency-aware Neighbor Discovery 307 o The efficiency-aware nodes in the network carry unique interface 308 ID in the network in order to form the auto-configured IPv6 309 address uniquely. An EUI-64 interface ID required for global 310 communication. 311 o All nodes are single IPv6-hop away from their default router in 312 the subnet. 313 o /64-bit IPv6 prefix is used for Stateless Auto-address 314 configuration (SLAAC). The IPv6 Prefix may be distributed with 315 Router Advertisement (RA) from the default router to all the nodes 316 in that link. 317 o The efficiency-aware node MAY maintain a sequence counter in 318 permanent memory according to section 7 of RFC 6550. 320 4. The set of Requirements for efficiency and optimization 322 o Node Registration: Node initiated Registration and address 323 allocation is done in order to avoid periodic multicast Router 324 Advertisement messages and often Neighbor Address resolution can 325 be skipped as all packets go via the default router which now 326 knows about all the registered nodes. Node Registration enables 327 reduction of all-node and solicited-node multicast messages in the 328 subnet. 329 o Address allocation of registered nodes [ND] are performed using 330 IPv6 Autoconfiguration [AUTOCONF]. 331 o Host initiated Registration and Refresh is done by sending a 332 Router Solicitation and then a Neighbor Solicitation Message using 333 Address Registration Option (described below). 334 o The node registration may replace the requirement of doing 335 Duplicate Address Detection. 336 o Sleepy hosts are supported by this Neighbor Discovery procedures 337 as they are not woken up periodically by Router Advertisement 338 multicast messages or Neighbor Solicitation multicast messages. 339 Sleepy nodes may wake up in its own schedule and send unicast 340 registration refresh messages when needed. 341 o Since this document requires formation of an IPv6 address with an 342 unique 64-bit Interface ID(EUI-64) is required for global IPv6 343 addresses, if the network is an isolated one and uses ULA [ULA] as 344 its IPv6 address then the deployment should make sure that each 345 MAC address in that network has unique address and can provide a 346 unique 64-bit ID for each node in the network. 347 o /64-bit Prefix is required to form the IPv6 address. 348 o MTU requirement is same as IPv6 network. 350 5. Basic Operations 352 In the efficient-nd IPv6 Network, the NEAR routers are the default 353 routers for the efficiency-aware hosts (EAH). During the startup or 354 joining the network the host does not wait for the Router 355 Advertisements as the NEAR routers do not perform periodic multicast 356 RA as per RFC 4861. Instead, the EAH sends a multicast RS to find 357 out a NEAR router in the network. The RS message is the same as in 358 RFC 4861. The advertising routers in the link responds to the RS 359 message with RA with Prefix Information Option and any other options 360 configured in the network. If EAH hosts will look for a RA from a 361 NEAR (E-flag) and choose a NEAR as its default router and 362 consequently sends a unicast Neighbor Solicitation Message with ARO 363 option in order to register itself with the default router. The EAH 364 does not do Duplicate Address Detection or NS Resolution of 365 addresses. NEAR maintains a binding of registered nodes and 366 registration life-time information along with the neighbor Cache 367 information. The NEAR is responsible for forwarding all the messages 368 from its EAH including on-link messages from one EAH to another. For 369 details of protocol operations please see the sections below. 371 When a IPv6 network consists of both legacy hosts and EAH, and if the 372 NEAR is configured for 'mixed mode' operation, it should be able to 373 handle Address Registration Option(ARO) requests and send periodic 374 RA. Thus it should be able to serve both efficiency-aware hosts and 375 legacy hosts. Similarly, a legacy host compatible EAH falls back to 376 RFC 4861 host behavior if a NEAR is not present in the link. See the 377 section on 'Mixed Mode Operations' for details below. 379 6. Applicability Statement 381 This document aims to guide the implementers to choose an appropriate 382 IPv6 neighbor discovery and Address configuration procedures suitable 383 for any efficient IPv6 network. These optimization is equally useful 384 for the energy-sensitive, non-multicast links and for classical IPv6 385 networks i.e. home networks, Data-Center IPv6 overlay networks where 386 saving Neighbor Discovery messages will reduce cost and increase 387 bandwidth availability. 389 The address registration mechanism and associated extension on 390 Neighbor Discovery protocol allow a low-power host to move between 391 the LLN and the classic IPv6 networks as well as movement from one 392 Border Router registration area to another while staying within the 393 same IPv6 subnet. 395 Note that the specification allows 'Mixed-mode' operation in the 396 efficiency-aware nodes for backward compatibility and transitioning 397 to a complete efficiency-aware network of hosts and routers. Though 398 the efficiency-aware only nodes will minimize the ND signaling and 399 DOS attacks in the LAN. 401 Applicability of this solution is limited to the legacy IPv6 nodes 402 and subnets and it optimizes the generic IPv6 signaling activities at 403 network layer. However, further optimization at the application 404 layers are possible for increased efficiency based on particular use- 405 cases and applications. 407 7. New Neighbor Discovery Options and Messages 409 This section will discuss the registration and de-registration 410 procedure of the hosts in the network. 412 7.1. Address Registration Option 414 The Address Registration Option(ARO) is useful for avoiding Duplicate 415 Address Detection messages since it requires a unique EUI-64 ID for 416 registration. The address registration is used for maintaining 417 reachability of the node or host by the router. This option is 418 exactly the same as in [6LOWPAN-ND] which is reproduced here for the 419 benefits of the readers. Additionally a Transaction ID field and a 420 corresponding bit have been introduced in order to detect duplicate 421 address registration and local mobility of a node. 423 The routers keep track of host IP addresses that are directly 424 reachable and their corresponding link-layer addresses. This is 425 useful for lossy and lowpower networks(LLN) and as well as wired 426 networks. An Address Registration Option (ARO) can be included in 427 unicast Neighbor Solicitation (NS) messages sent by hosts. Thus it 428 can be included in the unicast NS messages that a host sends as part 429 of Neighbor Unreachability Detection to determine that it can still 430 reach a default router. The ARO is used by the receiving router to 431 reliably maintain its Neighbor Cache. The same option is included in 432 corresponding Neighbor Advertisement (NA) messages with a Status 433 field indicating the success or failure of the registration. This 434 option is always host initiated. 436 The ARO is required for reliability and power saving. The lifetime 437 field provides flexibility to the host to register an address which 438 should be usable (the reachability information may be propagated to 439 the routing protocols) during its intended sleep schedule of nodes 440 that switches to frequent sleep mode. 442 The sender of the NS also includes the EUI-64 of the interface it is 443 registering an address from. This is used as a unique ID for the 444 detection of duplicate addresses. It is used to tell the difference 445 between the same node re-registering its address and a different node 446 (with a different EUI-64) registering an address that is already in 447 use by someone else. The EUI-64 is also used to deliver an NA 448 carrying an error Status code to the EUI-64 based link-local IPv6 449 address of the host. 451 When the ARO is used by hosts an SLLA option MUST be included and the 452 address that is to be registered MUST be the IPv6 source address of 453 the Neighbor Solicitation message. 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Type | Length = 2 | Status | Reserved | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Reservd |T| TID | Registration Lifetime | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | | 463 + EUI-64 or equivalent + 464 | | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Fields: 468 Type: 33 ( See [6LOWPAN-ND] ) 469 Length: 8-bit unsigned integer. The length of the option in 470 units of 8 bytes. Always 2. 471 Status: 8-bit unsigned integer. Indicates the status of a 472 registration in the NA response. MUST be set to 0 in 473 NS messages. See below. 474 Reserved: This field is unused. It MUST be initialized to zero 475 by the sender and MUST be ignored by the receiver. 476 TID: 8-bit integer. It is a transaction id maintained by 477 the host and incremented with each registration. it is 478 recommended that the node maintains a persistent 479 storage for TID. TID is used as a sequence counter to 480 detect the most recent registration request from a 481 host and its mobility within the same subnet across 482 multiple default Border Routers. Its operation 483 follows section 7 of RPL [RFC6550] for sequence 484 counters. 486 Registration Lifetime: 16-bit unsigned integer. The amount of time 487 in a unit of 60 seconds that the router should retain 488 the Neighbor Cache entry for the sender of the NS that 489 includes this option. 490 EUI-64: 64 bits. This field is used to uniquely identify the 491 interface of the registered address by including the 492 EUI-64 identifier assigned to it unmodified. 493 T bit: One bit flag. Set if the TID octet is present for 494 processing. 496 The Status values used in Neighbor Advertisements are: 498 +--------+--------------------------------------------+ 499 | Status | Description | 500 +--------+--------------------------------------------+ 501 | 0 | Success | 502 | 1 | Duplicate Address | 503 | 2 | Neighbor Cache Full | 504 | 3 | Registration Ownership Response | 505 | 4-255 | Allocated using Standards Action [RFC2434] | 506 +--------+--------------------------------------------+ 508 Table 1 510 7.2. Refresh and De-registration 512 A host SHOULD send a Registration message in order to renew its 513 registration before its registration lifetime expires in order to 514 continue its connectivity with the network. If anytime, the node 515 decides that it does not need the default router's service anymore, 516 it MUST send a de-registration message - i,e, a registration message 517 with lifetime being set to zero. A mobile host SHOULD first de- 518 register with the default router before it moves away from the 519 subnet. 521 7.3. A New Router Advertisement Flag 523 A new Router Advertisement flag [RF] is needed in order to 524 distinguish a router advertisement from a efficiency-aware default 525 router or a legacy IPv6 router. This flag is ignored by the legacy 526 IPv6 hosts. EAH hosts use this flag in order to discover a NEAR 527 router if it receives multiple RA from both legacy and NEAR routers. 529 0 1 2 3 4 5 6 7 530 +-+-+-+-+-+-+-+-+ 531 |M|O|H|Prf|P|E|R| 532 +-+-+-+-+-+-+-+-+ 534 The 'E' bit above MUST be 1 when a IPv6 router implements and 535 configures the efficiency-aware Router behavior for Neighbor 536 Discovery as per this document. All other cases E bit is 0. 538 The legacy IPv6 hosts will ignore the E bit in RA advertisement. All 539 EAH MUST look for E bit in RA in order to determine the efficiency- 540 aware support in the default router in the link. 542 7.4. The Transaction Identification(TID) 544 The TID field is used together with age of a registration for 545 arbitration between two routers (default or backbone) to ensure 546 freshness and ownership of the registration of a given target 547 address. Same value of TID indicates that both states of 548 registration are valid. In case of a mismatch between comparable 549 TIDs, the most recent TID wins. The TID definition used in section 550 6.4.1 of RFC 6550 for DAOSequence number would be applicable for here 551 for TID in ARO message. 553 It is 8 bit field. TID is generated by the host at the time of a new 554 registraton request. 556 This document assumes that an implementation will have configuration 557 knobs to determine whether it is running in classical IPv6 ND [ND] or 558 Optimized Energy Aware ND (this document) mode or both(Mixed mode). 560 8. Efficiency-aware Neighbor Discovery Messages 562 Router Advertisement(RA): Periodic RAs SHOULD be avoided. Only 563 solicited RAs are RECOMMENDED. An RA MUST 564 contain the Source Link-layer Address option 565 containing Router's link-layer address (this 566 is optional in [ND]. An RA MUST carry Prefix 567 information option with L bit being unset, so 568 that hosts do not multicast any NS messages 569 as part of address resolution. A new flag 570 (E-flag) is introduced in the RA in order to 571 characterize the efficiency-aware mode 572 support. Unlike RFC4861 which suggests 573 multicast Router Advertisements, this 574 specification optimizes the exchange by 575 always unicasting RAs in response to RS. 576 This is possible since the RS always includes 577 a SLLA option, which is used by the router to 578 unicast the RA. 579 Router Solicitation(RS): Upon system startup, the node sends a 580 multicast or link broadcast (when multicast 581 is not supported at the link-layer) RS to 582 find out the available routers in the link. 583 An RS may be sent at other times as described 584 in section 6.3.7 of RFC 4861. A Router 585 Solicitation MUST carry Source Link-layer 586 Address option. Since no periodic RAs are 587 allowed in the efficiency-aware IPv6 network, 588 the host may send periodic unicast RS to the 589 routers. The time-periods for the RS varies 590 on the deployment scenarios and the Default 591 Router Lifetime advertised in the RAs. 592 Default Router Selection: Same as in section 6.3.6 of RFC 4861[ND]. 593 Neighbor Solicitation (NS): Neighbor solicitation is used between 594 the hosts and the default-router as part of 595 NUD and registering the host's address(es). 596 An NS message MUST use the Address 597 Registration option in order to accomplish 598 the registration. 599 Neighbor Advertisement (NA): As defined in [ND] and ARO option. 600 Redirect Messages: A router SHOULD NOT send a Redirect message 601 to a host since the link has non-transitive 602 reachability. The host behavior is same as 603 described in section 8.3 of RFC 4861[ND], 604 i,e. a host MUST NOT send or accept redirect 605 messages when in efficiency-aware mode. 606 Same as in RFC 4861[ND] 607 MTU option: As per the RFC 4861. 608 Address Resolution: No NS/NA are sent as the prefixes are treated 609 as off-link. Thus no address resolution is 610 performed at the hosts. The routers keep 611 track of Neighbor Solicitations with Address 612 Registration options(ARO) and create an 613 extended neighbor cache of reachable 614 addresses. The router also knows the nexthop 615 link-local address and corresponding link- 616 layer address when it wants to route a 617 packet. 618 Neighbor Unreachability Detection(NUD): NUD is performed in 619 "forward-progress" fashion as described in 620 section 7.3.1 of RFC 4861[ND]. However, if 621 Address Registration Option is used, the NUD 622 SHOULD be combined with the Re-registration 623 of the node. This way no extra message for 624 NUD is required. 626 9. Efficiency-aware Host Behavior 628 A host sends Router Solicitation at the system startup and also when 629 it suspects that one of its default routers have become 630 unreachable(after NUD fails). The EAH MUST process the E-bit in RA 631 as described in this document. The EAH MUST use ARO option to 632 register with the neighboring NEAR router. 634 A host SHOULD be able to autoconfigure its IPv6 addresses using the 635 IPv6 prefix obtained from Router Advertisement. The host SHOULD form 636 its link-local address from the EUI-64 as specified by IEEE 637 Registration Authority and RFC 2373. If this draft feature is 638 implemented and configured, the host MUST NOT re-direct Neighbor 639 Discovery messages. The host is not required to join the solicited- 640 node multicast address but it MUST join the all-node multicast 641 address. 643 A host always sends packets to (one of) its default router(s). This 644 is accomplished by the routers never setting the 'L' flag in the 645 Prefix options. 647 The host is unable to forward routes or participate in a routing 648 protocol. A legacy IPv6 Host compliant EAH SHOULD be able to fall 649 back to RFC 4861 host behavior if there is no efficiency-aware router 650 (NEAR) in the link. 652 The efficiency-aware host MUST NOT send or accept re-direct messages. 653 It does not join solicited node multicast address. 655 If the EAH is capable of generating TID and configured for this 656 operation, the EAH MUST use the TID field and appropriate associated 657 operation bits in the ARO message during registration and refresh. 659 10. The Energy Aware Default Router (NEAR) Behavior 661 The main purpose of the default router in the context of this 662 document is to receive and process the registration request, forward 663 packets from one neighbor to the other, informs the routing protocol 664 about the un-availability of the registered nodes if the routing 665 protocol requires this information for the purpose of mobility or 666 fast convergence. A default router (NEAR) behavior may be observed 667 in one or more interfaces of a Border Router(BR). 669 A Border Router normally may have multiple interfaces and connects 670 the nodes in a link like a regular IPv6 subnet(s) or acts as a 671 gateway between separate networks such as Internet and home networks 672 . The Border Router is responsible for distributing one or more /64 673 prefixes to the nodes to identify a packet belonging to the 674 particular network. One or more of the interfaces of the Border 675 Router may be connected with the efficiency-aware hosts or a 676 efficiency-aware router(NEAR). 678 The efficiency-aware default router MUST not send periodic RA unless 679 it is configured to support both legacy IPv6 and efficiency-aware 680 hosts. If the Router is configured for efficiency-aware hosts 681 support, it MUST send Router Advertisements with E-bit flag ON and 682 MUST NOT set 'L' bit in the advertisements. 684 The router SHOULD NOT garbage collect Registered Neighbor Cache 685 entries since they need to retain them until the Registration 686 Lifetime expires. If a NEAR receives a NS message from the same host 687 one with ARO and another without ARO then the NS message with ARO 688 gets the precedence and the NS without ARO is ignored. This behavior 689 protects the router from Denial Of Service attacks. Similarly, if 690 Neighbor Unreachability Detection on the router determines that the 691 host is UNREACHABLE (based on the logic in [ND]), the Neighbor Cache 692 entry SHOULD NOT be deleted but be retained until the Registration 693 Lifetime expires. If an ARO arrives for an NCE that is in 694 UNCREACHABLE state, that NCE should be marked as STALE. 696 A default router keeps a cache for all the nodes' IP addresses, 697 created from the Address Registration processing. 699 10.1. Router Configuration Modes 701 An efficiency-aware Router(NEAR) MUST be able to configure in 702 efficiency-aware-only mode where it will expect all hosts register 703 with the router following RS; thus will not support legacy hosts. 704 However, it will create legacy NCE for NS messages for other routers 705 in the network. This mode is able to prevent ND flooding on the 706 link. 708 An efficiency-aware Router(NEAR) SHOULD be able to have configuration 709 knob to configure itself in Mixed-Mode where it will support both 710 efficiency-aware hosts and legacy hosts. However even in mixed-mode 711 the router should check for duplicate entries in the NCE before 712 creating a new ones and it should rate-limit creating new NCE based 713 on requests from the same host MAC address. 715 The RECOMMENDED default mode of operation for the efficiency-aware 716 router is Mixed-mode. Though it cannot reap the full benefit of 717 efficiency related optimization described in this document. 719 10.2. Movement Detection 721 When a host moves from one subnet to another its IPv6 prefix changes 722 and the movement detection is determined according to the existing 723 IPv6 movement detection described in [DNA]. 725 However, if the movement happens across different default routers in 726 the subnet and the node likes to register with one of the default 727 routers closest to its present location, it must send another 728 registration request to the new default router. The new default 729 router then first send an NS to its peers with a link scope multicast 730 message to IPv6 address ff02::2 with the ARO option. 732 10.2.1. Registration ownership 734 The subnet-local-routers check their respective NCE table for the 735 particular registration. If the registration entry exists, the NEAR 736 default router then calculates the 'age' of the registration by 737 subtracting the present time from the registration received time 738 recorded at the NCE. The NEAR router then responds with a NA with 739 ARO option Status being equal to 3 and replaces the 'registration 740 lifetime' field with the 'age' of registration. Upon receiving the 741 NA from the neighboring routers the prospective default router 742 determines its registration ownership. If the other router 743 registration age is higher than its own registration age, then the 744 current router is considered to have the most recent registration 745 ownership. 747 If both routers registration age are zero or within a 50msec window, 748 then the TID field is used to determine the ownership. The higher 749 value of TID wins. Note that the registration ownership and local 750 movement detection behavior in NEAR router MUST be optionally 751 configured. The NEAR routers MAY implement this feature. 752 Configuring this option is needed when the NEAR routers are used in a 753 low power and lossy network environment. 755 11. NCE Management in efficiency-aware Routers 757 The use of explicit registrations with lifetimes plus the desire to 758 not multicast Neighbor Solicitation messages for hosts imply that we 759 manage the Neighbor Cache entries slightly differently than in [ND]. 760 This results in two different types of NCEs and the types specify how 761 those entries can be removed: 763 Legacy: Entries that are subject to the normal rules in 764 [ND] that allow for garbage collection when low 765 on memory. Legacy entries are created only 766 when there is no duplicate NCE. In mixed-mode 767 and efficiency-aware mode the legacy entries 768 are converted to the registered entries upon 769 successful processing of ARO. Legacy type can 770 be considered as union of garbage-collectible 771 and Tentative Type NCEs described in 772 [6LOWPAN-ND]. 773 Registered: Entries that have an explicit registered 774 lifetime and are kept until this lifetime 775 expires or they are explicitly unregistered. 777 Note that the type of the NCE is orthogonal to the states specified 778 in [ND]. 780 When a host interacts with a router by sending Router Solicitations 781 that does not match with the existing NCE entry of any type, a Legacy 782 NCE is first created. Once a node successfully registers with a 783 Router the result is a Registered NCE. As Routers send RAs to legacy 784 hosts, or receive multicast NS messages from other Routers the result 785 is Legacy NCEs. There can only be one kind of NCE for an IP address 786 at a time. 788 A Router Solicitation might be received from a host that has not yet 789 registered its address with the router or from a legacy[ND] host in 790 the Mixed-mode of operation. 792 In the 'Efficiency-aware' only mode the router MUST NOT modify an 793 existing Neighbor Cache entry based on the SLLA option from the 794 Router Solicitation. Thus, a router SHOULD create a tentative Legacy 795 Neighbor Cache entry based on SLLA option when there is no match with 796 the existing NCE. Such a legacy Neighbor Cache entry SHOULD be timed 797 out in TENTATIVE_LEGACY_NCE_LIFETIME seconds unless a registration 798 converts it into a Registered NCE. 800 However, in 'Mixed-mode' operation, the router does not require to 801 keep track of TENTATIVE_LEGACY_NCE_LIFETIME as it does not know if 802 the RS request is from a legacy host or the efficiency-aware hosts. 803 However, it creates the legacy type of NCE and updates it to a 804 registered NCE if the ARO NS request arrives corresponding to the 805 legacy NCE. Successful processing of ARO will complete the NCE 806 creation phase. 808 If ARO did not result in a duplicate address being detected, and the 809 registration life-time is non-zero, the router creates and updates 810 the registered NCE for the IPv6 address. If the Neighbor Cache is 811 full and new entries need to be created, then the router SHOULD 812 respond with a NA with status field set to 2. For successful 813 creation of NCE, the router SHOULD include a copy of ARO and send NA 814 to the requestor with the status field 0. A TLLA(Target Link Layer) 815 Option is not required with this NA. 817 Typically for efficiency-aware routers (NEAR), the registration life- 818 time and EUI-64 are recorded in the Neighbor Cache Entry along with 819 the existing information described in [ND]. The registered NCE are 820 meant to be ready and reachable for communication and no address 821 resolution is required in the link. The efficiency-aware hosts will 822 renew their registration to keep maintain the state of reachability 823 of the NCE at the router. However the router may do NUD to the idle 824 or unreachable hosts as per [ND]. 826 In addition, NEAR default routers MUST associate a record of the age 827 of the registration. 'Age' is a simple way to detect movement of a 828 node from local default router to another. 'Age' information SHOULD 829 contain System-time when the registration is first created or last 830 refreshed. This system-time is deducted from the current system-time 831 to determine the "age" of the registration and it is used for age 832 reporting with Neighbor advertisement for selection of registration 833 ownership among the default-router contenders in case of local 834 movement of the host from one default-router to another in the same 835 subnet. 'Age' is always considered zero for a fresh registration or 836 a registration refresh message. 838 11.1. Handling ND DOS Attack 840 IETF community has discussed possible issues with /64 DOS attacks on 841 the ND networks when an attacker host can send thousands of packets 842 to the router with an on-link destination address or sending RS 843 messages to initiate a Neighbor Solicitation from the neighboring 844 router which will create a number of INCOMPLETE NCE entries for non- 845 existent nodes in the network resulting in table overflow and denial 846 of service of the existing communications. 848 The efficiency-aware behavior documented in this specification avoids 849 the ND DOS attacks by: 851 o Having the hosts register with the default router 852 o Having the hosts send their packets via the default router 853 o Not resolving addresses for the Routing Solicitor by mandating 854 SLLA option along with RS 855 o Checking for duplicates in NCE before the registration 856 o Checking against the MAC-address and EUI-64 id is possible now for 857 NCE matches 859 o On-link IPv6-destinations on a particular link must be registered 860 else these packets are not resolved and extra NCEs are not created 862 It is RECOMMENDED that Mixed-mode operation and legacy hosts SHOULD 863 NOT be mixed in the IPv6 link in order to avoid the ND DOS attacks. 864 For the general case of Mixed-mode the router does not create 865 INCOMPLETE NCEs for the registered hosts, but it follows the [ND] 866 steps of NCE states for legacy hosts. 868 12. Mixed-Mode Operations 870 Mixed-Mode operation discusses the protocol behavior where the IPv6 871 subnet is composed with legacy IPv6 Neighbor Discovery compliant 872 nodes and efficiency-aware IPv6 nodes implementing this 873 specification. 875 The mixed-mode model SHOULD support the following configurations in 876 the IPv6 link: 877 o The legacy IPv6 hosts and efficiency-aware-hosts in the network 878 and a NEAR router 879 o legacy IPv6 default-router and efficiency-aware hosts(EAH) in the 880 link 881 o one router is in mixed mode and the link contains both legacy IPv6 882 hosts and EAH 883 o A link contains both efficiency-aware IPv6 router and hosts and 884 legacy IPv6 routers and hosts and each host should be able to 885 communicate with each other. 887 In mixed-mode operation, a NEAR MUST be configured for mixed-mode in 888 order to support the legacy IPv6 hosts in the network. In mixed- 889 mode, the NEAR MUST act as proxy for Neighbor Solicitation for DAD 890 and Address Resolution on behalf of its registered hosts on that 891 link. It should follow the NCE management for the EAH as described 892 in this document and follow RFC 4861 NCE management for the legacy 893 IPv6 hosts. Both in mixed-mode and efficiency-aware mode, the NEAR 894 sets E-bit flag in the RA and does not set 'L' on-link bit. 896 If a NEAR receives NS message from the same host one with ARO and 897 another without ARO then the NS message with ARO gets the precedence. 899 An efficiency-aware Host implementation SHOULD support falling back 900 to legacy IPv6 node behavior when no efficiency-aware routers are 901 available in the network during the startup. If the EAH was 902 operational in efficiency-aware mode and it determines that the NEAR 903 is no longer available, then it should send a RS and find an 904 alternate default router in the link. If no efficiency-aware router 905 is indicated from the RA, then the EAH SHOULD fall back into RFC 4861 906 behavior. On the other hand, in the efficiency-aware mode EAH SHOULD 907 ignore multicast Router Advertisements(RA) sent by the legacy and 908 Mixed-mode routers in the link. 910 In mixed mode operation, the Router SHOULD be able to do local 911 movement detection based on ARO if it is configured for that 912 operation for EAH hosts. For the legacy hosts, the mixed-mode router 913 MAY follow classical IPv6 methods of movement detection and MAY act 914 as ND proxy by sending NA with 'O' bit.[ Reference??] 916 The routers that are running on efficiency-aware mode or legacy mode 917 SHOULD NOT dynamically switch the mode without flushing the Neighbor 918 Cache Entries. 920 13. Bootstrapping 922 If the network is a efficiency-aware IPv6 subnet, and the efficiency- 923 aware Neighbor Discovery mechanism is used by the hosts and routers 924 as described in this document. At the start, the node uses its link- 925 local address to send Router Solicitation and then it sends the Node 926 Registration message as described in this document in order to form 927 the address. The Duplicate address detection process should be 928 skipped if the network is guaranteed to have unique interface 929 identifiers which is used to form an IPv6 address. 931 Node Router 933 0. |[Forms LL IPv6 addr] | 935 1. | ---------- Router Solicitation --------> | 937 | [SLLAO] | 939 2. | <-------- Router Advertisement --------- | 941 | [PIO + SLLAO] | 942 | | 944 3. | ----- Address Registration (NS) --------> | 946 | [ARO + SLLAO] | 948 4. | <-------- Neighbor Advertisement ------- | 950 | [ARO with Status code] | 952 5. ====> Address Assignment Complete 954 Figure 1: Neighbor Discovery Address Registration and bootstrapping 956 In the mixed mode operation, it is expected that logically there will 957 be at least one legacy IPv6 router and another NEAR router present in 958 the link. The legacy IPv6 router will follow RFC 4861 behavior and 959 NEAR router will follow the efficiency-aware behavior for 960 registration, NCE maintenance, forwarding packets from a EAH and it 961 will also act as a ND proxy for the legacy IPv6 hosts querying to 962 resolve a EAH node. 964 A legacy IPv6 host and EAH are not expected to see a difference in 965 their bootstrapping if both legacy and efficiency-aware 966 functionalities of rotuers are available in the network. It is 967 RECOMMEDED that the EAH implementation SHOULD be able to behave like 968 a legacy IPv6 host if it discovers that no efficiency-aware routing 969 support is present in the link. 971 14. Handling Sleepy Nodes 973 The solution allows the sleepy nodes to complete its sleep schedule 974 without waking up due to periodic Router Advertisement messages or 975 due to Multicast Neighbor Solicitation for address resolution. The 976 node registration lifetime SHOULD be synchronized with its sleep 977 interval period in order to avoid waking up in the middle of sleep 978 for registration refresh. Depending on the application, the 979 registration lifetime SHOULD be equal to or integral multiple of a 980 node's sleep interval period. 982 15. Duplicate Address Detection 984 In efficiency-aware mode, there is no need for Duplicate Address 985 Detection(DAD) assuming that the deployment ensures unique 64bit 986 identification availability for each registered host. In the event 987 of collision of EUI64 field of ARO by two registration requests, the 988 later request is denied if the first one is a valid request. The 989 denied EAH node SHOULD pick another alternative IPv6 address to 990 register to prevent further registration denial. The method of 991 assignment of alternate IPv6 address is out of scope of this 992 document. 994 In some networks there are multiple default routers and the 995 registering node may move from one default router (where it was 996 registered before) to another default router in the same subnet. 997 Thus in order to differentiate between the duplicate request and the 998 movement, the router checks the 64-bit MAC address and 'age' of the 999 request. If there is an entry in the node already with 0 < 'age' < 1000 registration-life-time and the TID field of the existing entry and 1001 the new request is same with TID of the new request, it is a 1002 duplicate. 1004 If the default router does not have a registered entry for this host, 1005 it should check whether it is a local movement. Please see 'Mobility 1006 Consideration section' for details. 1008 16. Mobility Considerations 1010 If the hosts move from one subnet to another, they MUST first de- 1011 register and then register themselves in the new subnet or network. 1012 If a node moves away without de-registration and returns to the 1013 network before the registration lifetime expires, its registration is 1014 still considered valid. For run-away nodes the registration expires 1015 after the lifetime expiry or due to unreachablity whichever comes 1016 first. Otherwise, the regular IPv6 Mobility [IPV6M]behavior applies. 1018 In the multiple default router scenario, a node may move from its 1019 current primary default router to a prospective primary default 1020 router. At this point, the default routers use Neighbor 1021 Advertisements(NA) to arbitrate the latest ownership of the 1022 registration of host. The ownership of registration is useful for 1023 the Border Routers if they participate in a routing protocol which 1024 advertises proximity preferences or adjusts its own forwarding 1025 preference based on the host registration. This kind of forwarding 1026 or routing mechanisms are useful for energy efficiency and 1027 performance of the networks. See 'Movement Detection' section for 1028 details. 1030 17. Other Considerations 1032 17.1. Detecting Network Attachment(DNA) 1034 IPv6 DNA[DNA] uses unicast ND probes and link-layer indications to 1035 detect movement of its network attachments. Upon detecting link- 1036 layer indication, it sends a all-routers Solicitation message. When 1037 the node implements this document along with DNA, it MUST send ARO 1038 option with its Neighbor Solicitation unicast message if the 1039 candidate router advertisement indicates that the router is a NEAR 1040 router. If the candiate router is a legacy router then and it is the 1041 only choice then the EAH host adapt to the legacy behavior. However 1042 if EAH node implements DNA host capability as well, then it SHOULD 1043 give preference to the NEAR routers in its candidate list of routers. 1045 Thus the ND optimization solution will work seamlessly with DNA 1046 implementations and no change is required in DNA solution because of 1047 Neighbor Discovery updates. It is a deployment and configuration 1048 consideration as to run the network in mixed mode or efficient-mode. 1050 17.2. Proxying for Efficiency-Aware hosts 1052 The efficient-ND SHOULD continue to support the legacy IPv6 Neighbor 1053 Solicitation requests in the mixed mode. The NEAR router SHOULD act 1054 as the ND proxy on behalf of EAH hosts for the legacy nodes' NS 1055 requests for EAH. 1057 In the context of this specification, proxy ND means: defending a 1058 registered address over the backbone using NA messages with and ARO 1059 option and the Override bit set if the ARO option in the NS indicates 1060 either a different node (different EUI-64) or a older registration 1061 (when comparing the TID). 1063 o advertising a registered address over the backbone using NA 1064 messages, asynchronously or as a response to a Neighbor 1065 Solicitation messages. 1066 o Looking up a destination over the backbone in order to deliver 1067 packets arriving from the EAH host using Neighbor Solicitation 1068 messages. 1070 o Forwarding packets from the EAH over the backbone, and the other 1071 way around at a time if the devide has known sleeping periods or 1072 resides on a different link such as an LLN attached to the 1073 backbone. 1074 Eventually triggering a look up for a destination EAH that would not 1075 be registered at a given point of time, or as a verification of a 1076 registration. 1078 17.3. DHCPv6 Interaction 1080 Co-existence with DHCP: For classical IPv6, if DHCPv6 or central 1081 address allocation mechanism is used, then Neighbor Discovery 1082 autoconfiguration is not used for global address allocation. 1083 However, link-local duplicate address detection, Neighbor 1084 solicitation, Neighbor unreachability detection are still used. Upon 1085 assignment of the IPv6-address from DHCPv6, a EAH node SHOULD then 1086 register the IP-address with the default router for avoiding 1087 Duplicate address detection and Address Resolution. For Legacy 1088 DHCPv6 nodes there is no change in behavior. NOTE: DHCPv6 Server 1089 MUST be notified by NEAR for its efficiency-aware service interfaces. 1090 DHCPv6 server then SHOULD inform the DHCP requestor node about the 1091 default-rotuer capability during the address assignment period. 1093 Although the solution described in this document prevents unnecesary 1094 multicast messages in the IPv6 ND procedure, it does not affect 1095 normal IPv6 multicast packets and ability of nodes to join and leave 1096 the multicast group or forwarding multicast traffic or responding to 1097 multicast queries. 1099 18. RPL Implications 1101 RPL [RFC6550] does not provide means for duplicate address detection 1102 and in particular does not have a concept of unique identifier. On 1103 the other hand, RPL is designed to discover and resolve conflicts 1104 that arise when a mobile device changes its point of attachment, with 1105 a sequence counter that is owned by the device and incremented at 1106 each new registration, called a DAOSequence. As we extend 6LoWPAN ND 1107 operation over a backbone and scale, there is a similar need to 1108 resolve the latest point of attachment of a device, whether this 1109 device moves at layer 2 over a WIFI infrastructure, or at layer 3 1110 within a RPL DODAG or from a DODAG to another one attached to the 1111 same backbone. In order to cover all cases in a consistent fashion, 1112 this document requires that a sequence counter call TID for 1113 Transaction ID and with the similar rules as the RPL DAOSequence is 1114 added to the ND registration. This document defines the TID 1115 operations and RPL may use the reserved fields for their purpose 1116 inside the LLN. 1118 19. Updated Neighbor Discovery Constants 1120 This section discusses the updated default values of ND constants 1121 based on [ND] section 10. New and changed constants are listed only 1122 for efficiency-aware-nd implementation. These values SHOULD be 1123 configurable and tunable to fit implementations and deployment. 1125 Router Constants: 1126 MAX_RTR_ADVERTISEMENTS(NEW) 3 transmissions 1127 MIN_DELAY_BETWEEN_RAS(CHANGED) 1 second 1128 TENTATIVE_LEGACY_NCE_LIFETIME(NEW) 30 seconds 1130 Host Constants: 1131 MAX_RTR_SOLICITATION_INTERVAL(NEW) 60 seconds 1133 Also refer to [ENH-ND] , [IMPAT-ND] and [6LOWPAN-ND] for further 1134 tuning of ND constants. 1136 20. Security Considerations 1138 These optimizations are not known to introduce any new threats 1139 against Neighbor Discovery beyond what is already documented for IPv6 1140 [RFC 3756]. 1142 Section 11.2 of [ND] applies to this document as well. 1144 This mechanism minimizes the possibility of ND /64 DOS attacks in 1145 efficiency-aware mode. See Section 11.1. 1147 21. IANA Considerations 1149 A new flag (E-bit) in RA has been introduced. IANA assignment of the 1150 E-bit flag is required upon approval of this document. 1152 22. Changelog 1154 Changes from draft-chakrabarti-nordmark-energy-aware-nd-02: 1155 o Replaced energy-aware with efficency-aware which covers both 1156 energy efficiency and other operational efficiency 1157 o Added consideration for DNA, ND proxy and clarified that this is 1158 useful for networks with MLD-snooping switches as well 1159 o Added use-cases, Support for Mixed-mode operations and a diagram 1160 for bootstrapping scenario. 1162 o Clarified its applicability when DHCP is used for address 1163 allocation. 1165 23. Acknowledgements 1167 The primary idea of this document are from 6LoWPAN Neighbor Discovery 1168 document [6LOWPAN-ND] and the discussions from the 6lowpan working 1169 group members, chairs Carsten Bormann and Geoff Mulligan and through 1170 our discussions with Zach Shelby, editor of the [6LOWPAN-ND]. 1172 The inspiration of such a IPv6 generic document came from Margaret 1173 Wasserman who saw a need for such a document at the IOT workshop at 1174 Prague IETF. 1176 The authors acknowledge the ND denial of service issues and key 1177 causes mentioned in the draft-halpern-6man-nddos-mitigation document 1178 by Joel Halpern. Thanks to Joel Halpern for pinpointing the problems 1179 that are now addressed in the NCE management section. 1181 The authors like to thank Dave Thaler, Jari Arkko, Ylva Jading, 1182 Niklas J. Johnsson, Reda Nedjar, Purvi Shah, Jaume Rius Riu, Fredrik 1183 Garneij for their useful comments on this work. 1185 24. References 1187 24.1. Normative References 1189 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1190 Requirement Levels", BCP 14, RFC 2119, March 1997. 1192 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1193 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1194 October 1998. 1196 [6LOWPAN-ND] 1197 Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1198 "ND Optimizations for 6LoWPAN", RFC 6775, November 2012. 1200 [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1201 "Neighbor Discovery for IP version 6", RFC 4861, 1202 September 2007. 1204 [LOWPAN] Montenegro, G. and N. Kushalnagar, "Transmission of IPv6 1205 Packets over IEEE 802.15.4 networks", RFC 4944, 1206 September 2007. 1208 [LOWPANG] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview, 1209 Assumptions, Problem Statement and Goals", RFC 4919, 1210 August 2007. 1212 24.2. Informative References 1214 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1215 (IPv6), Specification", RFC 2460, December 1998. 1217 [DNA] Krishnan, S. and G. Daley, "Simple Procedures for 1218 Detecting Network Attachments in IPv6", RFC 6059, 1219 November 2010. 1221 [RFC6550] "RPL: IPv6 Routing Protocol for Low-Power and Lossy 1222 Networks", RFC 6550, March 2012. 1224 [AUTOCONF] 1225 Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1226 Autoconfiguration", RFC 4862, September 2007. 1228 [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "Secure 1229 Neighbor Discovery", RFC 3971, March 2005. 1231 [AUTOADHOC] 1232 Baccelli, E. and M. Townsley, "IP Addressing Model in 1233 Adhoc Networks", RFC 5889, September 2010. 1235 [NDDOS-halpern] 1236 Halpern, J., "IP Addressing Model in Adhoc Networks", 1237 draft-halpern-6man-nddos-mitigation-00.txt (work in 1238 progress), October 2011. 1240 [ENH-ND] Kumari, W., Gashinsky, I., Jaeggli, J., and K. 1241 Chittimaneni, "Neighbor Discovery Enhancement for DOS 1242 mitigation", draft-gashinsky-6man-v6nd-enhance-02 (work in 1243 progress), October 2012. 1245 [IMPAT-ND] 1246 Nordmark, E. and I. Gashinsky, "Neighbor Unreachability 1247 Detection is too impatient", 1248 draft-ietf-6man-impatient-nud-05 (work in progress), 1249 October 2012. 1251 [IEEE] IEEE Computer Society, "IEEE Std. 802.15.4-2003", , 1252 October 2003. 1254 [PD] Miwakawya, S., "Requirements for Prefix Delegation", 1255 RFC 3769, June 2004. 1257 [RF] Haberman, B. and B. Hinden, "IPv6 Router Advertisement 1258 Flags option", RFC 5175, March 2008. 1260 [ULA] "Unique Local IPv6 Addresses", RFC 4193. 1262 [IPV6M] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1263 in IPv6", RFC 6275, July 2011. 1265 Appendix A. Usecase Analysis 1267 This section provides applicability scenarios where the efficiency- 1268 aware Neighbor Discovery will be most beneficial. 1270 A.1. Data Center Routers on the link 1272 Efficiency-aware Routers and hosts are useful in IPv6 networks in the 1273 Data Center as they produce less signaling and also provides ways to 1274 minimize the ND flood of messages. Moreover, this mechanism will 1275 work with data-center nodes which are deliberately in sleep mode for 1276 saving energy. 1278 This solution will work well in Data Center Virtual network and VM 1279 scenarios where number of VLANs are very high and ND signalings are 1280 undesirably high due the multicast messaging and periodic Router 1281 Advertisments and Neighbor Unreachability detections. 1283 A.2. Edge Routers and Home Networks 1285 An Edge Router in the network will also benefit implementing the 1286 efficiency-aware Neighbor Discovery behavior in order to save the 1287 signaling and keeping track of the registered nodes in its domain. A 1288 BNG sits at the operator's edge network and often the BNG has to 1289 handle a large number of home CPEs. If a BNG runs Neighbor Discovery 1290 protocol and acts as the default router for the CPE at home, this 1291 solution will be helpful for reducing the control messages and 1292 improving network performances. 1294 The same solution can be run on CPE or Home Residential Gateways to 1295 assign IPv6 addresses to the wired and wireless home devices without 1296 the problem of ND flooding issues and consuming less power. It 1297 provides mechanism for the sleepy nodes to adjust their registration 1298 lifetime according to their sleep schedules. 1300 A.3. M2M Networks 1302 Any Machine-to-machine(M2M) networks such as IPv6 surveilance 1303 networks, wireless monitoring networks and other m2m networks desire 1304 for efficiency-aware control protocols and dynamic address 1305 allocation. The in-built address allocation and autoconfiguration 1306 mechanism in IPv6 along with the default router capability will be 1307 useful for the simple small-scale networks without having the burden 1308 of DHCPv6 service and Routing Protocols. 1310 A.4. Wi-fi Networks 1312 In Wi-fi networks, a multicast message will consume the wireless link 1313 on all Access Points around a switched fabric and will be transmitted 1314 at the lowest speed possible in order to ensure the maximum reception 1315 by all wireless nodes. This means that in an environment where 1316 bandwidth is scarce, a single multicast packet may consume the 1317 bandwidth for hundreds of unicast packets. 1319 The Wi-fi IPv6 hosts can act as efficiency-aware hosts and register 1320 with their nearest default router with NEAR behavior. This method 1321 reduces multicast operations in the wireless access points or routers 1322 by using this optimization. 1324 A.5. 3GPP Networks 1326 Section 9.2.1.1 of TS23.060 allows periodic RA and TS 123.401 stays 1327 silent about periodic RA. Though the informational drafts and 1328 RFC6459 about 3GPP systems IPv6 behavior provides best practices, 1329 this document provides standard based optimization that 3GPP systems 1330 can follow to improve efficiency in the mobile nodes and 3GPP 1331 Routers. 1333 A.6. Industrial Networks 1335 RPL [RFC6550] is used for Industrial wireless networks. 1337 Authors' Addresses 1339 Samita Chakrabarti 1340 Ericsson 1341 San Jose, CA 1342 USA 1344 Email: samita.chakrabarti@ericsson.com 1345 Erik Nordmark 1346 Cisco Systems 1347 San Jose, CA 1348 USA 1350 Email: nordmark@cisco.com 1352 Pascal Thubert 1353 Cisco Systems 1355 Email: pthubert@cisco.com 1357 Margaret Wasserman 1358 Painless Security 1360 Email: mrw@lilacglade.org