idnits 2.17.00 (12 Aug 2021) /tmp/idnits42102/draft-thubert-6lowpan-backbone-router-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 815. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 822. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 828. 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 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: P: Primary Flag. Set to indicate that the router is primary and MAY proxy for the node if Proxy ND is used on the transit link. If the flag is not set then the router MUST not proxy for the node. -- 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 10, 2008) is 5063 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-05) exists of draft-van-beijnum-multi-mtu-02 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 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 July 10, 2008 5 Expires: January 11, 2009 7 6LoWPAN Backbone Router 8 draft-thubert-6lowpan-backbone-router-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 11, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 ISA100.11a is a Working Group at the ISA SP100 standard committee 42 that covers Wireless Systems for Industrial Automation and Process 43 Control. The WG is mandated to design a scalable, industrial grade 44 LowPAN for devices such as sensors, valves, and actuators. The 45 upcoming standard uses the 6LoWPAN format for the network header. It 46 also introduces the concept of a Backbone Router to merge small 47 LoWPANs via a high speed transit and scale the ISA100.11a network. 48 This paper proposes an IPv6 version of the Backbone Router concept. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Neighbor Binding messages . . . . . . . . . . . . . . . . . . 6 56 4.1. Binding Solicitation message . . . . . . . . . . . . . . . 7 57 4.2. Binding Confirmation message . . . . . . . . . . . . . . . 8 58 5. LowPAN device operations . . . . . . . . . . . . . . . . . . . 10 59 5.1. Forming addresses . . . . . . . . . . . . . . . . . . . . 10 60 5.2. Binding process . . . . . . . . . . . . . . . . . . . . . 11 61 5.3. Looking up neighbor addresses . . . . . . . . . . . . . . 12 62 5.4. Answering address look up . . . . . . . . . . . . . . . . 12 63 6. Backbone router operations . . . . . . . . . . . . . . . . . . 13 64 6.1. Exposing the Backbone Router . . . . . . . . . . . . . . . 13 65 6.2. Binding process . . . . . . . . . . . . . . . . . . . . . 14 66 6.3. Looking up neighbor addresses . . . . . . . . . . . . . . 15 67 6.4. Answering address look up . . . . . . . . . . . . . . . . 15 68 6.5. Forwarding packets . . . . . . . . . . . . . . . . . . . . 15 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 71 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 74 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 Intellectual Property and Copyright Statements . . . . . . . . . . 19 78 1. Introduction 80 ISA100.11a is a Working Group at the ISA SP100 standard committee 81 that covers Wireless Systems for Industrial Automation and Process 82 Control. The ISA100.11a is mandated to design a scalable, industrial 83 grade wireless network and application layer suite of protocols for 84 low power devices such as sensors and actuators, with a response time 85 on the order of 100ms. 87 The ISA100.11a WG has also introduced the concept of a Backbone 88 Router that would interconnect small LoWPANs over a high speed 89 transit network and scale a single ISA100.11a network up to the 90 thousands of nodes. 92 This paper specifies IP layer functionalities that are required to 93 implement the concept of a Backbone Router with IPv6, in particular 94 the application of the "IP Version 6 Addressing Architecture" 95 [RFC4291], " the Neighbor Discovery Protocol" [RFC4861] and "IPv6 96 Stateless Address Autoconfiguration" [RFC4862]. The use of EUI-64 97 based link local addresses, Neighbor Discovery Proxying [RFC4389] and 98 Optimistic Duplicate Address Detection [RFC4429] are discussed. 99 Also, the concept of Transit Link is introduced to implement the 100 transit network that is envisioned by ISA100.11a. 102 An extension to the Neighbor Discovery Protocol is introduced to 103 enable LoWPAN nodes to register to one or more Backbone Routers that 104 acts as white board for address resolution. This feature enables to 105 avoid the use of multicast over a Low power Wireless Personal Area 106 Network for the purpose of address resolution. 108 The Backbone Router might also acts as proxy for the Neighbor 109 Discovery Protocol for all nodes attached to it through a process of 110 registration and enables to merge multiple LoWPANs via a transit link 111 into a larger link. 113 A Backbone Router advertises itself using a new option in the ND 114 Router Advertisement Message. A new anycast address 6LOWPAN_BBR is 115 also introduced for the purpose of reaching the nearest Backbone 116 Router in the absence of any information. This enables to reduce the 117 use of multicast RAs for the router discovery operation. The routing 118 to the nearest router that owns that anycast address is out of scope 119 for this specifiation. 121 Another anycast address 6LOWPAN-NODE is introduced to enable any 122 LowPAN node to receive a response to its registration whether it 123 completes successfully or not. 125 The way the PAN IDs and 16-bit short addresses are allocated and 126 distributed in the case of an 802.15.4 network is not covered by this 127 specification. Similarly, the aspects of joining and securing the 128 network are out of scope. 130 2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 Readers are expected to be familiar with all the terms and concepts 137 that are discussed in "Neighbor Discovery for IP version 6" 138 [RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862], 139 "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 140 Overview, Assumptions, Problem Statement, and Goals" [RFC4919] and 141 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944]. 143 Readers would benefit from reading "Mobility Support in IPv6" 144 [RFC3775], "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] and 145 "Optimistic Duplicate Address Detection" [RFC4429] prior to this 146 specification for a clear understanding of the art in ND-proxying and 147 binding. This document defines additional terms: 149 Transit Link 151 This is an IPv6 link that interconnects 2 or more backbone 152 routers. It is expected to be deployed as a high speed backbone 153 in order to federate a potentially large set of LoWPANS. Also 154 referred to as a LoWPAN backbone or transit network. 156 Backbone Router 158 An IPv6 router that interconnects the LoWPAN with a Transit Link. 160 Extended LoWPAN 162 This is the aggregation of multiple LoWPANs as defined in 163 [RFC4919] interconnected by a Transit Link via Backbone Routers 164 and forming a single IPv6 link. 166 Binding 168 The association of the LoWPAN node IPv6 address and Interface ID 169 with associated proxying states including the remaining lifetime 170 of that association. 172 Registration 174 The process during which a LoWPAN node sends a Binding ND message 175 to a Backbone Router causing a binding for the LoWPAN node to be 176 registered. 178 3. Overview 180 A Transit Link federates multiple LoWPANs as a single IP link, the 181 extended LoWPAN. Each LoWPAN is anchored at a Backbone Router. The 182 Backbone Routers interconnect the LoWPANs over the Transit Link. A 183 node can move freely from a LoWPAN anchored at a Backbone Router to a 184 LoWPAN anchored at another Backbone Router on the same Transit Link 185 and conserve its link local and any other IPv6 address it has formed. 187 ---+------------------------ 188 | Plant Network 189 | 190 +-----+ 191 | | Gateway 192 | | 193 +-----+ 194 | 195 | Transit Link 196 +--------------------+------------------+ 197 | | | 198 +-----+ +-----+ +-----+ 199 | | Backbone | | Backbone | | Backbone 200 | | router | | router | | router 201 +-----+ +-----+ +-----+ 202 o o o o o o 203 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 o o o o o 205 o o o o o o o o o o 206 o o o o o o o 208 LoWPAN LoWPAN LoWPAN 210 Figure 1: Transit Link and Backbone Routers 212 In order to achieve this, the Transit link is used as reference for 213 Neighbor Discovery operations, by extending the concept of a Home 214 Link as defined in [RFC3775] for Mobile IPv6. In particular, 215 Backbone Routers perform ND proxying for the LoWPAN nodes in the 216 LoWPANs they own through a Primary registration. 218 The backbone router operation is compatible with that of a Home 219 Agent. This enables mobility support for sensor devices that would 220 move outside of the network delimited by the transit link. This also 221 enables collocation of Home Agent functionality within Backbone 222 Router functionality on the same interface of a router. 224 The Backbone Router is centric for address resolution inside the 225 LoWPAN. The raison d'etre of the Backbone Router is to eliminate the 226 need of the support for multicasting over the LoWPAN for address 227 resolution that the Neighbor Discovery flows normally require. This 228 is based on a white board registration model that uses anycast and 229 unicast only. 231 As a result, a LoWPAN node performs unicast exchanges to its Backbone 232 Router to claim and lookup addresses, and the Backbone Router proxies 233 the ND requests over the Transit Link when necessary. 235 In turn, the Backbone Routers operate as a distributed database of 236 all the LoWPAN nodes and use the Neighbor Discovery Protocol to share 237 that information across the transit link. 239 This specification documents a Neighbor Binding protocol that enables 240 a LoWPAN Node to claim and lookup addresses using a Backbone Router 241 as a white board. 243 This specification also documents the use of EUI-64 based link-local 244 addresses and the way they are claimed by the Backbone Routers over 245 the transit link. 247 For the purpose of Neighbor Discovery proxying, this specification 248 documents the LoWPAN binding cache, a conceptual data structure that 249 is similar to the MIP6 binding cache. 251 Another function of the Backbone Router is to perform 6LowPAN 252 compression and expansion between the LoWPAN and the Transit Link and 253 ensure MTU compatibility. Packets flow uncompressed over the Transit 254 Link and are routed normally towards a Gateway or an Application 255 sitting on the transit link or on a different link that is reachable 256 via IP. 258 4. Neighbor Binding messages 260 This section introduces message formats for all messages used in this 261 specification. The new messages are all ICMP messages and extend the 262 capabilities of " the IPv6 Neighbor Discovery Protocol" [RFC4861] 264 4.1. Binding Solicitation message 266 The Binding Sollicitation has a function similar to that of the 267 Binding Solicitation message in [RFC3775] for Mobile IPv6 and 268 [RFC3963] for NEMO. Any option that is not recognized MUST be 269 skipped silently. The Binding Solicitation message is sent by the 270 LoWPAN node to its Backbone Router to register an address. 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Type | Code | Checksum | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Reserved |O|P| Sequence # | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Lifetime | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Reserved | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | | 284 + + 285 | | 286 + Binding Address + 287 | | 288 + + 289 | | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | option(s)... 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Figure 2: Binding Solicitation message format 296 IP fields 298 Source Address: An IP address assigned to the sending interface, or 299 the unspecified address if no address is assigned to the sending 300 interface. 302 Destination Address: The well-known Backbone Router anycast address 303 6LOWPAN_BBR or the specific address of a given Backbone Router if 304 available. 306 Hop Limit: 255 308 ICMP fields 309 Type: 8-bit unsigned integer. Value is "to be assigned by IANA". 311 Code: 0 313 Checksum: The ICMP checksum. See [RFC4443] 315 Reserved: This field is unused. It MUST be initialized to zero by 316 the sender and MUST be ignored by the receiver. 318 P: Primary Flag. Set to indicate that the router is primary and MAY 319 proxy for the node if Proxy ND is used on the transit link. If 320 the flag is not set then the router MUST not proxy for the node. 322 O: Optimistic Flag. Set to indicate that the node uses optimistic 323 addresses and can accept packets on the Binding Address even 324 before the binding is complete. The Router MUST always use that 325 Binding Address as destination for the response as opposed to the 326 well-known anywast address. 328 Sequence #: A 16-bit unsigned integer used by the receiving node to 329 sequence Binding Solicitation and by the sending node to match a 330 returned Binding Confirmation. 332 Lifetime: 32-bit unsigned integer. The number of seconds remaining 333 before the binding MUST be considered expired. A value of zero 334 indicates that the Binding Cache entry for the registered node 335 MUST be deleted. 337 Binding Address: The link-layer address that the sender wishes to 338 assign or maintain assigned to its interface. 340 Possible options 342 Target link-layer address: The link-layer address for the target, 343 i.e., the sender of the message. See [RFC4861]. The link-layer 344 address option MUST be included when the binding is created and 345 MAY be omitted in renewal. 347 MTU: Specifies the maximum size of a fragmented message that the 348 node stack can recompose. See [RFC4861] and [RFC4944]. 350 4.2. Binding Confirmation message 352 The Binding Confirmation has a function similar to that of the 353 Binding Ack message in [RFC3775] for Mobile IPv6 and [RFC3963] for 354 NEMO. Any option that is not recognized MUST be skipped silently. 355 The Binding Confirmation message is sent by the Backbone Router node 356 to the LoWPAN node to confirm whether an IP address MAY be assigned 357 to an interface. 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Type | Code | Checksum | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Reserved |X|P| Sequence # | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Lifetime | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Reserved | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | | 371 + + 372 | | 373 + Binding Address + 374 | | 375 + + 376 | | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | option(s)... 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Figure 3: Binding Confirmation message format 383 IP fields 385 Source Address: An IP address assigned to the sending interface of 386 the router. 388 Destination Address: The well-known LoWPAN node anycast address 389 6LOWPAN_NODE or the Binding Address for the LoWPAN node. 391 Hop Limit: 255 393 ICMP fields 395 Type: 8-bit unsigned integer. Value is "to be assigned by IANA". 397 Code: 0 399 Checksum: The ICMP checksum. See [RFC4443] 401 Reserved: This field is unused. It MUST be initialized to zero by 402 the sender and MUST be ignored by the receiver. 404 P: Primary Flag. MUST echo the P flag in the Binding solicitation. 406 X: Proxy Flag. Indicates that the route actually proxies for the 407 node. This can only happen if the P flag is set as well. 409 Sequence #: A 16-bit unsigned integer used by the receiving node to 410 sequence Binding Solicitation and by the sending node to match a 411 returned Binding Confirmation. 413 Lifetime: 32-bit unsigned integer. The number of seconds remaining 414 before the binding MUST be considered expired. A value of zero 415 indicates that the Binding Cache entry for the registered node 416 MUST be deleted. 418 Binding Address: The link-layer address that the sender wishes to 419 assign or maintain assigned to its interface. 421 Possible options 423 Source link-layer address: The link-layer address of the interface 424 from which the Router Advertisement is sent. See [RFC4861]. 426 MTU: Specifies the maximum size of a fragmented message that the 427 router stack can recompose. See [RFC4861] and [RFC4944]. 429 Prefix Information: The preferred address for the router. See 430 [RFC4861] and [RFC3775]. When this information is present, the 431 Source link-layer address option MUST be present as well. The 432 Prefix Information option MUST be included when the binding is 433 created and MAY be omitted in renewal. 435 5. LowPAN device operations 437 5.1. Forming addresses 439 All nodes are required to autoconfigure at least one address, a link- 440 local address that is derived from the IEEE 64-bit extended media 441 access control address that is globally unique to the device. Link- 442 local address are described in section 2.5.6 of [RFC4291]. Appendix 443 A of that specification explains how the node builds an interface-ID 444 based on the IEEE 64-bit extended MAC address by inverting the "u" 445 (universal/local) bit. 447 As a result, knowledge of the 64-bit address of another node on the 448 same extended LoWPAN is enough to derive its link-local address and 449 reach it over IP. Another consequence is that the link local address 450 is presumably unique on the Extended LoWPAN, which enables the use of 451 Optimistic Duplicate Address Detection (oDAD) [RFC4429] over the 452 Transit Link and the LoWPAN. The address MAY be created as 453 optimistic to enable its use in the binding process with the Backbone 454 Router. 456 Nodes should also autoconfigure the well known anycast address 457 6LOWPAN_NODE. If they do not, they have to use their link local 458 address in optimistic node and indicate so in the binding flows so 459 that the Backbone Router uses that address in its replies. 461 Nodes MAY learn the address of the Backbone Routers using traditional 462 means such as configuration or the Neighbor Discovery Protocol Router 463 Advertisement messages. But those messages are multicast and might 464 not be sent at a short interval or at all over the LoWPAN. This 465 specification introduces a new anycast address 6LOWPAN_BBR that the 466 node can use to reach the nearest Backbone Router without previous 467 knowledge of that router address. This specification tolerates 468 movement within the LoWPAN so the node does not have to stick with a 469 given backbone router and MAY keep using the 6LOWPAN_BBR address for 470 all its registrations. 472 The Link Layer Address associated to the 6LOWPAN_BBR address is that 473 of the PAN coordinator unless the node has a specific reason to 474 select an alternate next hop. It is expected that the selected next 475 hop has a route to the nearest Backbone Router but the routing 476 protocol involved is outside the scope of this specification. It 477 results that the next hop might have to forward the registration 478 message and decrement the Hop Limit. This is why the Backbone Router 479 MUST accept Binding Solicitations with a Hop Limit that is lower than 480 255 (min value TBD). 482 The node might also form Unique Local and Global Unicast addresses, 483 for instance if it needs to be reachable from the outside of the 484 Extended LoWPAN, or if it can manage its own mobility as prescribed 485 by Mobile IPv6 [RFC3775]. In that case, the node needs to bind each 486 individual address individually. 488 5.2. Binding process 490 The binding process is very similar to that of a MIP6 mobile node, 491 though the messages used are new Neighbor Discovery ICMP messages . 492 A LoWPAN node address is tentative or optimistic as long as the 493 binding is not confirmed by the Backbone Router. 495 The LoWPAN node uses unicast Binding Solicitations to perform the 496 binding. The destination Address is that of the Backbone Router or a 497 well know anycast address 6LOWPAN_BBR that indicates the function of 498 the Backbone Routers. The source address is the unspecified address 499 as long as the address is still optimistic or tentative, and it is 500 the link local address of the node after it is successfully bound. 502 The acknowledgment to a Binding Solicitation is a unicast Binding 503 Confirmation message that contains the status of the binding. The 504 source of the packet is the link-local address of the Backbone 505 Router. The destination address is a well-know anycast address 506 6LOWPAN_NODE unless the optimistic bit is set in the Binding 507 Solicitation or the address was already bound, in which case the link 508 local address of the node is used. 510 Upon successful completion in the Binding Confirmation message, the 511 LoWPAN node sets the address from optimistic or tentative to 512 preferred. 514 The 'X' flag in the Binding Confirmation message indicates that the 515 Backbone Router has completed DAD and now owns the Binding Address 516 over the Transit Link. 518 This specification also introduces the concept of secondary binding. 519 For redundancy, a node might place a secondary binding with one or 520 more other Backbone Routers over a same or different LoWPANs. The 521 'P' flag in the Binding Solicitation message indicates whether the 522 binding is primary (set) or secondary (reset). 524 5.3. Looking up neighbor addresses 526 A LoWPAN node does not use multicast for its Neighbor Solicitation as 527 prescribed by the ND protocol [RFC4861] and oDAD [RFC4429]. For 528 lookup purposes, all NS messages are sent in unicast to the Backbone 529 Router, that answers in unicast as well. The message is a standard 530 Neighbor Solicitation but for the destination that set to the 531 Backbone Router address or the well known 6LOWPAN_BBR address as 532 opposed to the solicited-node multicast address for the destination 533 address. 535 The Target link-layer address in the response is either that of the 536 destination if a short cut is possible over the LoWPAN, or that of 537 the Backbone Router if the destination is reachable over the Transit 538 Link, in which case the Backbone Router will terminate 6LoWPAN and 539 relay the packet. 541 5.4. Answering address look up 543 A LoWPAN node does not need to join the solicited-node multicast 544 address for its own addresses and should not have to answer a 545 multicast Neighbor Solicitation. It may be programmed to answer a 546 unicast NS but that is not required by this specification. 548 6. Backbone router operations 550 6.1. Exposing the Backbone Router 552 The Backbone Router forms a link-local address in exactly the same 553 way as any other node on the LoWPAN. It uses the same link local 554 address for the Transit Link and for all the associated LoWPAN(s) 555 connected to that Backbone Router. 557 The backbone router also configures the well known 6LOWPAN_BBR 558 anycast address on the LoWPAN interfaces where it serves as Backbone 559 Router. Note that The Backbone Router will accept registration 560 packets with a hop limit that is lower than 255 on that specific 561 address. 563 The Backbone Router announces itself using Router Advertisements (RA) 564 messages that are broadcasted periodically over the LOWPAN. (note: 565 can we merge RA with some other maintenance packet or distribute the 566 info from the manager in some specific cases like ISA100.11a where 567 such a thing exists?). (also, when the node moves to another LoWPAN, 568 is there a way to let it know faster which is the Backbone Router so 569 that it can stimulate a RA using RS?). 571 A new option in the RA indicates the Backbone Router capability. In 572 this way a node can learn the PAN-ID and the 16-bit short address for 573 the Backbone Router if it was not already acquired from another 574 process that is not covered by this specification. 576 The Backbone Router MAY also announce any prefix that is configured 577 on the transit link, and serve as the default gateway for any node on 578 the Transit Link or on the attached LoWPANs. 580 The transit link Maximum Transmission Unit serves as base for Path 581 MTU discovery and Transport layer Maximum Segment Size negotiation 582 (see section 8.3 of [RFC2460]) for all nodes in the LoWPANs. To 583 achieve this, the Backbone Router announces the MTU of the transit 584 link over the LoWPAN using the MTU option in the RA message as 585 prescribed in section "4.6.4. MTU" of IPv6 Neighbor Discovery 586 [RFC4861]. 588 LoWPAN nodes SHOULD form IPv6 packets that are smaller than that MTU. 589 As a result, those packets should not require any fragmentation over 590 the transit link though they might be intranet-fragmented over the 591 LoWPAN itself as prescribed by [RFC4944]). 593 More information on the MTU issue with regard to ND-proxying can be 594 found in Neighbor Discovery Proxies [RFC4389] and 595 [I-D.van-beijnum-multi-mtu]. 597 6.2. Binding process 599 Upon a new binding for a link-local address based on a IEEE 64-bit 600 extended MAC address, the Backbone Router MAY use Optimistic DAD on 601 the Transit Link. Any other Backbone Router that would happen to 602 have a binding for that same address SHOULD yield and deprecate its 603 binding to secondary if it was primary. A positive acknowledgement 604 can be sent to the LoWPAN node right away if oDAD is used on the 605 Transit Link. Note: A new option with a sequence number from the 606 Binding Solicitation should be used to select the winner 608 The Backbone Router operation on the transit link is similar to that 609 of a Home Agent as specified in Mobility Support for IPv6 [RFC3775]. 610 In particular, the Neighbor Advertisement message is used as 611 specified in section "10.4.1. Intercepting Packets for a Mobile 612 Node" with one exception that the override (O) bit is not set, 613 indicating that this Backbone Router acts as a proxy for the LoWPAN 614 and will yield should another Backbone Router claim that address on 615 the Transit Link. This enables the LoWPAN node to join a different 616 Backbone Router at any time without the complexities of terminating a 617 current binding. 619 This specification also introduces the concept of secondary binding. 620 Upon a secondary binding, the Backbone Router will not announce or 621 defend the address on the transit link, but will be able to forward 622 packets to the node over its LoWPAN interface. For other addresses, 623 the rules in [RFC3775] apply for compatibility. 625 The Backbone Router responds to a Binding Solicitation with a Binding 626 Confirmation. The source address is a link local address of the 627 router and the destination is the well known 6LOWPAN_NODE address 628 unless a binding flow has already successfully completed in which 629 case the router MAY use the node's Binding. The router will also use 630 the Binding Address if the 'O' flag is raised in the Solicitation, 631 indicating that the node accepts packets on that address prior to a 632 successful binding but may not accept packets on the 6LOWPAN_NODE 633 address. 635 If the Backbone Router is primary for a registration (as indicated by 636 the 'P' flag) and it is connected to a Backbone, then it SHOULD 637 perform proxy ND operations on the backbone and indicate so in the 638 Confirmation message using the 'X' flag. In particular it SHOULD 639 reject the registration if DAD fails on the backbone. When oDAD is 640 used over the backbone the Backbone Router MAY issue the Binding 641 Confirmation right away with a positive code, but if a collision is 642 finally detected, it cancels the registration with an asynchronous 643 Binding Confirmation and a negative completion code. 645 6.3. Looking up neighbor addresses 647 A Backbone Router knows and proxies for all the IPv6 addresses that 648 are registered to it. When resolving a target address, the Backbone 649 Router first considers its binding cache. If this address is in the 650 cache, then the target is reachable over the LoWPAN as indicated in 651 the cache. Else, the Backbone Router locates the target over the 652 transit link using standard "Neighbor Discovery" [RFC4861] over that 653 link. 655 If the target is located over a LoWPAN owned by another Backbone 656 Router, then that other Backbone Router is in charge of answering the 657 Neighbor Solicitation on behalf of the target node. 659 6.4. Answering address look up 661 To enable proxying over the Transit Link, a Backbone Router must join 662 the solicited-node multicast address on that link for all the 663 registered addresses of the nodes in its LoWPANs. The Backbone 664 Router answers the Neighbor Solicitation with a Neighbor 665 Advertisement that indicates its own link-layer address in the Target 666 link-layer address option. 668 A Backbone Router expects and answers unicast Neighbor Solicitations 669 for all nodes in its LoWPANs. It answers as a proxy for the real 670 target. The target link-layer address in the response is either that 671 of the destination if a short cut is possible over the LoWPAN, or 672 that of the Backbone Router if the destination is reachable over the 673 Transit Link, in which case the Backbone Router will terminate 674 6LoWPAN and relay the packet. 676 6.5. Forwarding packets 678 Upon receiving packets on one of its LoWPAN interfaces, the Backbone 679 Router checks whether it has a binding for the source address. If it 680 does, then the Backbone Router can forward the packet to another 681 LoWPAN node or over the Transit link. Otherwise, the Backbone Router 682 MUST discard the packet. If the packet is to be transmitted over the 683 Transit link, then the 6LoWPAN sublayer is terminated and the full 684 IPv6 packet is reassembled and expanded. 686 When forwarding a packet from the Transit Link towards a LOwPAN 687 interface, the Backbone Router performs the 6LoWPAN sublayer 688 operations of compression and fragmentation and passes the packet to 689 the lower layer for transmission. 691 7. Security Considerations 693 This specification expects that the link layer is sufficiently 694 protected, either by means of physical or IP security for the Transit 695 Link or MAC sublayer cryptography. In particular, it is expected 696 that the LoWPAN MAC provides secure unicast to/from the Backbone 697 Router and secure broadcast from the Backbone Router in a way that 698 prevents tempering with or replaying the RA messages. 700 The use of EUI-64 for forming the Interface ID in the link local 701 address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and 702 address privacy techniques. Considering the envisioned deployments 703 and the MAC layer security applied, this is not considered an issue 704 at this time. 706 8. IANA Considerations 708 This specification requires 2 new ICMP types for the binding flow. 709 The is also a need for 2 new link local anycast addresses, 710 6LOWPAN_BBR for the routers and 6LOWPAN_NODE the nodes; those 711 addresses used as functional addresses. 713 9. Acknowledgments 715 The author wishes to thank Geoff Mulligan for his help and in-depth 716 review. 718 10. References 720 10.1. Normative References 722 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 723 Requirement Levels", BCP 14, RFC 2119, March 1997. 725 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 726 (IPv6) Specification", RFC 2460, December 1998. 728 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 729 in IPv6", RFC 3775, June 2004. 731 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 732 Architecture", RFC 4291, February 2006. 734 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 735 for IPv6", RFC 4429, April 2006. 737 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 738 Message Protocol (ICMPv6) for the Internet Protocol 739 Version 6 (IPv6) Specification", RFC 4443, March 2006. 741 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 742 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 743 September 2007. 745 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 746 Address Autoconfiguration", RFC 4862, September 2007. 748 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 749 "Transmission of IPv6 Packets over IEEE 802.15.4 750 Networks", RFC 4944, September 2007. 752 10.2. Informative References 754 [I-D.van-beijnum-multi-mtu] 755 Beijnum, I., "Extensions for Multi-MTU Subnets", 756 draft-van-beijnum-multi-mtu-02 (work in progress), 757 February 2008. 759 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 760 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 761 RFC 3963, January 2005. 763 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 764 Neighbor Discovery (SEND)", RFC 3971, March 2005. 766 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 767 RFC 3972, March 2005. 769 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 770 Proxies (ND Proxy)", RFC 4389, April 2006. 772 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 773 over Low-Power Wireless Personal Area Networks (6LoWPANs): 774 Overview, Assumptions, Problem Statement, and Goals", 775 RFC 4919, August 2007. 777 Author's Address 779 Pascal Thubert 780 Cisco Systems 781 Village d'Entreprises Green Side 782 400, Avenue de Roumanille 783 Batiment T3 784 Biot - Sophia Antipolis 06410 785 FRANCE 787 Phone: +33 4 97 23 26 34 788 Email: pthubert@cisco.com 790 Full Copyright Statement 792 Copyright (C) The IETF Trust (2008). 794 This document is subject to the rights, licenses and restrictions 795 contained in BCP 78, and except as set forth therein, the authors 796 retain all their rights. 798 This document and the information contained herein are provided on an 799 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 800 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 801 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 802 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 803 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 804 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 806 Intellectual Property 808 The IETF takes no position regarding the validity or scope of any 809 Intellectual Property Rights or other rights that might be claimed to 810 pertain to the implementation or use of the technology described in 811 this document or the extent to which any license under such rights 812 might or might not be available; nor does it represent that it has 813 made any independent effort to identify any such rights. Information 814 on the procedures with respect to rights in RFC documents can be 815 found in BCP 78 and BCP 79. 817 Copies of IPR disclosures made to the IETF Secretariat and any 818 assurances of licenses to be made available, or the result of an 819 attempt made to obtain a general license or permission for the use of 820 such proprietary rights by implementers or users of this 821 specification can be obtained from the IETF on-line IPR repository at 822 http://www.ietf.org/ipr. 824 The IETF invites any interested party to bring to its attention any 825 copyrights, patents or patent applications, or other proprietary 826 rights that may cover technology that may be required to implement 827 this standard. Please address the information to the IETF at 828 ietf-ipr@ietf.org. 830 Acknowledgment 832 Funding for the RFC Editor function is provided by the IETF 833 Administrative Support Activity (IASA).