idnits 2.17.1 draft-thubert-6lowpan-backbone-router-03.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 104 has weird spacing: '...ization for L...' == Line 137 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 (February 25, 2013) is 4076 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: 'HART' is mentioned on line 650, but not defined == Unused Reference: 'RFC2460' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 583, but no explicit reference was found in the text == Unused Reference: 'I-D.van-beijnum-multi-mtu' is defined on line 625, but no explicit reference was found in the text == Unused Reference: 'RFC3963' is defined on line 630, 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: A later version (-07) exists of draft-chakrabarti-nordmark-6man-efficient-nd-01 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-11 == Outdated reference: A later version (-05) exists of draft-van-beijnum-multi-mtu-03 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 February 25, 2013 5 Expires: August 29, 2013 7 6LoWPAN Backbone Router 8 draft-thubert-6lowpan-backbone-router-03 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 August 29, 2013. 34 Copyright Notice 36 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 4. New types and formats . . . . . . . . . . . . . . . . . . . . 9 55 4.1. The Enhanced Address Registration Option (EARO) . . . . . 9 56 5. Backbone Router Operations . . . . . . . . . . . . . . . . . . 11 57 5.1. Backbone Link and Router . . . . . . . . . . . . . . . . . 11 58 5.2. ND Proxy Operations . . . . . . . . . . . . . . . . . . . 11 59 5.3. Claiming and Defending Addresses . . . . . . . . . . . . . 12 60 5.4. Conflict Resolution . . . . . . . . . . . . . . . . . . . 13 61 5.5. Assessing an entry . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . 19 68 9.3. External Informative References . . . . . . . . . . . . . 19 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 71 1. Introduction 73 In order to meet industrial requirements for non-critical monitoring, 74 alerting, supervisory control, open loop control and some closed loop 75 control applications, both [ISA100.11a] and wireless [HART] standards 76 leverage advanced technology at every layer, including the Time 77 Synchronized Channel Hopping (TSCH) Medium Access Control (MAC) 78 operation that enables deterministic behaviours for time-sensitive 79 flows. Additionally, [ISA100.11a] endorsed the 6LoWPAN Header 80 Compression [RFC6282] format for the network header, making it 81 possible to utilize IPv6 based protocols such as BACnet IP, Profibus 82 IP and Modbus TCP without significant changes to those protocols. 84 [ISA100.11a] has introduced the concept of a Backbone Router that 85 would interconnect small LLNs over a high speed Backbone network and 86 scale a single ISA100.11a network up to the thousands of nodes. In 87 that model the LLNs and the backbone form a single subnet in which 88 nodes can move freely without the need of renumbering, and the 89 Backbone Router is a special kind of Border Router designed to manage 90 the interaction between the LLNs and the backbone at layer 3. 91 Similar scalability requirements exist in the metering and monitoring 92 industries. In a network that large, it is impossible for a node to 93 register to all Border Routers as suggested for smaller topologies in 94 Neighbor Discovery Optimization for Low-power and Lossy Networks 95 [RFC6775]. 97 This paper specifies IP layer functionalities that are required to 98 implement the concept of a Backbone Router with IPv6, in particular 99 the application of the "IP Version 6 Addressing Architecture" 100 [RFC4291], " the Neighbor Discovery Protocol" [RFC4861] and "IPv6 101 Stateless Address Autoconfiguration" [RFC4862]. 103 The use of EUI-64 based link local addresses, Neighbor Discovery 104 Proxying [RFC4389], Neighbor Discovery Optimization for Low-power 105 and Lossy Networks [RFC6775], the IPv6 Routing Protocol for Low power 106 and Lossy Networks [RFC6550] , the mixed mode of Efficiency aware 107 IPv6 Neighbor Discovery Optimizations 108 [I-D.chakrabarti-nordmark-6man-efficient-nd] and Optimistic Duplicate 109 Address Detection [RFC4429] are discussed. Also, the concept of 110 Backbone Link is introduced to implement the backbone network that 111 was envisioned by ISA100.11a. 113 This operation of the Backbone Router requires that some protocol 114 operates over the LLNs from which node registrations can be obtained, 115 and that can disseminate the location of the backbone Router over the 116 LLN. Further expectations will be detailed. 118 The way the PAN IDs and 16-bit short addresses are allocated and 119 distributed in the case of an 802.15.4 network is not covered by this 120 specification. Similarly, the aspects of joining and securing the 121 network are out of scope. The way the nodes in the LLN learn about 122 their Backbone Router depends on the protocol used in the LLN. In 123 the case of RPL, a Border Router is the root of the DODAG that it 124 serves and represents all nodes attached to that DODAG. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 Readers are expected to be familiar with all the terms and concepts 133 that are discussed in "Neighbor Discovery for IP version 6" 134 [RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862], 135 "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 136 Overview, Assumptions, Problem Statement, and Goals" [RFC4919], 137 Neighbor Discovery Optimization for Low-power and Lossy Networks 138 [RFC6775] and "Transmission of IPv6 Packets over IEEE 802.15.4 139 Networks" [RFC4944]. 141 Readers would benefit from reading "Mobility Support in IPv6" 142 [RFC3775], "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] and 143 "Optimistic Duplicate Address Detection" [RFC4429] prior to this 144 specification for a clear understanding of the art in ND-proxying and 145 binding. 147 Additionally, this document uses terminology from 148 [I-D.ietf-roll-terminology], and introduces the following 149 terminology: 151 Backbone This is an IPv6 Backbone link that interconnects 2 or more 152 Backbone Routers. It is expected to be deployed as a high 153 speed backbone in order to federate a potentially large set of 154 LLNS. Also referred to as a LLN backbone or Backbone network. 156 Backbone Router An IPv6 router that federates the LLN using a 157 Backbone link as a backbone. A BBR acts as a 6LoWPAN Border 158 Routers (6LBR) and an Energy Aware Default Router (NEAR). 160 Extended LLN This is the aggregation of multiple LLNs as defined in 161 [RFC4919] interconnected by a Backbone Link via Backbone 162 Routers and forming a single IPv6 link. 164 Energy-Constrained Node An IPv6 node that operates ND registration 165 in order to save energy. This can be a LLN node, or an 166 Efficiency-Aware Host(EAH) on the backbone. 168 Binding The association of the Energy-Constrained Node IPv6 address 169 and Interface ID with associated proxying states including the 170 remaining lifetime of that association. 172 Registration The process during which a Energy-Constrained Node 173 injects its address in a protocol through which the Border 174 Router can learn the address and proxy ND for it. 176 Primary BBR 178 The BBR that will defend a registered address for the purpose 179 of DAD over the backbone 181 Secondary BBR 183 A BBR to which the address is registered. A Secondary Router 184 MAY advertise the address over the backbone and proxy for it. 186 3. Overview 188 The scope of this draft is a Backbone Link that federates multiple 189 LLNs as a single IPv6 subnet. Each LLN in the subnet is anchored at 190 a Backbone Router (BBR). The Backbone Routers interconnect the LLNs 191 over the Backbone Link and emulate that the LLN nodes are present on 192 the Backbone by proxy-ND operations. An LLN node can move freely 193 from an LLN anchored at a Backbone Router to an LLN anchored at 194 another Backbone Router on the same backbone and conserve any of the 195 IPv6 addresses that it has formed. In a same fashion, an Efficiency- 196 Aware Host (EAH) residing on the Backbone may change its BBR - acting 197 as IPv6 ND-efficiency-aware Router (NEAR) - and conserve its 198 addresses with no disruption. 200 Energy-Constrained Nodes are often associated with radios and 201 therefore may change their point of attachment in the network. 202 Virtual devices - typically virtual machines in a datacenter - also 203 move though in a different fashion, from a physical device to the 204 next. In the case if a movement, it might be difficult for Stateful 205 devices in the network such as the NEAR and SAVI switches to 206 differentiate a duplication from a movement. And if indeed it is a 207 movement, then it might be difficult to select to freshest 208 information to know where the device actually is. 210 ---+------------------------ 211 | Plant Network 212 | 213 +-----+ 214 | | Gateway 215 | | 216 +-----+ 217 | 218 | Backbone Link 219 +--------------------+------------------+ 220 | | | 221 +-----+ +-----+ +-----+ 222 | | Backbone | | Backbone | | Backbone 223 | | router | | router | | router 224 +-----+ +-----+ +-----+ 225 o o o o o o 226 o o o o o o o o o o o o o o 227 o o o o o o o o o o o o o o o 228 o o o o o o o o o o 229 o o o o o o o 231 LLN LLN LLN 232 Figure 1: Backbone Link and Backbone Routers 234 The Backbone Link is used as reference for Neighbor Discovery 235 operations, by extending the concept of a Home Link as defined in 236 [RFC3775] for Mobile IPv6. In particular, Backbone Routers perform 237 ND proxying for the Energy-Constrained Nodes in the LLNs they own 238 through a node registration. 240 The Backbone Router operation is compatible with that of a Home 241 Agent. This enables mobility support for LLN devices that would move 242 outside of the network delimited by the Backbone link. This also 243 enables collocation of Home Agent functionality within Backbone 244 Router functionality on the same interface of a router. 246 A Energy-Constrained Node registers and claims ownership of its 247 addresse(s) using proactive acknowledged registration exchanges with 248 a neighboring router. In case of a complex LLN topology, the router 249 might be an intermediate LLN Router that relays the registration to 250 the BBR (acting as LBR) as described in [RFC6775]. In turn, the 251 Backbone Routers operate as a distributed database of all the Energy- 252 Constrained Nodes whether theyreside on the LLNs or the backbone, and 253 use the Neighbor Discovery Protocol to share that information across 254 the Backbone in the classical ND reactive fashion. 256 For the purpose of Neighbor Discovery proxying, this specification 257 documents the LLN Master Neighbor Registry, a conceptual data 258 structure that is similar to the MIP6 binding cache. The Master 259 Neighbor Registry is fed by redistributing addresses learnt from the 260 registration protocol used over the LLN. 262 Another function of the Backbone Router is to perform 6LoWPAN 263 compression and expansion between the LLN and the Backbone Link and 264 ensure MTU compatibility. Packets flow uncompressed over the 265 Backbone Link and are routed normally towards a Gateway or an 266 Application sitting on the Backbone link or on a different link that 267 is reachable over the IP network. 269 4. New types and formats 271 The specification expects that the protocol running on the LLN can 272 provide a sequence number called Transaction ID (TID) that is 273 associated to the registration. When a node registers to multiple 274 BBRs, it is expected that the same TID is used, to enable the BBR to 275 correlate the registrations as being a single one, and differentiate 276 that situation from a movement. Otherwise, the resolution makes it 277 so that only the most recent registration was perceived from the 278 highest TID is kept. 280 The specification expects that the protocol running on the LLN can 281 provide a unique ID for the owner of the address that is being 282 registered. The Owner Unique ID enables to differentiate a duplicate 283 registration from a double registration. In case of a duplicate, the 284 last registration looses. The Owner Unique ID can be as simple as a 285 EUI-64 burnin address, if the device manufacturor is convinced that 286 there can not be a manuf error that would cause duplicate EUI64 287 addresses. Alternatively, the unique ID can be a hash of supposedly 288 unique information from multiple orthogonal sources, for instance: 290 o Burn in address. 292 o configured address, id, security keys... 294 o (pseudo) Random number, radio link metrics ... 296 In any fashion, it is recommended that the device stores the unique 297 Id in persistent memory. Otherwise, it will be prevented to 298 reregister after a reboot that would cause a loss of memory until the 299 Backbone Router times out the registration. 301 The unique ID and the sequence number are placed in a new ND option 302 that is used by the Backbone Routers over the Backbone link to detect 303 duplicates and movements. The option format is as follows: 305 4.1. The Enhanced Address Registration Option (EARO) 307 This option is designed to be used with standard NS and NA messages 308 between backbone Routers over a backbone link and may be used between 309 LRs and LBRs over the LLN. By using this option, the binding in 310 question can be uniquely identified and matched with the Master 311 Neighbor Registry entries of each Backbone Router. 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Type | Length = 2 | Status | Reserved | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 |T|N| Reserved | TID | Registration Lifetime | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | | 321 + OUI ( EUI-64 or equivalent ) + 322 | | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 Figure 2: EARO 327 Option Fields 329 Type: 331 Length: 2 333 T: One bit flag. Set if the next octet is a used as a TID. 335 N: One bit flag. et if the device moved. If not set, the router will 336 refrain from sending gratuitous NA(O) over the backbone, for 337 instance after the DAD operation upon entry creation. 339 Reserved: This field is unused. It MUST be initialized to zero by 340 the sender and MUST be ignored by the receiver. 342 TID: 1-byte integer; a transaction id that is maintained by the 343 device and incremented with each transaction. it is recommended 344 that the device maintains the TID in a persistent storage. 346 Owner Unique Identifier: A globally unique identifier for the host's 347 interface associated with the binding for the NS/NA message in 348 question. This can be the EUI-64 derived IID of an interface, 349 which can be hashed with other supposedly unique information from 350 multiple orthogonal sources. 352 5. Backbone Router Operations 354 5.1. Backbone Link and Router 356 The Backbone Router is a specific kind of Border Router that performs 357 proxy Neighbor Discovery on its backbone interface on behalf of the 358 nodes that it has discovered on its Low Power Lossy Network 359 interfaces. On the LLN side, the Backbone Router acquires its states 360 about the nodes by terminating protocols such as RPL [RFC6550] or 361 6LoWPAN ND [RFC6775] as a LLN Border Router. It is expected that the 362 backbone is the medium used to connect the subnet to the rest of the 363 infrastructure, and that all the LBRs are connected to that backbone 364 and support the Backbone Router feature as specified in this 365 document. 367 The backbone is expected to be a high speed, reliable Backbone link, 368 with affordable multicast capabilities, such as an Ethernet Network 369 or a fully meshed NBMA network with multicast emulation, which allows 370 a full support of classical ND as specified in [RFC4861] and 371 subsequent RFCs. In other words, the backbone is not a LLN. Still, 372 some restrictions of the attached LLNs will apply to the backbone. 373 In particular, it is expected that the MTU is set to the same value 374 on the backbone and all attached LLNs. 376 5.2. ND Proxy Operations 378 This specification enables a Backbone Router to proxy Neighbor 379 Discovery operations over the backbone on behalf of the nodes that 380 are registered to it, allowing any device on the backbone to reach a 381 Energy-Constrained Node as if it was on-link. 383 In the context of this specification, proxy ND means: 385 o defending a registered address over the backbone using NA messages 386 with the Override bit set 388 o advertising a registered address over the backbone using NA 389 messages, asynchronously or as a response to a Neighbor 390 Solicitation messages. 392 o Looking up a destination over the backbone in order to deliver 393 packets arriving from the LLN using Neighbor Sollicitation 394 messages. 396 o Forwarding packets from the LLN over the backkbone, and hte other 397 way around. 399 o Eventually triggering a look up for a destination over the LLN 400 that would not be registered at a given point of time, or as a 401 verification of a registration. 403 The draft introduces the concept of primary and secondary BBRs. The 404 concept is defined with the granularity of an address, that is a 405 given BBR can be primary for a given address and secondary or another 406 one, regardess on whether the addresses belong to the same node or 407 not. The primary Backbone Router is in charge of protecting the 408 address for DAD over the Backbone. Any of the Primary and Secondary 409 BBR may claim the address over the backbone, since they are all 410 capable to route from the backbone to the LLN device. 412 When the protocol used to register the nodes over the LLN is RPL 413 [RFC6550], it is expected that one BBR acts as virtual root 414 coordinating LLN BBRs (with the same DODAGID) over the non-LLN 415 backbone. In that case, the virtual root may act as primary BBR for 416 all addresses that it cares to support, whereas the physical roots to 417 which the node is attached are secondary BBRs. It is also possible 418 in a given deployment that the DODAGs are not coordinated. In that 419 case, there is no virtual root and no secondary BBR; the DODAG root 420 is primary all the nodes registered to it over the backbone. 422 When the protocol used to register the nodes over the LLN is 6LoWPAN 423 ND [RFC6775], the Backbone Routers act as a distributed DAD table, 424 using classical ND over the backbone to detect duplication. This 425 specification requires that: 427 1. Registrations for all addresses that can be required to reach the 428 device over the backbone, including registrations for IPv6 429 addresses based on burn-in EUI64 addresses are passed to the DAD 430 table. 432 2. Nodes include the EARO in their NS used for registering those 433 addresses and the LRs propagate that option to the LBRs. 435 A false positive duplicate detection may arise over the backbone, for 436 instance if the node registers to more than one LBR, or if the node 437 has moved. Both situations are handled gracefully unbeknownst to the 438 node. In the former case, one LBR becomes primary to defend the 439 address over the backbone while the others become secondary and may 440 still forward packets back and forth. In the latter case the LBR 441 that receives the newest registration wins and becomes primary. 443 5.3. Claiming and Defending Addresses 445 Upon a new or an updated registration, the BBR performs a DAD 446 operation. If either a TID or a OUI is available, the BBR places 447 them in a EARO in all its ND messages over the backbone. If content 448 is not available for a given field, it is set to 0. 450 If a primary already exists over the backbone, it will answer the DAD 451 with an RA. 453 o If a RA is received with the O bit set, the primary rejects the 454 DAD and the DAD fails. the BBR needs to inform the LLN protocol 455 that the address is a duplicate. 457 o If a RA is received with the O bit reset, the primary accepts the 458 BBR as secondary and DAD succeeds. The BBR may install or 459 maintain its proxy states for that address. This router MAY 460 advertise the address using a NA. during a registration flow, it 461 MAY set the O bit. 463 o If no RA is received, this router assumes the role of primary and 464 DAD succeeds. The BBR may install or maintain its proxy states 465 for that address. This router advertises the address using a NA 466 with the O bit reset. 468 When the BBR installs or maintains its proxy states for an address, 469 it sends an NA with a SLLA option for that address. The Primary BR 470 MAY set the O bit if it wished to attract the traffic for that 471 address. 473 5.4. Conflict Resolution 475 A conflict arise when multiple BBRs get a registration from a same 476 address. This situation might arise when a node moves from a BBR to 477 another, when a node registers to multiple BBRs, or in the RPL case 478 when the BRs belong to a single coordinated DODAG. 480 The primary looks up the EARO in ND messages with a SLLA option. 482 o If there is no option, normal ND operation takes place and the 483 primary defends the address with a NA with the O bit set, adding 484 the EARO with its own information. 486 o If there is a EARO and the OUIs are different, then the conflict 487 apparently happens between different nodes, and the the primary 488 defends the address with a NA with the O bit set, adding the EARO 489 with its own information. If the TID in the EARO is in the 490 straight part of the lollipop, it is possible that the request 491 comes from the same node that has rebooted and formed a new OUI 492 The primary BBR may assess its registered entry prior to 493 answering. 495 o If there is a EARO and the OUIs are the same: 497 * If the TID in the ND message is newer than the most recent one 498 known by the primary router, this is interpreted as a node 499 moving. The primary cleans up its states and stops defending 500 the address. 502 * If the TID in the ND message is the same as the most recent one 503 known by the primary router, this is interpreted as a double 504 registration. In case of a DAD, the promary responds with a NA 505 with the O bit reset, to confirm its position as primary, 506 including the EARO. 508 * If the TID in the ND message is older than the most recent one 509 known by the primary router, this is interpreted as a stale 510 information. The primary defends the address with a NA with 511 the O bit set, adding the EARO with its own information. 513 * If the TIDs are very different (more than 16 apart, discounting 514 the straight part of the lollipop), it is impossible to resolve 515 for sure. The primary BBR should assess its registered entry 516 prior to answering. 518 5.5. Assessing an entry 520 In a number of cases, it might happen that the information at the 521 primary BBR is stale and obsolete. In particular, a node with no 522 permanent storage might reboot and form a different OUI, in which 523 case the information at the BBR is inaccurate and should be removed. 524 In another case, the BBR and the node have been out of reach for too 525 long and the TID that the BBR maintains is so far out that it is 526 impossible to compare it with that stored at the BBR. 528 In such situation, the primary Backbone Router has the possibility to 529 assess the registration. this is performed by the protocol in use to 530 register the node over the LLN. 532 When the protocol used to register the nodes over the LLN is RPL 533 [RFC6550], the BBR sends a targetted DIS to the registered address 534 over the registered path. A DAO back indicates that the current 535 registration is still valid and provides the adequate data to resolve 536 the conflict. 538 When the protocol used to register the nodes over the LLN is 6LoWPAN 539 ND [RFC6775]. 541 6. Security Considerations 543 This specification expects that the link layer is sufficiently 544 protected, either by means of physical or IP security for the 545 Backbone Link or MAC sublayer cryptography. In particular, it is 546 expected that the LLN MAC provides secure unicast to/from the 547 Backbone Router and secure BBRoadcast from the Backbone Router in a 548 way that prevents tempering with or replaying the RA messages. 550 The use of EUI-64 for forming the Interface ID in the link local 551 address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and 552 address privacy techniques. Considering the envisioned deployments 553 and the MAC layer security applied, this is not considered an issue 554 at this time. 556 7. IANA Considerations 558 A new type is requested for an ND option. 560 8. Acknowledgments 562 TBD 564 9. References 566 9.1. Normative References 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Levels", BCP 14, RFC 2119, March 1997. 571 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 572 (IPv6) Specification", RFC 2460, December 1998. 574 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 575 in IPv6", RFC 3775, June 2004. 577 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 578 Architecture", RFC 4291, February 2006. 580 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 581 for IPv6", RFC 4429, April 2006. 583 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 584 Message Protocol (ICMPv6) for the Internet Protocol 585 Version 6 (IPv6) Specification", RFC 4443, March 2006. 587 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 588 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 589 September 2007. 591 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 592 Address Autoconfiguration", RFC 4862, September 2007. 594 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 595 "Transmission of IPv6 Packets over IEEE 802.15.4 596 Networks", RFC 4944, September 2007. 598 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 599 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 600 September 2011. 602 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 603 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 604 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 605 Lossy Networks", RFC 6550, March 2012. 607 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 608 "Neighbor Discovery Optimization for IPv6 over Low-Power 609 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 610 November 2012. 612 9.2. Informative References 614 [I-D.chakrabarti-nordmark-6man-efficient-nd] 615 Chakrabarti, S., Nordmark, E., and M. Wasserman, 616 "Efficiency aware IPv6 Neighbor Discovery Optimizations", 617 draft-chakrabarti-nordmark-6man-efficient-nd-01 (work in 618 progress), November 2012. 620 [I-D.ietf-roll-terminology] 621 Vasseur, J., "Terminology in Low power And Lossy 622 Networks", draft-ietf-roll-terminology-11 (work in 623 progress), February 2013. 625 [I-D.van-beijnum-multi-mtu] 626 Beijnum, I., "Extensions for Multi-MTU Subnets", 627 draft-van-beijnum-multi-mtu-03 (work in progress), 628 July 2010. 630 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 631 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 632 RFC 3963, January 2005. 634 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 635 Neighbor Discovery (SEND)", RFC 3971, March 2005. 637 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 638 RFC 3972, March 2005. 640 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 641 Proxies (ND Proxy)", RFC 4389, April 2006. 643 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 644 over Low-Power Wireless Personal Area Networks (6LoWPANs): 645 Overview, Assumptions, Problem Statement, and Goals", 646 RFC 4919, August 2007. 648 9.3. External Informative References 650 [HART] www.hartcomm.org, "Highway Addressable Remote Transducer, 651 a group of specifications for industrial process and 652 control devices administered by the HART Foundation". 654 [ISA100.11a] 655 ISA, "ISA100, Wireless Systems for Automation", May 2008, 656 . 659 Author's Address 661 Pascal Thubert 662 Cisco Systems 663 Village d'Entreprises Green Side 664 400, Avenue de Roumanille 665 Batiment T3 666 Biot - Sophia Antipolis 06410 667 FRANCE 669 Phone: +33 4 97 23 26 34 670 Email: pthubert@cisco.com