wdiff rfc7732.original rfc7732.txt

roll
Internet Engineering Task Force (IETF) P. van der Stok
Internet-Draft
Request for Comments: 7732 Consultant
Intended status:
Category: Informational R. Cragie
Expires: August 10, 2015 Gridmerge
ISSN: 2070-1721 ARM Ltd.
February 6, 2015 2016

Forwarder policy Policy for multicast Multicast with admin-local scope Admin-Local Scope
in the Multicast Protocol for Low power Low-Power and Lossy Networks (MPL)
draft-ietf-roll-admin-local-policy-03

Abstract

The purpose of this document is to specify an automated policy for
the routing of Multicast Protocol for Low power Low-Power and Lossy Networks
(MPL) multicast messages with admin-local Admin-Local scope in a border router.

Status of This Memo

This Internet-Draft document is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents not an Internet Standards Track specification; it is
published for informational purposes.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a maximum candidate for any level of Internet
Standard; see Section 2 of RFC 5741.

Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 10, 2015.
http://www.rfc-editor.org/info/rfc7732.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 ....................................................2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 ......................................4
1.2. Terminology and Acronyms . . . . . . . . . . . . . . . . 4 ...................................4
2. Network identifier . . . . . . . . . . . . . . . . . . . . . 4 Identifier ..............................................4
2.1. IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . 4 ..............................................5
2.2. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . 5 ................................................5
2.3. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 5 ...............................................5
2.4. BLUETOOTH BLUETOOTH(R) Low Energy . . . . . . . . . . . . . . . . . . 5 ....................................5
3. MPL4 router . . . . . . . . . . . . . . . . . . . . . . . . . 5 Router .....................................................5
3.1. MPL interface parameters . . . . . . . . . . . . . . . . 5 Interface Parameters ...................................6
3.2. Determination of MPL4 zone . . . . . . . . . . . . . . . 6 Zone .................................6
4. Admin-Local policy . . . . . . . . . . . . . . . . . . . . . 7 Policy ..............................................7
4.1. Legal multicast messages . . . . . . . . . . . . . . . . 7 Multicast Messages ...................................7
4.2. Forwarding legal packets . . . . . . . . . . . . . . . . 7 Legal Packets ...................................8
4.2.1. MPL message . . . . . . . . . . . . . . . . . . . . . 8 Message .........................................8
4.2.2. Multicast messages Messages without MPL option . . . . . . . . 8 Option ...............9
4.3. Encryption rules . . . . . . . . . . . . . . . . . . . . 9 Rules ...........................................9
5. MPL domains Domains and zones . . . . . . . . . . . . . . . . . . . . 9 Zones ...........................................9
6. Default parameter values . . . . . . . . . . . . . . . . . . 10 Parameter Values .......................................10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 ........................................11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
10. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. .....................................................12
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. ......................................12
8.2. Informative References . . . . . . . . . . . . . . . . . 14 ....................................14
Acknowledgements ..................................................15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 ................................................15

1. Introduction

Multicast scopes are defined in [RFC4291]. The [RFC7346] extends the
scope definition with the this text:

"Interface-Local, Link-Local, and Realm-Local scope boundaries are
automatically derived from physical connectivity or other, non-
multicast related configuration. other
non-multicast-related configurations. Global scope has no boundary.
The boundaries of all other non-reserved scopes of Admin-Local or
larger are administratively configured."

The admin-local Admin-Local scope must therefore be administratively configured.
In this document document, "administratively configured" does not imply
actions by a human beyond installing the here protocol specified protocol. herein.
"Administratively configured" means an automatic derivation as
described in this document.

This draft document describes an automated policy for the Multicast
Protocol for Low power Low-Power and Lossy Networks (MPL) [[I-D.ietf-roll-trickle-mcast] [RFC7731] forwarding
of multicast messages with admin-local Admin-Local scope within a border router
that lies between a network running MPL and some other network. This wish
policy is in line with the autonomous networking ideas presented in [I-D.irtf-nmrg-an-gap-analysis].
[RFC7576].

The realm-local Realm-Local multicast address is currently used by MPL to
propagate the multicast message to all receivers and forwarders
within a mesh network. The multicast propagation is limited to a
mesh network with a common layer-2. Layer 2. For example, a LoWPAN Low-Power
Wireless Personal Area Network (LoWPAN) is defined by an
IEEE 802.15.4 layer-2 Layer 2 mesh network, composed of all connected nodes
sharing the same Personal Area Network (PAN) ID [RFC4944].

The network concept differs between mesh network technologies. This
document maps a general network identifier to the specific network
identifier of existing mesh technologies.

In current and projected deployments, there is a requirement to
propagate a multicast message beyond the boundaries of the mesh
network it originated in which it originated, independent of the mesh technology.

Consider the case where propagation over two mesh networks is
required. In one example, each mesh network has a border router and
the two border routers are connected with an Ethernet link. In
another example example, each mesh network is connected to its own network
interface connected to the same border router. In both cases, an
admin-local
Admin-Local multicast message originating in one network needs to
propagate into the other mesh network. The boundary of the admin-
local
Admin-Local scope is administratively configured.

This document describes an "MPL4 router" that forwards MPL messages
with a multicast address with admin-local Admin-Local scope to all interfaces
connected to links that connect to other MPL enabled MPL-enabled interfaces. The
MPL4 router enables all its interfaces for MPL messages and allocates
an additional variable MPL_BLOCKED variable, MPL_BLOCKED, that permits(forbids) either permits or forbids
the forwarding of MPL messages.

The MPL4 router uses the following technique to establish over which
links MPL4 messages must be forwarded. forwarded: The MPL4 router listens on its
interfaces for the arrival of MPL4 messages. When MPL4 messages
arrive over an interface, the MPL4 router includes records this interface to in
the set of interfaces over which incoming MPL4 messages are
forwarded. Regularly, the The MPL4 router regularly sends MPL4 messages over its
interfaces to provoke the return of MPL4 messages to maintain or
remove the interfaces in/from the set
of forwarding interfaces.

It is expected that the private network of an organization, building,
or home, home is connected to the Internet via the edge routers provided by
an ISP. The intention is that MPL messages with multicast addresses
of admin-local Admin-Local scope are freely forwarded within the private network, network
but are never forwarded outside the private network by edge routers.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

1.2. Terminology and Acronyms

This document uses terminology defined in
[I-D.ietf-roll-trickle-mcast] [RFC7731] and [RFC7346].
In addition, the following terms are used in this document:

o MPL4 refers to MPL4: MPL with admin-local Admin-Local scope 4.

o MPL4 message: an MPL DATA message Data Message with a destination multicast
address of scope 4.

o MPL4 zone: a convex zone of interconnected interfaces over which
MPL messages with admin-local Admin-Local scope propagate. A An MPL4 zone is
bounded by a zone as defined in [RFC4007].

o MPL4 router: automatically determines the MPL4 zone in which MPL
messages with admin-local Admin-Local scope can be propagated.

2. Network identifier Identifier

Links may have the concept of a channel, for example channel. For example, in wireless
networks
networks, such a channel is associated with a communication
frequency. Additionally, for some link technologies, several
networks can coexist using the same channel. For these link
technologies, a network identifier exists. The network identifier is
determined by the link technology specification. When no network
identifier exists for a given link, the network identifier has the
value "any".

2.1. IEEE 802.15.4

IPv6 over IEEE 802.15.4 is described in [RFC4944]. A LoWPAN is
composed of the nodes connected by an IEEE 802.15.4 mesh sharing the
same PAN ID. The PAN ID identifies a network in the IEEE 802.15.4
mesh. Several networks with different PAN IDs can coexist on the
same channel [IEEE802.15.4]. The PAN ID of an interface is defined
when the interface is enabled. The value of the network identifier
of an IEEE 802.15.4 link is the value of the PAN ID.

2.2. IEEE 802.11

IP over IEEE 802.11 is described in [RFC5416]. The Service Set
IDentifier
Identifier (SSID) identifies a network in the IEEE 802.11 link.
Several networks with different SSIDs can coexist on the same channel
[IEEE802.11]. The SSID of an interface is defined when the interface
is switched on. The value of the network identifier of a an IEEE
802.11 link is the value of the SSID.

2.3. ITU-T G.9959

IPv6 over ITU-T G.9959 is specified in [I-D.ietf-6lo-lowpanz]. [RFC7428]. The HomeID
identifies a network of connected nodes [G.9959]. Several HomeIDs
can coexist within communication range, but nodes adhering to a
network with a given HomeID cannot communicate with nodes adhering to
a network with a different HomeID. The value of the network
identifier of a G.9959 link is the value of the HomeID.

2.4. BLUETOOTH BLUETOOTH(R) Low Energy

IPv6 over BLUETOOTH Low Energy Bluetooth low energy (BTLE) is specified in
[I-D.ietf-6lo-btle]. [RFC7668]. The
medium is specified in [btle]. [BTLE]. BTLE does not know the concept of
multiple networks in one channel. The value of the network
identifier of a BTLE link is "any".

3. MPL4 router Router

The concept of an MPL4 router serves to automatically determine the
MPL4 zone in which MPL messages with a scope 4 multicast address can
propagate. The MPL4 router periodically executes an algorithm that
determines the presence of MPL interfaces Interfaces on the links connected to
its interfaces. When no MPL interfaces Interfaces are present on a given link,
the corresponding MPL interface Interface is signalled signaled as not being part of the
MPL4 zone.

3.1. MPL interface parameters Interface Parameters

One parameter is associated with every MPL interface Interface in the MPL4
router, and two parameters are associated with the behaviour behavior of the
MPL4 router as a whole.

o MPL_BLOCKED: Boolean value that indicates whether or not the
associated interface belongs to the MPL4 zone.

o MPL_CHECK_INT: integer Integer that indicates the time interval between
successive activations of the MPL4 router algorithm algorithm, in seconds.

o MPL_TO: integer Integer that indicates the interval in which MPL messages
are expected to be received received, in seconds.

3.2. Determination of MPL4 zone Zone

All interfaces of the MPL4 router MUST be associated with the
following
parameters coming from MPL protocol [I-D.ietf-roll-trickle-mcast]: parameters, as described in [RFC7731]:
PROACTIVE_FORWARDING, DATA_MESSAGE_IMIN, DATA_MESSAGE_IMAX,
DATA_MESSAGE_K, and DATA_MESSAGE_TIMER_EXPIRATIONS. At start-up Upon startup of
the MPL4 router, the parameters associated with all interfaces are
assigned the following values: PROACTIVE_FORWARDING = true, TRUE,
MPL_BLOCKED = false. All interfaces MUST subscribe to the multicast
addresses ALL_MPL_FORWARDERS scope 3 and scope 4.

The MPL4 router executes the following algorithm for each interface:

o With a frequency determined by the value of MPL_CHECK_INT, the
MPL4 router sends an MPL4 message on each interface with a header
that includes the MPL option [I-D.ietf-roll-trickle-mcast] and Option [RFC7731]; the message is sent to
multicast address ALL_MPL_FORWARDERS with scope 4.

o When When, within an interval determined by the value of MPL_TO no MPL
message is received, the value of MPL_BLOCKED is set to true. TRUE.

o At On reception of an MPL4 message with a multicast address with
scope 4, message, the value of MPL_BLOCKED of the
receiving interface is set to false.

This protocol leads to a state where for each interface MPL_BLOCKED
is set to false if and only if MPL enabled MPL-enabled interfaces are connected
to the link associated with the interface. When an MPL message is
submitted to an MPL-enabled interface -called A- called "Interface A" in the MPL
router, the Trickle algorithm [RFC6206] is activated to send the MPL
message. The MPL4 message with multicast address ALL_MPL_FORWARDERS
scope 4 is accepted by every interface connected to the link that has
subscribed to ALL_MPL_FORWARDERS with scope 4. On acceptance of the
MPL4 message by an interface -called B-, called "Interface B", the MPL4 message
is returned with Trickle over interface Interface B. Consequently, the MPL4
message is received by the originating interface Interface A, after which
MPL_BLOCKED is set to false.

When a new node is connected to the link, it can immediately send an
MPL4 message, or it can wait for the reception of an MPL4 message to
announce its intention to be part of the MPL4 zone.

4. Admin-Local policy

The Policy

This section starts with begins by specifying what types of multicast messages
arriving at an interface are legal. It continues with a description
of forwarding legal admin-local Admin-Local multicast messages over other MPL
interfaces.
Interfaces.

The policy for forwarding admin-local Admin-Local multicast messages
automatically to a an MPL interface Interface is specified as a function of the
state of the MPL interface Interface and the multicast message. The state of
the multicast message is determined by the presence of the MPL option
[I-D.ietf-roll-trickle-mcast] Option
[RFC7731] and the destination multicast address. The state of the
MPL interface Interface is determined by the subscribed multicast addresses,
the zone index [RFC4007], and the values of the PROACTIVE_FORWARDING
parameter and the MPL_BLOCKED parameter of the MPL interface. Interface.

When the zone is undefined or not enabled, all interfaces have the
same zone index.

4.1. Legal multicast messages Multicast Messages

Multicast messages can be created within the node by an application
or can arrive at an interface.

A multicast message created at a source (MPL seed) Seed) is legal when it
conforms to the properties described in section Section 9.1 of
[I-D.ietf-roll-trickle-mcast]. [RFC7731].

A multicast message received at a given interface is legal when:

o The message carries an MPL option Option (MPL message) and the incoming
MPL interface Interface is subscribed to the destination multicast address.

o The message does not carry an MPL option, the multicast address is
unequal to ALL_MPL_FORWARDERS scope 4 or scope 3, Option and the interface has
expressed interest to receive in receiving messages with the specified
multicast address via MLD Multicast Listener Discovery (MLD) [RFC3810]
or via IGMP [RFC3376]. The message was sent on forwarded according to PIM-DM
Protocol Independent Multicast - Dense Mode (PIM-DM) [RFC3973] or according to PIM-SM
Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601].

Illegal multicast messages are discarded.

4.2. Forwarding legal packets Legal Packets

A legal multicast message received at a given interface is assigned
the network identifier of the interface of the incoming link . link. A
message that is created within the node is assigned the network
identifier "any".

Two types of legal multicast messages are considered: considered in Section 4.1:
(1) MPL
messages, messages and (2) multicast messages which that do not carry the MPL
option.
Option.

4.2.1. MPL message Message

MPL messages are forwarded on MPL interfaces Interfaces using the Trickle
parameter values assigned to the MPL interface Interface according to the
following rules:

o Link-local Link-Local (scope 2) MPL messages are not forwarded.

o Realm-local Realm-Local (scope 3) MPL messages are forwarded on all MPL
interfaces that
Interfaces where all of the following are subscribed true:

* The multicast address to which the MPL Interface subscribes is
the same as the multicast address, have address of the MPL message.

* The zone index of the MPL Interface is the same as the zone index, and have PROACTIVE-FORWARDING
index of the MPL Interface on which the MPL message was
received.

* The MPL Interface has PROACTIVE_FORWARDING set to true,
and the TRUE.

* The assigned network identifier of the multicast MPL message is
identical to "any", or
the assigned network identifier of the MPL interface, or message is equal to
the
assigned network identifier of the multicast message is "any". MPL Interface.

o Admin-local Admin-Local (scope 4) MPL messages are forwarded on all MPL
interfaces
Interfaces that are subscribed to the same multicast address, have
the same zone index, have PROACTIVE-FORWARDING PROACTIVE_FORWARDING set to true, TRUE, and
have MPL_BLOCKED set to false.

o MPL messages that encapsulate a message with a multicast scope of
5 or higher MUST
encapsulate a message with the same multicast address without MPL
option. The are decapsulated message can be and forwarded over an the interface when
the interface is subscribed with MLD to the same multicast address. address of the
decapsulated message.

4.2.2. Multicast messages Messages without MPL option Option

Multicast messages without the MPL option Option are forwarded on MPL interfaces
Interfaces according to the following rules:

o Link-local Link-Local (scope 2) messages or realm-local 2), Realm-Local (scope 3) multicast
messages are not forwarded.

o Admin-local 3), and Admin-Local
(scope 4) multicast messages are encapsulated with a
header carrying the MPL option and are forwarded on al MPL
interfaces that are subscribed to the multicast address, have the
same zone index, have PROACTIVE_FORWARDING set to true, and have
MPL_BLOCKED set to false. not forwarded.

o Multicast messages with a multicast scope of 5 or higher are
encapsulated with a header carrying the MPL option and are
forwarded on al in an MPL interfaces that are subscribed to the
multicast address, have PROACTIVE_FORWARDING set to true, and have
MPL_BLOCKED set to false. In addition these messages follow the
Multicast forwarding rules message with destination address
ALL_MPL_FORWARDERS with scope 4. The resulting message is then
treated as specified by PIM [RFC3973],
[RFC4601] according to group specifications enabled by MLD
[RFC3810] or IGMP [RFC3376]. described in Section 4.2.1.

4.3. Encryption rules Rules

An incoming message protected at layer-2 Layer 2 MUST be subsequently re-
protected
re-protected at layer-2 Layer 2 at all outgoing interfaces. Incoming
messages are integrity checked and optionally decrypted at the
incoming interface at layer-2 Layer 2 using the keys and protection algorithm
appropriate to the incoming interface's network and are re-protected
at the outgoing interface using the keys and protection algorithm
appropriate to the outgoing interface's network. It may be necessary
to assess the relative levels of protection on the respective
interfaces and apply policy rules, rules -- for example example, to avoid
downgrading security where one network has a lower level of security
than another.

An incoming MPL4 messages which message that is not protected at layer-2 Layer 2 MUST NOT be
re-protected at layer-2 Layer 2 at all outgoing interfaces.

5. MPL domains Domains and zones Zones

An MPL domain Domain is a scope zone in which MPL interfaces Interfaces subscribe to
the same MPL Domain Address [I-D.ietf-roll-trickle-mcast]. [RFC7731]. In accordance with [RFC4007] [RFC4007],
a zone boundary passes through a node. For example, a small LLN
Low-Power and Lossy Network (LLN) node usually has one MPL mesh
interface which that is
enabled subscribed to the ALL_MPL_FORWARDERS multicast
address with a scope value of 3 (realm-local) (Realm-Local) [RFC7346]. The node
interface belongs to the zone zone, and the corresponding zone boundary
does not pass through this node. In the border router with MPL interfaces enabled
Interfaces subscribed to the multicast address ALL_MPL_FORWARDERS
with scope value 3, the zone
includes usually includes this single interface
and excludes all other interfaces. A notable exception is provided
by a node where MPL
interfaces Interfaces of the same technology share the same
network identifier. These interfaces belong to the same MPL4 zone
when the interfaces share the same zone index.

In an MPL4 router, every MPL interface Interface subscribes to the admin_local Admin-Local
ALL_MPL_FORWARDERS multicast address next in addition to the realm-local Realm-Local
ALL_MPL_FORWARDERS address.

Every interface that belongs to an MPL domain Domain that extends over
border routers MUST be subscribed to the admin-local Admin-Local
ALL_MPL_FORWARDERS address.

The MPL4 zone corresponding with the MPL multicast address
ALL_MPL_FORWARDERS with scope 4 (Admin-local) (Admin-Local) applies to border
routers with multiple interfaces, of which at least one interface is
MPL enabled and is subscribed to multicast address ALL_MPL_FORWARDERS
with scope 4. In a border router, all MPL enabled MPL-enabled interfaces which that
subscribe to the ALL_MPL_FORWARDERS address with scope 4 and for
which MPL_BLOCKED is false belong to the same MPL4 zone when the
interfaces share the same zone index.

MPL4 messages remain bounded within a zone as defined in [RFC4007].
Consequently, MPL4 messages cannot be routed between interfaces
belonging to different zones. When the concept of zone is unknown or
disabled in a router, all interfaces belong to the same zone. For
example, consider a router with 5 interfaces five interfaces, where interfaces Interfaces A
and B belong to zone 1 and interfaces C,D, Interfaces C, D, and E belong to zone 2.
MPL4 messages can be routed freely between interfaces Interfaces A and B, and
freely between C,D, Interfaces C, D, and E. However, a an MPL4 message
MUST NOT be routed from Interface A to interface Interface D.

6. Default parameter values Parameter Values

Three parameters are created in by this draft. document. Their values are
related to the Trickle timer intervals.

o MPL_TO = DATA_MESSAGE_IMAX times 2. Which 2, which leaves the enough time to
receive the second response message.

o MPL_CHECK_INT = 5 minutes. Which minutes, which means that a reaction to a
network
malfunctioning malfunction happens within 5 minutes.

o MPL_BLOCKED = true. Which TRUE, which means that the interface has not
received MPL-enabled messages to include the interface to in the
MPL4 zone.

7. Security Considerations

The security considerations of [I-D.ietf-roll-trickle-mcast] [RFC7731] also apply to MPL4 routers.

The sending of MPL4 messages by a malicious node can have unwanted
consequences
consequences, as explained with by the following example. It is not
unusual for a wired (e.g. ethernet) (e.g., Ethernet) link to be used between two
floors or sections of an LLN, as radio propagation through reinforced
concrete is generally poor. The MPL4 zone can thus envelop multiple
routers,
meshes meshes, and links. It is possible that a malicious node connects
could connect to a wired link, link on which no MPL enabled MPL-enabled nodes are
foreseen. In this example configuration, the malicious node can send
MPL4 messages to the MPL4 router interfaces. When nothing is done,
the MPL4 routers will consequently distribute MPL4 messages from one
mesh over the wired link to the next mesh, although the wired link
was not expected to transport MPL4 messages.

To understand the consequences of this unwanted behaviour, behavior, the
following cases should be distinguished:

o The source mesh uses layer-2 Layer 2 encryption.

o The MPL4 router can be managed.

The four possible combinations are discussed below:

Layer-2

Layer 2 unsecured, Router router unmanaged: In this case case, MPL4 messages are
freely distributed over meshes and links which that are interconnected
by MPL4 routers within a zone. The MPL enabled MPL-enabled (malicious) nodes
can read all MPL4 messages and distribute MPL4 messages over a
network limited by a zone. This situation can be acceptable for
an isolated network, network within a clearly defined space, where the
connection of nodes can be tightly controlled. A completely wired
LLN --
LLN, e.g., such as is seen in BACnet -- (a protocol for building
automation and control networks) [BACnet] is an example of an
unencrypted LLN which that would be considered physically secure.

Layer-2

Layer 2 secured, Router router unmanaged: In this case case, MPL4 messages are
freely distributed over meshes and links, which links that are interconnected
by MPL4 routers within a zone. Following the rules of
Section 4.3, the MPL4 enabled MPL4-enabled (malicious) nodes can not cannot read the
MPL4 messages messages, and MPL4 messages sent by the malicious node are
not accepted by other nodes. This situation is acceptable for a
home network or managed network extending over precisely one zone,
occupying a clearly defined physical space, where ease of
installation is important. In such a network, the presence of the
malicious node is not different from any other malicious node,
which node that
tries to send messages over layer-2 Layer 2 protected links. Because the
network occupies exactly one zone, the MPL4 message distribution
cannot be extended outside the network.

Layer-2

Layer 2 unsecured, Router router managed: In this case case, the distribution of
MPL4 messages over MPL4 router interfaces can be limited to those
interfaces,
interfaces for which a manager has enabled for MPL and MPL, as well as a set
of multicast addresses. The malicious node cannot extend the
distribution of MPL4 messages over unwanted interfaces. It is
important that the handling of the interfaces by the manager is
protected. However, MPL4 messages sent over the mesh can be
interpreted by malicious
nodes nodes, and malicious messages can be
injected into the set of meshes and links which that are connected by
the MPL4 routers for which the manager enabled the interfaces.
This situation can be practical for interconnected links and meshes, which
meshes that are connected to a LAN over a limited period, period -- for example
example, during installation of the interconnected meshes and
links.

Layer-2

Layer 2 secured, Router router managed: In this case case, the distribution of
MPL4 messages over MPL4 router interfaces can be limited to those
interfaces,
interfaces for which a manager has enabled for MPL and MPL, as well as a set
of multicast addresses. Following the rules of Section 4.3, the
malicious node cannot extend the distribution of MPL4 messages
over unwanted
interfaces interfaces, and MPL4 messages sent by the malicious
node are not accepted by other nodes. It is important that the
handling of the interfaces by the manager is protected. The MPL enabled
MPL-enabled (malicious) nodes can not cannot read the MPL4 messages messages, and
MPL4 messages sent by the malicious node are not accepted by other
nodes.
Dependent Depending on the number of managed interfaces, the network
can progressively pass from auto-configured autoconfigured to fully
administratively controlled.

8. IANA Considerations

No considerations for IANA are formulated in this document.

9. Acknowledgements

This document reflects discussions and remarks from several
individuals including (in alphabetical order): Scott Bradner, Esko
Dijk, Adrian Farrel, Matthew Gillmore, Joel Halpern, Steve Hanna,
Michael Richardson, and Pascal Thubert.

10. Change log

When published as a RFC, this section needs to be removed.

Version 03 - version 01

o Explained MPL acronym

o Added relation of MPL4 zone to zone as defined in [RFC4007]

o Added a section on encryption rules

o Revised and clarified the security considerations

Version 00 - version 01

o Default parameter values declared
o Security section extended

o scope 5 of higher messages specified

o messages with address ALL_MPL_FORWARDERS are not allowed from
outside zone

Changes from personal version to WG version-00.

o Aligned terminology with MPL terminology
[I-D.ietf-roll-trickle-mcast]

o Text on MPL4 router included

11. References

11.1.

8.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997. 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC3810] Vida, R. R., Ed., and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004. 2004,
<http://www.rfc-editor.org/info/rfc3810>.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291,
February 2006. 2006, <http://www.rfc-editor.org/info/rfc4291>.

[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007. 2007,
<http://www.rfc-editor.org/info/rfc4944>.

[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002. 2002,
<http://www.rfc-editor.org/info/rfc3376>.

[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
DOI 10.17487/RFC4007, March 2005. 2005,
<http://www.rfc-editor.org/info/rfc4007>.

[RFC5416] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley,
Ed., "Control and Provisioning of Wireless Access Points
(CAPWAP) Protocol Binding for IEEE 802.11", RFC 5416,
DOI 10.17487/RFC5416, March 2009. 2009,
<http://www.rfc-editor.org/info/rfc5416>.

[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
March 2011. 2011, <http://www.rfc-editor.org/info/rfc6206>.

[RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,
DOI 10.17487/RFC7346, August 2014.

[I-D.ietf-roll-trickle-mcast] 2014,
<http://www.rfc-editor.org/info/rfc7346>.

[RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low power Low-Power
and Lossy Networks (MPL)", draft-ietf-roll-trickle-
mcast-11 (work in progress), November 2014. RFC 7731, DOI 10.17487/RFC7731,
February 2016, <http://www.rfc-editor.org/info/rfc7731>.

[IEEE802.15.4]
IEEE, "IEEE 802.15.4 - Standard for Local and metropolitan area
networks -- Part
networks--Part 15.4: Low-Rate Wireless Personal Area
Networks", <IEEE Standard 802.15.4>.
Networks (LR-WPANs)", IEEE 802.15.4,
DOI 10.1109/ieeestd.2011.6012487,
<http://ieeexplore.ieee.org/servlet/
opac?punumber=6012485>.

[IEEE802.11]
IEEE, "IEEE 802.11 - Standard for Information technology--
Telecommunications and information exchange between
systems Local and metropolitan area networks -- networks--Specific
requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", <IEEE Standard
802.11>.
IEEE 802.11-2012, DOI 10.1109/ieeestd.2012.6178212,
<http://ieeexplore.ieee.org/servlet/
opac?punumber=6178209>.

[G.9959] "ITU-T G.9959 Short International Telecommunication Union, "Short range
narrow-band digital radiocommunication transceivers - PHY PHY,
MAC, SAR and MAC LLC layer specifications", <ITU-T G.9959>.

[btle] "BLUETOOTH ITU-T
Recommendation G.9959, January 2015,
<http://www.itu.int/rec/T-REC-G.9959>.

[BTLE] Bluetooth Special Interest Group, "Bluetooth Core
Specification Version 4.0", <BLUETOOTH low
energy>.

11.2. 4.1", December 2013,
<https://www.bluetooth.org/en-us/specification/
adopted-specifications>.

8.2. Informative References

[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973,
January 2005. 2005, <http://www.rfc-editor.org/info/rfc3973>.

[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601,
DOI 10.17487/RFC4601, August 2006.

[I-D.irtf-nmrg-an-gap-analysis] 2006,
<http://www.rfc-editor.org/info/rfc4601>.

[RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "Gap "General Gap
Analysis for Autonomic Networking", draft-irtf-nmrg-an-gap-
analysis-03 (work in progress), December 2014.

[I-D.ietf-6lo-lowpanz] RFC 7576,
DOI 10.17487/RFC7576, June 2015,
<http://www.rfc-editor.org/info/rfc7576>.

[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 packets Packets
over ITU-T G.9959 Networks", draft-ietf-6lo-lowpanz-08
(work in progress), October 2014.

[I-D.ietf-6lo-btle] RFC 7428,
DOI 10.17487/RFC7428, February 2015,
<http://www.rfc-editor.org/info/rfc7428>.

[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets "IPv6 over BLUETOOTH(R) Low
Energy", draft-ietf-6lo-btle-07
(work in progress), January 2015. RFC 7668, DOI 10.17487/RFC7668, October 2015,
<http://www.rfc-editor.org/info/rfc7668>.

[BACnet] "BACnet Webpage", <http://www.bacnet.org>.

Acknowledgements

This document reflects discussions and remarks from several
individuals, including (in alphabetical order) Scott Bradner, Esko
Dijk, Adrian Farrel, Matthew Gillmore, Joel Halpern, Steve Hanna,
Michael Richardson, and Pascal Thubert.

Authors' Addresses

Peter van der Stok
Consultant

Email: consultancy@vanderstok.org

Robert Cragie
Gridmerge
ARM Ltd.
110 Fulbourn Road
Cambridge CB1 9NJ
United Kingdom

Email: robert.cragie@gridmerge.com robert.cragie@arm.com