idnits 2.17.1 draft-thubert-lowpan-backbone-router-00.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 645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 656. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 663. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 669. 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 -- 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 (November 4, 2007) is 6010 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-01 Summary: 3 errors (**), 0 flaws (~~), 2 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 November 4, 2007 5 Expires: May 7, 2008 7 LoWPAN Backbone Router 8 draft-thubert-lowpan-backbone-router-00 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 May 7, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 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. New Neighbor Discovery options . . . . . . . . . . . . . . . . 6 56 4.1. Binding Update Option . . . . . . . . . . . . . . . . . . 6 57 4.2. Binding Acknowledgement Option . . . . . . . . . . . . . . 7 58 5. LowPAN device operations . . . . . . . . . . . . . . . . . . . 8 59 5.1. Forming addresses . . . . . . . . . . . . . . . . . . . . 8 60 5.2. Binding process . . . . . . . . . . . . . . . . . . . . . 9 61 5.3. Looking up neighbor addresses . . . . . . . . . . . . . . 9 62 5.4. Answering address look up . . . . . . . . . . . . . . . . 10 63 6. Backbone router operations . . . . . . . . . . . . . . . . . . 10 64 6.1. Exposing the Backbone Router . . . . . . . . . . . . . . . 10 65 6.2. Binding process . . . . . . . . . . . . . . . . . . . . . 11 66 6.3. Looking up neighbor addresses . . . . . . . . . . . . . . 11 67 6.4. Answering address look up . . . . . . . . . . . . . . . . 12 68 6.5. Forwarding packets . . . . . . . . . . . . . . . . . . . . 12 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 74 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 Intellectual Property and Copyright Statements . . . . . . . . . . 15 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 In order to meet industrial requirements for non-critical monitoring, 88 alerting, supervisory control, open loop control and some closed loop 89 control applications, the Working Group is leveraging advanced 90 technology at every layer, including a mix of DSSS and FHSS at the 91 MAC/PHY layer, path diversity at Data Link Layer, and endorsed the 92 6LoWPAN format for the network header, making it possible to utilize 93 IP based protocols such as BACnet IP, Profibus IP and Modbus TCP 94 without significant changes to those protocols. 96 The ISA100.11a WG has also introduced the concept of a Backbone 97 Router that would interconnect small LoWPANs over a high speed 98 transit network and scale a single ISA100.11a network up to the 99 thousands of nodes. 101 This paper specifies IP layer functionalities that are required to 102 implement a such Backbone Router with IPv6, in particular the 103 application of the "IP Version 6 Addressing Architecture" [RFC4291], 104 "Neighbor Discovery for IP version 6" [RFC4861] and "IPv6 Stateless 105 Address Autoconfiguration" [RFC4862]. The use of EUI-64 based link 106 local addresses, Neighbor Discovery Proxying and Optimistic Duplicate 107 Address Detection are discussed. Also, the concept of Transit Link 108 is introduced to implement the transit network that is envisioned by 109 ISA100.11a. 111 This draft solves the problem of finding the other Backbone Router or 112 gateway on the transit link from a 64 bits address that is used as 113 interface ID for building a link local address. The Backbone Router 114 acts as proxy for all nodes attached to it through a process of 115 registration. The Backbone Router also acts as a server for all 116 Neighbor Discovery flows from and to its nodes, avoiding the burden 117 of multicast over the LoWPAN. 119 The way the PAN IDs and 16-bit short addresses are allocated and 120 distributed in the case of an 802.15.4 network is not covered by this 121 specification. This specification is compatible with a deployment 122 where each Backbone Router is connected to a different PAN-ID that is 123 managed locally, as well as a deployment where the whole transit link 124 and all nodes attached are a single PAN-ID. Similarly, the aspects 125 of joining and securing the network are out of scope. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 Readers are expected to be familiar with all the terms and concepts 134 that are discussed in "Neighbor Discovery for IP version 6" 135 [RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862], 136 "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 137 Overview, Assumptions, Problem Statement, and Goals" [RFC4919] and 138 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944]. 140 Readers would benefit from reading "Mobility Support in IPv6" 141 [RFC3775], "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] and 142 "Optimistic Duplicate Address Detection" [RFC4429] prior to this 143 specification for a clear understanding of the art in ND-proxying and 144 binding. This document defines additional terms: 146 Transit Link 148 This is an IPv6 link that interconnects 2 or more backbone 149 routers. It is expected to be deployed as a high speed backbone 150 in order to federate a potentially large set of LoWPANS. Also 151 referred to as a LoWPAN backbone or transit network. 153 Backbone Router 155 An IPv6 router that interconnects the LoWPAN with a Transit Link. 157 Extended LoWPAN 159 This is the aggregation of multiple LoWPANs as defined in 160 [RFC4919] interconnected by a Transit Link via Backbone Routers 161 and forming a single IPv6 link. 163 Binding 165 The association of the LoWPAN node IPv6 address and Interface ID 166 with associated proxying states including the remaining lifetime 167 of that association. 169 Registration 171 The process during which a LoWPAN node sends a Binding ND message 172 to a Backbone Router causing a binding for the LoWPAN node to be 173 registered. 175 3. Overview 177 A Transit Link federates multiple LoWPANs as a single IP link, the 178 extended LoWPAN. Each LoWPAN is anchored at a Backbone Router. The 179 Backbone Routers interconnect the LoWPANs over the Transit Link. A 180 node can move freely from a LoWPAN anchored at a Backbone Router to a 181 LoWPAN anchored at another Backbone Router on the same Transit Link 182 and conserve its link local and any other IPv6 address it has formed. 184 ---+------------------------ 185 | Plant Network 186 | 187 +-----+ 188 | | Gateway 189 | | 190 +-----+ 191 | 192 | Transit Link 193 +--------------------+------------------+ 194 | | | 195 +-----+ +-----+ +-----+ 196 | | Backbone | | Backbone | | Backbone 197 | | router | | router | | router 198 +-----+ +-----+ +-----+ 199 o o o o o o 200 o o o o o o o o o o o o o o 201 o o o o o o o o o o o o o o o 202 o o o o o o o o o o 203 o o o o o o o 205 LoWPAN LoPWAN LoWPAN 207 Figure 1: Transit Link and Backbone Routers 209 In order to achieve this, the Transit link is used as reference for 210 Neighbor Discovery operations, by extending the concept of a Home 211 Link as defined in [RFC3775] for Mobile IPv6. In particular, 212 Backbone Routers perform ND proxying for the LoWPAN nodes in the 213 LoWPANs they own. 215 The backbone router operation is compatible with that of a Home 216 Agent. This enables mobility support for sensor devices that would 217 move outside of the network delimited by the transit link. This also 218 enables collocation of Home Agent functionality within Backbone 219 Router functionality on the same interface of the router. 221 The Backbone Router is centric for ND operation inside the LoWPAN. 222 Part of the reason is the cost of the support for multicasting over 223 the LoWPAN that this specification avoids for the Neighbor 224 Solicitation flows. As a result, a LoWPAN node performs unicast 225 exchanges to its Backbone Router to claim and lookup addresses, and 226 the Backbone Router proxies the ND requests over the Transit Link 227 when necessary. 229 This specification documents the extensions to IPv6 Neighbor 230 Discovery that enables a LoWPAN Node to claim and lookup addresses 231 using a Backbone Router as an intermediate proxy. The draft also 232 documents the use of EUI-64 based link-local addresses and the way 233 they are claimed by the Backbone Routers over the transit link. 235 For the purpose of Neighbor Discovery proxying, this specification 236 documents the LoWPAN binding cache, a conceptual data structure that 237 is similar to the MIP6 binding cache. 239 Another function of the Backbone Router is to perform 6LowPAN 240 compression and uncompression between the LoWPAN and the Transit Link 241 and ensure MTU compatibility. Packets flow uncompressed over the 242 Transit Link and are routed normally towards a Gateway or an 243 Application sitting on the transit link or on a different link that 244 is reachable via IP. 246 4. New Neighbor Discovery options 248 4.1. Binding Update Option 250 The binding Update Option echoes the BU in [RFC3775] for Mobile IPv6. 251 At this stage of the specification, there is no control bit or 252 suboption. The BU option is used in Neighbor Solicitation messages 253 sent by the LoWPAN node to its Backbone Router for registration. 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Type | Length | Sequence # | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Reserved | Lifetime | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | sub-option(s)... 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Figure 2: NS BU option 267 Type: 8-bit unsigned integer. Value is "to be assigned by IANA". 269 Length: 8-bit unsigned integer set to 1 when there is no suboption. 270 The length of the option (including the type and length fields and 271 the suboptions) in units of 8 octets. 273 Sequence #: A 16-bit unsigned integer used by the receiving node to 274 sequence Binding Updates and by the sending node to match a 275 returned Binding Acknowledgement option with this Binding Update 276 option. 278 Lifetime: 16-bit unsigned integer. The number of time units 279 remaining before the binding MUST be considered expired. A value 280 of zero indicates that the Binding Cache entry for the mobile node 281 MUST be deleted. (In this case the specified care-of address MUST 282 also be set equal to the home address.) One time unit is 4 283 seconds. 285 4.2. Binding Acknowledgement Option 287 The Binding Ack Option echoes the Binding Ack in [RFC3775] for Mobile 288 IPv6. At this stage of the specification, there is no control bit or 289 suboption. The Binding Ack option is used in Neighbor Advertisement 290 messages sent by the Backbone Router to a LoWPAN node to acknowledge 291 its registration. A status indicates the completion. 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Type | Length | Status | Reserved | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Sequence # | Lifetime | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | sub-option(s)... 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 3: NA Binding Ack option 305 Type: 8-bit unsigned integer. Value is "to be assigned by IANA". 307 Length: 8-bit unsigned integer set to 1 when there is no suboption. 308 The length of the option (including the type and length fields and 309 the suboptions) in units of 8 octets. 311 Status: 8-bit unsigned integer indicating the disposition of the 312 Binding Update. Values of the Status field less than 128 indicate 313 that the Binding Update Option was accepted by the Backbone 314 Router. Values greater than or equal to 128 indicate that the 315 Binding Update was rejected by the Backbone Router. The following 316 Status values are currently defined: 318 0 Binding Update accepted (primary) 320 2 Binding Update accepted (secondary) 322 128 Reason unspecified 324 129 Administratively prohibited 326 130 Insufficient resources 328 134 Duplicate Address Detection failed 330 135 Duplicate Address Detection failed 332 Sequence #: 16-bit unsigned integer. The Sequence Number in the 333 Binding Acknowledgement is copied from the Sequence Number field 334 in the Binding Update. It is used by the LoWPAN node in matching 335 this Binding Acknowledgement with an outstanding Binding Update. 337 Lifetime: 16-bit unsigned integer. The granted lifetime, in time 338 units of 4 seconds, for which the Backbone Router SHOULD retain 339 the entry for this LoWPAN node in its Binding Cache. The value of 340 this field is undefined if the Status field indicates that the 341 Binding Update was rejected. 343 5. LowPAN device operations 345 5.1. Forming addresses 347 All nodes are required to autoconfigure at least one address, a link- 348 local address that is derived from the IEEE 64-bit extended media 349 access control address that is globally unique to the device. Link- 350 local address are described in section 2.5.6 of [RFC4291]. Appendix 351 A of that specification explains how the node builds an interface-ID 352 based on the IEEE 64-bit extended MAC address by inverting the "u" 353 (universal/local) bit. 355 As a result, knowledge of the 64-bit address of another node on the 356 same extended LoWPAN is enough to derive its link-local address and 357 reach it over IP. Another consequence is that the link local address 358 is presumably unique on the Extended LoWPAN, which enables the use of 359 Optimistic Duplicate Address Detection (oDAD) [RFC4429] over the 360 Transit Link and the LoWPAN. The address is created as optimistic to 361 enable its use in the binding process with the Backbone Router. 363 The node might also form Unique Local and Global Unicast addresses, 364 for instance if it needs to be reachable from the outside of the 365 Extended LoWPAN, or if it can manage its own mobility as prescribed 366 by Mobile IPv6 [RFC3775]. In that case, the node needs to bind each 367 individual address individually. 369 5.2. Binding process 371 The binding process is very similar to that of a MIP6 mobile node, 372 though the messages used are Neighbor Discovery messages with new 373 extensions to specify a binding relationship associated to the 374 advertisements. A LoWPAN Address is tentative as long as the binding 375 is not confirmed by the Backbone Router. 377 The LoWPAN node uses unicast Neighbor Solicitations to perform the 378 binding. The destination Address is that of the Backbone Router. 379 The source address the unspecified address as long as the address is 380 still optimistic or tentative, and it is the link local address of 381 the node after DAD is completed. The target address is the address 382 being bound. A new binding-update option specifies parameters such 383 as the binding lifetime. 385 The acknowledgment to an NS is a unicast Neighbor Advertisement with 386 a new Binding Acknowledgement option that contains the status of the 387 binding. The source of the packet is the link-local address of the 388 Backbone Router. The destination address is the link-local address 389 of the LoWPAN node, and the Target Address field contains the address 390 being bound. That unicast NA is not to be confused with the response 391 to a DAD and does not mean that the address is duplicated. 393 A bit in the Binding Acknowledgement option indicates whether the 394 Backbone Router has completed DAD and now owns the bound address over 395 the Transit Link. If the bit is set, the LoWPAN node set the address 396 from optimistic to preferred. 398 This specification also introduces the concept of secondary binding. 399 For redundancy, a node might place a secondary binding with one or 400 more other Backbone Routers over a same or different LoWPANs. A flag 401 in the binding option indicates whether the binding is secondary. 403 The Backbone Router might learn the PAN-ID and the 16-bit short 404 address from the NS message if it was not already known by another 405 means that is not within the scope of this specification. 407 5.3. Looking up neighbor addresses 409 A LoWPAN node does use multicast for its Neighbor Solicitation. 410 Whether for DAD or lookup purposes, all NS messages are sent in 411 unicast to the Backbone Router, that answers in unicast as well. 413 The Target link-layer address in the response is either that of the 414 destination if a short cut is possible over the LoWPAN, or that of 415 the Backbone Router if the destination is reachable over the Transit 416 Link, in which case the Backbone Router will terminate 6LoWPAN and 417 relay the packet. 419 5.4. Answering address look up 421 A LoWPAN node does not need to join the solicited-node multicast 422 address for its own addresses and should not have to answer a 423 multicast Neighbor Solicitation. It may be programmed to answer a 424 unicast NS but that is not required by this specification. 426 6. Backbone router operations 428 6.1. Exposing the Backbone Router 430 The Backbone Router forms a link-local address in exactly the same 431 way as any other node on the LoWPAN. It uses the same link local 432 address for the Transit Link and for all the associated LoWPAN(s) 433 connected to that Backbone Router. 435 The Backbone Router announces itself using Router Advertisements (RA) 436 messages that are broadcasted periodically over the LOWPAN. (note: 437 can we merge RA with some other maintenance packet or distribute the 438 info from the manager in some specific cases like ISA100.11a where 439 such a thing exists?). (also, when the node moves to another LoWPAN, 440 is there a way to let it know faster which is the Backbone Router so 441 that it can stimulate a RA using RS?). 443 A new option in the RA indicates the Backbone Router capability. In 444 this way a node can learn the PAN-ID and the 16-bit short address for 445 the Backbone Router if it was not already acquired from another 446 process that is not covered by this specification. 448 The Backbone Router MAY also announce any prefix that is configured 449 on the transit link, and serve as the default gateway for any node on 450 the Transit Link or on the attached LoWPANs. 452 The transit link Maximum Transmission Unit serves as base for Path 453 MTU discovery and Transport layer Maximum Segment Size negotiation 454 (see section 8.3 of [RFC2460]) for all nodes in the LoWPANs. To 455 achieve this, the Backbone Router announces the MTU of the transit 456 link over the LoWPAN using the MTU option in the RA message as 457 prescribed in section "4.6.4. MTU" of IPv6 Neighbor Discovery 459 [RFC4861]. 461 LoWPAN nodes SHOULD form IPv6 packets that are smaller than that MTU. 462 As a result, those packets should not require any fragmentation over 463 the transit link though they might be intranet-fragmented over the 464 LoWPAN itself as prescribed by [RFC4944]). 466 More information on the MTU issue with regard to ND-proxying can be 467 found in Neighbor Discovery Proxies [RFC4389] and 468 [I-D.van-beijnum-multi-mtu]. 470 6.2. Binding process 472 Upon a new binding for a link-local address based on a IEEE 64-bit 473 extended MAC address, the Backbone Router uses Optimistic DAD on the 474 Transit Link. Any other Backbone Router that would happen to have a 475 binding for that same address SHOULD yield and deprecate its binding 476 to secondary if it was primary. A positive acknowledgement can be 477 sent to the LoWPAN node right away if oDAD is used on the Transit 478 Link. 480 The Backbone Router operation on the transit link is similar to that 481 of a Home Agent as specified in Mobility Support for IPv6 [RFC3775]. 482 In particular, the Neighbor Advertisement message is used as 483 specified in section "10.4.1. Intercepting Packets for a Mobile 484 Node" with one exception that the override (O) bit is not set, 485 indicating that this Backbone Router acts as a proxy for the LoWPAN 486 and will yield should another Backbone Router claim that address on 487 the Transit Link. This enables the LoWPAN node to join a different 488 Backbone Router at any time without the complexities of terminating a 489 current binding. 491 This specification also introduces the concept of secondary binding. 492 Upon a secondary binding, the Backbone Router will not announce or 493 defend the address on the transit link, but will be able to forward 494 packets to the node over its LoWPAN interface. For other addresses, 495 the rules in [RFC3775] apply for compatibility. 497 6.3. Looking up neighbor addresses 499 A Backbone Router knows and proxies for all the IPv6 addresses that 500 are registered to it. When resolving a target address, the Backbone 501 Router first considers its binding cache. If this address is in the 502 cache, then the target is reachable over the LoWPAN as indicated in 503 the cache. Else, the Backbone Router locates the target over the 504 transit link using standard "Neighbor Discovery" [RFC4861] over that 505 link. 507 If the target is located over a LoWPAN owned by another Backbone 508 Router, then that other Backbone Router is in charge of answering the 509 Neighbor Solicitation on behalf of the target node. 511 6.4. Answering address look up 513 To enable proxying over the Transit Link, a Backbone Router must join 514 the solicited-node multicast address on that link for all the 515 registered addresses of the nodes in its LoWPANs. The Backbone 516 Router answers the Neighbor Solicitation with a Neighbor 517 Advertisement that indicates its own link-layer address in the Target 518 link-layer address option. 520 A Backbone Router expects and answers unicast Neighbor Solicitations 521 for all nodes in its LoWPANs. It answers as a proxy for the real 522 target. The target link-layer address in the response is either that 523 of the destination if a short cut is possible over the LoWPAN, or 524 that of the Backbone Router if the destination is reachable over the 525 Transit Link, in which case the Backbone Router will terminate 526 6LoWPAN and relay the packet. 528 6.5. Forwarding packets 530 Upon receiving packets on one of its LoWPAN interfaces, the Backbone 531 Router checks whether it has a binding for the source address. If it 532 does, then the Backbone Router can forward the packet to another 533 LoWPAN node or over the Transit link. Otherwise, the Backbone Router 534 MUST discard the packet. If the packet is to be transmitted over the 535 Transit link, then the 6LoWPAN sublayer is terminated and the full 536 IPv6 packet is uncompressed and reassembled. 538 When forwarding a packet from the Transit Link towards a LOwPAN 539 interface, the Backbone Router performs the 6LoWPAN sublayer 540 operations of compression and fragmentation and passes the packet to 541 the lower layer for transmission. 543 7. Security Considerations 545 This specification expects that the link layer is sufficiently 546 protected, either by means of physical or IP security for the Transit 547 Link or MAC sublayer cryptography. In particular, it is expected 548 that the LoWPAN MAC provides secure unicast to/from the Backbone 549 Router and secure broadcast from the Backbone Router in a way that 550 prevents tempering with or replaying the RA messages. 552 The use of EUI-64 for forming the Interface ID in the link local 553 address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and 554 address privacy techniques. Considering the envisioned deployments 555 and the MAC layer security applied, this is not considered an issue 556 at this time. 558 8. IANA Considerations 560 Need new NS/NA option numbers for the binding flow. 562 9. Acknowledgments 564 The author wishes to thank Geoff Mulligan for his help and in-depth 565 review. 567 10. References 569 10.1. Normative References 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", BCP 14, RFC 2119, March 1997. 574 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 575 (IPv6) Specification", RFC 2460, December 1998. 577 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 578 in IPv6", RFC 3775, June 2004. 580 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 581 Architecture", RFC 4291, February 2006. 583 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 584 for IPv6", RFC 4429, April 2006. 586 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 587 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 588 September 2007. 590 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 591 Address Autoconfiguration", RFC 4862, September 2007. 593 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 594 "Transmission of IPv6 Packets over IEEE 802.15.4 595 Networks", RFC 4944, September 2007. 597 10.2. Informative References 599 [I-D.van-beijnum-multi-mtu] 600 Beijnum, I., "IPv6 Extensions for Multi-MTU Subnets", 601 draft-van-beijnum-multi-mtu-01 (work in progress), 602 August 2007. 604 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 605 Neighbor Discovery (SEND)", RFC 3971, March 2005. 607 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 608 RFC 3972, March 2005. 610 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 611 Proxies (ND Proxy)", RFC 4389, April 2006. 613 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 614 over Low-Power Wireless Personal Area Networks (6LoWPANs): 615 Overview, Assumptions, Problem Statement, and Goals", 616 RFC 4919, August 2007. 618 Author's Address 620 Pascal Thubert 621 Cisco Systems 622 Village d'Entreprises Green Side 623 400, Avenue de Roumanille 624 Batiment T3 625 Biot - Sophia Antipolis 06410 626 FRANCE 628 Phone: +33 4 97 23 26 34 629 Email: pthubert@cisco.com 631 Full Copyright Statement 633 Copyright (C) The IETF Trust (2007). 635 This document is subject to the rights, licenses and restrictions 636 contained in BCP 78, and except as set forth therein, the authors 637 retain all their rights. 639 This document and the information contained herein are provided on an 640 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 641 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 642 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 643 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 644 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 645 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 647 Intellectual Property 649 The IETF takes no position regarding the validity or scope of any 650 Intellectual Property Rights or other rights that might be claimed to 651 pertain to the implementation or use of the technology described in 652 this document or the extent to which any license under such rights 653 might or might not be available; nor does it represent that it has 654 made any independent effort to identify any such rights. Information 655 on the procedures with respect to rights in RFC documents can be 656 found in BCP 78 and BCP 79. 658 Copies of IPR disclosures made to the IETF Secretariat and any 659 assurances of licenses to be made available, or the result of an 660 attempt made to obtain a general license or permission for the use of 661 such proprietary rights by implementers or users of this 662 specification can be obtained from the IETF on-line IPR repository at 663 http://www.ietf.org/ipr. 665 The IETF invites any interested party to bring to its attention any 666 copyrights, patents or patent applications, or other proprietary 667 rights that may cover technology that may be required to implement 668 this standard. Please address the information to the IETF at 669 ietf-ipr@ietf.org. 671 Acknowledgment 673 Funding for the RFC Editor function is provided by the IETF 674 Administrative Support Activity (IASA).