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