idnits 2.17.00 (12 Aug 2021) /tmp/idnits40170/draft-thubert-6lowpan-backbone-router-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 92 has weird spacing: '...ization for L...' == Line 123 has weird spacing: '...ization for L...' -- 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 (June 6, 2010) is 4367 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) == Unused Reference: 'RFC2460' is defined on line 547, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 559, but no explicit reference was found in the text == Unused Reference: 'I-D.van-beijnum-multi-mtu' is defined on line 591, but no explicit reference was found in the text == Unused Reference: 'RFC3963' is defined on line 596, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-6lowpan-nd has been published as RFC 6775 == Outdated reference: draft-ietf-roll-rpl has been published as RFC 6550 == Outdated reference: draft-ietf-roll-terminology has been published as RFC 7102 == Outdated reference: A later version (-05) exists of draft-van-beijnum-multi-mtu-02 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6LoWPAN P. Thubert 3 Internet-Draft Cisco 4 Intended status: Standards Track June 6, 2010 5 Expires: December 8, 2010 7 6LoWPAN Backbone Router 8 draft-thubert-6lowpan-backbone-router-02 10 Abstract 12 Some LLN subnets are expected to scale up to the thousands of nodes 13 and hundreds of routers. This paper proposes an IPv6 version of the 14 Backbone Router concept that enables such a degree of scalability 15 using a high speed network as a backbone to the subnet. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 8, 2010. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 4. New types and formats . . . . . . . . . . . . . . . . . . . . 8 55 4.1. Binding Tracking Option . . . . . . . . . . . . . . . . . 8 56 5. Backbone Router Operations . . . . . . . . . . . . . . . . . . 10 57 5.1. Backbone Link and Router . . . . . . . . . . . . . . . . . 10 58 5.2. ND Proxy Operations . . . . . . . . . . . . . . . . . . . 10 59 5.3. Claiming and defending . . . . . . . . . . . . . . . . . . 12 60 5.4. Conflict Resolution . . . . . . . . . . . . . . . . . . . 12 61 5.5. Assessing an entry . . . . . . . . . . . . . . . . . . . . 13 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 64 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 70 1. Introduction 72 The ISA100.11a standard has introduced the concept of a Backbone 73 Router that would interconnect small LLNs over a high speed transit 74 network and scale a single ISA100.11a network up to the thousands of 75 nodes. In that model the LLNs and the backbone form a single subnet 76 in which nodes can move freely without the need of renumbering, and 77 the Backbone Router is a special kind of Border Router designed to 78 manage the interaction between the LLNs and the backbone at layer 3. 79 Similar scalability requirements exist in the metering and monitoring 80 industries. In a network that large, it is impossible for a node to 81 register to all Border Routers as suggested for smaller topologies in 82 Neighbor Discovery Optimization for Low-power and Lossy Networks 83 [I-D.ietf-6lowpan-nd]. 85 This paper specifies IP layer functionalities that are required to 86 implement the concept of a Backbone Router with IPv6, in particular 87 the application of the "IP Version 6 Addressing Architecture" 88 [RFC4291], " the Neighbor Discovery Protocol" [RFC4861] and "IPv6 89 Stateless Address Autoconfiguration" [RFC4862]. 91 The use of EUI-64 based link local addresses, Neighbor Discovery 92 Proxying [RFC4389], Neighbor Discovery Optimization for Low-power 93 and Lossy Networks [I-D.ietf-6lowpan-nd], the IPv6 Routing Protocol 94 for Low power and Lossy Networks [I-D.ietf-roll-rpl] and Optimistic 95 Duplicate Address Detection [RFC4429] are discussed. Also, the 96 concept of Transit Link is introduced to implement the backbone 97 network that was envisioned by ISA100.11a. 99 This operation of the Backbone Router requires that some protocol 100 operates over the LLNs from which node registrations can be obtained, 101 and that can disseminate the location of the backbone Router over the 102 LLN. Further expectations will be detailed. 104 The way the PAN IDs and 16-bit short addresses are allocated and 105 distributed in the case of an 802.15.4 network is not covered by this 106 specification. Similarly, the aspects of joining and securing the 107 network are out of scope. The way the nodes in the LLN learn about 108 their Backbone Router depends on the protocol used in the LLN. In 109 the case of RPL, a Border Router is the root of the DODAG that it 110 serves and represents all nodes attached to that DODAG. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 Readers are expected to be familiar with all the terms and concepts 119 that are discussed in "Neighbor Discovery for IP version 6" 120 [RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862], 121 "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 122 Overview, Assumptions, Problem Statement, and Goals" [RFC4919], 123 Neighbor Discovery Optimization for Low-power and Lossy Networks 124 [I-D.ietf-6lowpan-nd] and "Transmission of IPv6 Packets over IEEE 125 802.15.4 Networks" [RFC4944]. 127 Readers would benefit from reading "Mobility Support in IPv6" 128 [RFC3775], "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] and 129 "Optimistic Duplicate Address Detection" [RFC4429] prior to this 130 specification for a clear understanding of the art in ND-proxying and 131 binding. 133 Additionally, this document uses terminology from 134 [I-D.ietf-roll-terminology], and introduces the following 135 terminology: 137 Backbone 139 This is an IPv6 transit link that interconnects 2 or more 140 Backbone Routers. It is expected to be deployed as a high 141 speed backbone in order to federate a potentially large set of 142 LLNS. Also referred to as a LLN backbone or transit network. 144 Backbone Router 146 An IPv6 router that federates the LLN using a transit link as a 147 backbone. 149 Extended LLN 151 This is the aggregation of multiple LLNs as defined in 152 [RFC4919] interconnected by a Transit Link via Backbone Routers 153 and forming a single IPv6 link. 155 Binding 156 The association of the LLN node IPv6 address and Interface ID 157 with associated proxying states including the remaining 158 lifetime of that association. 160 Registration 162 The process during which a LLN node injects its address in a 163 protocol through which the Border Router can learn the address 164 and proxy ND for it. 166 Primary BR 168 The BR that will defend a registered address for the purpose of 169 DAD over the backbone 171 Secondary BR 173 A BR to which the address is registered. A Secondary Router 174 MAY advertise the address over the backbone and proxy for it. 176 3. Overview 178 A Transit Link that we'll refer to a the LLN Backbone federates 179 multiple LLNs as a single IP subnet. Each LLN in the subnet is 180 anchored at a Backbone Router. The Backbone Routers interconnect the 181 LLNs over that Backbone Link. A node can move freely from a LLN 182 anchored at a Backbone Router to a LLN anchored at another Backbone 183 Router on the same backbone and conserve its link local and any other 184 IPv6 address it has formed. 186 ---+------------------------ 187 | Plant Network 188 | 189 +-----+ 190 | | Gateway 191 | | 192 +-----+ 193 | 194 | Transit Link 195 +--------------------+------------------+ 196 | | | 197 +-----+ +-----+ +-----+ 198 | | Backbone | | Backbone | | Backbone 199 | | router | | router | | router 200 +-----+ +-----+ +-----+ 201 o o o o o o 202 o o o o o o o o o o o o o o 203 o o o o o o o o o o o o o o o 204 o o o o o o o o o o 205 o o o o o o o 207 LLN LLN LLN 209 Figure 1: Backbone Link and Backbone Routers 211 The Backbone Link is used as reference for Neighbor Discovery 212 operations, by extending the concept of a Home Link as defined in 213 [RFC3775] for Mobile IPv6. In particular, Backbone Routers perform 214 ND proxying for the LLN nodes in the LLNs they own through a node 215 registration. 217 The Backbone Router operation is compatible with that of a Home 218 Agent. This enables mobility support for LLN devices that would move 219 outside of the network delimited by the transit link. This also 220 enables collocation of Home Agent functionality within Backbone 221 Router functionality on the same interface of a router. 223 A LLN node registers and claims ownership of its addresse(s) using 224 proactive acknowledged registration exchanges with a neighboring 225 router. In case of a complex LLN topology, the router might be an 226 intermediate LLN Router that relays the registration to the LBR as 227 described for instance in [I-D.ietf-6lowpan-nd] and 228 [I-D.ietf-roll-rpl]. In turn, the Backbone Routers operate as a 229 distributed database of all the LLN nodes and use the Neighbor 230 Discovery Protocol to share that information across the transit link 231 in a reactive fashion. 233 For the purpose of Neighbor Discovery proxying, this specification 234 documents the LLN Master Neighbor Registry, a conceptual data 235 structure that is similar to the MIP6 binding cache. The Master 236 Neighbor Registry is fed by redistributing addresses learnt from the 237 registration protocol used over the LLN. 239 Another function of the Backbone Router is to perform 6LoWPAN 240 compression and expansion between the LLN and the Transit Link and 241 ensure MTU compatibility. Packets flow uncompressed over the Transit 242 Link and are routed normally towards a Gateway or an Application 243 sitting on the transit link or on a different link that is reachable 244 over the IP network. 246 4. New types and formats 248 The specification expects that the protocol running on the LLN can 249 provide a sequence number called Transaction ID (TID) that is 250 associated to the registration. When a node registers to multiple 251 BRs, it is expected that the same TID is used, to enable the BR to 252 correlate the registrations as being a single one, and differentiate 253 that situation from a movement. Otherwise, the resolution makes it 254 so that only the most recent registration was perceived from the 255 highest TID is kept. 257 The specification expects that the protocol running on the LLN can 258 provide a unique ID for the owner of the address that is being 259 registered. The Owner Unique ID enables to differentiate a duplicate 260 registration from a double registration. In case of a duplicate, the 261 last registration looses. The Owner Unique ID can be as simple as a 262 EUI-64 burnin address, if the device manufacturor is convinced that 263 there can not be a manuf error that would cause duplicate EUI64 264 addresses. Alternatively, the unique ID can be a hash of supposedly 265 unique information from multiple orthogonal sources, for instance: 267 o Burn in address. 269 o configured address, id, security keys... 271 o (pseudo) Random number, radio link metrics ... 273 In any fashion, it is recommended that the device stores the unique 274 Id in persistent memory. Otherwise, it will be prevented to 275 reregister after a reboot that would cause a loss of memory until the 276 Backbone Router times out the registration. 278 The unique ID and the sequence number are placed in a new ND option 279 that is used by the Backbone Routers over the transit link to detect 280 duplicates and movements. The option format is as follows: 282 4.1. Binding Tracking Option 284 This option is designed to be used with standard NS and NA messages 285 between backbone Routers over a backbone link and may be used between 286 LRs and LBRs over the LLN. By using this option, the binding in 287 question can be uniquely identified and matched with the Master 288 Neighbor Registry entries of each Backbone Router. 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Type | Length | TID | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | reserved | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | 298 + Owner Unique Identifier + 299 | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Figure 2: Binding Tracking Option 304 Option Fields 306 Type: 308 Length: 2 310 TID: A unique Transaction ID assigned by the host in the associated 311 NR and used to match NC replies. The TID is set to zero when the 312 node boots and then follows a lollipop lifetime, wrapping direcly 313 from 0xFFFF to 0x10. 315 Reserved: This field is unused. It MUST be initialized to zero by 316 the sender and MUST be ignored by the receiver. 318 Owner Unique Identifier: A globally unique identifier for the host's 319 interface associated with the binding for the NS/NA message in 320 question. This can be the EUI-64 derived IID of an interface, 321 which can be hashed with other supposedly unique information from 322 multiple orthogonal sources. 324 5. Backbone Router Operations 326 5.1. Backbone Link and Router 328 The Backbone Router is a specific kind of Border Router that performs 329 proxy Neighbor Discovery on its backbone interface on behalf of the 330 nodes that it has discovered on its Low Power Lossy Network 331 interfaces. On the LLN side, the Backbone Router acquires its states 332 about the nodes by terminating protocols such as RPL 333 [I-D.ietf-roll-rpl] or 6LoWPAN ND [I-D.ietf-6lowpan-nd] as a LLN 334 Border Router. It is expected that the backbone is the medium used 335 to connect the subnet to the rest of the infrastructure, and that all 336 the LBRs are connected to that backbone and support the Backbone 337 Router feature as specified in this document. 339 The backbone is expected to be a high speed, reliable transit link, 340 with affordable multicast capabilities, such as an Ethernet Network 341 or a fully meshed NBMA network with multicast emulation, which allows 342 a full support of classical ND as specified in [RFC4861] and 343 subsequent RFCs. In other words, the backbone is not a LLN. Still, 344 some restrictions of the attached LLNs will apply to the backbone. 345 In particular, it is expected that the MTU is set to the same value 346 on the backbone and all attached LLNs. 348 5.2. ND Proxy Operations 350 This specification enables a Backbone Router to proxy Neighbor 351 Discovery operations over the backbone on behalf of the nodes that 352 are registered to it, allowing any device on the backbone to reach a 353 LLN node as if it was on-link. 355 In the context of this specification, proxy ND means: 357 o defending a registered address over the backbone using NA messages 358 with the Override bit set 360 o advertising a registered address over the backbone using NA 361 messages, asynchronously or as a response to a Neighbor 362 Solicitation messages. 364 o Looking up a destination over the backbone in order to deliver 365 packets arriving from the LLN using Neighbor Sollicitation 366 messages. 368 o Forwarding packets from the LLN over the backkbone, and hte other 369 way around. 371 o Eventually triggering a look up for a destination over the LLN 372 that would not be registered at a given point of time, or as a 373 verification of a registration. 375 The draft introduces the concept of primary and secondary BRs. The 376 concept is defined with the granularity of an address, that is a 377 given BR can be primary for a given address and secondary or another 378 one, regardess on whether the addresses belong to the same node or 379 not. The primary Backbone Router is in charge of protecting the 380 address for DAD over the Backbone. Any of the Primary and Secondary 381 BR may claim the address over the backbone, since they are all 382 capable to route from the backbone to the LLN device. 384 When the protocol used to register the nodes over the LLN is RPL 385 [I-D.ietf-roll-rpl], it is expected that one BR acts as virtual root 386 coordinating LLN BRs (with the same DODAGID) over the non-LLN 387 backbone. In that case, the virtual root may act as primary BR for 388 all addresses that it cares to support, whereas the physical roots to 389 which the node is attached are secondary BRs. It is also possible in 390 a given deployment that the DODAGs are not coordinated. In that 391 case, there is no virtual root and no secondary BR; the DODAG root is 392 primary all the nodes registered to it over the backbone. 394 When the protocol used to register the nodes over the LLN is 6LoWPAN 395 ND [I-D.ietf-6lowpan-nd], the Backbone Routers act as a distributed 396 DAD table, using classical ND over the backbone to detect 397 duplication. This specification requires that: 399 1. Registrations for all addresses that can be required to reach the 400 device over the backbone, including registrations for IPv6 401 addresses based on burn-in EUI64 addresses are passed to the DAD 402 table. 404 2. Nodes include the Binding Tracking Option in their NS used for 405 registering those addresses and the LRs propagate that option to 406 the LBRs. 408 A false positive duplicate detection may arise over the backbone, for 409 instance if the node registers to more than one LBR, or if the node 410 has moved. Both situations are handled gracefully unbeknownst to the 411 node. In the former case, one LBR becomes primary to defend the 412 address over the backbone while the others become secondary and may 413 still forward packets back and forth. In the latter case the LBR 414 that receives the newest registration wins and becomes primary. 416 5.3. Claiming and defending 418 Upon a new or an updated registration, the BR performs a DAD 419 operation. If either a TID or a OUI is available, the BR places them 420 in a Binding Tracking Option in all its ND messages over the 421 backbone. If content is not available for a given field, it is set 422 to 0. 424 If a primary already exists over the backbone, it will answer the DAD 425 with an RA. 427 o If a RA is received with the O bit set, the primary rejects the 428 DAD and the DAD fails. the BR needs to inform the LLN protocol 429 that the address is a duplicate. 431 o If a RA is received with the O bit reset, the primary accepts the 432 BR as secondary and DAD succeeds. The BR may install or maintain 433 its proxy states for that address. This router MAY advertise the 434 address using a NA. during a registration flow, it MAY set the O 435 bit. 437 o If no RA is received, this router assumes the role of primary and 438 DAD succeeds. The BR may install or maintain its proxy states for 439 that address. This router advertises the address using a NA with 440 the O bit reset. 442 When the BR installs or maintains its proxy states for an address, it 443 sends an NA with a SLLA option for that address. The Primary BR MAY 444 set the O bit if it wished to attract the traffic for that address. 446 5.4. Conflict Resolution 448 A conflict arise when multiple BRs get a registration from a same 449 address. This situation might arise when a node moves from a BR to 450 another, when a node registers to multiple BRs, or in the RPL case 451 when the BRs belong to a single coordinated DODAG. 453 The primary looks up the Binding Tracking Option in ND messages with 454 a SLLA option. 456 o If there is no option, normal ND operation takes place and the 457 primary defends the address with a NA with the O bit set, adding 458 the Binding Tracking Option with its own information. 460 o If there is a Binding Tracking Option and the OUIs are different, 461 then the conflict apparently happens between different nodes, and 462 the the primary defends the address with a NA with the O bit set, 463 adding the Binding Tracking Option with its own information. If 464 the TID in the Binding Tracking Option is in the straight part of 465 the lollipop, it is possible that the request comes from the same 466 node that has rebooted and formed a new OUI The primary BR may 467 assess its registered entry prior to answering. 469 o If there is a Binding Tracking Option and the OUIs are the same: 471 * If the TID in the ND message is newer than the most recent one 472 known by the primary router, this is interpreted as a node 473 moving. The primary cleans up its states and stops defending 474 the address. 476 * If the TID in the ND message is the same as the most recent one 477 known by the primary router, this is interpreted as a double 478 registration. In case of a DAD, the promary responds with a NA 479 with the O bit reset, to confirm its position as primary, 480 including the Binding Tracking Option. 482 * If the TID in the ND message is older than the most recent one 483 known by the primary router, this is interpreted as a stale 484 information. The primary defends the address with a NA with 485 the O bit set, adding the Binding Tracking Option with its own 486 information. 488 * If the TIDs are very different (more than 16 apart, discounting 489 the straight part of the lollipop), it is impossible to resolve 490 for sure. The primary BR should assess its registered entry 491 prior to answering. 493 5.5. Assessing an entry 495 In a number of cases, it might happen that the information at the 496 primary BR is stale and obsolete. In particular, a node with no 497 permanent storage might reboot and form a different OUI, in which 498 case the information at the BR is inaccurate and should be removed. 499 In another case, the Br and the node have been out of reach for too 500 long and the TID that the BR maintains is so far out that it is 501 impossible to compare it with that stored at the BR. 503 In such situation, the primary Backbone Router has the possibility to 504 assess the registration. this is performed by the protocol in use to 505 register the node over the LLN. 507 When the protocol used to register the nodes over the LLN is RPL 508 [I-D.ietf-roll-rpl], the BR sends a targetted DIS to the registered 509 address over the registered path. A DAO back indicates that the 510 current registration is still valid and provides the adequate data to 511 resolve the conflict. 513 When the protocol used to register the nodes over the LLN is 6LoWPAN 514 ND [I-D.ietf-6lowpan-nd], TBD. 516 6. Security Considerations 518 This specification expects that the link layer is sufficiently 519 protected, either by means of physical or IP security for the Transit 520 Link or MAC sublayer cryptography. In particular, it is expected 521 that the LLN MAC provides secure unicast to/from the Backbone Router 522 and secure broadcast from the Backbone Router in a way that prevents 523 tempering with or replaying the RA messages. 525 The use of EUI-64 for forming the Interface ID in the link local 526 address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and 527 address privacy techniques. Considering the envisioned deployments 528 and the MAC layer security applied, this is not considered an issue 529 at this time. 531 7. IANA Considerations 533 A new type is requested for an ND option. 535 8. Acknowledgments 537 The author wishes to thank Zach Shelby for their help and in-depth 538 review. 540 9. References 542 9.1. Normative References 544 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 545 Requirement Levels", BCP 14, RFC 2119, March 1997. 547 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 548 (IPv6) Specification", RFC 2460, December 1998. 550 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 551 in IPv6", RFC 3775, June 2004. 553 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 554 Architecture", RFC 4291, February 2006. 556 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 557 for IPv6", RFC 4429, April 2006. 559 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 560 Message Protocol (ICMPv6) for the Internet Protocol 561 Version 6 (IPv6) Specification", RFC 4443, March 2006. 563 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 564 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 565 September 2007. 567 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 568 Address Autoconfiguration", RFC 4862, September 2007. 570 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 571 "Transmission of IPv6 Packets over IEEE 802.15.4 572 Networks", RFC 4944, September 2007. 574 9.2. Informative References 576 [I-D.ietf-6lowpan-nd] 577 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 578 Discovery Optimization for Low-power and Lossy Networks", 579 draft-ietf-6lowpan-nd-09 (work in progress), April 2010. 581 [I-D.ietf-roll-rpl] 582 Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing 583 Protocol for Low power and Lossy Networks", 584 draft-ietf-roll-rpl-08 (work in progress), May 2010. 586 [I-D.ietf-roll-terminology] 587 Vasseur, J., "Terminology in Low power And Lossy 588 Networks", draft-ietf-roll-terminology-03 (work in 589 progress), March 2010. 591 [I-D.van-beijnum-multi-mtu] 592 Beijnum, I., "Extensions for Multi-MTU Subnets", 593 draft-van-beijnum-multi-mtu-02 (work in progress), 594 February 2008. 596 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 597 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 598 RFC 3963, January 2005. 600 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 601 Neighbor Discovery (SEND)", RFC 3971, March 2005. 603 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 604 RFC 3972, March 2005. 606 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 607 Proxies (ND Proxy)", RFC 4389, April 2006. 609 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 610 over Low-Power Wireless Personal Area Networks (6LoWPANs): 611 Overview, Assumptions, Problem Statement, and Goals", 612 RFC 4919, August 2007. 614 Author's Address 616 Pascal Thubert 617 Cisco Systems 618 Village d'Entreprises Green Side 619 400, Avenue de Roumanille 620 Batiment T3 621 Biot - Sophia Antipolis 06410 622 FRANCE 624 Phone: +33 4 97 23 26 34 625 Email: pthubert@cisco.com