idnits 2.17.1 draft-chakrabarti-nordmark-energy-aware-nd-01.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 Energy-Aware default router MUST not send periodic RA unless it is configured to support both legacy IPv6 and energy-aware hosts. If the Router is configured for Energy-Aware hosts support, it MUST send Router Advertisments 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 31, 2011) is 4553 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 175, but not defined == Missing Reference: 'SLLAO' is mentioned on line 761, but not defined == Missing Reference: 'RFC 3756' is mentioned on line 875, but not defined == Unused Reference: 'LOWPANG' is defined on line 935, but no explicit reference was found in the text == Unused Reference: 'IPV6' is defined on line 941, but no explicit reference was found in the text == Unused Reference: 'SEND' is defined on line 948, but no explicit reference was found in the text == Unused Reference: 'AUTOADHOC' is defined on line 951, but no explicit reference was found in the text == Unused Reference: 'IEEE' is defined on line 957, but no explicit reference was found in the text == Unused Reference: 'PD' is defined on line 960, but no explicit reference was found in the text == Unused Reference: 'IPV6M' is defined on line 968, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-17 ** 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 (-03) exists of draft-ietf-autoconf-adhoc-addr-model-02 Summary: 2 errors (**), 0 flaws (~~), 14 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTAREA WG S. Chakrabarti 3 Internet-Draft Ericsson 4 Updates: 4861 (if approved) E. Nordmark 5 Intended status: Standards Track Cisco Systems 6 Expires: May 3, 2012 M. Wasserman 7 Painless Security 8 October 31, 2011 10 Energy Aware IPv6 Neighbor Discovery Optimizations 11 draft-chakrabarti-nordmark-energy-aware-nd-01 13 Abstract 15 IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for 16 neighbor's address resolution, unreachability detection, address 17 autoconfiguration, router advertisement and solicitation. With the 18 progress of Internet adoption on various industries including home, 19 wireless and machine-to-machine communications, there is a desire for 20 optimizing legacy IPv6 Neighbor Discovery protocol for energy- 21 efficient networks and nodes. Research indicates that often 22 networked- nodes require more energy than stand-alone nodes because a 23 node's energy usage depends on network messages it receives and 24 responds. While reducing energy consumption is essential for battery 25 operated nodes in some machines, saving energy actually a cost factor 26 in business in general as the explosion of more device usage is 27 leading to usage of more servers and network infrastructure in all 28 sectors of the society and business. This document describes a 29 method of optimizations by reducing periodic multicast messages, 30 frequent Neighbor Solicitation messages and discusses 31 interoperability with legacy IPv6 nodes. This document also 32 addresses the ND denial of service issues by introducing node 33 Registration procedure. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on May 3, 2012. 51 Copyright Notice 53 Copyright (c) 2011 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 5 70 3. Assumptions for energy-aware Neighbor Discovery . . . . . . . 6 71 4. The set of Requirements for Energy-awareness and 72 optimization . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 5. Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 7 74 6. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 75 7. New Neighbor Discovery Options and Messages . . . . . . . . . 8 76 7.1. Address Registration Option . . . . . . . . . . . . . . . 8 77 7.2. Refresh and De-registration . . . . . . . . . . . . . . . 10 78 7.3. A New Router Advertisement Flag . . . . . . . . . . . . . 10 79 8. Energy-aware Neighbor Discovery Messages . . . . . . . . . . . 11 80 9. Energy-Aware Host Behavior . . . . . . . . . . . . . . . . . . 12 81 10. The Energy Aware Default Router (NEAR) Behavior . . . . . . . 13 82 10.1. Router Configuration Modes . . . . . . . . . . . . . . . . 14 83 11. NCE Management in Energy-Aware Routers . . . . . . . . . . . . 14 84 11.1. Handling ND DOS Attack . . . . . . . . . . . . . . . . . . 16 85 12. Mixed-Mode Operations . . . . . . . . . . . . . . . . . . . . 16 86 13. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 17 87 14. Handling Sleepy Nodes . . . . . . . . . . . . . . . . . . . . 18 88 15. Use Case Analysis . . . . . . . . . . . . . . . . . . . . . . 19 89 15.1. Data Center Routers on the link . . . . . . . . . . . . . 19 90 15.2. Edge Routers and Home Networks . . . . . . . . . . . . . . 19 91 15.3. M2M Networks . . . . . . . . . . . . . . . . . . . . . . . 19 92 16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 20 93 17. Updated Neighbor Discovery Constants . . . . . . . . . . . . . 20 94 18. Security Considerations . . . . . . . . . . . . . . . . . . . 20 95 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 96 20. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 20 97 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 98 22. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 99 22.1. Normative References . . . . . . . . . . . . . . . . . . . 21 100 22.2. Informative References . . . . . . . . . . . . . . . . . . 22 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 103 1. Introduction 105 IPv6 ND [ND] is based on multicast signaling messages on the local 106 link in order to avoid broadcast messages. Following power-on and 107 initialization of the network in IPv6 Ethernet networks, a node joins 108 the solicited-node multicast address on the interface and then 109 performs duplicate address detection (DAD) for the acquired link- 110 local address by sending a solicited-node multicast message to the 111 link. After that it sends multicast router solicitation (RS) 112 messages to the all-router address to solicit router advertisements. 113 Once the host receives a valid router advertisement (RA) with the "A" 114 flag, it autoconfigures the IPv6 address with the advertised prefix 115 in the router advertisement (RA). Besides this, the IPv6 routers 116 usually send router advertisements periodically on the network. RAs 117 are sent to the all-node multicast address. Nodes send Neighbor 118 Solicitation (NS) and Neighbor Advertisement (NA) messages to resolve 119 the IPv6 address of the destination on the link. These NS/NA 120 messages are also often multicast messages and it is assumed that the 121 node is on the same link and relies on the fact that the destination 122 node is always powered and generally available. 124 The periodic RA messages in IPv6 ND [ND], and NS/NA messages require 125 all IPv6 nodes in the link to be in listening mode even when they are 126 in idle cycle. It requires energy for the sleepy nodes which may 127 otherwise be sleeping during the idle period. Non-sleepy nodes also 128 save energy if instead of continuous listening, they actually pro- 129 actively synchronize their states with one or two entities in the 130 network. With the explosion of Internet-of-things and machine to 131 machine communication, more and more devices would be using IPv6 132 addresses in the near future. Today, most electricity usage in 133 United States and in developing countries are in the home buildings 134 and commercial buildings; the electronic Internet appliances/tablets 135 etc. are gaining popularities in the modern home networks. These 136 network of nodes must be conscious about saving energy in order to 137 reduce user-cost. This will eventually reduce stress on electrical 138 grids and carbon foot-print. 140 IPv6 Neighbor Discovery Optimization for 6LoWPAN [6LOWPAN-ND] 141 addresses many of the concerns described above by optimizing the 142 Router advertisement, minimizing periodic multicast packets in the 143 network and introducing two new options - one for node registration 144 and another for prefix dissemination in a network where all nodes in 145 the network are uniquely identified by their 64-bit Interface 146 Identifier. EUI-64 identifiers are recommended as unique Interface 147 Identifiers, however if the network is isolated from the Internet, 148 uniqueness of the identifiers may be obtained by other mechanisms 149 such as a random number generator with lowest collision rate. 150 Although, the ND optimization [6LOWPAN-ND] applies to 6LoWPAN 152 [LOWPAN] network, the concept is mostly applicable to a power-aware 153 IPv6 network. Therefore, this document generalizes the address 154 registration and multicast reduction in [6LOWPAN-ND] to all IPv6 155 links. 157 Thus optimizing the regular IPv6 Neighbor Discovery [ND] to minimize 158 total number of related signaling messages without losing generality 159 of Neighbor Discovery and autoconfiguration and making host and 160 router communication reliable, is desirable in any IPv6 energy-aware 161 networks such as Home or Enterprise building networks and as well as 162 Data Centers. 164 The goal of this document is to provide energy-aware and optimized 165 Neighbor Discovery Protocols in the IPv6 subnets and links. Thus 166 this document does not provide a solution of router advertisements 167 and registration for 'multi-level subnets' as indicated in 6LoWPAN 168 [LOWPAN]. In the process, the node registration method is also 169 useful for preventing Neighbor Discovery denial of service (DOS) 170 attacks. 172 The proposed changes can be used in two different ways. In one case 173 all the hosts and routers on a link implement the new mechanisms, 174 which gives the maximum benefits. In another case the link has a 175 mixture of new hosts and/or routers and legacy [RFC4861] hosts and 176 routers, operating in a mixed-mode providing some of the benefits. 178 In the following sections the document describes the basic operations 179 of registration methods, optimization of Neighbor Discovery messages, 180 interoperability with legacy IPv6 implementations and provides a 181 section on use-case scenarios where it can be typically applicable. 183 2. Definition Of Terms 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in [RFC2119]. 189 multi-level Subnets: 190 It is a wireless link determined by one IPv6 off-link prefix in a 191 network where in order to reach a destination with same prefix a 192 packet may have to travel throguh one more 'intermediate' routers 193 which relays the packet to the next 'intermediate' router or the 194 host in its own. 196 Border Rotuer(BR): 197 A border router is typically located at the junction Internet and 198 Home Network. An IPv6 router with one interface connected to IPv6 199 subnet and other interface connecting to a non-classic IPv6 200 interface such as 6LoWPAN interface. Border router is usually the 201 gateway to the IPv6 network or Internet. 202 IPv6 ND-energy-aware Rotuer(NEAR): 203 It is the default Router of the single hop IPv6 subnet. This 204 router implements the optimizations specified in this document. 205 This router should be able to handle both legacy IPv6 nodes and 206 nodes that sends registration request. 207 Enery-Aware Host(EAH): 208 A host in a IPv6 network is considered a IPv6 node without routing 209 and forwarding capability. The EAH is the host which implements 210 the host functionality for optimized Neighbor Discovery mentioned 211 in this document. 212 Legacy IPv6 Host: 213 A host in a IPv6 network is considered a IPv6 node without routing 214 and forwarding capability and implements RFC 4861 host functions. 215 Legacy IPv6 Router: 216 An IPv6 Router which implements RFC 4861 Neighbor Discovery 217 protocols. 218 EUI-64: 219 It is the IEEE defined 64-bit extended unique identifier formed by 220 concatenation of 24-bit or 36-bit company id value by IEEE 221 Registration Authority and the extension identifier within that 222 company-id assignment. The extension identifiers are 40-bit (for 223 24-bit company-id) or 28-bit (for the 36-bit company-id) 224 respectively. 226 3. Assumptions for energy-aware Neighbor Discovery 228 o The energy-aware nodes in the network carry unique interface ID in 229 the network in order to form the auto-configured IPv6 address 230 uniquely. An EUI-64 interface ID required for global 231 communication. 232 o All nodes are single IPv6-hop away from their default router in 233 the subnet. 234 o /64-bit IPv6 prefix is used for Stateless Auto-address 235 configuration (SLAAC). The IPv6 Prefix may be distributed with 236 Router Advertisement (RA) from the default router to all the nodes 237 in that link. 239 4. The set of Requirements for Energy-awareness and optimization 241 In future homes, machine-to-machine networks and Data-center Virtual 242 networks, it is essential to reduce unnecessary number of IPv6 243 Neighbor Discovery signalings for saving energy and saving bits in 244 the network. 246 In the cloud computing environment, the concept of IPv6-subnet of 247 link-local nodes is often extended across different networks over a 248 Virtual LAN. Thus reducing Neighbor Discovery signaling messages is 249 a key for enhanced services. 251 o Node Registration: Node initiated Registration and address 252 allocation is done in order to avoid periodic multicast Router 253 Advertisement messages and often Neighbor Address resolution can 254 be skipped as all packets go via the default router which now 255 knows about all the registered nodes. Node Registration enables 256 reduction of all-node and solicited-node multicast messages in the 257 subnet. 258 o Address allocation of registered nodes [ND] are performed using 259 IPv6 Autoconfiguration [AUTOCONF]. 260 o Host initiated Registration and Refresh is done by sending a 261 Router Solicitation and then a Neighbor Solicitation Messge using 262 Address Registration Option (described below). 263 o The node registration may replace the requirement of doing 264 Duplicate Address Detection. 265 o Sleepy hosts are supported by this Neighbor Discovery procedures 266 as they are not woken up periodically by Router Advertisement 267 multicast messages or Neighbor Solicitation multicast messages. 268 Sleepy nodes may wake up in its own schedule and send unicast 269 registration refresh messages when needed. 270 o Since this document requires formation of an IPv6 address with an 271 unique 64-bit Interface ID(EUI-64) is required for global IPv6 272 addresses. If the network is an isolated one and uses ULA [ULA] 273 as its IPv6 address then the deployment should make sure that each 274 MAC address in that network has unique address and can provide a 275 unique 64-bit ID for each node in the network. 276 o /64-bit Prefix is required to form the IPv6 address. 277 o MTU requirement is same as IPv6 network. 279 5. Basic Operations 281 In the energy-aware IPv6 Network, the NEAR routers are the default 282 routers for the energy-aware hosts (EAH). During the startup or 283 joining the network the host does not wait for the Router 284 Advertisements as the NEAR routers do not perform periodic multicast 285 RA as per RFC 4861. Instead, the EAH sends a multicast RS to find 286 out a NEAR router in the network. The RS message is the same as in 287 RFC 4861. The advertising routers in the link responds to the RS 288 message with RA with Prefix Information Option and any other options 289 configured in the network. If EAH hosts will look for a RA from a 290 NEAR (E-flag) and choose a NEAR as its default router and 291 consequently sends a unicast Neighbor Solicitation Message with ARO 292 option in order to register itself with the default router. The EAH 293 does not do Duplicate Address Detection or NS Resolution of 294 addresses. NEAR maintains a binding of registered nodes and 295 registration life-time information along with the neighbor Cache 296 information. The NEAR is responsible for forwarding all the messages 297 from its EAH including on-link messages from one EAH to another. For 298 details of protocol operations please see the sections below. 300 When a IPv6 network consists of both legacy hosts and EAH, and if the 301 NEAR is configured for 'mixed mode' operation, it should be able to 302 handle ARO requests and send periodic RA. Thus it should be able to 303 serve both energy-aware hosts and legacy hosts. Similarly, a legacy 304 host compatible EAH falls back to RFC 4861 host behavior if a NEAR is 305 not present in the link. See the section on 'Mixed Mode Operations' 306 for details below. 308 6. Applicability Statement 310 This document aims to guide the implementors to choose an appropriate 311 IPv6 neighbor discovery and Address configuration procedures suitable 312 for any IPv6 energy-aware network. These optimization is useful for 313 the classical IPv6 subnet and as well as future home networks, Data- 314 Centers where saving Neighbor Discovery messages will reduce cost of 315 control signaling and network bandwidth and as well as energy of the 316 connected nodes. See use cases towards the end of the document. 318 Note that the specification allows 'Mixed-mode' operation in the 319 energy-aware nodes for backward compatibility and transitioning to a 320 complete energy-aware network of hosts and routers. Though the 321 energy-aware only nodes will minimize the ND signalling and DOS 322 attacks in the LAN. 324 7. New Neighbor Discovery Options and Messages 326 This section will discuss the registration and de-registration 327 procedure of the hosts in the network. 329 7.1. Address Registration Option 331 The Address Registration Option(ARO) is useful for avoiding Duplicate 332 Address Detection messages since it requires a unique ID for 333 registration. The address registration is used for maintaining 334 reachability of the node or host by the router. This option is 335 exactly the same as in [6LOWPAN-ND] which is reproduced here for the 336 benefits of the readers. 338 The routers keep track of host IP addresses that are directly 339 reachable and their corresponding link-layer addresses. This is 340 useful for lossy and lowpower networks and as well as wired networks. 341 An Address Registration Option (ARO) can be included in unicast 342 Neighbor Solicitation (NS) messages sent by hosts. Thus it can be 343 included in the unicast NS messages that a host sends as part of 344 Neighbor Unreachability Detection to determine that it can still 345 reach a default router. The ARO is used by the receiving router to 346 reliably maintain its Neighbor Cache. The same option is included in 347 corresponding Neighbor Advertisement (NA) messages with a Status 348 field indicating the success or failure of the registration. This 349 option is always host initiated. 351 The ARO is required for reliability and power saving. The lifetime 352 field provides flexibility to the host to register an address which 353 should be usable (the reachability information may be propagated to 354 the routing protocols) during its intended sleep schedule of nodes 355 that switches to frequent sleep mode. 357 The sender of the NS also includes the EUI-64 of the interface it is 358 registering an address from. This is used as a unique ID for the 359 detection of duplicate addresses. It is used to tell the difference 360 between the same node re-registering its address and a different node 361 (with a different EUI-64) registering an address that is already in 362 use by someone else. The EUI-64 is also used to deliver an NA 363 carrying an error Status code to the EUI-64 based link-local IPv6 364 address of the host. 366 When the ARO is used by hosts an SLLA option MUST be included and the 367 address that is to be registered MUST be the IPv6 source address of 368 the Neighbor Solicitation message. 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Type | Length = 2 | Status | Reserved | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Reserved | Registration Lifetime | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | | 378 + EUI-64 or equivalent + 379 | | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Fields: 382 Type: TBD1 ( See [6LOWPAN-ND] ) 383 Length: 8-bit unsigned integer. The length of the option in 384 units of 8 bytes. Always 2. 385 Status: 8-bit unsigned integer. Indicates the status of a 386 registration in the NA response. MUST be set to 0 in 387 NS messages. See below. 388 Reserved: This field is unused. It MUST be initialized to zero 389 by the sender and MUST be ignored by the receiver. 390 Registration Lifetime: 16-bit unsigned integer. The amount of time 391 in a unit of 10 seconds that the router should retain 392 the Neighbor Cache entry for the sender of the NS that 393 includes this option. 394 EUI-64: 64 bits. This field is used to uniquely identify the 395 interface of the registered address by including the 396 EUI-64 identifier assigned to it unmodified. 398 The Status values used in Neighbor Advertisements are: 400 +--------+--------------------------------------------+ 401 | Status | Description | 402 +--------+--------------------------------------------+ 403 | 0 | Success | 404 | 1 | Duplicate Address | 405 | 2 | Neighbor Cache Full | 406 | 3-255 | Allocated using Standards Action [RFC2434] | 407 +--------+--------------------------------------------+ 409 Table 1 411 7.2. Refresh and De-registration 413 A host SHOULD send a Registration messge in order to renew its 414 registration before its registration lifetime expires in order to 415 continue its connectivity with the network. If anytime, the node 416 decides that it does not need the default router's service anymore, 417 it MUST send a de-registration message - i,e, a registration message 418 with lifetime being set to zero. A mobile host SHOULD first de- 419 register with the default router before it moves away from the 420 subnet. 422 7.3. A New Router Advertisement Flag 424 A new Router Advertisment flag [RF] is needed in order to distnguish 425 a router advertisement from a energy-aware default router or a legacy 426 IPv6 router. This flag is ignored by the legacy IPv6 hosts. EAH 427 hosts use this flag in oder to discover a NEAR router if it receives 428 multiple RA from both legacy and NEAR routers. 430 0 1 2 3 4 5 6 7 431 +-+-+-+-+-+-+-+-+ 432 |M|O|H|Prf|P|E|R| 433 +-+-+-+-+-+-+-+-+ 435 The 'E' bit above MUST be 1 when a IPv6 router implements and 436 configures the Energy-aware Router behavior for Neighbor Discovery as 437 per this document. All other cases E bit is 0. 439 The legacy IPv6 hosts will ignore the E bit in RA advertisement. All 440 EAH MUST look for E bit in RA in order to determine the Energy-aware 441 support in the default router in the link. 443 This document assumes that an implementation will have configuration 444 knobs to determine whether it is running in classical IPv6 ND [ND] or 445 Optimized Energy Aware ND (this document) mode or both(Mixed mode). 447 8. Energy-aware Neighbor Discovery Messages 449 Router Advertisement(RA): Periodic RAs SHOULD be avoided. Only 450 solicited RAs are RECOMMENDED. An RA MUST 451 contain the Source Link-layer Address option 452 containing Router's link-layer address (this 453 is optional in [ND]. An RA MUST carry Prefix 454 information option with L bit being unset, so 455 that hosts do not multicast any NS messages 456 as part of address resolution. A new flag 457 (E-flag) is introduced in the RA in order to 458 characterize the energy-aware mode support. 459 Unlike RFC4861 which suggests multicast 460 Router Advertisements, this specification 461 optimizes the exchange by always unicasting 462 RAs in response to RS. This is possible 463 since the RS always includes a SLLA option, 464 which is used by the router to unicast the 465 RA. 466 Router Solicitation(RS): Upon system startup, the node sends a 467 multicast or link broadcast (when multicast 468 is not supported at the link-layer) RS to 469 find out the available routers in the link. 470 An RS may be sent at other times as described 471 in section 6.3.7 of RFC 4861. A Router 472 Solicitation MUST carry Source Link-layer 473 Address option. Since no periodic RAs are 474 allowed in the energy-aware IPv6 network, the 475 host may send periodic unicast RS to the 476 routers. The time-periods for the RS varies 477 on the deployment scenarios and the Default 478 Router Lifetime advertised in the RAs. 479 Default Router Selection: Same as in section 6.3.6 of RFC 4861[ND]. 480 Neighbor Solicitation (NS): Neighbor solicitation is used between 481 the hosts and the default-router as part of 482 NUD and registering the host's address(es). 483 An NS message MUST use the Address 484 Registration option in order to accomplish 485 the registration. 486 Neighbor Advertisement (NA): As defined in [ND] and ARO option. 487 Redirect Messages: A router SHOULD NOT send a Redirect message 488 to a host since the link has non-transitive 489 reachability. The host behavior is same as 490 described in section 8.3 of RFC 4861[ND], 491 i,e. a host MUST NOT send or accept redirect 492 messages when in energy-aware mode. 493 Same as in RFC 4861[ND] 494 MTU option: As per the RFC 4861. 495 Address Resolution: No NS/NA are sent as the prefixes are treated 496 as off-link. Thus no address resolution is 497 performed at the hosts. The routers keep 498 track of Neighbor Solicitations with Address 499 Registration options(ARO) and create an 500 extended neighbor cache of reachable 501 addresses. The router also knows the nexthop 502 link-local address and corresponding link- 503 layer address when it wants to route a 504 packet. 505 Neighbor Unreachability Detection(NUD): NUD is performed in 506 "forward-progress" fashion as described in 507 section 7.3.1 of RFC 4861[ND]. However, if 508 Address Registration Option is used, the NUD 509 SHOULD be combined with the Re-registration 510 of the node. This way no extra message for 511 NUD is required. 513 9. Energy-Aware Host Behavior 515 A host sends Router Solicitation at the system startup and also when 516 it suspects that one of its default routers have become 517 unreachable(after NUD fails). The EAH MUST process the E-bit in RA 518 as described in this document. The EAH MUST use ARO option to 519 register with the neighboring NEAR router. 521 A host SHOULD be able to autoconfigure its IPv6 addresses using the 522 IPv6 prefix obtained from Router Advertisement. The host SHOULD form 523 its link-local address from the EUI-64 as specified by IEEE 524 Registration Authority and RFC 2373. If this draft feature is 525 implemented and configured, the host MUST NOT re-direct Neighbor 526 Discovery messages. The host does not require to join solicited-node 527 multicast address but it MUST join the all-node multicast address. 529 A host always sends packets to (one of) its default router(s). This 530 is accomplished by the routers never setting the 'L' flag in the 531 Prefix options. 533 The host is unable to forward routes or participate in a routing 534 protocol. A legacy IPv6 Host compliant EAH SHOULD be able to fall 535 back to RFC 4861 host behavior if there is no energy-aware router 536 (NEAR) in the link. 538 The energy-aware host MUST NOT send or accept re-direct messages. It 539 does not join solicited node multicast address. 541 10. The Energy Aware Default Router (NEAR) Behavior 543 The main purpose of the default router in the context of this 544 document is to receive and process the registration request, forward 545 packets from one neighbor to the other, informs the routing protocol 546 about the un-availability of the registered nodes if the routing 547 protocol requires this information for the purpose of mobility or 548 fast convergence. A default router (NEAR) behavior may be observed 549 in one or more interfaces of a Border Router(BR). 551 A Border Router normally may have multiple interfaces and connects 552 the nodes in a link like a regular IPv6 subnet(s) or acts as a 553 gateway between separate networks such as Internet and home networks 554 . The Border Router is responsible for distributing one or more /64 555 prefixes to the nodes to identify a packet belonging to the 556 particular network. One or more of the interfaces of the Border 557 Router may be connected with the energy-aware hosts or a energy-aware 558 router(NEAR). 560 The Energy-Aware default router MUST not send periodic RA unless it 561 is configured to support both legacy IPv6 and energy-aware hosts. If 562 the Router is configured for Energy-Aware hosts support, it MUST send 563 Router Advertisments with E-bit flag ON and MUST NOT set 'L' bit in 564 the advertisements. 566 The router SHOULD NOT garbage collect Registered Neighbor Cache 567 entries since they need to retain them until the Registration 568 Lifetime expires. If a NEAR receives a NS message from the same host 569 one with ARO and another without ARO then the NS message with ARO 570 gets the precedence and the NS without ARO is ignored. This behavior 571 protects the router from Denial Of Service attacks. Similarly, if 572 Neighbor Unreachability Detection on the router determines that the 573 host is UNREACHABLE (based on the logic in [ND]), the Neighbor Cache 574 entry SHOULD NOT be deleted but be retained until the Registration 575 Lifetime expires. If an ARO arrives for an NCE that is in 576 UNCREACHABLE state, that NCE should be marked as STALE. 578 A default router keeps a cache for all the nodes' IP addresses, 579 created from the Address Registration processing. 581 10.1. Router Configuration Modes 583 An energy-aware Router(NEAR) MUST be able to configure in energy- 584 aware-only mode where it will expect all hosts register with the 585 router following RS; thus will not support legacy hosts. However, it 586 will create legacy NCE for NS messages for other routers in the 587 network. This mode is able to prevent ND flooding on the link. 589 An energy-aware Router(NEAR) SHOULD be able to have configuration 590 knob to configure itself in Mixed-Mode where it will support both 591 energy-aware hosts and legacy hosts. However even in mixed-mode the 592 router should check for duplicate entries in the NCE before creating 593 a new ones and it should rate-limit creating new NCE based on 594 requests from the same host MAC address. 596 The RECOMMENDED default mode of operation for the energy-aware router 597 is Mixed-mode. 599 11. NCE Management in Energy-Aware Routers 601 The use of explicit registrations with lifetimes plus the desire to 602 not multicast Neighbor Solicitation messages for hosts imply that we 603 manage the Neighbor Cache entries slightly differently than in [ND]. 604 This results in two different types of NCEs and the types specify how 605 those entries can be removed: 607 Legacy: Entries that are subject to the normal rules in 608 [ND] that allow for garbage collection when low 609 on memory. Legacy entries are created only 610 when there is no duplicate NCE. In mixed-mode 611 and energy-aware mode the legacy entries are 612 converted to the registered entries upon 613 successful processing of ARO. Legacy type can 614 be considered as union of garbage-collectible 615 and Tentative Type NCEs described in 616 [6LOWPAN-ND]. 618 Registered: Entries that have an explicit registered 619 lifetime and are kept until this lifetime 620 expires or they are explicitly unregistered. 622 Note that the type of the NCE is orthogonal to the states specified 623 in [ND]. 625 When a host interacts with a router by sending Router Solicitations 626 that does not match with the existing NCE entry of any type, a Legacy 627 NCE is first created. Once a node successfully registers with a 628 Router the result is a Registered NCE. As Routers send RAs to legacy 629 hosts, or receive multicast NS messages from other Routers the result 630 is Legacy NCEs. There can only be one kind of NCE for an IP address 631 at a time. 633 A Router Solicitation might be received from a host that has not yet 634 registered its address with the router or from a legacy[ND] host in 635 the Mixed-mode of operation. 637 In the 'Enrgy-aware' only mode the router MUST NOT modify an existing 638 Neighbor Cache entry based on the SLLA option from the Router 639 Solicitation. Thus, a router SHOULD create a tentative Legacy 640 Neighbor Cache entry based on SLLA option when there is no match with 641 the existing NCE. Such a legacy Neighbor Cache entry SHOULD be timed 642 out in TENTATIVE_LEGACY_NCE_LIFETIME seconds unless a registration 643 converts it into a Registered NCE. 645 However, in 'Mixed-mode' operation, the router does not require to 646 keep track of TENTATIVE_LEGACY_NCE_LIFETIME as it does not know if 647 the RS request is from a legacy host or the energy-aware hosts. 648 However, it creates the legacy type of NCE and updates it to a 649 registered NCE if the ARO NS request arrives corresponding to the 650 legacy NCE. Successful processing of ARO will complete the NCE 651 creation phase. 653 If ARO did not result in a duplicate address being detected, and the 654 registration life-time is non-zero, the router creates and updates 655 the registered NCE for the IPv6 address. if the Neighbor Cache is 656 full and new entries need to be created, then the router SHOULD 657 respond with a NA with status field set to 2. For successful 658 creation of NCE, the router SHOULD include a copy of ARO and send NA 659 to the requestor with the status field 0. A TLLA(Target Link Layer) 660 Option is not required with this NA. 662 Typically for energy-aware routers (NEAR), the registration life-time 663 and EUI-64 are recorded in the Neighbor Cache Entry along with the 664 existing information described in [ND]. The registered NCE are meant 665 to be ready and reachable for communication and no address resolution 666 is required in the link. The energy-aware hosts will renew their 667 registration to keep maintain the state of reachability of the NCE at 668 the router. However the router may do NUD to the idle or unreachable 669 hosts as per [ND]. 671 11.1. Handling ND DOS Attack 673 IETF community has discussed possible issues with /64 DOS attacks on 674 the ND networks when a attacker host can send thousands of packets to 675 the router with a on-link destination address or sending RS messages 676 to initiate a Neighbor Solicitation from the neighboring router which 677 will create a number of INCOMPLETE NCE entries for non-existent nodes 678 in the network resulting in table overflow and denial of service of 679 the existing communications. 681 The energy-aware behavior documented in this specification avoids the 682 ND DOS attacks by: 684 o Having the hosts register with the default router 685 o Having the hosts send their packets via the default router 686 o Not resolving addresses for the Routing Solicitor by mandating 687 SLLA option along with RS 688 o Checking for duplicates in NCE before the registration 689 o Checking against the MAC-address and EUI-64 id is possible now for 690 NCE matches 691 o On-link IPv6-destinations on a particular link must be registered 692 else these packets are not resolved and extra NCEs are not created 694 It is recomended that Mixed-mode operation and legacy hosts SHOULD 695 NOT be used in the IPv6 link in order to avoid the ND DOS attacks. 696 For the general case of Mixed-mode the router does not create 697 INCOMPLETE NCEs for the registered hosts, but it follows the [ND] 698 steps of NCE states for legacy hosts. 700 12. Mixed-Mode Operations 702 Mixed-Mode operation discusses the protocol behavior where the IPv6 703 subnet is composed with legacy IPv6 Neighbor Discovery compliant 704 nodes and energy-aware IPv6 nodes implementing this specification. 706 The mixed-mode model SHOULD support the following configurations in 707 the IPv6 link: 708 o The legacy IPv6 hosts and energy-aware-hosts in the network and a 709 NEAR router 710 o legacy IPv6 default-router and energy-aware hosts(EAH) in the link 711 o one router is in mixed mode and the link contains both legacy IPv6 712 hosts and EAH 713 o A link contains both energy-aware IPv6 router and hosts and legacy 714 IPv6 routers and hosts and each host should be able to communicate 715 with each other. 717 In mixed-mode operation, a NEAR MUST be configured for mixed-mode in 718 order to support the legacy IPv6 hosts in the network. In mixed- 719 mode, the NEAR MUST act as proxy for Neighbor Solicitation for DAD 720 and Address Resolution on behalf of its registered hosts on that 721 link. It should follow the NCE management for the EAH as described 722 in this document and follow RFC 4861 NCE management for the legacy 723 IPv6 hosts. Both in mixed-mode and energy-aware mode, the NEAR sets 724 E-bit flag in the RA and does not set 'L' on-link bit. 726 If a NEAR receives NS message from the same host one with ARO and 727 another without ARO then the NS message with ARO gets the precedence. 729 An Energy-Aware Host implementation SHOULD support falling back to 730 legacy IPv6 node behavior when no energy-aware routers are available 731 in the network during the startup. If the EAH was operational in 732 energy-aware mode and it determines that the NEAR is no longer 733 available, then it should send a RS and find an alternate default 734 router in the link. If no energy-aware router is indicated from the 735 RA, then the EAH SHOULD fall back into RFC 4861 behavior. On the 736 otherhand, in the energy-aware mode EAH SHOULD ignore multicast 737 Router Advertisements(RA) sent by the legacy and Mixed-mode routers 738 in the link. 740 The routers that are running on energy-aware mode or legacy mode 741 SHOULD NOT dynamically switch the mode without flushing the Neighbor 742 Cache Entries. 744 13. Bootstrapping 746 If the network is a energy-aware IPv6 subnet, and the energy-aware 747 Neighbor Discovery mechansim is used by the hosts and routers as 748 described in this document. At the start, the node uses its link- 749 local address to send Router Solicitation and then it sends the Node 750 Registration message as described in this document in order to form 751 the address. The Duplicate address detection process should be 752 skipped if the network is guaranteed to have unique interface 753 identifiers which is used to form the IPv6 address. 755 Node Router 757 | | 759 1. | ---------- Router Solicitation --------> | 761 | [SLLAO] | 763 2. | <-------- Router Advertisement --------- | 765 | [PIO + SLLAO] | 766 | | 768 3. | ----- Address Registration (NS) --------> | 770 | [ARO + SLLAO] | 772 4. | <-------- Neighbor Advertisement ------- | 774 | [ARO with Status code] | 776 5. ====> Address Assignment Complete 778 Figure 1: Neighbor Discovery Address Registration and bootstrapping 780 In the mixed mode operation, it is expected that logically there will 781 be at least one legacy IPv6 router and another NEAR router present in 782 the link. The legacy IPv6 router will follow RFC 4861 behavior and 783 NEAR router will follow the energy-aware behavior for registration, 784 NCE maintenance, forwarding packets from a EAH and it will also act 785 as a ND proxy for the legacy IPv6 hosts querying to resolve a EAH 786 node. 788 A legacy IPv6 host and EAH are not expected to see a difference in 789 their bootstrapping if both legacy and energy-aware functionalities 790 of rotuers are available in the network. It is RECOMMEDED that the 791 EAH implementation SHOULD be able to behave like a legacy IPv6 host 792 if it discovers that no energy-aware routing support is present in 793 the link. 795 14. Handling Sleepy Nodes 797 The solution allows the sleepy nodes to complete its sleep schedule 798 without waking up due to periodic Router Advertisement messages or 799 due to Multicast Neighbor Solicitation for address resolution. The 800 node registration lifetime SHOULD be synchronized with its sleep 801 interval period in order to avoid waking up in the middle of sleep 802 for registration refresh. Depending on the application, the 803 registration lifetime SHOULD be equal to or integral multiple of a 804 node's sleep interval period. 806 15. Use Case Analysis 808 This section provides applicability scenarios where the energy-aware 809 Neighbor Discovery will be most beneficial. 811 15.1. Data Center Routers on the link 813 Energy-aware Routers and hosts are useful in IPv6 networks in the 814 Data Center as they produce less signaling and also provides ways to 815 minimize the ND flood of messages. Moreover, this mechanism will 816 work with data-center nodes which are deliberately in sleep mode for 817 saving energy. 819 This solution will work well in Data Center Virtual network and VM 820 scenarios where number of VLANs are very high and ND signalings are 821 undesirably high due the multicast messaging and periodic Router 822 Advertisments and Neighbor Unreachability detections. 824 15.2. Edge Routers and Home Networks 826 An Edge Router in the network will also benefit implementing the 827 energy-aware Neighbor Discovery behavior in order to save the 828 signaling and keeping track of the registered nodes in its domain. A 829 BNG sits at the operator's edge network and often the BNG has to 830 handle a large number of home CPEs. If a BNG runs Neighbor Discovery 831 protocol and acts as the default router for the CPE at home, this 832 solution will be helpful for reducing the control messages and 833 improving network performances. 835 The same solution can be run on CPE or Home Residential Gateways to 836 assign IPv6 addresses to the wired and wireless home devices without 837 the problem of ND flooding issues and consuming less power. It 838 provides mechanism for the sleepy nodes to adjust their registration 839 lifetime according to their sleep schedules. 841 15.3. M2M Networks 843 Any Machine-to-machine(M2M) networks such as IPv6 surveilance 844 networks, wireless monitoring networks and other m2m networks desire 845 for energy-aware control protocols and dynamic address allocation. 846 The in-built address allocation and autoconfiguration mechanism in 847 IPv6 along with the default router capability will be useful for the 848 simple small-scale networks without having the burden of DHCPv6 849 service and Routing Protocols. 851 16. Mobility Considerations 853 If the hosts move from one subnet to another, they MUST first de- 854 register and then register themselves in the new subnet or network. 855 Otherwise, the regular IPv6 Mobility [IPV6M]behavior applies. 857 17. Updated Neighbor Discovery Constants 859 This section discusses the updated default values of ND constants 860 based on [ND] section 10. New and changed constants are listed only 861 for energy-aware-nd implementation. 863 Router Constants: 864 MAX_RTR_ADVERTISEMENTS(NEW) 3 transmissions 865 MIN_DELAY_BETWEEN_RAS(CHANGED) 1 second 866 TENTATIVE_LEGACY_NCE_LIFETIME(NEW) 30 seconds 868 Host Constants: 869 MAX_RTR_SOLICITATION_INTERVAL(NEW) 60 seconds 871 18. Security Considerations 873 These optimizations are not known to introduce any new threats 874 against Neighbor Discovery beyond what is already documented for IPv6 875 [RFC 3756]. 877 Section 11.2 of [ND] applies to this document as well. 879 This mechanism minimizes the possibility of ND /64 DOS attacks in 880 energy-aware mode. See Section 11.1. 882 19. IANA Considerations 884 A new flag (E-bit) in RA has been introduced. IANA assignment of the 885 E-bit flag is required upon approval of this document. 887 20. Changelog 889 Changes from 00 to 01: 891 o Removed ABRO options and Multi-level subnet concept 892 o Removed intermediate-router concept, behavior and definition 893 o Added use-cases, Support for Mixed-mode operations and a diagram 894 for bootstrapping scenario. 895 o Added updates to ND constant values 896 o A new co-author has beed added 897 o Text for NCE Management and ND-DOS handling has been added 898 o A new Router Advertisement flag has been added 900 21. Acknowledgements 902 The primary idea of this document are from 6LoWPAN Neighbor Discovery 903 document [6LOWPAN-ND] and the discussions from the 6lowpan working 904 group members, chairs Carsten Bormann and Geoff Mulligan and through 905 our discussions with Zach Shelby, editor of the [6LOWPAN-ND]. 907 The inspiration of such a IPv6 generic document came from Margaret 908 Wasserman who saw a need for such a document at the IOT workshop at 909 Prague IETF. 911 22. References 913 22.1. Normative References 915 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 916 Requirement Levels", BCP 14, RFC 2119, March 1997. 918 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 919 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 920 October 1998. 922 [6LOWPAN-ND] 923 Shelby, Z., Chakrabarti, S., and E. Nordmark, "ND 924 Optimizations for 6LoWPAN", draft-ietf-6lowpan-nd-17.txt 925 (work in progress), June 2011. 927 [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 928 "Neighbor Discovery for IP version 6", RFC 4861, 929 September 2007. 931 [LOWPAN] Montenegro, G. and N. Kushalnagar, "Transmission of IPv6 932 Packets over IEEE 802.15.4 networks", RFC 4944, 933 September 2007. 935 [LOWPANG] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview, 936 Assumptions, Problem Statement and Goals", RFC 4919, 937 August 2007. 939 22.2. Informative References 941 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 942 (IPv6), Specification", RFC 2460, December 1998. 944 [AUTOCONF] 945 Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 946 Autoconfiguration", RFC 4862, September 2007. 948 [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "Secure 949 Neighbor Discovery", RFC 3971, March 2005. 951 [AUTOADHOC] 952 Baccelli, E. and M. Townsley, "IP Addressing Model in 953 Adhoc Networks", 954 draft-ietf-autoconf-adhoc-addr-model-02.txt (work in 955 progress), December 2009. 957 [IEEE] IEEE Computer Society, "IEEE Std. 802.15.4-2003", , 958 October 2003. 960 [PD] Miwakawya, S., "Requirements for Prefix Delegation", 961 RFC 3769, June 2004. 963 [RF] Haberman, B. and B. Hinden, "IPv6 Router Advertisement 964 Flags option", RFC 5175, March 2008. 966 [ULA] "Unique Local IPv6 Addresses", RFC 4193. 968 [IPV6M] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 969 in IPv6", RFC 6275, July 2011. 971 Authors' Addresses 973 Samita Chakrabarti 974 Ericsson 975 San Jose, CA 976 USA 978 Email: samita.chakrabarti@ericsson.com 979 Erik Nordmark 980 Cisco Systems 981 San Jose, CA 982 USA 984 Email: nordmark@cisco.com 986 Margaret Wasserman 987 Painless Security 989 Email: mrw@lilacglade.org