idnits 2.17.1 draft-ietf-6lo-blemesh-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 -- The document date (July 2, 2018) is 2122 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 7416' is mentioned on line 355, but not defined == Unused Reference: 'RFC7668' is defined on line 539, but no explicit reference was found in the text == Unused Reference: 'RFC7416' is defined on line 550, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IPSP' Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group C. Gomez 3 Internet-Draft S. Darroudi 4 Intended status: Standards Track Universitat Politecnica de Catalunya 5 Expires: January 3, 2019 T. Savolainen 6 DarkMatter 7 M. Spoerk 8 Graz University of Technology 9 July 2, 2018 11 IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP 12 draft-ietf-6lo-blemesh-03 14 Abstract 16 RFC 7668 describes the adaptation of 6LoWPAN techniques to enable 17 IPv6 over Bluetooth low energy networks that follow the star 18 topology. However, recent Bluetooth specifications allow the 19 formation of extended topologies as well. This document specifies 20 the mechanisms needed to enable IPv6 over mesh networks composed of 21 Bluetooth low energy links established by using the Bluetooth 22 Internet Protocol Support Profile. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 3, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology and Requirements Language . . . . . . . . . . 3 60 2. Bluetooth LE Networks and the IPSP . . . . . . . . . . . . . 3 61 3. Specification of IPv6 mesh over Bluetooth LE networks . . . . 4 62 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Subnet model . . . . . . . . . . . . . . . . . . . . . . 4 64 3.3. Link model . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.3.1. Stateless address autoconfiguration . . . . . . . . . 5 66 3.3.2. Neighbor Discovery . . . . . . . . . . . . . . . . . 5 67 3.3.3. Header compression . . . . . . . . . . . . . . . . . 7 68 3.3.4. Unicast and multicast mapping . . . . . . . . . . . . 8 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 73 8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 76 9.2. Informative References . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 Bluetooth low energy (hereinafter, Bluetooth LE) was first introduced 82 in the Bluetooth 4.0 specification. Bluetooth LE (which has been 83 marketed as Bluetooth Smart) is a low-power wireless technology 84 designed for short-range control and monitoring applications. 85 Bluetooth LE is currently implemented in a wide range of consumer 86 electronics devices, such as smartphones and wearable devices. Given 87 the high potential of this technology for the Internet of Things, the 88 Bluetooth Special Interest Group (Bluetooth SIG) and the IETF have 89 produced specifications in order to enable IPv6 over Bluetooth LE, 90 such as the Internet Protocol Support Profile (IPSP) [IPSP], and RFC 91 7668, respectively. Bluetooth 4.0 only supports Bluetooth LE 92 networks that follow the star topology. In consequence, RFC 7668 was 93 specifically developed and optimized for that type of network 94 topology. However, subsequent Bluetooth specifications allow the 95 formation of extended topologies [BTCorev4.1], such as the mesh 96 topology. The functionality described in RFC 7668 is not sufficient 97 and would fail to enable IPv6 over mesh networks composed of 98 Bluetooth LE links. This document specifies the mechanisms needed to 99 enable IPv6 over mesh networks composed of Bluetooth LE links. This 100 specification also allows to run IPv6 over Bluetooth LE star topology 101 networks, albeit without all the topology-specific optimizations 102 contained in RFC 7668. 104 1.1. Terminology and Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 The terms 6LoWPAN Node (6LN), 6LoWPAN Router (6LR) and 6LoWPAN Border 111 Router (6LBR) are defined as in [RFC6775], with an addition that 112 Bluetooth LE central and Bluetooth LE peripheral (see Section 2) can 113 both be adopted by a 6LN, a 6LR or a 6LBR. 115 2. Bluetooth LE Networks and the IPSP 117 Bluetooth LE defines two Generic Access Profile (GAP) roles of 118 relevance herein: the Bluetooth LE central role and the Bluetooth LE 119 peripheral role. A device in the central role, which is called 120 central from now on, has traditionally been able to manage multiple 121 simultaneous connections with a number of devices in the peripheral 122 role, called peripherals hereinafter. Bluetooth 4.1 introduced the 123 possibility for a peripheral to be connected to more than one central 124 simultaneously, therefore allowing extended topologies beyond the 125 star topology for a Bluetooth LE network. In addition, a device may 126 simultaneously be a central in a set of link layer connections, as 127 well as a peripheral in others. On the other hand, the IPSP enables 128 discovery of IP-enabled devices and the establishment of a link layer 129 connection for transporting IPv6 packets. The IPSP defines the Node 130 and Router roles for devices that consume/originate IPv6 packets and 131 for devices that can route IPv6 packets, respectively. Consistently 132 with Bluetooth 4.1, a device may implement both roles simultaneously. 134 This document assumes a mesh network composed of Bluetooth LE links, 135 where link layer connections are established between neighboring 136 IPv6-enabled devices (see Section 3.3.2, item 3.b)). The IPv6 137 forwarding devices of the mesh have to implement both Node and Router 138 roles, while simpler leaf-only nodes can implement only the Node 139 role. In an IPv6-enabled mesh of Bluetooth LE links, a node is a 140 neighbor of another node, and vice versa, if a link layer connection 141 has been established between both by using the IPSP functionality for 142 discovery and link layer connection establishment for IPv6 packet 143 transport. 145 3. Specification of IPv6 mesh over Bluetooth LE networks 147 3.1. Protocol stack 149 Figure 1 illustrates the protocol stack for IPv6 mesh over Bluetooth 150 LE networks. There are two main differences with the IPv6 over 151 Bluetooth LE stack in RFC 7668: a) the adaptation layer below IPv6 152 (labelled as "6Lo for IPv6 mesh of Bluetooth LE") is now adapted for 153 mesh networks of Bluetooth LE links, and b) the protocol stack for 154 IPv6 mesh networks of Bluetooth LE links includes IPv6 routing 155 functionality. 157 +------------------------------------+ 158 | Application | 159 +---------+ +------------------------------------+ 160 | IPSS | | UDP/TCP/other | 161 +---------+ +------------------------------------+ 162 | GATT | | IPv6 |routing| | 163 +---------+ +------------------------------------+ 164 | ATT | | 6Lo for IPv6 mesh over Bluetooh LE | 165 +---------+--+------------------------------------+ 166 | Bluetooth LE L2CAP | 167 - - +-------------------------------------------------+- - - HCI 168 | Bluetooth LE Link Layer | 169 +-------------------------------------------------+ 170 | Bluetooth LE Physical | 171 +-------------------------------------------------+ 173 Figure 1: Protocol stack for IPv6 mesh over Bluetooth LE. 175 3.2. Subnet model 177 For IPv6 mesh over Bluetooth LE, a multilink model has been chosen, 178 as further illustrated in Figure 2. As IPv6 over Bluetooth LE is 179 intended for constrained nodes, and for Internet of Things use cases 180 and environments, the complexity of implementing a separate subnet on 181 each peripheral-central link and routing between the subnets appears 182 to be excessive. In this specification, the benefits of treating the 183 collection of point-to-point links between a central and its 184 connected peripherals as a single multilink subnet rather than a 185 multiplicity of separate subnets are considered to outweigh the 186 multilink model's drawbacks as described in [RFC4903]. 188 / 189 .--------------------------------. / 190 / 6LR 6LN 6LN \ / 191 / \ \ \ \ / 192 | \ \ \ | / 193 | 6LN ----- 6LR --------- 6LR ------ 6LBR ----- | Internet 194 | <--Link--> <---Link--->/<--Link->/ | | 195 \ / / / \ 196 \ 6LN ---- 6LR ----- 6LR / \ 197 '--------------------------------' \ 198 \ 200 <------------ Subnet -----------------><---- IPv6 connection --> 201 to the Internet 203 Figure 2: Example of an IPv6 mesh over a Bluetooth LE network 204 connected to the Internet 206 One or more 6LBRs are connected to the Internet. 6LNs are connected 207 to the network through a 6LR or a 6LBR. A prefix is used on the 208 whole subnet. 210 IPv6 mesh networks over Bluetooth LE MUST follow a route-over 211 approach. This document does not specify the routing protocol to be 212 used in an IPv6 mesh over Bluetooth LE. 214 3.3. Link model 216 3.3.1. Stateless address autoconfiguration 218 6LN, 6LR and 6LBR IPv6 addresses in an IPv6 mesh over Bluetooth LE 219 are configured as per section 3.2.2 of RFC 7668. 221 Multihop DAD functionality as defined in section 8.2 of RFC 6775, or 222 some substitute mechanism (see section 3.3.2), MUST be supported. 224 3.3.2. Neighbor Discovery 226 'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 227 Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor 228 discovery approach as adapted for use in several 6LoWPAN topologies, 229 including the mesh topology. The route-over functionality of RFC 230 6775 MUST be supported. 232 The following aspects of the Neighbor Discovery optimizations 233 [RFC6775] are applicable to Bluetooth LE 6LNs: 235 1. A Bluetooth LE 6LN MUST NOT register its link-local address. A 236 Bluetooth LE host MUST register its non-link-local addresses with its 237 routers by sending a Neighbor Solicitation (NS) message with the 238 Address Registration Option (ARO) and process the Neighbor 239 Advertisement (NA) accordingly. The NS with the ARO option MUST be 240 sent irrespective of the method used to generate the IID. The ARO 241 option requires use of an EUI-64 identifier [RFC6775]. In the case 242 of Bluetooth LE, the field SHALL be filled with the 48-bit device 243 address used by the Bluetooth LE node converted into 64-bit Modified 244 EUI-64 format [RFC4291]. 246 If the 6LN registers for a same compression context multiple 247 addresses that are not based on Bluetooth device address, the header 248 compression efficiency will decrease. 250 2. For sending Router Solicitations and processing Router 251 Advertisements the Bluetooth LE hosts MUST, respectively, follow 252 Sections 5.3 and 5.4 of the [RFC6775]. 254 3. The router behavior for 6LRs and 6LBRs is described in Section 6 255 of RFC 6775. However, as per this specification: a) Routers SHALL 256 NOT use multicast NSs to discover other routers' link layer 257 addresses. b) As per section 6.2 of RFC 6775, in a dynamic 258 configuration scenario, a 6LR comes up as a non-router and waits to 259 receive a Router Advertisement for configuring its own interface 260 address first, before setting its interfaces to be advertising 261 interfaces and turning into a router. In order to support such 262 operation in an IPv6-enabled mesh of Bluetooth LE links, a 6LR first 263 uses the IPSP Node role only. Once the 6LR has established a 264 connection with another node previously running as a router, and 265 receives a Router Advertisement from that router, the 6LR configures 266 its own interface address, it turns into a router, and it runs as an 267 IPSP Router. A 6LBR uses the IPSP Router role since the 6LBR is 268 initialized. See an example in the Appendix. 270 4. Border router behavior is described in Section 7 of RFC 6775. 272 RFC 6775 defines substitutable mechanisms for distributing prefixes 273 and context information (section 8.1 of RFC 6775), as well as for 274 Duplicate Address Detection across a route-over 6LoWPAN (section 8.2 275 of RFC 6775). Implementations of this specification MUST support the 276 features described in sections 8.1 and 8.2 of RFC 6775 unless some 277 alternative ("substitute") from some other specification is 278 supported. 280 3.3.3. Header compression 282 Header compression as defined in RFC 6282 [RFC6282], which specifies 283 the compression format for IPv6 datagrams on top of IEEE 802.15.4, is 284 REQUIRED as the basis for IPv6 header compression on top of Bluetooth 285 LE. All headers MUST be compressed according to RFC 6282 [RFC6282] 286 encoding formats. 288 To enable efficient header compression, when the 6LBR sends a Router 289 Advertisement it MUST include a 6LoWPAN Context Option (6CO) 290 [RFC6775] matching each address prefix advertised via a Prefix 291 Information Option (PIO) [RFC4861] for use in stateless address 292 autoconfiguration. 294 The specific optimizations of RFC 7668 for header compression, which 295 exploit the star topology and ARO, cannot be generalized in a mesh 296 network composed of Bluetooth LE links. Still, a subset of those 297 optimizations can be applied in some cases in such a network. In 298 particular, the latter comprise link-local interactions, non-link- 299 local packet transmissions originated and performed by a 6LN, and 300 non-link-local packets transmitted (but not necessarily originated) 301 by the neighbor of a 6LN to that 6LN. For the rest of packet 302 transmissions, context-based compression MAY be used. 304 When a device transmits a packet to a neighbor, the sender MUST fully 305 elide the source IID if the source IPv6 address is the link-local 306 address based on the sender's Bluetooth device address (SAC=0, 307 SAM=11). The sender also MUST fully elide the destination IPv6 308 address if it is the link-local-address based on the neighbor's 309 Bluetooth device address (DAC=0, DAM=11). 311 When a 6LN transmits a packet, with a non-link-local source address 312 that the 6LN has registered with ARO in the next-hop router for the 313 indicated prefix, the source address MUST be fully elided if it is 314 the latest address that the 6LN has registered for the indicated 315 prefix (SAC=1, SAM=11). If the source non-link-local address is not 316 the latest registered by the 6LN, then the 64-bits of the IID SHALL 317 be fully carried in-line (SAC=1, SAM=01) or if the first 48-bits of 318 the IID match with the latest address registered by the 6LN, then the 319 last 16-bits of the IID SHALL be carried in-line (SAC=1, SAM=10). 321 When a router transmits a packet to a neighboring 6LN, with a non- 322 link-local destination address, the router MUST fully elide the 323 destination IPv6 address if the destination address is the latest 324 registered by the 6LN with ARO for the indicated context (DAC=1, 325 DAM=11). If the destination address is a non-link-local address and 326 not the latest registered, then the 6LN MUST either include the IID 327 part fully in-line (DAM=01) or, if the first 48-bits of the IID match 328 to the latest registered address, then elide those 48-bits (DAM=10). 330 3.3.4. Unicast and multicast mapping 332 The Bluetooth LE Link Layer does not support multicast. Hence, 333 traffic is always unicast between two Bluetooth LE neighboring nodes. 334 If a node needs to send a multicast packet to several neighbors, it 335 has to replicate the packet and unicast it on each link. However, 336 this may not be energy efficient, and particular care must be taken 337 if the node is battery powered. A router (i.e. a 6LR or a 6LBR) MUST 338 keep track of neighboring multicast listeners, and it MUST NOT 339 forward multicast packets to neighbors that have not registered as 340 listeners for multicast groups the packets belong to. 342 4. IANA Considerations 344 There are no IANA considerations related to this document. 346 5. Security Considerations 348 The security considerations in RFC 7668 apply. 350 IPv6 mesh networks over Bluetooth LE require a routing protocol to 351 find end-to-end paths. Unfortunately, the routing protocol may 352 generate additional opportunities for threats and attacks to the 353 network. 355 RFC 7416 [RFC 7416] provides a systematic overview of threats and 356 attacks on the IPv6 Routing Protocol for Low-Power and Lossy Networks 357 (RPL), as well as countermeasures. In that document, described 358 threats and attacks comprise threats due to failures to authenticate, 359 threats due to failure to keep routing information, threats and 360 attacks on integrity, and threats and attacks on availability. 361 Reported countermeasures comprise confidentiality attack, integrity 362 attack, and availability attack countermeasures. 364 While this specification does not state the routing protocol to be 365 used in IPv6 mesh over Bluetooth LE networks, the guidance of RFC 366 7416 is useful when RPL is used in such scenarios. Furthermore, such 367 guidance may partly apply for other routing protocols as well. 369 6. Contributors 371 Carlo Alberto Boano (Graz University of Technology) contributed to 372 the design and validation of this document. 374 7. Acknowledgements 376 The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are 377 registered trademarks owned by Bluetooth SIG, Inc. 379 The authors of this document are grateful to all RFC 7668 authors, 380 since this document borrows many concepts (albeit, with necessary 381 extensions) from RFC 7668. 383 The authors also thank Alain Michaud, Mark Powell and Martin Turon 384 for their comments, which helped improve the document. 386 Carles Gomez has been supported in part by the Spanish Government 387 Ministerio de Economia y Competitividad through project 388 TEC2012-32531, and FEDER. 390 8. Appendix 392 This appendix provides an example of Bluetooth LE connection 393 establishment and use of IPSP roles in an IPv6-enabled mesh of 394 Bluetooth LE links that uses dynamic configuration. The example 395 follows text in Section 3.3.2, item 3.b). 397 The example assumes a network with one 6LBR, two 6LRs and three 6LNs, 398 as shown in Figure 3. Connectivity between the 6LNs and the 6LBR is 399 only possible via the 6LRs. 401 The following text describes the different steps as time evolves, in 402 the example. Note that other sequences of events that may lead to 403 the same final scenario are also possible. 405 At the beginning, the 6LBR starts running as an IPSP Router, whereas 406 the rest of devices are not yet initialized (Step 1). Next, the 6LRs 407 start running as IPSP Nodes, i.e., they use Bluetooth LE 408 advertisement packets to announce their presence and support of IPv6 409 capabilities (Step 2). The 6LBR (already running as an IPSP Router) 410 discovers the presence of the 6LRs and establishes one Bluetooth LE 411 connection with each 6LR (Step 3). After establishment of those link 412 layer connections (and after reception of Router Advertisements from 413 the 6LBR), Step 4, the 6LRs start operating as routers, and also 414 initiate the IPSP Router role (note: whether the IPSP Node role is 415 kept running simultaneously is an implementation decision). Then, 416 6LNs start running the IPSP Node role (Step 5). Finally, the 6LRs 417 discover presence of the 6LNs and establish connections with the 418 latter (Step 6). 420 Step 1 421 ****** 422 6LBR 423 (IPSP: Router) 425 6LR 6LR 426 (not initialized) (not initialized) 428 6LN 6LN 6LN 429 (not initialized) (not initialized) (not initialized) 431 Step 2 432 ****** 433 6LBR 434 (IPSP: Router) 436 6LR 6LR 437 (IPSP: Node) (IPSP: Node) 439 6LN 6LN 6LN 440 (not initialized) (not initialized) (not initialized) 442 Step 3 443 ****** 445 6LBR 446 (IPSP: Router) 447 Bluetooth LE connection --> / \ 448 / \ 449 6LR 6LR 450 (IPSP: Node) (IPSP: Node) 452 6LN 6LN 6LN 453 (not initialized) (not initialized) (not initialized) 455 Step 4 456 ****** 458 6LBR 459 (IPSP: Router) 460 / \ 461 / \ 462 6LR 6LR 463 (IPSP: Router) (IPSP: Router) 465 6LN 6LN 6LN 466 (not initialized) (not initialized) (not initialized) 468 Step 5 469 ****** 471 6LBR 472 (IPSP: Router) 473 / \ 474 / \ 475 6LR 6LR 476 (IPSP: Router) (IPSP: Router) 478 6LN 6LN 6LN 479 (IPSP: Node) (IPSP: Node) (IPSP: Node) 481 Step 6 482 ****** 484 6LBR 485 (IPSP: Router) 486 / \ 487 / \ 488 6LR 6LR 489 (IPSP: Router) (IPSP: Router) 490 / \ / \ 491 / \ / \ 492 / \ / \ 493 6LN 6LN 6LN 494 (IPSP: Node) (IPSP: Node) (IPSP: Node) 496 Figure 3: An example of connection establishment and use of IPSP 497 roles in an IPv6-enabled mesh of Bluetooth LE links. 499 9. References 501 9.1. Normative References 503 [BTCorev4.1] 504 Bluetooth Special Interest Group, "Bluetooth Core 505 Specification Version 4.1", December 2013, 506 . 509 [IPSP] Bluetooth Special Interest Group, "Bluetooth Internet 510 Protocol Support Profile Specification Version 1.0.0", 511 December 2014, . 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, 516 DOI 10.17487/RFC2119, March 1997, 517 . 519 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 520 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 521 2006, . 523 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 524 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 525 DOI 10.17487/RFC4861, September 2007, 526 . 528 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 529 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 530 DOI 10.17487/RFC6282, September 2011, 531 . 533 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 534 Bormann, "Neighbor Discovery Optimization for IPv6 over 535 Low-Power Wireless Personal Area Networks (6LoWPANs)", 536 RFC 6775, DOI 10.17487/RFC6775, November 2012, 537 . 539 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 540 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 541 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 542 . 544 9.2. Informative References 546 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 547 DOI 10.17487/RFC4903, June 2007, 548 . 550 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 551 and M. Richardson, Ed., "A Security Threat Analysis for 552 the Routing Protocol for Low-Power and Lossy Networks 553 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 554 . 556 Authors' Addresses 558 Carles Gomez 559 Universitat Politecnica de Catalunya 560 C/Esteve Terradas, 7 561 Castelldefels 08860 562 Spain 564 Email: carlesgo@entel.upc.edu 566 Seyed Mahdi Darroudi 567 Universitat Politecnica de Catalunya 568 C/Esteve Terradas, 7 569 Castelldefels 08860 570 Spain 572 Email: sm.darroudi@entel.upc.edu 574 Teemu Savolainen 575 DarkMatter LLC 577 Email: teemu.savolainen@darkmatter.ae 579 Michael Spoerk 580 Graz University of Technology 581 Inffeldgasse 16/I 582 Graz 8010 583 Austria 585 Email: michael.spoerk@tugraz.at