draft-ietf-roll-admin-local-policy-02.txt   draft-ietf-roll-admin-local-policy-03.txt 
roll P. van der Stok roll P. van der Stok
Internet-Draft Consultant Internet-Draft Consultant
Intended status: Informational R. Cragie Intended status: Informational R. Cragie
Expires: May 28, 2015 Gridmerge Expires: August 10, 2015 Gridmerge
November 24, 2014 February 6, 2015
MPL forwarder policy for multicast with admin-local scope Forwarder policy for multicast with admin-local scope in the Multicast
draft-ietf-roll-admin-local-policy-02 Protocol for Low power and Lossy Networks (MPL)
draft-ietf-roll-admin-local-policy-03
Abstract Abstract
The purpose of this document is to specify an automated policy for The purpose of this document is to specify an automated policy for
the routing of MPL multicast messages with admin-local scope in a the routing of Multicast Protocol for Low power and Lossy Networks
border router. (MPL) multicast messages with admin-local scope in a border router.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 28, 2015. This Internet-Draft will expire on August 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology and Acronyms . . . . . . . . . . . . . . . . 3 1.2. Terminology and Acronyms . . . . . . . . . . . . . . . . 4
2. Network identifier . . . . . . . . . . . . . . . . . . . . . 4 2. Network identifier . . . . . . . . . . . . . . . . . . . . . 4
2.1. IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . 4 2.1. IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . 4
2.2. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 4 2.3. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 5
2.4. BLUETOOTH Low Energy . . . . . . . . . . . . . . . . . . 5 2.4. BLUETOOTH Low Energy . . . . . . . . . . . . . . . . . . 5
3. MPL4 router . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. MPL4 router . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. MPL interface parameters . . . . . . . . . . . . . . . . 5 3.1. MPL interface parameters . . . . . . . . . . . . . . . . 5
3.2. Determination of MPL zone . . . . . . . . . . . . . . . . 5 3.2. Determination of MPL4 zone . . . . . . . . . . . . . . . 6
4. Admin-Local policy . . . . . . . . . . . . . . . . . . . . . 6 4. Admin-Local policy . . . . . . . . . . . . . . . . . . . . . 7
4.1. Legal multicast messages . . . . . . . . . . . . . . . . 6 4.1. Legal multicast messages . . . . . . . . . . . . . . . . 7
4.2. Forwarding legal packets . . . . . . . . . . . . . . . . 7 4.2. Forwarding legal packets . . . . . . . . . . . . . . . . 7
4.2.1. MPL message . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. MPL message . . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Multicast messages without MPL option . . . . . . . . 8 4.2.2. Multicast messages without MPL option . . . . . . . . 8
5. MPL domains and zones . . . . . . . . . . . . . . . . . . . . 8 4.3. Encryption rules . . . . . . . . . . . . . . . . . . . . 9
6. Default parameter values . . . . . . . . . . . . . . . . . . 9 5. MPL domains and zones . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Default parameter values . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Multicast scopes are defined in [RFC4291]. The [RFC7346] extends the Multicast scopes are defined in [RFC4291]. The [RFC7346] extends the
scope definition with the text: scope definition with the text:
"Interface-Local, Link-Local, and Realm-Local scope boundaries are "Interface-Local, Link-Local, and Realm-Local scope boundaries are
automatically derived from physical connectivity or other, non- automatically derived from physical connectivity or other, non-
multicast related configuration. Global scope has no boundary. The multicast related configuration. Global scope has no boundary. The
boundaries of all other non-reserved scopes of Admin-Local or larger boundaries of all other non-reserved scopes of Admin-Local or larger
are administratively configured." are administratively configured."
The admin-local scope must therefore be administratively configured. The admin-local scope must therefore be administratively configured.
This draft describes an automated policy for the MPL forwarding of In this document "administratively configured" does not imply actions
multicast messages with admin-local scope within a border router. by a human beyond installing the here specified protocol.
This wish is in line with the autonomous networking ideas presented "Administratively configured" means an automatic derivation as
in [I-D.irtf-nmrg-an-gap-analysis]. described in this document.
This draft describes an automated policy for the Multicast Protocol
for Low power and Lossy Networks (MPL) [[I-D.ietf-roll-trickle-mcast]
forwarding of multicast messages with admin-local scope within a
border router that lies between a network running MPL and some other
network. This wish is in line with the autonomous networking ideas
presented in [I-D.irtf-nmrg-an-gap-analysis].
The realm-local multicast address is currently used by MPL to The realm-local multicast address is currently used by MPL to
propagate the multicast message to all receivers and forwarders propagate the multicast message to all receivers and forwarders
within a mesh network. The multicast propagation is limited to a within a mesh network. The multicast propagation is limited to a
mesh network with a common layer-2. For example, a LoWPAN is defined mesh network with a common layer-2. For example, a LoWPAN is defined
by an IEEE 802.15.4 layer-2 mesh network, composed of all connected by an IEEE 802.15.4 layer-2 mesh network, composed of all connected
nodes sharing the same PAN ID [RFC4944]. nodes sharing the same Personal Area Network (PAN) ID [RFC4944].
The network concept differs between mesh network technologies. This The network concept differs between mesh network technologies. This
document maps a general network identifier to the specific network document maps a general network identifier to the specific network
identifier of existing mesh technologies. identifier of existing mesh technologies.
In current and projected deployments, there is a requirement to In current and projected deployments, there is a requirement to
propagate a multicast message beyond the boundaries of the mesh propagate a multicast message beyond the boundaries of the mesh
network it originated in independent of the mesh technology. network it originated in independent of the mesh technology.
Consider the case where propagation over two mesh networks is Consider the case where propagation over two mesh networks is
skipping to change at page 3, line 33 skipping to change at page 3, line 43
propagate into the other mesh network. The boundary of the admin- propagate into the other mesh network. The boundary of the admin-
local scope is administratively configured. local scope is administratively configured.
This document describes an "MPL4 router" that forwards MPL messages This document describes an "MPL4 router" that forwards MPL messages
with a multicast address with admin-local scope to all interfaces with a multicast address with admin-local scope to all interfaces
connected to links that connect to other MPL enabled interfaces. The connected to links that connect to other MPL enabled interfaces. The
MPL4 router enables all its interfaces for MPL messages and allocates MPL4 router enables all its interfaces for MPL messages and allocates
an additional variable MPL_BLOCKED that permits(forbids) the an additional variable MPL_BLOCKED that permits(forbids) the
forwarding of MPL messages. forwarding of MPL messages.
It is expected that the network of an organization, building, or The MPL4 router uses the following technique to establish over which
home, is connected to the Internet via the edge routers provided by links MPL4 messages must be forwarded. The MPL4 router listens on
an ISP. The intention is that within the network of an organization, its interfaces for arrival of MPL4 messages. When MPL4 messages
building, or home, MPL messages with multicast addresses of admin- arrive over an interface, the MPL4 router includes this interface to
local scope are freely forwarded but are never forwarded to edge the set of interfaces over which incoming MPL4 messages are
routers which MUST NOT enable their interfaces for MPL messages. forwarded. Regularly, the MPL4 router 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, 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 scope are freely forwarded within the
private network, but are never forwarded outside the private network
by edge routers.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terminology and Acronyms 1.2. Terminology and Acronyms
This document uses terminology defined in This document uses terminology defined in
[I-D.ietf-roll-trickle-mcast] and [RFC7346]. In addition, the [I-D.ietf-roll-trickle-mcast] and [RFC7346]. In addition, the
following terms are used in this document: following terms are used in this document:
o MPL4 refers to MPL with admin-local scope 4.
o MPL4 message: an MPL DATA message with a destination multicast o MPL4 message: an MPL DATA message with a destination multicast
address of scope 4. address of scope 4.
o MPL4 router: automatically determines the zone in which MPL
messages with admin-local scope can be propagated.
o MPL4 zone: a convex zone of interconnected interfaces over which o MPL4 zone: a convex zone of interconnected interfaces over which
MPL messages with admin-local scope propagate. [RFC4007]. MPL messages with admin-local scope propagate. A 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 scope can be propagated.
2. Network identifier 2. Network identifier
Links may have the concept of a channel, for example in wireless Links may have the concept of a channel, for example in wireless
networks such a channel is associated with a communication frequency. networks such a channel is associated with a communication frequency.
Additionally, for some link technologies, several networks can Additionally, for some link technologies, several networks can
coexist using the same channel. For these link technologies, a coexist using the same channel. For these link technologies, a
network identifier exists. The network identifier is determined by network identifier exists. The network identifier is determined by
the link technology specification. When no network identifier exists the link technology specification. When no network identifier exists
for a given link, the network identifier has the value "undefined". for a given link, the network identifier has the value "any".
2.1. IEEE 802.15.4 2.1. IEEE 802.15.4
IPv6 over IEEE 802.15.4 is described in [RFC4944]. A LoWPAN is 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 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 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 mesh. Several networks with different PAN IDs can coexist on the
same channel [IEEE802.15.4]. The PAN ID of an interface is defined same channel [IEEE802.15.4]. The PAN ID of an interface is defined
when the interface is enabled. The value of the network identifier 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. of an IEEE 802.15.4 link is the value of the PAN ID.
2.2. IEEE 802.11 2.2. IEEE 802.11
IP over IEEE 802.11 is described in [RFC5416]. The SSID identifies a IP over IEEE 802.11 is described in [RFC5416]. The Service Set
network in the IEEE 802.11 link. Several networks with different IDentifier (SSID) identifies a network in the IEEE 802.11 link.
SSIDs can coexist on the same channel [IEEE802.11]. The SSID of an Several networks with different SSIDs can coexist on the same channel
interface is defined when the interface is switched on. The value of [IEEE802.11]. The SSID of an interface is defined when the interface
the network identifier of a IEEE 802.11 link is the value of the is switched on. The value of the network identifier of a IEEE 802.11
SSID. link is the value of the SSID.
2.3. ITU-T G.9959 2.3. ITU-T G.9959
IPv6 over ITU-T G.9959 is specified in [I-D.ietf-6lo-lowpanz]. The IPv6 over ITU-T G.9959 is specified in [I-D.ietf-6lo-lowpanz]. The
HomeID identifies a network of connected nodes [G.9959]. Several HomeID identifies a network of connected nodes [G.9959]. Several
HomeIDs can coexist within communication range, but nodes adhering to HomeIDs can coexist within communication range, but nodes adhering to
a network with a given HomeID cannot communicate with nodes adhering a network with a given HomeID cannot communicate with nodes adhering
to a network with a different HomeID. The value of the network to a network with a different HomeID. The value of the network
identifier of a G.9959 link is the value of the HomeID. identifier of a G.9959 link is the value of the HomeID.
2.4. BLUETOOTH Low Energy 2.4. BLUETOOTH Low Energy
IPv6 over BLUETOOTH Low Energy (BTLE) is specified in IPv6 over BLUETOOTH Low Energy (BTLE) is specified in
[I-D.ietf-6lo-btle]. The medium is specified in [btle]. [I-D.ietf-6lo-btle]. The medium is specified in [btle]. BTLE does
not know the concept of multiple networks in one channel. The value
BTLE does not know the concept of multiple networks in one channel. of the network identifier of a BTLE link is "any".
The value of the network identifier of a BTLE link is "any".
3. MPL4 router 3. MPL4 router
The concept of an MPL4 router serves to automatically determine the The concept of an MPL4 router serves to automatically determine the
zone in which MPL messages with an scope 4 multicast address can MPL4 zone in which MPL messages with a scope 4 multicast address can
propagate. The MPL4 router periodically executes an algorithm that propagate. The MPL4 router periodically executes an algorithm that
determines the presence of MPL interfaces on the links connected to determines the presence of MPL interfaces on the links connected to
its interfaces. When no MPL interfaces are present on a given link, its interfaces. When no MPL interfaces are present on a given link,
the corresponding MPL interface is signalled as not being part of the the corresponding MPL interface is signalled as not being part of the
MPL zone. MPL4 zone.
3.1. MPL interface parameters 3.1. MPL interface parameters
One parameter is associated with every MPL interface in the MPL4 One parameter is associated with every MPL interface in the MPL4
router, and two parameters are associated with the behaviour of the router, and two parameters are associated with the behaviour of the
MPL4 router as a whole. MPL4 router as a whole.
o MPL_BLOCKED: Boolean value that indicates whether the associated o MPL_BLOCKED: Boolean value that indicates whether the associated
interface belongs to the MPL zone. interface belongs to the MPL4 zone.
o MPL_CHECK_INT: integer that indicates the time interval between o MPL_CHECK_INT: integer that indicates the time interval between
successive activations of the MPL4 router algorithm in seconds. successive activations of the MPL4 router algorithm in seconds.
o MPL_TO: integer that indicates the interval in which MPL messages o MPL_TO: integer that indicates the interval in which MPL messages
are expected in seconds. are expected to be received in seconds.
3.2. Determination of MPL zone 3.2. Determination of MPL4 zone
All interfaces of the MPL4 router MUST be associated with following All interfaces of the MPL4 router MUST be associated with following
parameters coming from MPL protocol [I-D.ietf-roll-trickle-mcast]: parameters coming from MPL protocol [I-D.ietf-roll-trickle-mcast]:
PROACTIVE_FORWARDING, DATA_MESSAGE_IMIN, DATA_MESSAGE_IMAX, PROACTIVE_FORWARDING, DATA_MESSAGE_IMIN, DATA_MESSAGE_IMAX,
DATA_MESSAGE_K, DATA_MESSAGE_TIMER_EXPIRATIONS. At start-up of the DATA_MESSAGE_K, DATA_MESSAGE_TIMER_EXPIRATIONS. At start-up of the
MPL4 router, the parameters associated with all interfaces are MPL4 router, the parameters associated with all interfaces are
assigned the following values: PROACTIVE_FORWARDING = true, assigned the following values: PROACTIVE_FORWARDING = true,
MPL_BLOCKED = false. All interfaces MUST subscribe to the multicast MPL_BLOCKED = false. All interfaces MUST subscribe to the multicast
addresses ALL_MPL_FORWARDERS scope 3 and scope 4. addresses ALL_MPL_FORWARDERS scope 3 and scope 4.
The MPL4 router executes the following algorithm for each interface: The MPL4 router executes the following algorithm for each interface:
o With a frequency determined by the value of MPL_CHECK_INT, the 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 MPL4 router sends an MPL4 message on each interface with a header
that includes the MPL option and is sent to multicast address that includes the MPL option [I-D.ietf-roll-trickle-mcast] and is
ALL_MPL_FORWARDERS with scope 4. sent to multicast address ALL_MPL_FORWARDERS with scope 4.
o When within an interval determined by the value of MPL_TO no MPL o 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. message is received, the value of MPL_BLOCKED is set to true.
o At reception of an MPL4 message with a multicast address with o At reception of an MPL4 message with a multicast address with
scope 4, the value of MPL_BLOCKED of the receiving interface is scope 4, the value of MPL_BLOCKED of the receiving interface is
set to false. set to false.
This protocol leads to a state where for each interface MPL_BLOCKED This protocol leads to a state where for each interface MPL_BLOCKED
is set to false if and only if MPL enabled interfaces are connected is set to false if and only if MPL enabled interfaces are connected
to the link associated with the interface. When an MPL message is to the link associated with the interface. When an MPL message is
submitted to an MPL-enabled interface -called A- in the MPL router, submitted to an MPL-enabled interface -called A- in the MPL router,
the TRICKLE algorithm is activated to send the MPL message. The MPL4 the Trickle algorithm [RFC6206] is activated to send the MPL message.
message with multicast address ALL_MPL_FORWARDERS scope 4 is accepted The MPL4 message with multicast address ALL_MPL_FORWARDERS scope 4 is
by every interface connected to the link that has subscribed to accepted by every interface connected to the link that has subscribed
ALL_MPL_FORWARDERS with scope 4. On acceptance of the MPL4 message to ALL_MPL_FORWARDERS with scope 4. On acceptance of the MPL4
by an interface -called B-, the MPL4 message is returned with Trickle message by an interface -called B-, the MPL4 message is returned with
over interface B. Consequently, the MPL4 message is received by the Trickle over interface B. Consequently, the MPL4 message is received
originating interface A, after which MPL_BLOCKED is set to false. by the originating interface A, after which MPL_BLOCKED is set to
false.
When a new node is connected to the link, it can immediately send an When a new node is connected to the link, it can immediately send an
MPL4 message, or can wait for the reception of an MPL4 message to MPL4 message, or can wait for the reception of an MPL4 message to
announce its intention to be part of the MPL zone. announce its intention to be part of the MPL4 zone.
4. Admin-Local policy 4. Admin-Local policy
The section starts with specifying what multicast messages arriving The section starts with specifying what multicast messages arriving
at an interface are legal. It continues with a description of at an interface are legal. It continues with a description of
forwarding legal admin-local multicast messages over other MPL forwarding legal admin-local multicast messages over other MPL
interfaces. interfaces.
The policy for forwarding admin-local multicast messages The policy for forwarding admin-local multicast messages
automatically to a MPL interface is specified as function of the automatically to a MPL interface is specified as function of the
state of the MPL interface and the multicast message. The state of state of the MPL interface and the multicast message. The state of
the multicast message is determined by the presence of the MPL option the multicast message is determined by the presence of the MPL option
and the destination multicast address. The state of the MPL [I-D.ietf-roll-trickle-mcast] and the destination multicast address.
interface is determined by the subscribed multicast addresses, and The state of the MPL interface is determined by the subscribed
the values of the PROACTIVE_FORWARDING parameter and the MPL_BLOCKED multicast addresses, the zone index [RFC4007], and the values of the
parameter of the MPL interface. PROACTIVE_FORWARDING parameter and the MPL_BLOCKED parameter of the
MPL interface.
When zone is undefined or not enabled, all interfaces have the same
zone index.
4.1. Legal multicast messages 4.1. Legal multicast messages
Multicast messages can be created within the node by an application Multicast messages can be created within the node by an application
or can arrive at an interface. or can arrive at an interface.
A multicast message created at a source (MPL seed) is legal when it A multicast message created at a source (MPL seed) is legal when it
conforms to the properties described in section 9.1 of conforms to the properties described in section 9.1 of
[I-D.ietf-roll-trickle-mcast]. [I-D.ietf-roll-trickle-mcast].
skipping to change at page 7, line 43 skipping to change at page 8, line 20
4.2.1. MPL message 4.2.1. MPL message
MPL messages are forwarded on MPL interfaces using the Trickle MPL messages are forwarded on MPL interfaces using the Trickle
parameter values assigned to the MPL interface according to the parameter values assigned to the MPL interface according to the
following rules: following rules:
o Link-local (scope 2) MPL messages are not forwarded. o Link-local (scope 2) MPL messages are not forwarded.
o Realm-local (scope 3) MPL messages are forwarded on all MPL o Realm-local (scope 3) MPL messages are forwarded on all MPL
interfaces that are subscribed to the same multicast address and interfaces that are subscribed to the same multicast address, have
have PROACTIVE-FORWARDING set to true, and the assigned network the same zone index, and have PROACTIVE-FORWARDING set to true,
identifier of the multicast message is identical to the network and the assigned network identifier of the multicast message is
identifier of the MPL interface, or the assigned network identical to the network identifier of the MPL interface, or the
identifier of the multicast message is "any". assigned network identifier of the multicast message is "any".
o Admin-local (scope 4) MPL messages are forwarded on all MPL o Admin-local (scope 4) MPL messages are forwarded on all MPL
interfaces that are subscribed to the same multicast address, have interfaces that are subscribed to the same multicast address, have
PROACTIVE-FORWARDING set to true, and have MPL_BLOCKED set to the same zone index, have PROACTIVE-FORWARDING set to true, and
false. have MPL_BLOCKED set to false.
o MPL messages with a multicast scope of 5 or higher MUST o MPL messages with a multicast scope of 5 or higher MUST
encapsulate a message with the same multicast address without MPL encapsulate a message with the same multicast address without MPL
option. The decapsulated message can be forwarded over an option. The decapsulated message can be forwarded over an
interface when the interface is subscribed with MLD to the same interface when the interface is subscribed with MLD to the same
multicast address. multicast address.
4.2.2. Multicast messages without MPL option 4.2.2. Multicast messages without MPL option
Multicast messages without MPL option are forwarded on MPL interfaces Multicast messages without MPL option are forwarded on MPL interfaces
according to the following rules: according to the following rules:
o Link-local (scope 2) messages or realm-local (scope 3) multicast o Link-local (scope 2) messages or realm-local (scope 3) multicast
messages are not forwarded. messages are not forwarded.
o Admin-local (scope 4) multicast messages are encapsulated with a o Admin-local (scope 4) multicast messages are encapsulated with a
header carrying the MPL option and are forwarded on al MPL header carrying the MPL option and are forwarded on al MPL
interfaces that are subscribed to the multicast address, have interfaces that are subscribed to the multicast address, have the
PROACTIVE_FORWARDING set to true, and have MPL_BLOCKED set to same zone index, have PROACTIVE_FORWARDING set to true, and have
false. MPL_BLOCKED set to false.
o Multicast messages with a multicast scope of 5 or higher are o Multicast messages with a multicast scope of 5 or higher are
encapsulated with a header carrying the MPL option and are encapsulated with a header carrying the MPL option and are
forwarded on al MPL interfaces that are subscribed to the forwarded on al MPL interfaces that are subscribed to the
multicast address, have PROACTIVE_FORWARDING set to true, and have multicast address, have PROACTIVE_FORWARDING set to true, and have
MPL_BLOCKED set to false. In addition these messages follow the MPL_BLOCKED set to false. In addition these messages follow the
Multicast forwarding rules as specified by PIM [RFC3973], Multicast forwarding rules as specified by PIM [RFC3973],
[RFC4601] according to group specifications enabled by MLD [RFC4601] according to group specifications enabled by MLD
[RFC3810] or IGMP [RFC3376]. [RFC3810] or IGMP [RFC3376].
4.3. Encryption rules
An incoming message protected at layer-2 MUST be subsequently re-
protected at layer-2 at all outgoing interfaces. Incoming messages
are integrity checked and optionally decrypted at the incoming
interface at layer-2 using the keys and protection algorithm
appropriate to the incoming interface's network and 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, for example to avoid downgrading
security where one network has a lower level of security than
another.
An incoming MPL4 messages which is not protected at layer-2 MUST NOT
be re-protected at layer-2 at all outgoing interfaces.
5. MPL domains and zones 5. MPL domains and zones
An MPL domain is a scope zone in which MPL interfaces subscribe to An MPL domain is a scope zone in which MPL interfaces subscribe to
the same MPL Domain Address [I-D.ietf-roll-trickle-mcast]. In the same MPL Domain Address [I-D.ietf-roll-trickle-mcast]. In
accordance with [RFC4007] a zone boundary passes through a node. For accordance with [RFC4007] a zone boundary passes through a node. For
example, a small LLN node usually has one MPL mesh interface which is example, a small LLN node usually has one MPL mesh interface which is
enabled to the ALL_MPL_FORWARDERS multicast address with a scope enabled to the ALL_MPL_FORWARDERS multicast address with a scope
value of 3 (realm-local) [RFC7346]. The node interface belongs to value of 3 (realm-local) [RFC7346]. The node interface belongs to
the zone and the corresponding zone boundary does not pass through the zone and the corresponding zone boundary does not pass through
this node. In the border router with MPL interfaces enabled to the this node. In the border router with MPL interfaces enabled to the
multicast address ALL_MPL_FORWARDERS with scope value 3, the zone multicast address ALL_MPL_FORWARDERS with scope value 3, the zone
includes usually this single interface and excludes all other includes usually this single interface and excludes all other
interfaces. A notable exception is provided by a node where MPL interfaces. A notable exception is provided by a node where MPL
interfaces of the same technology share the same network identifier. interfaces of the same technology share the same network identifier.
These interfaces belong to the same zone. These interfaces belong to the same MPL4 zone when the interfaces
share the same zone index.
In an MPL4 router, every MPL interface subscribes to the admin_local In an MPL4 router, every MPL interface subscribes to the admin_local
ALL_MPL_FORWARDERS multicast address next to the realm-local ALL_MPL_FORWARDERS multicast address next to the realm-local
ALL_MPL_FORWARDERS address. ALL_MPL_FORWARDERS address.
Every interface that belongs to an MPL domain that extends over Every interface that belongs to an MPL domain that extends over
border routers MUST be subscribed to the admin-local border routers MUST be subscribed to the admin-local
ALL_MPL_FORWARDERS address. ALL_MPL_FORWARDERS address.
The zone corresponding with the MPL multicast address The MPL4 zone corresponding with the MPL multicast address
ALL_MPL_FORWARDERS with scope 4 (Admin-local) applies to border ALL_MPL_FORWARDERS with scope 4 (Admin-local) applies to border
routers with multiple interfaces, of which at least one interface is routers with multiple interfaces, of which at least one interface is
MPL enabled and is subscribed to multicast address ALL_MPL_FORWARDERS MPL enabled and is subscribed to multicast address ALL_MPL_FORWARDERS
with scope 4. In a border router, all MPL enabled interfaces which with scope 4. In a border router, all MPL enabled interfaces which
subscribe to the ALL_MPL_FORWARDERS address with scope 4 and for subscribe to the ALL_MPL_FORWARDERS address with scope 4 and for
which MPL_BLOCKED is false belong to the same zone. 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 where interfaces A and B
belong to zone 1 and interfaces C,D, and E belong to zone 2. MPL4
messages can be routed freely between interfaces A and B, and freely
between C,D, and E. However, a MPL4 message MUST NOT be routed from
Interface A to interface D.
6. Default parameter values 6. Default parameter values
Three parameters are created in this draft. Their values are related Three parameters are created in this draft. Their values are related
to the trickle timer intervals. to the Trickle timer intervals.
MPL_TO = DATA_MESSAGE_IMAX times 2. Which leaves the time to receive MPL_TO = DATA_MESSAGE_IMAX times 2. Which leaves the time to receive
the second response message. the second response message.
MPL_CHECK_INT = 5 minutes. Which means that a reaction to network MPL_CHECK_INT = 5 minutes. Which means that a reaction to network
malfunctioning happens within 5 minutes. malfunctioning happens within 5 minutes.
MPL_BLOCKED = true. Which means that the interface must have MPL_BLOCKED = true. Which means that the interface has not received
received MPL-enabled messages to include the interface to the zone. MPL-enabled messages to include the interface to the MPL4 zone.
7. Security Considerations 7. Security Considerations
Refer to the security considerations of The security considerations of [I-D.ietf-roll-trickle-mcast] also
[I-D.ietf-roll-trickle-mcast]. apply to MPL4 routers.
MPL enabled interfaces MUST subscribe to the ALL_MPL_FORWARDERS The sending of MPL4 messages by a malicious node can have unwanted
address with scope 3 and scope 4. In the latter case the nodes may consequences explained with the following example. It is not unusual
become flooded by multicast messages with as destination for a wired (e.g. ethernet) link to be used between two floors or
ALL_MPL_FORWARDERS address with scope 4 coming from outside the zone sections of an LLN, as radio propagation through reinforced concrete
corresponding with the connected mesh networks. Therefore, Multicast is generally poor. The MPL4 zone can thus envelop multiple routers,
messages with address ALL_MPL_FORWADERS scope 4 and scope 3 cannot be meshes and links. It is possible that a malicious node connects to a
forwarded from sources out of the zone corresponding with the scope 4 wired link, on which no MPL enabled nodes are foreseen. In this
address. 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.
The enabling of the interfaces for a given set of multicast addresses To understand the consequences of this unwanted behaviour, the
and the setting of the MPL parameter values must be done in a secure following cases should be distinguished:
way, such that they cannot be set or modified by unauthorized nodes.
That means a setting of the parameters with secured means, or o The source mesh uses layer-2 encryption.
initializing the parameter values in the factory without
possibilities for change afterwards. o The MPL4 router can be managed.
The four possible combinations are discussed below:
Layer-2 unsecured, Router unmanaged: In this case MPL4 messages are
freely distributed over meshes and links which are interconnected
by MPL4 routers within a zone. The 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, within a clearly defined space, where the
connection of nodes can be tightly controlled. A completely wired
LLN -- such as is seen in BACnet -- is an example of an
unencrypted LLN which would be considered physically secure.
Layer-2 secured, Router unmanaged: In this case MPL4 messages are
freely distributed over meshes and links, which are interconnected
by MPL4 routers within a zone. Following the rules of
Section 4.3, the MPL4 enabled (malicious) nodes can not read the
MPL4 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 tries to send messages over layer-2 protected links.
Because the network occupies exactly one zone, the MPL4 message
distribution cannot be extended outside the network.
Layer-2 unsecured, Router managed: In this case the distribution of
MPL4 messages over MPL4 router interfaces can be limited to those
interfaces, which a manager enabled for MPL and 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 and malicious messages can be injected into the set of
meshes and links which are connected by the MPL4 routers for which
the manager enabled the interfaces. This situation can be
practical for interconnected links and meshes, which are connected
to a LAN over a limited period, for example during installation of
the interconnected meshes and links.
Layer-2 secured, Router managed: In this case the distribution of
MPL4 messages over MPL4 router interfaces can be limited to those
interfaces, which a manager enabled for MPL and 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 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
(malicious) nodes can not read the MPL4 messages and MPL4 messages
sent by the malicious node are not accepted by other nodes.
Dependent on the number of managed interfaces, the network can
progressively pass from auto-configured to fully administratively
controlled.
8. IANA Considerations 8. IANA Considerations
No considerations for IANA are formulated in this document. No considerations for IANA are formulated in this document.
9. Acknowledgements 9. Acknowledgements
This document reflects discussions and remarks from several This document reflects discussions and remarks from several
individuals including (in alphabetical order): Esko Dijk, Matthew individuals including (in alphabetical order): Scott Bradner, Esko
Gillmore, Michael Richardson, and Pascal Thubert. Dijk, Adrian Farrel, Matthew Gillmore, Joel Halpern, Steve Hanna,
Michael Richardson, and Pascal Thubert.
10. Change log 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 Version 00 - version 01
o Default parameter values declared o Default parameter values declared
o Security section extended o Security section extended
o scope 5 of higher messages specified o scope 5 of higher messages specified
o messages with address ALL_MPL_FORWARDERS are not allowed from o messages with address ALL_MPL_FORWARDERS are not allowed from
outside zone outside zone
Changes from personal version to WG version-00. Changes from personal version to WG version-00.
o Aligned terminology with MPL terminology o Aligned terminology with MPL terminology
skipping to change at page 11, line 17 skipping to change at page 13, line 47
3", RFC 3376, October 2002. 3", RFC 3376, October 2002.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
March 2005. March 2005.
[RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and [RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and
Provisioning of Wireless Access Points (CAPWAP) Protocol Provisioning of Wireless Access Points (CAPWAP) Protocol
Binding for IEEE 802.11", RFC 5416, March 2009. Binding for IEEE 802.11", RFC 5416, March 2009.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, March 2011.
[RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,
August 2014. August 2014.
[I-D.ietf-roll-trickle-mcast] [I-D.ietf-roll-trickle-mcast]
Hui, J. and R. Kelsey, "Multicast Protocol for Low power Hui, J. and R. Kelsey, "Multicast Protocol for Low power
and Lossy Networks (MPL)", draft-ietf-roll-trickle- and Lossy Networks (MPL)", draft-ietf-roll-trickle-
mcast-10 (work in progress), November 2014. mcast-11 (work in progress), November 2014.
[IEEE802.15.4] [IEEE802.15.4]
"IEEE 802.15.4 - Standard for Local and metropolitan area "IEEE 802.15.4 - Standard for Local and metropolitan area
networks -- Part 15.4: Low-Rate Wireless Personal Area networks -- Part 15.4: Low-Rate Wireless Personal Area
Networks", <IEEE Standard 802.15.4>. Networks", <IEEE Standard 802.15.4>.
[IEEE802.11] [IEEE802.11]
"IEEE 802.11 - Telecommunications and information exchange "IEEE 802.11 - Telecommunications and information exchange
between systems Local and metropolitan area networks -- between systems Local and metropolitan area networks --
Part 11: Wireless LAN Medium Access Control (MAC) and Part 11: Wireless LAN Medium Access Control (MAC) and
skipping to change at page 12, line 8 skipping to change at page 14, line 42
Independent Multicast - Dense Mode (PIM-DM): Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, January 2005. Specification (Revised)", RFC 3973, January 2005.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[I-D.irtf-nmrg-an-gap-analysis] [I-D.irtf-nmrg-an-gap-analysis]
Jiang, S., Carpenter, B., and M. Behringer, "Gap Analysis Jiang, S., Carpenter, B., and M. Behringer, "Gap Analysis
for Autonomic Networking", draft-irtf-nmrg-an-gap- for Autonomic Networking", draft-irtf-nmrg-an-gap-
analysis-02 (work in progress), October 2014. analysis-03 (work in progress), December 2014.
[I-D.ietf-6lo-lowpanz] [I-D.ietf-6lo-lowpanz]
Brandt, A. and J. Buron, "Transmission of IPv6 packets Brandt, A. and J. Buron, "Transmission of IPv6 packets
over ITU-T G.9959 Networks", draft-ietf-6lo-lowpanz-08 over ITU-T G.9959 Networks", draft-ietf-6lo-lowpanz-08
(work in progress), October 2014. (work in progress), October 2014.
[I-D.ietf-6lo-btle] [I-D.ietf-6lo-btle]
Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets
over BLUETOOTH(R) Low Energy", draft-ietf-6lo-btle-03 over BLUETOOTH(R) Low Energy", draft-ietf-6lo-btle-07
(work in progress), September 2014. (work in progress), January 2015.
Authors' Addresses Authors' Addresses
Peter van der Stok Peter van der Stok
Consultant Consultant
Email: consultancy@vanderstok.org Email: consultancy@vanderstok.org
Robert Cragie Robert Cragie
Gridmerge Gridmerge
 End of changes. 47 change blocks. 
110 lines changed or deleted 237 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/