idnits 2.17.1 draft-chakrabarti-nordmark-energy-aware-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 the creation date from RFC4861, updated by this document, for RFC5378 checks: 2004-07-16) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2, 2011) is 4675 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: 'RFC 3756' is mentioned on line 532, but not defined == Unused Reference: 'LOWPANG' is defined on line 574, but no explicit reference was found in the text == Unused Reference: 'IPV6' is defined on line 580, but no explicit reference was found in the text == Unused Reference: 'SEND' is defined on line 587, but no explicit reference was found in the text == Unused Reference: 'AUTOADHOC' is defined on line 590, but no explicit reference was found in the text == Unused Reference: 'IEEE' is defined on line 596, but no explicit reference was found in the text == Unused Reference: 'PD' is defined on line 599, but no explicit reference was found in the text == Unused Reference: 'ULA' is defined on line 602, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-17 ** Downref: Normative reference to an Informational RFC: RFC 4919 (ref. 'LOWPANG') -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) == Outdated reference: A later version (-03) exists of draft-ietf-autoconf-adhoc-addr-model-02 Summary: 2 errors (**), 0 flaws (~~), 11 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: January 3, 2012 July 2, 2011 8 Energy Aware IPv6 Neighbor Discovery Optimizations 9 draft-chakrabarti-nordmark-energy-aware-nd-00 11 Abstract 13 IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for 14 neighbor's address resolution, unreachability detection, address 15 autoconfiguration, router advertisement and solicitation. With the 16 progress of Internet adoption on various industries including home, 17 wireless and machine-to-machine communications, there is a desire for 18 extension or optimization of RFC 4861 protocol for more energy- 19 efficient networks and nodes. Research indicates that often 20 networked- nodes require more energy than stand-alone nodes because a 21 node's energy usage depends on network messages it has to receive and 22 or respond. While reducing energy consumption is essential for 23 battery operated nodes in some machines, saving energy actually a 24 cost factor in business in general as the explosion of more device 25 usage is leading to usage of more servers and network infrastructure 26 in all sectors of the society and business. This document describes 27 methods of optimizations by reducing periodic multicast messages, 28 frequent Neighbor Solicitation messages and provides a mechanism of 29 built-in prefix-dissemination in simple scenarios. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 3, 2012. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 4 66 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. The New Set Of Requirements . . . . . . . . . . . . . . . . . 5 68 5. New Neighbor Discovery Options and Messages . . . . . . . . . 5 69 5.1. Address Registration Option . . . . . . . . . . . . . . . 6 70 5.2. Authoritative Border Router Option . . . . . . . . . . . . 7 71 6. Applicability Statement . . . . . . . . . . . . . . . . . . . 9 72 7. Energy-aware Neighbor Discovery Messages . . . . . . . . . . . 10 73 8. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 11 74 9. The Border Router(BR) Behavior . . . . . . . . . . . . . . . . 11 75 10. Intermediate-router Behavior . . . . . . . . . . . . . . . . . 12 76 11. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 12 77 12. Local Mobility . . . . . . . . . . . . . . . . . . . . . . . . 12 78 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 81 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 16.1. Normative References . . . . . . . . . . . . . . . . . . . 13 83 16.2. Informative References . . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Introduction 88 IPv6 ND [ND] is based on multicast signaling messages on the local 89 link in order to avoid broadcast messages. Following power-on and 90 initialization of the network in IPv6 Ethernet networks, a node joins 91 the solicited-node multicast address on the interface and then 92 performs duplicate address detection (DAD) for the acquired link- 93 local address by sending a solicited-node multicast message to the 94 link. After that it sends multicast router solicitation (RS) 95 messages to the all-router address to solicit router advertisements. 96 Once the host receives a valid router advertisement (RA) with the "A" 97 flag, it autoconfigures the IPv6 address with the advertised prefix 98 in the router advertisement (RA). Besides this, the IPv6 routers 99 usually send router advertisements periodically on the network. RAs 100 are sent to the all-node multicast address. Nodes send Neighbor 101 Solicitation (NS) and Neighbor Advertisement (NA) messages to resolve 102 the IPv6 address of the destination on the link. These NS/NA 103 messages are also often multicast messages and it is assumed that the 104 node is on the same link and relies on the fact that the destination 105 node is always powered and generally available. 107 The periodic RA messages in IPv6 ND [ND], and NS/NA messages require 108 all IPv6 nodes in the link to be in listening mode even when they are 109 in idle mode. It requires energy for the sleepy nodes which may be 110 otherwise sleeping during idle mode. Non-sleepy nodes also may save 111 energy if instead of continuous listening mode, they actually pro- 112 actively synchronize their state with one or two entity in the 113 network. With the explosion of Internet-of-things and machine to 114 machine communication, more and more devices would be using IPv6 115 addresses in the near future. Today, most electricity usage in 116 United States and in developing countries are in the home buildings 117 and commercial buildings; the electronic Internet appliances/tablets 118 etc. are gaining popularities in the modern home networks. These 119 network of nodes must be conscious about saving energy as their 120 number increases as otherwise it will cost more and increase stress 121 on electrical grids, and increases carbon foot-print. 123 IPv6 Neighbor Discovery Optimization for 6LoWPAN [6LOWPAN-ND] 124 addresses many of the concerns described above by optimizing the 125 Router advertisement, minimizing periodic multicast packets in the 126 network and introducing two new options - one for node registration 127 and another for prefix dissemination in a network where all nodes in 128 the network are uniquely identified by their 64-bit Interface 129 Identifier. EUI-64 identifiers are recommended as unique Interface 130 Identifiers, however if the network is isolated from the Internet, 131 uniqueness of the identifiers may be obtained by other mechanisms 132 such as a random number generator with lowest collision rate. 133 Although, the ND optimization [6LOWPAN-ND] applies to 6LoWPAN 135 [LOWPAN] network, the concept is mostly applicable to IPv6 network 136 that wants to optimize power. 138 Thus optimizing the regular IPv6 Neighbor Discovery [ND] to minimize 139 total number of related signaling messages without loosing generality 140 of Neighbor Discovery and autoconfiguration and making host and 141 router communication reliable, is desirable in any IPv6 energy-aware 142 networks such as Home or Enterprise building networks and as well as 143 Data Centers. 145 [ This document is under construction and will have an update soon to 146 solidify the content of the draft] 148 2. Definition Of Terms 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 6LoWPAN-link: 155 It is a wireless link determined by single hop reachability of 156 neighboring nodes. 157 Intermediate-routers: 158 These are the intermediate routers in the home network who can 159 communicate with other intermediate routers in the same home 160 network. These are also the immediate first-hop router for the 161 physically attached hosts or wirelessly reachable hosts. 162 Root-node or Border Rotuer(BR): 163 It is a border router typically located at the junction Internet 164 and Home Network. 165 Host: 166 A host in a IPv6 network is considered a IPv6 node without routing 167 and forwarding capability. 168 EUI-64: 169 It is the IEEE defined 64-bit extended unique identifier formed by 170 concatenation of 24-bit or 36-bit company id value by IEEE 171 Registration Authority and the extension identifier within that 172 company-id assignment. The extension identifiers are 40-bit (for 173 24-bit company-id) or 28-bit (for the 36-bit company-id) 174 respectively. 176 3. Assumptions 178 o All nodes in the network carry unique interface ID in order to 179 form the auto-configured IPv6 address uniquely. 181 o All nodes use the same IPv6 prefix if multi-level prefix 182 distribution technique (described in this document) is used 183 o The special scenario for multi-level prefix dissemination requires 184 a topology where all packets of that network must go through a 185 access-gateway of that network. The access gateway may support 186 multi-level intermediate-rotuers with packet forwarding capability 187 and prefix-distribution capability as discussed in this document. 188 The hosts in this network must send and receive packets through a 189 default router. The default router could be the access-gateway or 190 the Border Router or the intermediate-router depending on the 191 location of the host. 193 4. The New Set Of Requirements 195 In future homes and new machine-to-machine networks, it will be very 196 often a hierarchical networks of sub-networks which are all directly 197 or indirectly served by a root-node router or gateway with an access 198 to the Internet. 200 In the cloud computing environment, it is possible that part of the 201 network or sub-network are geographically separated. Thus the 202 concept of IPv6-subnet of link-local nodes may be extended. 204 o Node initiated Registration and address allocation in order to 205 avoid periodic multicast messages. 206 o Address allocation through multicast IPv6 Neighbor Discovery [ND] 207 and IPv6 Autoconfiguration [AUTOCONF] with tuned parameters for 208 different sub-networks under one gateway or root home router. For 209 example, one sub-network consists of television and game station 210 networks and another network is a IEE 802.15.4 ZigBee IP network 211 running 6LoWPAN [LOWPAN]. 212 o A Requirement of distribution of configuration securely cascading 213 through the network of sub-networks. 214 o The node registration may replace the requirement of doing 215 Duplicate Address Detection. 217 5. New Neighbor Discovery Options and Messages 219 This document points to the section of 6LoWPAN-ND [6LOWPAN-ND] as 220 appropriate. 6LoWPAN-ND [6LOWPAN-ND] assumes a concept of 6Lowpan- 221 link which is equivalent to a subnet in classical IPv6-subnet sharing 222 the same IPv6-prefix but it is a collection of sub-networks connected 223 by special routers called 6LR [6LOWPAN-ND]. 225 5.1. Address Registration Option 227 The Address Registration Option(ARO) is useful for avoiding Duplicate 228 Address Detection messages since it requires a unique ID for 229 registration. The address registration is used for maintaining 230 reachability of the node or host by the router. 232 The routers keep track of host IP addresses that are directly 233 reachable and their corresponding link-layer addresses. This is 234 useful for lossy and lowpower networks and as well as wired networks. 235 An Address Registration Option (ARO) can be included in unicast 236 Neighbor Solicitation (NS) messages sent by hosts. Thus it can be 237 included in the unicast NS messages that a host sends as part of 238 Neighbor Unreachability Detection to determine that it can still 239 reach a default router. The ARO is used by the receiving router to 240 reliably maintain its Neighbor Cache. The same option is included in 241 corresponding Neighbor Advertisement (NA) messages with a Status 242 field indicating the success or failure of the registration. This 243 option is always host initiated. 245 The ARO is required for reliability and power saving. The lifetime 246 field provides flexibility to the host to register an address which 247 should be usable (the reachability information may be propagated to 248 the routing protocols) during its intended sleep schedule of nodes 249 that switches to frequent sleep mode. 251 The sender of the NS also includes the EUI-64 of the interface it is 252 registering an address from. This is used as a unique ID for the 253 detection of duplicate addresses. It is used to tell the difference 254 between the same node re-registering its address and a different node 255 (with a different EUI-64) registering an address that is already in 256 use by someone else. The EUI-64 is also used to deliver an NA 257 carrying an error Status code to the EUI-64 based link-local IPv6 258 address of the host. 260 When the ARO is used by hosts an SLLA option MUST be included and the 261 address that is to be registered MUST be the IPv6 source address of 262 the Neighbor Solicitation message. 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Type | Length = 2 | Status | Reserved | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Reserved | Registration Lifetime | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | 272 + EUI-64 + 273 | | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Fields: 277 Type: TBD1 278 Length: 8-bit unsigned integer. The length of the option in 279 units of 8 bytes. Always 2. 280 Status: 8-bit unsigned integer. Indicates the status of a 281 registration in the NA response. MUST be set to 0 in 282 NS messages. See below. 283 Reserved: This field is unused. It MUST be initialized to zero 284 by the sender and MUST be ignored by the receiver. 285 Registration Lifetime: 16-bit unsigned integer. The amount of time 286 in a unit of 10 seconds that the router should retain 287 the Neighbor Cache entry for the sender of the NS that 288 includes this option. 289 EUI-64: 64 bits. This field is used to uniquely identify the 290 interface of the registered address by including the 291 EUI-64 identifier assigned to it unmodified. 293 The Status values used in Neighbor Advertisements are: 295 +--------+--------------------------------------------+ 296 | Status | Description | 297 +--------+--------------------------------------------+ 298 | 0 | Success | 299 | 1 | Duplicate Address | 300 | 2 | Neighbor Cache Full | 301 | 3-255 | Allocated using Standards Action [RFC2434] | 302 +--------+--------------------------------------------+ 304 Table 1 306 5.2. Authoritative Border Router Option 308 This is a special optional operation introducing prefix dissemination 309 for a simple scenario where a network of nodes under the same Border 310 Router (example: Home gateway) share the same prefix. The routers 311 below the Border Router have limited forwarding/routing capabilities 312 and the packets sent/received by them from the Internet MUST go via 313 the Border Router. This can assume that /64 bit prefix is delegated 314 from the authoritative Border Router node then propagated down 315 through the intermediate nodes to the hosts without change. The 316 intermediate routers should keep a copy of this prefix for local 317 distribution and are responsible for periodic synchronization. 319 |----| 320 | BR | 321 ------ 322 | 323 H7--------------H6 324 | | 325 iR1 iR2--H1 326 / \ \ 327 H2 H3 iR3 328 / \ 329 H4 H5 331 A typical Topology where ABRO is useful 333 In the above example, we can can think of BR as a Home gateway while 334 iR routers represent intermediate routers which can be considered as 335 in-home smaller routers connecting hosts for different applications 336 or usages such as appliance network or home-entertainment network. 338 The Authoritative Border Router option MUST be included in all Router 339 Advertisement messages when Router Advertisements are used to 340 propagate information between routers in the topology described 341 above. 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Type | Length = 3 | Version Number | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Reserved | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | | 351 + + 352 | | 353 + BR Address + 354 | | 355 + + 356 | | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 Fields: 360 Type: TBD3 361 Length: 8-bit unsigned integer. The length of the option in 362 units of 8 bytes. Always 3. 363 Version Number: 16-bit unsigned integer. The version number 364 corresponding to this set of information contained in 365 the RA message. The authoritative Border router 366 originating the prefix increases this version number 367 each time its set of prefix or context information 368 changes. This version number uses sequence number 369 arithmetic as it may wrap around. 370 Reserved: This field is unused. It MUST be initialized to zero 371 by the sender and MUST be ignored by the receiver. 372 BR Address: IPv6 address of the Border Router that is the origin 373 of the included version number. 375 This document assumes that an implementation will have configuration 376 knobs to determine whether it is running in classical IPv6 ND [ND] or 377 Optimized Energy Aware ND (this document) mode 379 6. Applicability Statement 381 This document aims to guide the implementors to choose an appropriate 382 IPv6 neighbor discovery and Address configuration procedures suitable 383 for any IPv6 energy-aware network. These optimization is useful for 384 the classical IPv6 subnet and as well as future home network where 385 the network is composed of several sub-networks served by a root-node 386 or home-gateway and the hosts always send packets through a default- 387 router. 389 7. Energy-aware Neighbor Discovery Messages 391 1. Router Advertisement(RA): Periodic RAs SHOULD be avoided. Only 392 solicited RAs are recommended. An RA MUST contain the Source 393 Link-layer Address option containing Router's link-layer address 394 (this is optional in [ND]. An RA MUST carry Prefix information 395 option with L bit being unset, so that hosts do not multicast 396 any NS messages as part of address resolution. In addition to 397 the Prefix option the RA may carry Authoritative Router option 398 option generated by the root-node. 399 2. Router Solicitation(RS): Upon system startup, the node sends a 400 multicast or link broadcast (when multicast is not supported at 401 the link-layer) RS to find out the available routers in the 402 link. An RS may be sent at other times as described in section 403 6.3.7 of RFC 4861. A Router Solicitation MUST carry Source 404 Link-layer Address option. Since no periodic RAs are allowed in 405 a 6LoWPAN network, the host may send periodic unicast messages 406 RS to the routers. The time-periods for the RS varies on the 407 deployment scenarios and the Default Router Lifetime advertised 408 in the RAs. 409 3. Default Router Selection: Same as in section 6.3.6 of RFC 410 4861[ND]. 411 4. Neighbor Solicitation (NS): Neighbor solicitation is used 412 between the hosts and the default-router as part of NUD and 413 registering the host's address(es). An NS message MUST use the 414 Address Registration option in order to accomplish the 415 registration. 416 5. Neighbor Advertisement (NA): As defined in [ND] 417 6. Redirect Messages: A router may send a Redirect message to a 418 host. When to send the redirect message is implementation 419 specific; a router may be overloaded or by some means it can 420 determine the proximity of source and destination and decide 421 that they should directly talk to each other. The host behavior 422 is same as described in section 8.3 of RFC 4861[ND], i,e. a host 423 MUST NOT send redirect messages. 424 7. Message Validation: Same as in RFC 4861[ND] 425 8. MTU option: As per the RFC 4861. 426 9. Address Resolution: No NS/NA are sent as the prefixes are 427 treated as off-link. Thus no address resolution is performed at 428 the hosts. The routers keep track of Neighbor Solicitations 429 with Address Registration options(ARO) and create an extended 430 neighbor cache of reachable addresses. The router also knows 431 the nexthop link-local address and corresponding link-layer 432 address when it wants to route a packet. 433 10. Neighbor Unreachability Detection(NUD): NUD is performed in 434 "forward-progress" fashion as described in section 7.3.1 of RFC 435 4861[ND]. However, if Address Registration Option is used, the 436 NUD SHOULD be combined with the Re-registration of the node. 438 This way no extra message for NUD is required. 440 8. Host Behavior 442 A host sends Router Solicitation at the system startup and also when 443 it suspects that one of its default routers have become unreachable 444 (after NUD fails). 446 A host SHOULD be able to autoconfigure its IPv6 addresses using the 447 IPv6 prefix obtained from Router Advertisement. The host SHOULD form 448 its link-local address from the EUI-64 as specified by IEEE 449 Registration Authority and RFC 2373. If this draft feature is 450 implemented and configured, the host MUST NOT re-direct Neighbor 451 Discovery messages. The host does not require to join solicited-node 452 multicast address but it MUST join the all-node multicast address. 454 A host always sends packets to (one of) its default router(s) unless 455 it receives Router redirect messages from a neighboring router. This 456 is accomplished by the routers never setting the 'L' flag in the 457 Prefix options. 459 The host is unable to forward routes or participate in a routing 460 protocol. 462 9. The Border Router(BR) Behavior 464 A Border Router normally may have multiple interfaces and connects 465 the nodes in a link like a regular IPv6 subnet(s) or acts as a 466 gateway between separate networks such as Internet and home networks 467 . The Border Router is responsible for distributing one or more /64 468 prefixes to the nodes to identify a packet belonging to the 469 particular network. 471 The routers SHOULD NOT garbage collect Registered Neighbor Cache 472 entries since they need to retain them until the Registration 473 Lifetime expires. Similarly, if Neighbor Unreachability Detection on 474 the router determines that the host is UNREACHABLE (based on the 475 logic in [ND]), the Neighbor Cache entry SHOULD NOT be deleted but be 476 retained until the Registration Lifetime expires. A renewed ARO 477 should mark the cache entry as STALE. 479 When the BR sends a Router Advertisement it SHOULD include a 480 Authoritative Router option that includes its own address. 482 A BR keeps a cache for all the nodes' IP addresses, created from the 483 Address Registration processing. It may send the Router 484 advertisement with Prefix option and Authoritative Border Router 485 option. 487 10. Intermediate-router Behavior 489 The intermediate routers may exist in some special scenarios of home 490 networks or other networks where the Border Router sits at the root 491 of the network and all packets go in and out of the gateway. 493 The behavior of this node is still under discussion. But it aids in 494 prefix dissemination or distribution if the Border Router sends the 495 ABRO option with Router Advertisements. The intermediate-router role 496 is somewhat similar to 6LR as defined in [6LOWPAN-ND]. If the 497 intermediate-router acts as a default router to its neighboring 498 hosts, then it should be able to process the Address Registration 499 option and register the neighboring nodes. 501 11. Bootstrapping 503 If the network is a classic IPv6 subnet, and the energy-aware 504 Neighbor Discovery mechansim is used, then the node uses its link- 505 local address to send Router Solicitation and then it sends the Node 506 Registration message as described in this document in order to form 507 the address. The Duplicate address detection process should be 508 skipped if the network is guaranteed to have unique interface 509 identifiers. 511 The intermerdiate-routers may also first bootstrap as a host and then 512 turn themselves into router-mode. The detail messages will be 513 discussed in the next version of the document. 515 12. Local Mobility 517 If energy-aware Neighbor Discovery model is used and same IPv6 prefix 518 is shared by all the nodes in the network that is accessed by the 519 Border Router, then it assures transparent mobility of the nodes 520 inside the network bordered by Border Router. 522 The local mobility transparency is quite useful in a home network 523 environment where multiple networks may exist and be served by a 524 Border Router or a Home Gateway. Thus one can wirelessly move a node 525 from one home sub-network to another without disrupting data 526 connection. 528 13. Security Considerations 530 These optimizations are not known to introduce any new threats 531 against Neighbor Discovery beyond what is already documented for IPv6 532 [RFC 3756]. However, careful security considerations will be handled 533 in a follow-up IETF publication of this draft. 535 14. IANA Considerations 537 TBD 539 15. Acknowledgements 541 The primary idea of this document are from 6LoWPAN Neighbor Discovery 542 document [6LOWPAN-ND] and the discussions from the 6lowpan working 543 group members, chairs Carsten Bormann and Geoff Mulligan and through 544 our discussions with Zach Shelby. 546 The inspiration of such a IPv6 generic document came from Margaret 547 Wasserman who saw a need for such a document at the IOT workshop at 548 Prague IETF. 550 16. References 552 16.1. Normative References 554 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 555 Requirement Levels", BCP 14, RFC 2119, March 1997. 557 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 558 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 559 October 1998. 561 [6LOWPAN-ND] 562 Shelby, Z., Chakrabarti, S., and E. Nordmark, "ND 563 Optimizations for 6LoWPAN", draft-ietf-6lowpan-nd-17.txt 564 (work in progress), June 2011. 566 [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 567 "Neighbor Discovery for IP version 6", RFC 4861, 568 September 2007. 570 [LOWPAN] Montenegro, G. and N. Kushalnagar, "Transmission of IPv6 571 Packets over IEEE 802.15.4 networks", RFC 4944, 572 September 2007. 574 [LOWPANG] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview, 575 Assumptions, Problem Statement and Goals", RFC 4919, 576 August 2007. 578 16.2. Informative References 580 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 581 (IPv6), Specification", RFC 2460, December 1998. 583 [AUTOCONF] 584 Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 585 Autoconfiguration", RFC 4862, September 2007. 587 [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "Secure 588 Neighbor Discovery", RFC 3971, March 2005. 590 [AUTOADHOC] 591 Baccelli, E. and M. Townsley, "IP Addressing Model in 592 Adhoc Networks", 593 draft-ietf-autoconf-adhoc-addr-model-02.txt (work in 594 progress), December 2009. 596 [IEEE] IEEE Computer Society, "IEEE Std. 802.15.4-2003", , 597 October 2003. 599 [PD] Miwakawya, S., "Requirements for Prefix Delegation", 600 RFC 3769, June 2004. 602 [ULA] "Unique Local IPv6 Addresses", RFC 4193. 604 Authors' Addresses 606 Samita Chakrabarti 607 Ericsson 608 San Jose, CA 609 USA 611 Email: samita.chakrabarti@ericsson.com 613 Erik Nordmark 614 Cisco Systems 615 San Jose, CA 616 USA 618 Email: nordmark@cisco.com