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