[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-vanderstok-roll-admin-local-policy) 00 01 02 03 RFC 7732

roll                                                     P. van der Stok
Internet-Draft                                                Consultant
Intended status: Informational                                 R. Cragie
Expires: August 10, 2015                                       Gridmerge
                                                        February 6, 2015


 Forwarder policy for multicast with admin-local scope in the Multicast
            Protocol for 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 and Lossy Networks
   (MPL) multicast messages with admin-local scope in a border router.

Status of This Memo

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

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents 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.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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.



van der Stok & Cragie    Expires August 10, 2015                [Page 1]


Internet-Draft           MPL admin-local policy            February 2015


Table of Contents

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

1.  Introduction

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

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

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





van der Stok & Cragie    Expires August 10, 2015                [Page 2]


Internet-Draft           MPL admin-local policy            February 2015


   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
   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.  For example, a LoWPAN is defined
   by an IEEE 802.15.4 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 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 each mesh network is connected to its own network
   interface connected to the same border router.  In both cases, an
   admin-local multicast message originating in one network needs to
   propagate into the other mesh network.  The boundary of the admin-
   local scope is administratively configured.

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

   The MPL4 router uses the following technique to establish over which
   links MPL4 messages must be forwarded.  The MPL4 router listens on
   its interfaces for arrival of MPL4 messages.  When MPL4 messages
   arrive over an interface, the MPL4 router includes this interface to
   the set of interfaces over which incoming MPL4 messages are
   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.





van der Stok & Cragie    Expires August 10, 2015                [Page 3]


Internet-Draft           MPL admin-local policy            February 2015


   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

   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] and [RFC7346].  In addition, the
   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
      address of scope 4.

   o  MPL4 zone: a convex zone of interconnected interfaces over which
      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

   Links may have the concept of a channel, for example in wireless
   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



van der Stok & Cragie    Expires August 10, 2015                [Page 4]


Internet-Draft           MPL admin-local policy            February 2015


   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 (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 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].  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 Low Energy

   IPv6 over BLUETOOTH Low Energy (BTLE) is specified in
   [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
   of the network identifier of a BTLE link is "any".

3.  MPL4 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 on the links connected to
   its interfaces.  When no MPL interfaces are present on a given link,
   the corresponding MPL interface is signalled as not being part of the
   MPL4 zone.

3.1.  MPL interface parameters

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

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





van der Stok & Cragie    Expires August 10, 2015                [Page 5]


Internet-Draft           MPL admin-local policy            February 2015


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

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

3.2.  Determination of MPL4 zone

   All interfaces of the MPL4 router MUST be associated with following
   parameters coming from MPL protocol [I-D.ietf-roll-trickle-mcast]:
   PROACTIVE_FORWARDING, DATA_MESSAGE_IMIN, DATA_MESSAGE_IMAX,
   DATA_MESSAGE_K, DATA_MESSAGE_TIMER_EXPIRATIONS.  At start-up of the
   MPL4 router, the parameters associated with all interfaces are
   assigned the following values: PROACTIVE_FORWARDING = 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 is
      sent to multicast address ALL_MPL_FORWARDERS with scope 4.

   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.

   o  At reception of an MPL4 message with a multicast address with
      scope 4, 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 interfaces are connected
   to the link associated with the interface.  When an MPL message is
   submitted to an MPL-enabled interface -called 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-, the MPL4 message is returned with
   Trickle over interface B.  Consequently, the MPL4 message is received
   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
   MPL4 message, or can wait for the reception of an MPL4 message to
   announce its intention to be part of the MPL4 zone.




van der Stok & Cragie    Expires August 10, 2015                [Page 6]


Internet-Draft           MPL admin-local policy            February 2015


4.  Admin-Local policy

   The section starts with specifying what multicast messages arriving
   at an interface are legal.  It continues with a description of
   forwarding legal admin-local multicast messages over other MPL
   interfaces.

   The policy for forwarding admin-local multicast messages
   automatically to a MPL interface is specified as function of the
   state of the MPL 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] and the destination multicast address.
   The state of the MPL 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.

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

4.1.  Legal 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) is legal when it
   conforms to the properties described in section 9.1 of
   [I-D.ietf-roll-trickle-mcast].

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

   o  The message carries an MPL option (MPL message) and the incoming
      MPL 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, and the
      interface has expressed interest to receive messages with the
      specified multicast address via MLD [RFC3810] or via IGMP
      [RFC3376].  The message was sent on according to PIM-DM [RFC3973]
      or according to PIM-SM [RFC4601].

   Illegal multicast messages are discarded.

4.2.  Forwarding legal packets

   A legal multicast message received at a given interface is assigned
   the network identifier of the interface of the incoming link . A




van der Stok & Cragie    Expires August 10, 2015                [Page 7]


Internet-Draft           MPL admin-local policy            February 2015


   message that is created within the node is assigned the network
   identifier "any".

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

4.2.1.  MPL message

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

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

   o  Realm-local (scope 3) MPL messages are forwarded on all MPL
      interfaces that are subscribed to the same multicast address, have
      the same zone index, and have PROACTIVE-FORWARDING set to true,
      and the assigned network identifier of the multicast message is
      identical to the network identifier of the MPL interface, or the
      assigned network identifier of the multicast message is "any".

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

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

4.2.2.  Multicast messages without MPL option

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

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

   o  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.





van der Stok & Cragie    Expires August 10, 2015                [Page 8]


Internet-Draft           MPL admin-local policy            February 2015


   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 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 as specified by PIM [RFC3973],
      [RFC4601] according to group specifications enabled by MLD
      [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

   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
   accordance with [RFC4007] a zone boundary passes through a node.  For
   example, a small LLN node usually has one MPL mesh interface which is
   enabled to the ALL_MPL_FORWARDERS multicast address with a scope
   value of 3 (realm-local) [RFC7346].  The node interface belongs to
   the zone and the corresponding zone boundary does not pass through
   this node.  In the border router with MPL interfaces enabled to the
   multicast address ALL_MPL_FORWARDERS with scope value 3, the zone
   includes usually this single interface and excludes all other
   interfaces.  A notable exception is provided by a node where MPL
   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 subscribes to the admin_local
   ALL_MPL_FORWARDERS multicast address next to the realm-local
   ALL_MPL_FORWARDERS address.





van der Stok & Cragie    Expires August 10, 2015                [Page 9]


Internet-Draft           MPL admin-local policy            February 2015


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

   The MPL4 zone corresponding with the MPL multicast address
   ALL_MPL_FORWARDERS with scope 4 (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 interfaces which
   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 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

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

   MPL_TO = DATA_MESSAGE_IMAX times 2.  Which leaves the time to receive
   the second response message.

   MPL_CHECK_INT = 5 minutes.  Which means that a reaction to network
   malfunctioning happens within 5 minutes.

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

7.  Security Considerations

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

   The sending of MPL4 messages by a malicious node can have unwanted
   consequences explained with the following example.  It is not unusual
   for a wired (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 and links.  It is possible that a malicious node connects to a



van der Stok & Cragie    Expires August 10, 2015               [Page 10]


Internet-Draft           MPL admin-local policy            February 2015


   wired link, on which no 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, the
   following cases should be distinguished:

   o  The source mesh uses layer-2 encryption.

   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



van der Stok & Cragie    Expires August 10, 2015               [Page 11]


Internet-Draft           MPL admin-local policy            February 2015


      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

   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



van der Stok & Cragie    Expires August 10, 2015               [Page 12]


Internet-Draft           MPL admin-local policy            February 2015


   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.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC4007]  Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
              B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
              March 2005.

   [RFC5416]  Calhoun, P., Montemurro, M., and D. Stanley, "Control and
              Provisioning of Wireless Access Points (CAPWAP) Protocol
              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,
              August 2014.



van der Stok & Cragie    Expires August 10, 2015               [Page 13]


Internet-Draft           MPL admin-local policy            February 2015


   [I-D.ietf-roll-trickle-mcast]
              Hui, J. and R. Kelsey, "Multicast Protocol for Low power
              and Lossy Networks (MPL)", draft-ietf-roll-trickle-
              mcast-11 (work in progress), November 2014.

   [IEEE802.15.4]
              "IEEE 802.15.4 - Standard for Local and metropolitan area
              networks -- Part 15.4: Low-Rate Wireless Personal Area
              Networks", <IEEE Standard 802.15.4>.

   [IEEE802.11]
              "IEEE 802.11 - Telecommunications and information exchange
              between systems Local and metropolitan area networks --
              Part 11: Wireless LAN Medium Access Control (MAC) and
              Physical Layer (PHY) Specifications", <IEEE Standard
              802.11>.

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

   [btle]     "BLUETOOTH Specification Version 4.0", <BLUETOOTH low
              energy>.

11.2.  Informative References

   [RFC3973]  Adams, A., Nicholas, J., and W. Siadak, "Protocol
              Independent Multicast - Dense Mode (PIM-DM): Protocol
              Specification (Revised)", RFC 3973, January 2005.

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

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

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








van der Stok & Cragie    Expires August 10, 2015               [Page 14]


Internet-Draft           MPL admin-local policy            February 2015


   [I-D.ietf-6lo-btle]
              Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
              Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets
              over BLUETOOTH(R) Low Energy", draft-ietf-6lo-btle-07
              (work in progress), January 2015.

Authors' Addresses

   Peter van der Stok
   Consultant

   Email: consultancy@vanderstok.org


   Robert Cragie
   Gridmerge

   Email: robert.cragie@gridmerge.com

































van der Stok & Cragie    Expires August 10, 2015               [Page 15]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/