idnits 2.17.1 draft-chakrabarti-nordmark-6man-efficient-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 efficiency-aware default router MUST not send periodic RA unless it is configured to support both legacy IPv6 and efficiency-aware hosts. If the Router is configured for efficiency-aware hosts support, it MUST send Router 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 (November 21, 2012) is 4175 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 182, but not defined == Missing Reference: 'SLLAO' is mentioned on line 780, but not defined == Missing Reference: 'RFC 3756' is mentioned on line 969, but not defined == Unused Reference: 'LOWPANG' is defined on line 1036, but no explicit reference was found in the text == Unused Reference: 'IPV6' is defined on line 1042, but no explicit reference was found in the text == Unused Reference: 'SEND' is defined on line 1053, but no explicit reference was found in the text == Unused Reference: 'AUTOADHOC' is defined on line 1056, but no explicit reference was found in the text == Unused Reference: 'NDDOS-halpern' is defined on line 1060, but no explicit reference was found in the text == Unused Reference: 'IEEE' is defined on line 1076, but no explicit reference was found in the text == Unused Reference: 'PD' is defined on line 1079, but no explicit reference was found in the text == Unused Reference: 'IPV6M' is defined on line 1087, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 4919 (ref. 'LOWPANG') -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) == Outdated reference: A later version (-07) exists of draft-ietf-6man-impatient-nud-05 Summary: 2 errors (**), 0 flaws (~~), 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 25, 2013 M. Wasserman 7 Painless Security 8 November 21, 2012 10 Efficiency aware IPv6 Neighbor Discovery Optimizations 11 draft-chakrabarti-nordmark-6man-efficient-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, m2m and Cellular(LTE) networks, there is a desire for 20 optimizing the legacy IPv6 Neighbor Discovery protocol. This 21 document describes a method of optimization by reducing multicast 22 messages and introducing an IPv6 address Registration mechanism. 23 Efficient IPv6 Neighbor Discovery protocol is useful for energy- 24 efficient IPv6 networks and as well as Data Center and Home Networks. 25 The solution is capable of handling existing legacy IPv6 nodes in the 26 network. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 25, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 5 64 3. Assumptions for efficiency-aware Neighbor Discovery . . . . . 7 65 4. The set of Requirements for efficiency and optimization . . . 7 66 5. Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 7 67 6. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 68 7. New Neighbor Discovery Options and Messages . . . . . . . . . 9 69 7.1. Address Registration Option . . . . . . . . . . . . . . . 9 70 7.2. Refresh and De-registration . . . . . . . . . . . . . . . 10 71 7.3. A New Router Advertisement Flag . . . . . . . . . . . . . 11 72 8. Efficiency-aware Neighbor Discovery Messages . . . . . . . . . 11 73 9. Efficiency-aware Host Behavior . . . . . . . . . . . . . . . . 13 74 10. The Energy Aware Default Router (NEAR) Behavior . . . . . . . 13 75 10.1. Router Configuration Modes . . . . . . . . . . . . . . . . 14 76 11. NCE Management in efficiency-aware Routers . . . . . . . . . . 15 77 11.1. Handling ND DOS Attack . . . . . . . . . . . . . . . . . . 16 78 12. Mixed-Mode Operations . . . . . . . . . . . . . . . . . . . . 17 79 13. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 18 80 14. Handling Sleepy Nodes . . . . . . . . . . . . . . . . . . . . 19 81 15. Duplicate Address Detection . . . . . . . . . . . . . . . . . 19 82 16. Use Case Analysis . . . . . . . . . . . . . . . . . . . . . . 19 83 16.1. Data Center Routers on the link . . . . . . . . . . . . . 19 84 16.2. Edge Routers and Home Networks . . . . . . . . . . . . . . 20 85 16.3. M2M Networks . . . . . . . . . . . . . . . . . . . . . . . 20 86 16.4. Cellular and Wi-fi Networks . . . . . . . . . . . . . . . 20 87 17. Mobility Considerations . . . . . . . . . . . . . . . . . . . 20 88 18. Other Considerations . . . . . . . . . . . . . . . . . . . . . 21 89 18.1. Detecting Network Attachment(DNA) . . . . . . . . . . . . 21 90 18.2. Proxying for Efficiency-Aware hosts . . . . . . . . . . . 21 91 18.3. DHCPv6 Interaction . . . . . . . . . . . . . . . . . . . . 21 92 19. Updated Neighbor Discovery Constants . . . . . . . . . . . . . 22 93 20. Security Considerations . . . . . . . . . . . . . . . . . . . 22 94 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 95 22. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22 96 23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 97 24. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 98 24.1. Normative References . . . . . . . . . . . . . . . . . . . 23 99 24.2. Informative References . . . . . . . . . . . . . . . . . . 24 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 102 1. Introduction 104 IPv6 ND [ND] is based on multicast signaling messages on the local 105 link in order to avoid broadcast messages. Following power-on and 106 initialization of the network in IPv6 Ethernet networks, a node joins 107 the solicited-node multicast address on the interface and then 108 performs duplicate address detection (DAD) for the acquired link- 109 local address by sending a solicited-node multicast message to the 110 link. After that it sends multicast router solicitation (RS) 111 messages to the all-router address to solicit router advertisements. 112 Once the host receives a valid router advertisement (RA) with the "A" 113 flag, it autoconfigures the IPv6 address with the advertised prefix 114 in the router advertisement (RA). Besides this, the IPv6 routers 115 usually send router advertisements periodically on the network. RAs 116 are sent to the all-node multicast address. The minimum RA interval 117 range can be 3sec to 600sec depending on applications. Nodes send 118 Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages 119 to resolve the IPv6 address of the destination on the link. These 120 NS/NA messages are also often multicast messages and it is assumed 121 that the node is on the same link and relies on the fact that the 122 destination 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. 134 IPv6 Neighbor Discovery Optimization for 6LoWPAN [6LOWPAN-ND] 135 addresses many of the concerns described above by optimizing the 136 Router advertisement, minimizing periodic multicast packets in the 137 network and introducing two new options - one for node registration 138 and another for prefix dissemination in a network where all nodes in 139 the network are uniquely identified by their 64-bit Interface 140 Identifier. EUI-64 identifiers are recommended as unique Interface 141 Identifiers, however if the network is isolated from the Internet, 142 uniqueness of the identifiers may be obtained by other mechanisms 143 such as a random number generator with lowest collision rate. 144 Although, the ND optimization [6LOWPAN-ND] applies to 6LoWPAN 145 [LOWPAN] network, the concept is mostly applicable to a power-aware 146 IPv6 network. Therefore, this document generalizes the address 147 registration and multicast reduction in [6LOWPAN-ND] to all IPv6 148 links. 150 Thus optimizing the regular IPv6 Neighbor Discovery [ND] to minimize 151 total number of related signaling messages without losing generality 152 of Neighbor Discovery, autoconfiguration and reliable host-router 153 communication, are desirable in any efficient IPv6 networks such as 154 Home, Enterprise networks, Data Centers and Operator's Cellular/ 155 Wireless networks. 157 The optimization will be highly effective for links and nodes which 158 do not support multicast and as well as for a multicast network 159 without MLD snooping switches. Moreover, in the MLD-snooping 160 networks the MLD switches will deal with less number of multicasts. 162 The goal of this document is to provide an efficient Neighbor 163 Discovery Protocol in classic IPv6 subnets and links. Research 164 indicates that often networked-nodes require more energy than stand- 165 alone nodes because a node's energy usage depends on network messages 166 it receives and responds. While reducing energy consumption is 167 essential for battery operated nodes in some machines, saving energy 168 actually a cost factor in business in general as the explosion of 169 more device usage is leading to usage of more servers and network 170 infrastructure in all sectors of the society and business. Thus this 171 document introduces the node registration concept discussed in 172 6LoWPAN [LOWPAN], without handling the 'multi-level subnets' 173 scenarios that are not the typical usecases in classic IPv6 subnets. 175 In the process, the node registration method is also deemed to be 176 useful for preventing Neighbor Discovery denial of service ( ND DOS) 177 attacks. 179 The proposed changes can be used in two different ways. In one case 180 all the hosts and routers on a link implement the new mechanisms, 181 which gives the maximum benefits. In another case the link has a 182 mixture of new hosts and/or routers and legacy [RFC4861] hosts and 183 routers, operating in a mixed-mode providing some of the benefits. 185 In the following sections the document describes the basic operations 186 of registration methods, optimization of Neighbor Discovery messages, 187 interoperability with legacy IPv6 implementations and provides a 188 section on use-case scenarios where it can be typically applicable. 190 2. Definition Of Terms 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in [RFC2119]. 196 multi-level Subnets: 197 It is a wireless link determined by one IPv6 off-link prefix in a 198 network where in order to reach a destination with same prefix a 199 packet may have to travel throguh one more 'intermediate' routers 200 which relays the packet to the next 'intermediate' router or the 201 host in its own. 202 Border Rotuer(BR): 203 A border router is typically located at the junction Internet and 204 Home Network. An IPv6 router with one interface connected to IPv6 205 subnet and other interface connecting to a non-classic IPv6 206 interface such as 6LoWPAN interface. Border router is usually the 207 gateway to the IPv6 network or Internet. 208 Efficiency-Aware Network: 209 An Efficiency-Aware network is composed of network elements that 210 are sensitive to energy usage or number of signalling messages in 211 the network. An efficiency-aware network may also contain links 212 that do not support multicast or it does not have MLD snooping 213 capabilities and yet the network likes to communicate most 214 efficiently with minimum number of signaling messages. Data 215 center networks with virtual machines, cellular IPv6 networks, any 216 IPv6 networks with energy-sensitive nodes are examples of 217 Efficiency-Aware networks. 218 IPv6 ND-efficiency-aware Rotuer(NEAR): 219 It is the default Router of the single hop IPv6 subnet. This 220 router implements the optimizations specified in this document. 221 This router should be able to handle both legacy IPv6 nodes and 222 nodes that sends registration request. 223 Efficiency-Aware Host(EAH): 224 A host in a IPv6 network is considered a IPv6 node without routing 225 and forwarding capability. The EAH is the host which implements 226 the host functionality for optimized Neighbor Discovery mentioned 227 in this document. 228 Legacy IPv6 Host: 229 A host in a IPv6 network is considered a IPv6 node without routing 230 and forwarding capability and implements RFC 4861 host functions. 231 Legacy IPv6 Router: 232 An IPv6 Router which implements RFC 4861 Neighbor Discovery 233 protocols. 234 EUI-64: 235 It is the IEEE defined 64-bit extended unique identifier formed by 236 concatenation of 24-bit or 36-bit company id value by IEEE 237 Registration Authority and the extension identifier within that 238 company-id assignment. The extension identifiers are 40-bit (for 239 24-bit company-id) or 28-bit (for the 36-bit company-id) 240 respectively. 242 3. Assumptions for efficiency-aware Neighbor Discovery 244 o The efficiency-aware nodes in the network carry unique interface 245 ID in the network in order to form the auto-configured IPv6 246 address uniquely. An EUI-64 interface ID required for global 247 communication. 248 o All nodes are single IPv6-hop away from their default router in 249 the subnet. 250 o /64-bit IPv6 prefix is used for Stateless Auto-address 251 configuration (SLAAC). The IPv6 Prefix may be distributed with 252 Router Advertisement (RA) from the default router to all the nodes 253 in that link. 255 4. The set of Requirements for efficiency and optimization 257 o Node Registration: Node initiated Registration and address 258 allocation is done in order to avoid periodic multicast Router 259 Advertisement messages and often Neighbor Address resolution can 260 be skipped as all packets go via the default router which now 261 knows about all the registered nodes. Node Registration enables 262 reduction of all-node and solicited-node multicast messages in the 263 subnet. 264 o Address allocation of registered nodes [ND] are performed using 265 IPv6 Autoconfiguration [AUTOCONF]. 266 o Host initiated Registration and Refresh is done by sending a 267 Router Solicitation and then a Neighbor Solicitation Messge using 268 Address Registration Option (described below). 269 o The node registration may replace the requirement of doing 270 Duplicate Address Detection. 271 o Sleepy hosts are supported by this Neighbor Discovery procedures 272 as they are not woken up periodically by Router Advertisement 273 multicast messages or Neighbor Solicitation multicast messages. 274 Sleepy nodes may wake up in its own schedule and send unicast 275 registration refresh messages when needed. 276 o Since this document requires formation of an IPv6 address with an 277 unique 64-bit Interface ID(EUI-64) is required for global IPv6 278 addresses, if the network is an isolated one and uses ULA [ULA] as 279 its IPv6 address then the deployment should make sure that each 280 MAC address in that network has unique address and can provide a 281 unique 64-bit ID for each node in the network. 282 o /64-bit Prefix is required to form the IPv6 address. 283 o MTU requirement is same as IPv6 network. 285 5. Basic Operations 287 In the efficient-nd IPv6 Network, the NEAR routers are the default 288 routers for the efficiency-aware hosts (EAH). During the startup or 289 joining the network the host does not wait for the Router 290 Advertisements as the NEAR routers do not perform periodic multicast 291 RA as per RFC 4861. Instead, the EAH sends a multicast RS to find 292 out a NEAR router in the network. The RS message is the same as in 293 RFC 4861. The advertising routers in the link responds to the RS 294 message with RA with Prefix Information Option and any other options 295 configured in the network. If EAH hosts will look for a RA from a 296 NEAR (E-flag) and choose a NEAR as its default router and 297 consequently sends a unicast Neighbor Solicitation Message with ARO 298 option in order to register itself with the default router. The EAH 299 does not do Duplicate Address Detection or NS Resolution of 300 addresses. NEAR maintains a binding of registered nodes and 301 registration life-time information along with the neighbor Cache 302 information. The NEAR is responsible for forwarding all the messages 303 from its EAH including on-link messages from one EAH to another. For 304 details of protocol operations please see the sections below. 306 When a IPv6 network consists of both legacy hosts and EAH, and if the 307 NEAR is configured for 'mixed mode' operation, it should be able to 308 handle ARO requests and send periodic RA. Thus it should be able to 309 serve both efficiency-aware hosts and legacy hosts. Similarly, a 310 legacy host compatible EAH falls back to RFC 4861 host behavior if a 311 NEAR is not present in the link. See the section on 'Mixed Mode 312 Operations' for details below. 314 6. Applicability Statement 316 This document aims to guide the implementors to choose an appropriate 317 IPv6 neighbor discovery and Address configuration procedures suitable 318 for any efficient IPv6 network. These optimization is equally useful 319 for the energy-sensitive, non-multicast links and for classical IPv6 320 networks i.e home networks, Data-Center IPv6 overlay networks where 321 saving Neighbor Discovery messages will reduce cost and increase 322 bandwidth availability. See use cases towards the end of the 323 document. 325 Note that the specification allows 'Mixed-mode' operation in the 326 efficiency-aware nodes for backward compatibility and transitioning 327 to a complete efficiency-aware network of hosts and routers. Though 328 the efficiency-aware only nodes will minimize the ND signalling and 329 DOS attacks in the LAN. 331 Applicability of this solution is limited to the legacy IPv6 nodes 332 and subnets and it optimizes the generic IPv6 siganling activities at 333 network layer. However, further optimization at the application 334 layers are possible for increased efficiency based on particular 335 usecases and applications. 337 7. New Neighbor Discovery Options and Messages 339 This section will discuss the registration and de-registration 340 procedure of the hosts in the network. 342 7.1. Address Registration Option 344 The Address Registration Option(ARO) is useful for avoiding Duplicate 345 Address Detection messages since it requires a unique ID for 346 registration. The address registration is used for maintaining 347 reachability of the node or host by the router. This option is 348 exactly the same as in [6LOWPAN-ND] which is reproduced here for the 349 benefits of the readers. 351 The routers keep track of host IP addresses that are directly 352 reachable and their corresponding link-layer addresses. This is 353 useful for lossy and lowpower networks and as well as wired networks. 354 An Address Registration Option (ARO) can be included in unicast 355 Neighbor Solicitation (NS) messages sent by hosts. Thus it can be 356 included in the unicast NS messages that a host sends as part of 357 Neighbor Unreachability Detection to determine that it can still 358 reach a default router. The ARO is used by the receiving router to 359 reliably maintain its Neighbor Cache. The same option is included in 360 corresponding Neighbor Advertisement (NA) messages with a Status 361 field indicating the success or failure of the registration. This 362 option is always host initiated. 364 The ARO is required for reliability and power saving. The lifetime 365 field provides flexibility to the host to register an address which 366 should be usable (the reachability information may be propagated to 367 the routing protocols) during its intended sleep schedule of nodes 368 that switches to frequent sleep mode. 370 The sender of the NS also includes the EUI-64 of the interface it is 371 registering an address from. This is used as a unique ID for the 372 detection of duplicate addresses. It is used to tell the difference 373 between the same node re-registering its address and a different node 374 (with a different EUI-64) registering an address that is already in 375 use by someone else. The EUI-64 is also used to deliver an NA 376 carrying an error Status code to the EUI-64 based link-local IPv6 377 address of the host. 379 When the ARO is used by hosts an SLLA option MUST be included and the 380 address that is to be registered MUST be the IPv6 source address of 381 the Neighbor Solicitation message. 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Type | Length = 2 | Status | Reserved | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Reserved | Registration Lifetime | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | | 391 + EUI-64 or equivalent + 392 | | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Fields: 396 Type: 33 ( See [6LOWPAN-ND] ) 397 Length: 8-bit unsigned integer. The length of the option in 398 units of 8 bytes. Always 2. 399 Status: 8-bit unsigned integer. Indicates the status of a 400 registration in the NA response. MUST be set to 0 in 401 NS messages. See below. 402 Reserved: This field is unused. It MUST be initialized to zero 403 by the sender and MUST be ignored by the receiver. 404 Registration Lifetime: 16-bit unsigned integer. The amount of time 405 in a unit of 60 seconds that the router should retain 406 the Neighbor Cache entry for the sender of the NS that 407 includes this option. 408 EUI-64: 64 bits. This field is used to uniquely identify the 409 interface of the registered address by including the 410 EUI-64 identifier assigned to it unmodified. 412 The Status values used in Neighbor Advertisements are: 414 +--------+--------------------------------------------+ 415 | Status | Description | 416 +--------+--------------------------------------------+ 417 | 0 | Success | 418 | 1 | Duplicate Address | 419 | 2 | Neighbor Cache Full | 420 | 3-255 | Allocated using Standards Action [RFC2434] | 421 +--------+--------------------------------------------+ 423 Table 1 425 7.2. Refresh and De-registration 427 A host SHOULD send a Registration messge in order to renew its 428 registration before its registration lifetime expires in order to 429 continue its connectivity with the network. If anytime, the node 430 decides that it does not need the default router's service anymore, 431 it MUST send a de-registration message - i,e, a registration message 432 with lifetime being set to zero. A mobile host SHOULD first de- 433 register with the default router before it moves away from the 434 subnet. 436 7.3. A New Router Advertisement Flag 438 A new Router Advertisment flag [RF] is needed in order to distnguish 439 a router advertisement from a efficiency-aware default router or a 440 legacy IPv6 router. This flag is ignored by the legacy IPv6 hosts. 441 EAH hosts use this flag in oder to discover a NEAR router if it 442 receives multiple RA from both legacy and NEAR routers. 444 0 1 2 3 4 5 6 7 445 +-+-+-+-+-+-+-+-+ 446 |M|O|H|Prf|P|E|R| 447 +-+-+-+-+-+-+-+-+ 449 The 'E' bit above MUST be 1 when a IPv6 router implements and 450 configures the efficiency-aware Router behavior for Neighbor 451 Discovery as per this document. All other cases E bit is 0. 453 The legacy IPv6 hosts will ignore the E bit in RA advertisement. All 454 EAH MUST look for E bit in RA in order to determine the efficiency- 455 aware support in the default router in the link. 457 This document assumes that an implementation will have configuration 458 knobs to determine whether it is running in classical IPv6 ND [ND] or 459 Optimized Energy Aware ND (this document) mode or both(Mixed mode). 461 8. Efficiency-aware Neighbor Discovery Messages 463 Router Advertisement(RA): Periodic RAs SHOULD be avoided. Only 464 solicited RAs are RECOMMENDED. An RA MUST 465 contain the Source Link-layer Address option 466 containing Router's link-layer address (this 467 is optional in [ND]. An RA MUST carry Prefix 468 information option with L bit being unset, so 469 that hosts do not multicast any NS messages 470 as part of address resolution. A new flag 471 (E-flag) is introduced in the RA in order to 472 characterize the efficiency-aware mode 473 support. Unlike RFC4861 which suggests 474 multicast Router Advertisements, this 475 specification optimizes the exchange by 476 always unicasting RAs in response to RS. 477 This is possible since the RS always includes 478 a SLLA option, which is used by the router to 479 unicast the RA. 480 Router Solicitation(RS): Upon system startup, the node sends a 481 multicast or link broadcast (when multicast 482 is not supported at the link-layer) RS to 483 find out the available routers in the link. 484 An RS may be sent at other times as described 485 in section 6.3.7 of RFC 4861. A Router 486 Solicitation MUST carry Source Link-layer 487 Address option. Since no periodic RAs are 488 allowed in the efficiency-aware IPv6 network, 489 the host may send periodic unicast RS to the 490 routers. The time-periods for the RS varies 491 on the deployment scenarios and the Default 492 Router Lifetime advertised in the RAs. 493 Default Router Selection: Same as in section 6.3.6 of RFC 4861[ND]. 494 Neighbor Solicitation (NS): Neighbor solicitation is used between 495 the hosts and the default-router as part of 496 NUD and registering the host's address(es). 497 An NS message MUST use the Address 498 Registration option in order to accomplish 499 the registration. 500 Neighbor Advertisement (NA): As defined in [ND] and ARO option. 501 Redirect Messages: A router SHOULD NOT send a Redirect message 502 to a host since the link has non-transitive 503 reachability. The host behavior is same as 504 described in section 8.3 of RFC 4861[ND], 505 i,e. a host MUST NOT send or accept redirect 506 messages when in efficiency-aware mode. 507 Same as in RFC 4861[ND] 508 MTU option: As per the RFC 4861. 509 Address Resolution: No NS/NA are sent as the prefixes are treated 510 as off-link. Thus no address resolution is 511 performed at the hosts. The routers keep 512 track of Neighbor Solicitations with Address 513 Registration options(ARO) and create an 514 extended neighbor cache of reachable 515 addresses. The router also knows the nexthop 516 link-local address and corresponding link- 517 layer address when it wants to route a 518 packet. 520 Neighbor Unreachability Detection(NUD): NUD is performed in 521 "forward-progress" fashion as described in 522 section 7.3.1 of RFC 4861[ND]. However, if 523 Address Registration Option is used, the NUD 524 SHOULD be combined with the Re-registration 525 of the node. This way no extra message for 526 NUD is required. 528 9. Efficiency-aware Host Behavior 530 A host sends Router Solicitation at the system startup and also when 531 it suspects that one of its default routers have become 532 unreachable(after NUD fails). The EAH MUST process the E-bit in RA 533 as described in this document. The EAH MUST use ARO option to 534 register with the neighboring NEAR router. 536 A host SHOULD be able to autoconfigure its IPv6 addresses using the 537 IPv6 prefix obtained from Router Advertisement. The host SHOULD form 538 its link-local address from the EUI-64 as specified by IEEE 539 Registration Authority and RFC 2373. If this draft feature is 540 implemented and configured, the host MUST NOT re-direct Neighbor 541 Discovery messages. The host does not require to join solicited-node 542 multicast address but it MUST join the all-node multicast address. 544 A host always sends packets to (one of) its default router(s). This 545 is accomplished by the routers never setting the 'L' flag in the 546 Prefix options. 548 The host is unable to forward routes or participate in a routing 549 protocol. A legacy IPv6 Host compliant EAH SHOULD be able to fall 550 back to RFC 4861 host behavior if there is no efficiency-aware router 551 (NEAR) in the link. 553 The efficiency-aware host MUST NOT send or accept re-direct messages. 554 It does not join solicited node multicast address. 556 10. The Energy Aware Default Router (NEAR) Behavior 558 The main purpose of the default router in the context of this 559 document is to receive and process the registration request, forward 560 packets from one neighbor to the other, informs the routing protocol 561 about the un-availability of the registered nodes if the routing 562 protocol requires this information for the purpose of mobility or 563 fast convergence. A default router (NEAR) behavior may be observed 564 in one or more interfaces of a Border Router(BR). 566 A Border Router normally may have multiple interfaces and connects 567 the nodes in a link like a regular IPv6 subnet(s) or acts as a 568 gateway between separate networks such as Internet and home networks 569 . The Border Router is responsible for distributing one or more /64 570 prefixes to the nodes to identify a packet belonging to the 571 particular network. One or more of the interfaces of the Border 572 Router may be connected with the efficiency-aware hosts or a 573 efficiency-aware router(NEAR). 575 The efficiency-aware default router MUST not send periodic RA unless 576 it is configured to support both legacy IPv6 and efficiency-aware 577 hosts. If the Router is configured for efficiency-aware hosts 578 support, it MUST send Router Advertisments with E-bit flag ON and 579 MUST NOT set 'L' bit in the advertisements. 581 The router SHOULD NOT garbage collect Registered Neighbor Cache 582 entries since they need to retain them until the Registration 583 Lifetime expires. If a NEAR receives a NS message from the same host 584 one with ARO and another without ARO then the NS message with ARO 585 gets the precedence and the NS without ARO is ignored. This behavior 586 protects the router from Denial Of Service attacks. Similarly, if 587 Neighbor Unreachability Detection on the router determines that the 588 host is UNREACHABLE (based on the logic in [ND]), the Neighbor Cache 589 entry SHOULD NOT be deleted but be retained until the Registration 590 Lifetime expires. If an ARO arrives for an NCE that is in 591 UNCREACHABLE state, that NCE should be marked as STALE. 593 A default router keeps a cache for all the nodes' IP addresses, 594 created from the Address Registration processing. 596 10.1. Router Configuration Modes 598 An efficiency-aware Router(NEAR) MUST be able to configure in 599 efficiency-aware-only mode where it will expect all hosts register 600 with the router following RS; thus will not support legacy hosts. 601 However, it will create legacy NCE for NS messages for other routers 602 in the network. This mode is able to prevent ND flooding on the 603 link. 605 An efficiency-aware Router(NEAR) SHOULD be able to have configuration 606 knob to configure itself in Mixed-Mode where it will support both 607 efficiency-aware hosts and legacy hosts. However even in mixed-mode 608 the router should check for duplicate entries in the NCE before 609 creating a new ones and it should rate-limit creating new NCE based 610 on requests from the same host MAC address. 612 The RECOMMENDED default mode of operation for the efficiency-aware 613 router is Mixed-mode. 615 11. NCE Management in efficiency-aware Routers 617 The use of explicit registrations with lifetimes plus the desire to 618 not multicast Neighbor Solicitation messages for hosts imply that we 619 manage the Neighbor Cache entries slightly differently than in [ND]. 620 This results in two different types of NCEs and the types specify how 621 those entries can be removed: 623 Legacy: Entries that are subject to the normal rules in 624 [ND] that allow for garbage collection when low 625 on memory. Legacy entries are created only 626 when there is no duplicate NCE. In mixed-mode 627 and efficiency-aware mode the legacy entries 628 are converted to the registered entries upon 629 successful processing of ARO. Legacy type can 630 be considered as union of garbage-collectible 631 and Tentative Type NCEs described in 632 [6LOWPAN-ND]. 633 Registered: Entries that have an explicit registered 634 lifetime and are kept until this lifetime 635 expires or they are explicitly unregistered. 637 Note that the type of the NCE is orthogonal to the states specified 638 in [ND]. 640 When a host interacts with a router by sending Router Solicitations 641 that does not match with the existing NCE entry of any type, a Legacy 642 NCE is first created. Once a node successfully registers with a 643 Router the result is a Registered NCE. As Routers send RAs to legacy 644 hosts, or receive multicast NS messages from other Routers the result 645 is Legacy NCEs. There can only be one kind of NCE for an IP address 646 at a time. 648 A Router Solicitation might be received from a host that has not yet 649 registered its address with the router or from a legacy[ND] host in 650 the Mixed-mode of operation. 652 In the 'Efficiency-aware' only mode the router MUST NOT modify an 653 existing Neighbor Cache entry based on the SLLA option from the 654 Router Solicitation. Thus, a router SHOULD create a tentative Legacy 655 Neighbor Cache entry based on SLLA option when there is no match with 656 the existing NCE. Such a legacy Neighbor Cache entry SHOULD be timed 657 out in TENTATIVE_LEGACY_NCE_LIFETIME seconds unless a registration 658 converts it into a Registered NCE. 660 However, in 'Mixed-mode' operation, the router does not require to 661 keep track of TENTATIVE_LEGACY_NCE_LIFETIME as it does not know if 662 the RS request is from a legacy host or the efficiency-aware hosts. 664 However, it creates the legacy type of NCE and updates it to a 665 registered NCE if the ARO NS request arrives corresponding to the 666 legacy NCE. Successful processing of ARO will complete the NCE 667 creation phase. 669 If ARO did not result in a duplicate address being detected, and the 670 registration life-time is non-zero, the router creates and updates 671 the registered NCE for the IPv6 address. if the Neighbor Cache is 672 full and new entries need to be created, then the router SHOULD 673 respond with a NA with status field set to 2. For successful 674 creation of NCE, the router SHOULD include a copy of ARO and send NA 675 to the requestor with the status field 0. A TLLA(Target Link Layer) 676 Option is not required with this NA. 678 Typically for efficiency-aware routers (NEAR), the registration life- 679 time and EUI-64 are recorded in the Neighbor Cache Entry along with 680 the existing information described in [ND]. The registered NCE are 681 meant to be ready and reachable for communication and no address 682 resolution is required in the link. The efficiency-aware hosts will 683 renew their registration to keep maintain the state of reachability 684 of the NCE at the router. However the router may do NUD to the idle 685 or unreachable hosts as per [ND]. 687 11.1. Handling ND DOS Attack 689 IETF community has discussed possible issues with /64 DOS attacks on 690 the ND networks when a attacker host can send thousands of packets to 691 the router with a on-link destination address or sending RS messages 692 to initiate a Neighbor Solicitation from the neighboring router which 693 will create a number of INCOMPLETE NCE entries for non-existent nodes 694 in the network resulting in table overflow and denial of service of 695 the existing communications. 697 The efficiency-aware behavior documented in this specification avoids 698 the ND DOS attacks by: 700 o Having the hosts register with the default router 701 o Having the hosts send their packets via the default router 702 o Not resolving addresses for the Routing Solicitor by mandating 703 SLLA option along with RS 704 o Checking for duplicates in NCE before the registration 705 o Checking against the MAC-address and EUI-64 id is possible now for 706 NCE matches 707 o On-link IPv6-destinations on a particular link must be registered 708 else these packets are not resolved and extra NCEs are not created 710 It is recomended that Mixed-mode operation and legacy hosts SHOULD 711 NOT be used in the IPv6 link in order to avoid the ND DOS attacks. 713 For the general case of Mixed-mode the router does not create 714 INCOMPLETE NCEs for the registered hosts, but it follows the [ND] 715 steps of NCE states for legacy hosts. 717 12. Mixed-Mode Operations 719 Mixed-Mode operation discusses the protocol behavior where the IPv6 720 subnet is composed with legacy IPv6 Neighbor Discovery compliant 721 nodes and efficiency-aware IPv6 nodes implementing this 722 specification. 724 The mixed-mode model SHOULD support the following configurations in 725 the IPv6 link: 726 o The legacy IPv6 hosts and efficiency-aware-hosts in the network 727 and a NEAR router 728 o legacy IPv6 default-router and efficiency-aware hosts(EAH) in the 729 link 730 o one router is in mixed mode and the link contains both legacy IPv6 731 hosts and EAH 732 o A link contains both efficiency-aware IPv6 router and hosts and 733 legacy IPv6 routers and hosts and each host should be able to 734 communicate with each other. 736 In mixed-mode operation, a NEAR MUST be configured for mixed-mode in 737 order to support the legacy IPv6 hosts in the network. In mixed- 738 mode, the NEAR MUST act as proxy for Neighbor Solicitation for DAD 739 and Address Resolution on behalf of its registered hosts on that 740 link. It should follow the NCE management for the EAH as described 741 in this document and follow RFC 4861 NCE management for the legacy 742 IPv6 hosts. Both in mixed-mode and efficiency-aware mode, the NEAR 743 sets E-bit flag in the RA and does not set 'L' on-link bit. 745 If a NEAR receives NS message from the same host one with ARO and 746 another without ARO then the NS message with ARO gets the precedence. 748 An efficiency-aware Host implementation SHOULD support falling back 749 to legacy IPv6 node behavior when no efficiency-aware routers are 750 available in the network during the startup. If the EAH was 751 operational in efficiency-aware mode and it determines that the NEAR 752 is no longer available, then it should send a RS and find an 753 alternate default router in the link. If no efficiency-aware router 754 is indicated from the RA, then the EAH SHOULD fall back into RFC 4861 755 behavior. On the otherhand, in the efficiency-aware mode EAH SHOULD 756 ignore multicast Router Advertisements(RA) sent by the legacy and 757 Mixed-mode routers in the link. 759 The routers that are running on efficiency-aware mode or legacy mode 760 SHOULD NOT dynamically switch the mode without flushing the Neighbor 761 Cache Entries. 763 13. Bootstrapping 765 If the network is a efficiency-aware IPv6 subnet, and the efficiency- 766 aware Neighbor Discovery mechansim is used by the hosts and routers 767 as described in this document. At the start, the node uses its link- 768 local address to send Router Solicitation and then it sends the Node 769 Registration message as described in this document in order to form 770 the address. The Duplicate address detection process should be 771 skipped if the network is guaranteed to have unique interface 772 identifiers which is used to form an IPv6 address. 774 Node Router 776 0. |[Forms LL IPv6 addr] | 778 1. | ---------- Router Solicitation --------> | 780 | [SLLAO] | 782 2. | <-------- Router Advertisement --------- | 784 | [PIO + SLLAO] | 785 | | 787 3. | ----- Address Registration (NS) --------> | 789 | [ARO + SLLAO] | 791 4. | <-------- Neighbor Advertisement ------- | 793 | [ARO with Status code] | 795 5. ====> Address Assignment Complete 797 Figure 1: Neighbor Discovery Address Registration and bootstrapping 799 In the mixed mode operation, it is expected that logically there will 800 be at least one legacy IPv6 router and another NEAR router present in 801 the link. The legacy IPv6 router will follow RFC 4861 behavior and 802 NEAR router will follow the efficiency-aware behavior for 803 registration, NCE maintenance, forwarding packets from a EAH and it 804 will also act as a ND proxy for the legacy IPv6 hosts querying to 805 resolve a EAH node. 807 A legacy IPv6 host and EAH are not expected to see a difference in 808 their bootstrapping if both legacy and efficiency-aware 809 functionalities of rotuers are available in the network. It is 810 RECOMMEDED that the EAH implementation SHOULD be able to behave like 811 a legacy IPv6 host if it discovers that no efficiency-aware routing 812 support is present in the link. 814 14. Handling Sleepy Nodes 816 The solution allows the sleepy nodes to complete its sleep schedule 817 without waking up due to periodic Router Advertisement messages or 818 due to Multicast Neighbor Solicitation for address resolution. The 819 node registration lifetime SHOULD be synchronized with its sleep 820 interval period in order to avoid waking up in the middle of sleep 821 for registration refresh. Depending on the application, the 822 registration lifetime SHOULD be equal to or integral multiple of a 823 node's sleep interval period. 825 15. Duplicate Address Detection 827 In efficiency-aware mode, there is no need for Duplicate Address 828 Detection(DAD) assuming that the deployment ensures unique 64bit 829 identification availability for each registered host. In the event 830 of collision of EUI64 field of ARO by two registration requests, the 831 later request is denied if the first one is a valid request. The 832 denied EAH node SHOULD pick another alternative IPv6 address to 833 register to prevent further registration denial. The method of 834 assignment of alternate IPv6 address is out of scope of this 835 document. 837 16. Use Case Analysis 839 This section provides applicability scenarios where the efficiency- 840 aware Neighbor Discovery will be most beneficial. 842 16.1. Data Center Routers on the link 844 Efficiency-aware Routers and hosts are useful in IPv6 networks in the 845 Data Center as they produce less signaling and also provides ways to 846 minimize the ND flood of messages. Moreover, this mechanism will 847 work with data-center nodes which are deliberately in sleep mode for 848 saving energy. 850 This solution will work well in Data Center Virtual network and VM 851 scenarios where number of VLANs are very high and ND signalings are 852 undesirably high due the multicast messaging and periodic Router 853 Advertisments and Neighbor Unreachability detections. 855 16.2. Edge Routers and Home Networks 857 An Edge Router in the network will also benefit implementing the 858 efficiency-aware Neighbor Discovery behavior in order to save the 859 signaling and keeping track of the registered nodes in its domain. A 860 BNG sits at the operator's edge network and often the BNG has to 861 handle a large number of home CPEs. If a BNG runs Neighbor Discovery 862 protocol and acts as the default router for the CPE at home, this 863 solution will be helpful for reducing the control messages and 864 improving network performances. 866 The same solution can be run on CPE or Home Residential Gateways to 867 assign IPv6 addresses to the wired and wireless home devices without 868 the problem of ND flooding issues and consuming less power. It 869 provides mechanism for the sleepy nodes to adjust their registration 870 lifetime according to their sleep schedules. 872 16.3. M2M Networks 874 Any Machine-to-machine(M2M) networks such as IPv6 surveilance 875 networks, wireless monitoring networks and other m2m networks desire 876 for efficiency-aware control protocols and dynamic address 877 allocation. The in-built address allocation and autoconfiguration 878 mechanism in IPv6 along with the default router capability will be 879 useful for the simple small-scale networks without having the burden 880 of DHCPv6 service and Routing Protocols. 882 16.4. Cellular and Wi-fi Networks 884 The cellular and Wi-fi IPv6 devices can act as efficiency-aware hosts 885 and register with their nearest default router. This will reduce 886 number of signalings and the registration method(ARO) will provide 887 operators a mechanism for tracking the nodes in the default router. 889 17. Mobility Considerations 891 If the hosts move from one subnet to another, they MUST first de- 892 register and then register themselves in the new subnet or network. 893 If a node moves away without de-registration and returns to the 894 network before the registration lifetime expires, its registration is 895 still considered valid. For run-away nodes the registration expires 896 after the lifetime expiry or due to unreachablity whichever comes 897 first. Otherwise, the regular IPv6 Mobility [IPV6M]behavior applies. 899 18. Other Considerations 901 18.1. Detecting Network Attachment(DNA) 903 IPv6 DNA[DNA] uses unicast ND probes and link-layer indications to 904 detect movement of its network attachments. Upon detecting link- 905 layer indication, it sends a all-routers Solicitation message. When 906 the node implements this document along with DNA, it MUST send ARO 907 option with its Neighbor Solicitation unicast message if the 908 candidate router advertisement indicates that the router is a NEAR 909 router. If the candiate router is a legacy router then and it is the 910 only choice then the EAH host adapt to the legacy behavior. However 911 if EAH node implements DNA host capability as well, then it SHOULD 912 give preference to the NEAR routers in its candidate list of routers. 914 Thus the ND optimization solution will work seamlessly with DNA 915 implementations and no change is required in DNA solution because of 916 Neighbor Discovery updates. It is a deployment and configuration 917 consideration as to run the network in mixed mode or efficient-mode. 919 18.2. Proxying for Efficiency-Aware hosts 921 The efficient-ND SHOULD continue to support the legacy IPv6 Neighbor 922 Solicitation requests in the mixed mode. The NEAR router SHOULD act 923 as the ND proxy on behalf of EAH hosts for the legacy nodes' NS 924 requests for EAH. 926 18.3. DHCPv6 Interaction 928 Co-existence with DHCP: For classical IPv6, if DHCPv6 or central 929 address allocation mechanism is used, then Neighbor Discovery 930 autoconfiguration is not used for global address allocation. 931 However, link-local duplicate address detection, Neighbor 932 solicitation, Neighbor unreachability detection are still used. Upon 933 assignment of the IPv6-address from DHCPv6, a EAH node SHOULD then 934 register the IP-address with the default router for avoiding 935 Duplicate address detection and Address Resolution. For Legacy 936 DHCPv6 nodes there is no change in behavior. NOTE: DHCPv6 Server 937 MUST be notified by NEAR for its efficiency-aware service interfaces. 938 DHCPv6 server then SHOULD inform the DHCP requestor node about the 939 default-rotuer capability during the address assignment period. 941 Although the solution described in this document prevents unnecesary 942 multicast messages in the IPv6 ND procedure, it does not affect 943 normal IPv6 multicast packets and ability of nodes to join and leave 944 the multicast group or forwarding multicast traffic or responding to 945 multicast queries. 947 19. Updated Neighbor Discovery Constants 949 This section discusses the updated default values of ND constants 950 based on [ND] section 10. New and changed constants are listed only 951 for efficiency-aware-nd implementation. These values SHOULD be 952 configurable and tunable to fit implementations and deployment. 954 Router Constants: 955 MAX_RTR_ADVERTISEMENTS(NEW) 3 transmissions 956 MIN_DELAY_BETWEEN_RAS(CHANGED) 1 second 957 TENTATIVE_LEGACY_NCE_LIFETIME(NEW) 30 seconds 959 Host Constants: 960 MAX_RTR_SOLICITATION_INTERVAL(NEW) 60 seconds 962 Also refer to [ENH-ND] , [IMPAT-ND] and [6LOWPAN-ND] for further 963 tuning of ND constants. 965 20. Security Considerations 967 These optimizations are not known to introduce any new threats 968 against Neighbor Discovery beyond what is already documented for IPv6 969 [RFC 3756]. 971 Section 11.2 of [ND] applies to this document as well. 973 This mechanism minimizes the possibility of ND /64 DOS attacks in 974 efficiency-aware mode. See Section 11.1. 976 21. IANA Considerations 978 A new flag (E-bit) in RA has been introduced. IANA assignment of the 979 E-bit flag is required upon approval of this document. 981 22. Changelog 983 Changes from draft-chakrabarti-nordmark-energy-aware-nd-02: 984 o Replaced energy-aware with efficency-aware which covers both 985 energy efficiency and other operational efficiency 986 o Added consideration for DNA, ND proxy and clarified that this is 987 useful for networks with MLD-snooping switches as well 988 o Added use-cases, Support for Mixed-mode operations and a diagram 989 for bootstrapping scenario. 990 o Clarified its applicability when DHCP is used for address 991 allocation. 993 23. Acknowledgements 995 The primary idea of this document are from 6LoWPAN Neighbor Discovery 996 document [6LOWPAN-ND] and the discussions from the 6lowpan working 997 group members, chairs Carsten Bormann and Geoff Mulligan and through 998 our discussions with Zach Shelby, editor of the [6LOWPAN-ND]. 1000 The inspiration of such a IPv6 generic document came from Margaret 1001 Wasserman who saw a need for such a document at the IOT workshop at 1002 Prague IETF. 1004 The authors acknowledge the ND denial of service issues and key 1005 causes mentioned in the draft-halpern-6man-nddos-mitigation document 1006 by Joel Halpern. Thanks to Joel Halpern for pinpointing the problems 1007 that are now addressed in the NCE management section. 1009 The authors like to thank Dave Thaler, Jari Arkko, Ylva Jading, 1010 Niklas J. Johnsson, Reda Nedjar, Purvi Shah, Jaume Rius Riu, Fredrik 1011 Garneij for their useful comments on this work. 1013 24. References 1015 24.1. Normative References 1017 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1018 Requirement Levels", BCP 14, RFC 2119, March 1997. 1020 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1021 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1022 October 1998. 1024 [6LOWPAN-ND] 1025 Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1026 "ND Optimizations for 6LoWPAN", RFC 6775, November 2012. 1028 [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1029 "Neighbor Discovery for IP version 6", RFC 4861, 1030 September 2007. 1032 [LOWPAN] Montenegro, G. and N. Kushalnagar, "Transmission of IPv6 1033 Packets over IEEE 802.15.4 networks", RFC 4944, 1034 September 2007. 1036 [LOWPANG] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview, 1037 Assumptions, Problem Statement and Goals", RFC 4919, 1038 August 2007. 1040 24.2. Informative References 1042 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1043 (IPv6), Specification", RFC 2460, December 1998. 1045 [DNA] Krishnan, S. and G. Daley, "Simple Procedures for 1046 Detecting Network Attachments in IPv6", RFC 6059, 1047 November 2010. 1049 [AUTOCONF] 1050 Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1051 Autoconfiguration", RFC 4862, September 2007. 1053 [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "Secure 1054 Neighbor Discovery", RFC 3971, March 2005. 1056 [AUTOADHOC] 1057 Baccelli, E. and M. Townsley, "IP Addressing Model in 1058 Adhoc Networks", RFC 5889, September 2010. 1060 [NDDOS-halpern] 1061 Halpern, J., "IP Addressing Model in Adhoc Networks", 1062 draft-halpern-6man-nddos-mitigation-00.txt (work in 1063 progress), October 2011. 1065 [ENH-ND] Kumari, W., Gashinsky, I., Jaeggli, J., and K. 1066 Chittimaneni, "Neighbor Discovery Enhancement for DOS 1067 mitigation", draft-gashinsky-6man-v6nd-enhance-02 (work in 1068 progress), October 2012. 1070 [IMPAT-ND] 1071 Nordmark, E. and I. Gashinsky, "Neighbor Unreachability 1072 Detection is too impatient", 1073 draft-ietf-6man-impatient-nud-05 (work in progress), 1074 October 2012. 1076 [IEEE] IEEE Computer Society, "IEEE Std. 802.15.4-2003", , 1077 October 2003. 1079 [PD] Miwakawya, S., "Requirements for Prefix Delegation", 1080 RFC 3769, June 2004. 1082 [RF] Haberman, B. and B. Hinden, "IPv6 Router Advertisement 1083 Flags option", RFC 5175, March 2008. 1085 [ULA] "Unique Local IPv6 Addresses", RFC 4193. 1087 [IPV6M] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1088 in IPv6", RFC 6275, July 2011. 1090 Authors' Addresses 1092 Samita Chakrabarti 1093 Ericsson 1094 San Jose, CA 1095 USA 1097 Email: samita.chakrabarti@ericsson.com 1099 Erik Nordmark 1100 Cisco Systems 1101 San Jose, CA 1102 USA 1104 Email: nordmark@cisco.com 1106 Margaret Wasserman 1107 Painless Security 1109 Email: mrw@lilacglade.org