idnits 2.17.1 draft-ietf-roll-admin-local-policy-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages 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 (February 6, 2015) is 3338 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-roll-trickle-mcast-11 -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-06) exists of draft-irtf-nmrg-an-gap-analysis-03 == Outdated reference: A later version (-17) exists of draft-ietf-6lo-btle-07 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 roll P. van der Stok 3 Internet-Draft Consultant 4 Intended status: Informational R. Cragie 5 Expires: August 10, 2015 Gridmerge 6 February 6, 2015 8 Forwarder policy for multicast with admin-local scope in the Multicast 9 Protocol for Low power and Lossy Networks (MPL) 10 draft-ietf-roll-admin-local-policy-03 12 Abstract 14 The purpose of this document is to specify an automated policy for 15 the routing of Multicast Protocol for Low power and Lossy Networks 16 (MPL) multicast messages with admin-local scope in a border router. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 10, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 54 1.2. Terminology and Acronyms . . . . . . . . . . . . . . . . 4 55 2. Network identifier . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.3. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 5 59 2.4. BLUETOOTH Low Energy . . . . . . . . . . . . . . . . . . 5 60 3. MPL4 router . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. MPL interface parameters . . . . . . . . . . . . . . . . 5 62 3.2. Determination of MPL4 zone . . . . . . . . . . . . . . . 6 63 4. Admin-Local policy . . . . . . . . . . . . . . . . . . . . . 7 64 4.1. Legal multicast messages . . . . . . . . . . . . . . . . 7 65 4.2. Forwarding legal packets . . . . . . . . . . . . . . . . 7 66 4.2.1. MPL message . . . . . . . . . . . . . . . . . . . . . 8 67 4.2.2. Multicast messages without MPL option . . . . . . . . 8 68 4.3. Encryption rules . . . . . . . . . . . . . . . . . . . . 9 69 5. MPL domains and zones . . . . . . . . . . . . . . . . . . . . 9 70 6. Default parameter values . . . . . . . . . . . . . . . . . . 10 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 74 10. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 77 11.2. Informative References . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 Multicast scopes are defined in [RFC4291]. The [RFC7346] extends the 83 scope definition with the text: 85 "Interface-Local, Link-Local, and Realm-Local scope boundaries are 86 automatically derived from physical connectivity or other, non- 87 multicast related configuration. Global scope has no boundary. The 88 boundaries of all other non-reserved scopes of Admin-Local or larger 89 are administratively configured." 91 The admin-local scope must therefore be administratively configured. 92 In this document "administratively configured" does not imply actions 93 by a human beyond installing the here specified protocol. 94 "Administratively configured" means an automatic derivation as 95 described in this document. 97 This draft describes an automated policy for the Multicast Protocol 98 for Low power and Lossy Networks (MPL) [[I-D.ietf-roll-trickle-mcast] 99 forwarding of multicast messages with admin-local scope within a 100 border router that lies between a network running MPL and some other 101 network. This wish is in line with the autonomous networking ideas 102 presented in [I-D.irtf-nmrg-an-gap-analysis]. 104 The realm-local multicast address is currently used by MPL to 105 propagate the multicast message to all receivers and forwarders 106 within a mesh network. The multicast propagation is limited to a 107 mesh network with a common layer-2. For example, a LoWPAN is defined 108 by an IEEE 802.15.4 layer-2 mesh network, composed of all connected 109 nodes sharing the same Personal Area Network (PAN) ID [RFC4944]. 111 The network concept differs between mesh network technologies. This 112 document maps a general network identifier to the specific network 113 identifier of existing mesh technologies. 115 In current and projected deployments, there is a requirement to 116 propagate a multicast message beyond the boundaries of the mesh 117 network it originated in independent of the mesh technology. 119 Consider the case where propagation over two mesh networks is 120 required. In one example, each mesh network has a border router and 121 the two border routers are connected with an Ethernet link. In 122 another example each mesh network is connected to its own network 123 interface connected to the same border router. In both cases, an 124 admin-local multicast message originating in one network needs to 125 propagate into the other mesh network. The boundary of the admin- 126 local scope is administratively configured. 128 This document describes an "MPL4 router" that forwards MPL messages 129 with a multicast address with admin-local scope to all interfaces 130 connected to links that connect to other MPL enabled interfaces. The 131 MPL4 router enables all its interfaces for MPL messages and allocates 132 an additional variable MPL_BLOCKED that permits(forbids) the 133 forwarding of MPL messages. 135 The MPL4 router uses the following technique to establish over which 136 links MPL4 messages must be forwarded. The MPL4 router listens on 137 its interfaces for arrival of MPL4 messages. When MPL4 messages 138 arrive over an interface, the MPL4 router includes this interface to 139 the set of interfaces over which incoming MPL4 messages are 140 forwarded. Regularly, the MPL4 router sends MPL4 messages over its 141 interfaces to provoke the return of MPL4 messages to maintain or 142 remove the interfaces in/from the set of forwarding interfaces. 144 It is expected that the private network of an organization, building, 145 or home, is connected to the Internet via the edge routers provided 146 by an ISP. The intention is that MPL messages with multicast 147 addresses of admin-local scope are freely forwarded within the 148 private network, but are never forwarded outside the private network 149 by edge routers. 151 1.1. Requirements Language 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 1.2. Terminology and Acronyms 159 This document uses terminology defined in 160 [I-D.ietf-roll-trickle-mcast] and [RFC7346]. In addition, the 161 following terms are used in this document: 163 o MPL4 refers to MPL with admin-local scope 4. 165 o MPL4 message: an MPL DATA message with a destination multicast 166 address of scope 4. 168 o MPL4 zone: a convex zone of interconnected interfaces over which 169 MPL messages with admin-local scope propagate. A MPL4 zone is 170 bounded by a zone as defined in [RFC4007]. 172 o MPL4 router: automatically determines the MPL4 zone in which MPL 173 messages with admin-local scope can be propagated. 175 2. Network identifier 177 Links may have the concept of a channel, for example in wireless 178 networks such a channel is associated with a communication frequency. 179 Additionally, for some link technologies, several networks can 180 coexist using the same channel. For these link technologies, a 181 network identifier exists. The network identifier is determined by 182 the link technology specification. When no network identifier exists 183 for a given link, the network identifier has the value "any". 185 2.1. IEEE 802.15.4 187 IPv6 over IEEE 802.15.4 is described in [RFC4944]. A LoWPAN is 188 composed of the nodes connected by an IEEE 802.15.4 mesh sharing the 189 same PAN ID. The PAN ID identifies a network in the IEEE 802.15.4 190 mesh. Several networks with different PAN IDs can coexist on the 191 same channel [IEEE802.15.4]. The PAN ID of an interface is defined 192 when the interface is enabled. The value of the network identifier 193 of an IEEE 802.15.4 link is the value of the PAN ID. 195 2.2. IEEE 802.11 197 IP over IEEE 802.11 is described in [RFC5416]. The Service Set 198 IDentifier (SSID) identifies a network in the IEEE 802.11 link. 199 Several networks with different SSIDs can coexist on the same channel 200 [IEEE802.11]. The SSID of an interface is defined when the interface 201 is switched on. The value of the network identifier of a IEEE 802.11 202 link is the value of the SSID. 204 2.3. ITU-T G.9959 206 IPv6 over ITU-T G.9959 is specified in [I-D.ietf-6lo-lowpanz]. The 207 HomeID identifies a network of connected nodes [G.9959]. Several 208 HomeIDs can coexist within communication range, but nodes adhering to 209 a network with a given HomeID cannot communicate with nodes adhering 210 to a network with a different HomeID. The value of the network 211 identifier of a G.9959 link is the value of the HomeID. 213 2.4. BLUETOOTH Low Energy 215 IPv6 over BLUETOOTH Low Energy (BTLE) is specified in 216 [I-D.ietf-6lo-btle]. The medium is specified in [btle]. BTLE does 217 not know the concept of multiple networks in one channel. The value 218 of the network identifier of a BTLE link is "any". 220 3. MPL4 router 222 The concept of an MPL4 router serves to automatically determine the 223 MPL4 zone in which MPL messages with a scope 4 multicast address can 224 propagate. The MPL4 router periodically executes an algorithm that 225 determines the presence of MPL interfaces on the links connected to 226 its interfaces. When no MPL interfaces are present on a given link, 227 the corresponding MPL interface is signalled as not being part of the 228 MPL4 zone. 230 3.1. MPL interface parameters 232 One parameter is associated with every MPL interface in the MPL4 233 router, and two parameters are associated with the behaviour of the 234 MPL4 router as a whole. 236 o MPL_BLOCKED: Boolean value that indicates whether the associated 237 interface belongs to the MPL4 zone. 239 o MPL_CHECK_INT: integer that indicates the time interval between 240 successive activations of the MPL4 router algorithm in seconds. 242 o MPL_TO: integer that indicates the interval in which MPL messages 243 are expected to be received in seconds. 245 3.2. Determination of MPL4 zone 247 All interfaces of the MPL4 router MUST be associated with following 248 parameters coming from MPL protocol [I-D.ietf-roll-trickle-mcast]: 249 PROACTIVE_FORWARDING, DATA_MESSAGE_IMIN, DATA_MESSAGE_IMAX, 250 DATA_MESSAGE_K, DATA_MESSAGE_TIMER_EXPIRATIONS. At start-up of the 251 MPL4 router, the parameters associated with all interfaces are 252 assigned the following values: PROACTIVE_FORWARDING = true, 253 MPL_BLOCKED = false. All interfaces MUST subscribe to the multicast 254 addresses ALL_MPL_FORWARDERS scope 3 and scope 4. 256 The MPL4 router executes the following algorithm for each interface: 258 o With a frequency determined by the value of MPL_CHECK_INT, the 259 MPL4 router sends an MPL4 message on each interface with a header 260 that includes the MPL option [I-D.ietf-roll-trickle-mcast] and is 261 sent to multicast address ALL_MPL_FORWARDERS with scope 4. 263 o When within an interval determined by the value of MPL_TO no MPL 264 message is received, the value of MPL_BLOCKED is set to true. 266 o At reception of an MPL4 message with a multicast address with 267 scope 4, the value of MPL_BLOCKED of the receiving interface is 268 set to false. 270 This protocol leads to a state where for each interface MPL_BLOCKED 271 is set to false if and only if MPL enabled interfaces are connected 272 to the link associated with the interface. When an MPL message is 273 submitted to an MPL-enabled interface -called A- in the MPL router, 274 the Trickle algorithm [RFC6206] is activated to send the MPL message. 275 The MPL4 message with multicast address ALL_MPL_FORWARDERS scope 4 is 276 accepted by every interface connected to the link that has subscribed 277 to ALL_MPL_FORWARDERS with scope 4. On acceptance of the MPL4 278 message by an interface -called B-, the MPL4 message is returned with 279 Trickle over interface B. Consequently, the MPL4 message is received 280 by the originating interface A, after which MPL_BLOCKED is set to 281 false. 283 When a new node is connected to the link, it can immediately send an 284 MPL4 message, or can wait for the reception of an MPL4 message to 285 announce its intention to be part of the MPL4 zone. 287 4. Admin-Local policy 289 The section starts with specifying what multicast messages arriving 290 at an interface are legal. It continues with a description of 291 forwarding legal admin-local multicast messages over other MPL 292 interfaces. 294 The policy for forwarding admin-local multicast messages 295 automatically to a MPL interface is specified as function of the 296 state of the MPL interface and the multicast message. The state of 297 the multicast message is determined by the presence of the MPL option 298 [I-D.ietf-roll-trickle-mcast] and the destination multicast address. 299 The state of the MPL interface is determined by the subscribed 300 multicast addresses, the zone index [RFC4007], and the values of the 301 PROACTIVE_FORWARDING parameter and the MPL_BLOCKED parameter of the 302 MPL interface. 304 When zone is undefined or not enabled, all interfaces have the same 305 zone index. 307 4.1. Legal multicast messages 309 Multicast messages can be created within the node by an application 310 or can arrive at an interface. 312 A multicast message created at a source (MPL seed) is legal when it 313 conforms to the properties described in section 9.1 of 314 [I-D.ietf-roll-trickle-mcast]. 316 A multicast message received at a given interface is legal when: 318 o The message carries an MPL option (MPL message) and the incoming 319 MPL interface is subscribed to the destination multicast address. 321 o The message does not carry an MPL option, the multicast address is 322 unequal to ALL_MPL_FORWARDERS scope 4 or scope 3, and the 323 interface has expressed interest to receive messages with the 324 specified multicast address via MLD [RFC3810] or via IGMP 325 [RFC3376]. The message was sent on according to PIM-DM [RFC3973] 326 or according to PIM-SM [RFC4601]. 328 Illegal multicast messages are discarded. 330 4.2. Forwarding legal packets 332 A legal multicast message received at a given interface is assigned 333 the network identifier of the interface of the incoming link . A 334 message that is created within the node is assigned the network 335 identifier "any". 337 Two types of legal multicast messages are considered: (1) MPL 338 messages, and (2) multicast messages which do not carry the MPL 339 option. 341 4.2.1. MPL message 343 MPL messages are forwarded on MPL interfaces using the Trickle 344 parameter values assigned to the MPL interface according to the 345 following rules: 347 o Link-local (scope 2) MPL messages are not forwarded. 349 o Realm-local (scope 3) MPL messages are forwarded on all MPL 350 interfaces that are subscribed to the same multicast address, have 351 the same zone index, and have PROACTIVE-FORWARDING set to true, 352 and the assigned network identifier of the multicast message is 353 identical to the network identifier of the MPL interface, or the 354 assigned network identifier of the multicast message is "any". 356 o Admin-local (scope 4) MPL messages are forwarded on all MPL 357 interfaces that are subscribed to the same multicast address, have 358 the same zone index, have PROACTIVE-FORWARDING set to true, and 359 have MPL_BLOCKED set to false. 361 o MPL messages with a multicast scope of 5 or higher MUST 362 encapsulate a message with the same multicast address without MPL 363 option. The decapsulated message can be forwarded over an 364 interface when the interface is subscribed with MLD to the same 365 multicast address. 367 4.2.2. Multicast messages without MPL option 369 Multicast messages without MPL option are forwarded on MPL interfaces 370 according to the following rules: 372 o Link-local (scope 2) messages or realm-local (scope 3) multicast 373 messages are not forwarded. 375 o Admin-local (scope 4) multicast messages are encapsulated with a 376 header carrying the MPL option and are forwarded on al MPL 377 interfaces that are subscribed to the multicast address, have the 378 same zone index, have PROACTIVE_FORWARDING set to true, and have 379 MPL_BLOCKED set to false. 381 o Multicast messages with a multicast scope of 5 or higher are 382 encapsulated with a header carrying the MPL option and are 383 forwarded on al MPL interfaces that are subscribed to the 384 multicast address, have PROACTIVE_FORWARDING set to true, and have 385 MPL_BLOCKED set to false. In addition these messages follow the 386 Multicast forwarding rules as specified by PIM [RFC3973], 387 [RFC4601] according to group specifications enabled by MLD 388 [RFC3810] or IGMP [RFC3376]. 390 4.3. Encryption rules 392 An incoming message protected at layer-2 MUST be subsequently re- 393 protected at layer-2 at all outgoing interfaces. Incoming messages 394 are integrity checked and optionally decrypted at the incoming 395 interface at layer-2 using the keys and protection algorithm 396 appropriate to the incoming interface's network and re-protected at 397 the outgoing interface using the keys and protection algorithm 398 appropriate to the outgoing interface's network. It may be necessary 399 to assess the relative levels of protection on the respective 400 interfaces and apply policy rules, for example to avoid downgrading 401 security where one network has a lower level of security than 402 another. 404 An incoming MPL4 messages which is not protected at layer-2 MUST NOT 405 be re-protected at layer-2 at all outgoing interfaces. 407 5. MPL domains and zones 409 An MPL domain is a scope zone in which MPL interfaces subscribe to 410 the same MPL Domain Address [I-D.ietf-roll-trickle-mcast]. In 411 accordance with [RFC4007] a zone boundary passes through a node. For 412 example, a small LLN node usually has one MPL mesh interface which is 413 enabled to the ALL_MPL_FORWARDERS multicast address with a scope 414 value of 3 (realm-local) [RFC7346]. The node interface belongs to 415 the zone and the corresponding zone boundary does not pass through 416 this node. In the border router with MPL interfaces enabled to the 417 multicast address ALL_MPL_FORWARDERS with scope value 3, the zone 418 includes usually this single interface and excludes all other 419 interfaces. A notable exception is provided by a node where MPL 420 interfaces of the same technology share the same network identifier. 421 These interfaces belong to the same MPL4 zone when the interfaces 422 share the same zone index. 424 In an MPL4 router, every MPL interface subscribes to the admin_local 425 ALL_MPL_FORWARDERS multicast address next to the realm-local 426 ALL_MPL_FORWARDERS address. 428 Every interface that belongs to an MPL domain that extends over 429 border routers MUST be subscribed to the admin-local 430 ALL_MPL_FORWARDERS address. 432 The MPL4 zone corresponding with the MPL multicast address 433 ALL_MPL_FORWARDERS with scope 4 (Admin-local) applies to border 434 routers with multiple interfaces, of which at least one interface is 435 MPL enabled and is subscribed to multicast address ALL_MPL_FORWARDERS 436 with scope 4. In a border router, all MPL enabled interfaces which 437 subscribe to the ALL_MPL_FORWARDERS address with scope 4 and for 438 which MPL_BLOCKED is false belong to the same MPL4 zone when the 439 interfaces share the same zone index. 441 MPL4 messages remain bounded within a zone as defined in [RFC4007]. 442 Consequently, MPL4 messages cannot be routed between interfaces 443 belonging to different zones. When the concept of zone is unknown or 444 disabled in a router, all interfaces belong to the same zone. For 445 example, consider a router with 5 interfaces where interfaces A and B 446 belong to zone 1 and interfaces C,D, and E belong to zone 2. MPL4 447 messages can be routed freely between interfaces A and B, and freely 448 between C,D, and E. However, a MPL4 message MUST NOT be routed from 449 Interface A to interface D. 451 6. Default parameter values 453 Three parameters are created in this draft. Their values are related 454 to the Trickle timer intervals. 456 MPL_TO = DATA_MESSAGE_IMAX times 2. Which leaves the time to receive 457 the second response message. 459 MPL_CHECK_INT = 5 minutes. Which means that a reaction to network 460 malfunctioning happens within 5 minutes. 462 MPL_BLOCKED = true. Which means that the interface has not received 463 MPL-enabled messages to include the interface to the MPL4 zone. 465 7. Security Considerations 467 The security considerations of [I-D.ietf-roll-trickle-mcast] also 468 apply to MPL4 routers. 470 The sending of MPL4 messages by a malicious node can have unwanted 471 consequences explained with the following example. It is not unusual 472 for a wired (e.g. ethernet) link to be used between two floors or 473 sections of an LLN, as radio propagation through reinforced concrete 474 is generally poor. The MPL4 zone can thus envelop multiple routers, 475 meshes and links. It is possible that a malicious node connects to a 476 wired link, on which no MPL enabled nodes are foreseen. In this 477 example configuration, the malicious node can send MPL4 messages to 478 the MPL4 router interfaces. When nothing is done, the MPL4 routers 479 will consequently distribute MPL4 messages from one mesh over the 480 wired link to the next mesh, although the wired link was not expected 481 to transport MPL4 messages. 483 To understand the consequences of this unwanted behaviour, the 484 following cases should be distinguished: 486 o The source mesh uses layer-2 encryption. 488 o The MPL4 router can be managed. 490 The four possible combinations are discussed below: 492 Layer-2 unsecured, Router unmanaged: In this case MPL4 messages are 493 freely distributed over meshes and links which are interconnected 494 by MPL4 routers within a zone. The MPL enabled (malicious) nodes 495 can read all MPL4 messages and distribute MPL4 messages over a 496 network limited by a zone. This situation can be acceptable for 497 an isolated network, within a clearly defined space, where the 498 connection of nodes can be tightly controlled. A completely wired 499 LLN -- such as is seen in BACnet -- is an example of an 500 unencrypted LLN which would be considered physically secure. 502 Layer-2 secured, Router unmanaged: In this case MPL4 messages are 503 freely distributed over meshes and links, which are interconnected 504 by MPL4 routers within a zone. Following the rules of 505 Section 4.3, the MPL4 enabled (malicious) nodes can not read the 506 MPL4 messages and MPL4 messages sent by the malicious node are not 507 accepted by other nodes. This situation is acceptable for a home 508 network or managed network extending over precisely one zone, 509 occupying a clearly defined physical space, where ease of 510 installation is important. In such a network, the presence of the 511 malicious node is not different from any other malicious node, 512 which tries to send messages over layer-2 protected links. 513 Because the network occupies exactly one zone, the MPL4 message 514 distribution cannot be extended outside the network. 516 Layer-2 unsecured, Router managed: In this case the distribution of 517 MPL4 messages over MPL4 router interfaces can be limited to those 518 interfaces, which a manager enabled for MPL and a set of multicast 519 addresses. The malicious node cannot extend the distribution of 520 MPL4 messages over unwanted interfaces. It is important that the 521 handling of the interfaces by the manager is protected. However, 522 MPL4 messages sent over the mesh can be interpreted by malicious 523 nodes and malicious messages can be injected into the set of 524 meshes and links which are connected by the MPL4 routers for which 525 the manager enabled the interfaces. This situation can be 526 practical for interconnected links and meshes, which are connected 527 to a LAN over a limited period, for example during installation of 528 the interconnected meshes and links. 530 Layer-2 secured, Router managed: In this case the distribution of 531 MPL4 messages over MPL4 router interfaces can be limited to those 532 interfaces, which a manager enabled for MPL and a set of multicast 533 addresses. Following the rules of Section 4.3, the malicious node 534 cannot extend the distribution of MPL4 messages over unwanted 535 interfaces and MPL4 messages sent by the malicious node are not 536 accepted by other nodes. It is important that the handling of the 537 interfaces by the manager is protected. The MPL enabled 538 (malicious) nodes can not read the MPL4 messages and MPL4 messages 539 sent by the malicious node are not accepted by other nodes. 540 Dependent on the number of managed interfaces, the network can 541 progressively pass from auto-configured to fully administratively 542 controlled. 544 8. IANA Considerations 546 No considerations for IANA are formulated in this document. 548 9. Acknowledgements 550 This document reflects discussions and remarks from several 551 individuals including (in alphabetical order): Scott Bradner, Esko 552 Dijk, Adrian Farrel, Matthew Gillmore, Joel Halpern, Steve Hanna, 553 Michael Richardson, and Pascal Thubert. 555 10. Change log 557 When published as a RFC, this section needs to be removed. 559 Version 03 - version 01 561 o Explained MPL acronym 563 o Added relation of MPL4 zone to zone as defined in [RFC4007] 565 o Added a section on encryption rules 567 o Revised and clarified the security considerations 569 Version 00 - version 01 571 o Default parameter values declared 572 o Security section extended 574 o scope 5 of higher messages specified 576 o messages with address ALL_MPL_FORWARDERS are not allowed from 577 outside zone 579 Changes from personal version to WG version-00. 581 o Aligned terminology with MPL terminology 582 [I-D.ietf-roll-trickle-mcast] 584 o Text on MPL4 router included 586 11. References 588 11.1. Normative References 590 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 591 Requirement Levels", BCP 14, RFC 2119, March 1997. 593 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 594 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 596 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 597 Architecture", RFC 4291, February 2006. 599 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 600 "Transmission of IPv6 Packets over IEEE 802.15.4 601 Networks", RFC 4944, September 2007. 603 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 604 Thyagarajan, "Internet Group Management Protocol, Version 605 3", RFC 3376, October 2002. 607 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 608 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 609 March 2005. 611 [RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and 612 Provisioning of Wireless Access Points (CAPWAP) Protocol 613 Binding for IEEE 802.11", RFC 5416, March 2009. 615 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 616 "The Trickle Algorithm", RFC 6206, March 2011. 618 [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, 619 August 2014. 621 [I-D.ietf-roll-trickle-mcast] 622 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 623 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 624 mcast-11 (work in progress), November 2014. 626 [IEEE802.15.4] 627 "IEEE 802.15.4 - Standard for Local and metropolitan area 628 networks -- Part 15.4: Low-Rate Wireless Personal Area 629 Networks", . 631 [IEEE802.11] 632 "IEEE 802.11 - Telecommunications and information exchange 633 between systems Local and metropolitan area networks -- 634 Part 11: Wireless LAN Medium Access Control (MAC) and 635 Physical Layer (PHY) Specifications", . 638 [G.9959] "ITU-T G.9959 Short range narrow-band digital 639 radiocommunication transceivers - PHY and MAC layer 640 specifications", . 642 [btle] "BLUETOOTH Specification Version 4.0", . 645 11.2. Informative References 647 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 648 Independent Multicast - Dense Mode (PIM-DM): Protocol 649 Specification (Revised)", RFC 3973, January 2005. 651 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 652 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 653 Protocol Specification (Revised)", RFC 4601, August 2006. 655 [I-D.irtf-nmrg-an-gap-analysis] 656 Jiang, S., Carpenter, B., and M. Behringer, "Gap Analysis 657 for Autonomic Networking", draft-irtf-nmrg-an-gap- 658 analysis-03 (work in progress), December 2014. 660 [I-D.ietf-6lo-lowpanz] 661 Brandt, A. and J. Buron, "Transmission of IPv6 packets 662 over ITU-T G.9959 Networks", draft-ietf-6lo-lowpanz-08 663 (work in progress), October 2014. 665 [I-D.ietf-6lo-btle] 666 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 667 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 668 over BLUETOOTH(R) Low Energy", draft-ietf-6lo-btle-07 669 (work in progress), January 2015. 671 Authors' Addresses 673 Peter van der Stok 674 Consultant 676 Email: consultancy@vanderstok.org 678 Robert Cragie 679 Gridmerge 681 Email: robert.cragie@gridmerge.com