draft-ietf-roll-admin-local-policy-03.txt		rfc7732.txt
	roll P. van der Stok		Internet Engineering Task Force (IETF) P. van der Stok
	Internet-Draft Consultant		Request for Comments: 7732 Consultant
	Intended status: Informational R. Cragie		Category: Informational R. Cragie
	Expires: August 10, 2015 Gridmerge		ISSN: 2070-1721 ARM Ltd.
	February 6, 2015		February 2016
	Forwarder policy for multicast with admin-local scope in the Multicast		Forwarder Policy for Multicast with Admin-Local Scope
	Protocol for Low power and Lossy Networks (MPL)		in the Multicast 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 Multicast Protocol for Low power and Lossy Networks		the routing of Multicast Protocol for Low-Power and Lossy Networks
	(MPL) multicast messages with admin-local scope in a 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 document is not an Internet Standards Track specification; it is
	provisions of BCP 78 and BCP 79.		published for informational purposes.
	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		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Not all documents
			approved by the IESG are a candidate for any level of Internet
			Standard; see Section 2 of RFC 5741.
	This Internet-Draft will expire on August 10, 2015.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc7732.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . 4		1.1. Requirements Language ......................................4
	1.2. Terminology and Acronyms . . . . . . . . . . . . . . . . 4		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 ..............................................5
	2.2. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . 5		2.2. IEEE 802.11 ................................................5
	2.3. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 5		2.3. ITU-T G.9959 ...............................................5
	2.4. BLUETOOTH Low Energy . . . . . . . . . . . . . . . . . . 5		2.4. BLUETOOTH(R) Low Energy ....................................5
	3. MPL4 router . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. MPL4 Router .....................................................5
	3.1. MPL interface parameters . . . . . . . . . . . . . . . . 5		3.1. MPL Interface Parameters ...................................6
	3.2. Determination of MPL4 zone . . . . . . . . . . . . . . . 6		3.2. Determination of MPL4 Zone .................................6
	4. Admin-Local policy . . . . . . . . . . . . . . . . . . . . . 7		4. Admin-Local Policy ..............................................7
	4.1. Legal multicast messages . . . . . . . . . . . . . . . . 7		4.1. Legal Multicast Messages ...................................7
	4.2. Forwarding legal packets . . . . . . . . . . . . . . . . 7		4.2. Forwarding Legal Packets ...................................8
	4.2.1. MPL message . . . . . . . . . . . . . . . . . . . . . 8		4.2.1. MPL Message .........................................8
	4.2.2. Multicast messages without MPL option . . . . . . . . 8		4.2.2. Multicast Messages without MPL Option ...............9
	4.3. Encryption rules . . . . . . . . . . . . . . . . . . . . 9		4.3. Encryption Rules ...........................................9
	5. MPL domains and zones . . . . . . . . . . . . . . . . . . . . 9		5. MPL Domains and Zones ...........................................9
	6. Default parameter values . . . . . . . . . . . . . . . . . . 10		6. Default Parameter Values .......................................10
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations ........................................11
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		8. References .....................................................12
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		8.1. Normative References ......................................12
	10. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 12		8.2. Informative References ....................................14
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		Acknowledgements ..................................................15
	11.1. Normative References . . . . . . . . . . . . . . . . . . 13		Authors' Addresses ................................................15
	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]. [RFC7346] extends the
	scope definition with the text:		scope definition with this 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
	multicast related configuration. Global scope has no boundary. The		non-multicast-related configurations. Global scope has no boundary.
	boundaries of all other non-reserved scopes of Admin-Local or larger		The boundaries of all other non-reserved scopes of Admin-Local or
	are administratively configured."		larger are administratively configured."
	The admin-local scope must therefore be administratively configured.		The Admin-Local scope must therefore be administratively configured.
	In this document "administratively configured" does not imply actions		In this document, "administratively configured" does not imply
	by a human beyond installing the here specified protocol.		actions by a human beyond installing the protocol specified herein.
	"Administratively configured" means an automatic derivation as		"Administratively configured" means an automatic derivation as
	described in this document.		described in this document.
	This draft describes an automated policy for the Multicast Protocol		This document describes an automated policy for the Multicast
	for Low power and Lossy Networks (MPL) [[I-D.ietf-roll-trickle-mcast]		Protocol for Low-Power and Lossy Networks (MPL) [RFC7731] forwarding
	forwarding of multicast messages with admin-local scope within a		of multicast messages with Admin-Local scope within a border router
	border router that lies between a network running MPL and some other		that lies between a network running MPL and some other network. This
	network. This wish is in line with the autonomous networking ideas		policy is in line with the autonomous networking ideas presented in
	presented in [I-D.irtf-nmrg-an-gap-analysis].		[RFC7576].
	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 Low-Power
	by an IEEE 802.15.4 layer-2 mesh network, composed of all connected		Wireless Personal Area Network (LoWPAN) is defined by an
	nodes sharing the same Personal Area Network (PAN) ID [RFC4944].		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		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 in which it originated, 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
	required. In one example, each mesh network has a border router and		required. In one example, each mesh network has a border router and
	the two border routers are connected with an Ethernet link. In		the two border routers are connected with an Ethernet link. In
	another example each mesh network is connected to its own network		another example, each mesh network is connected to its own network
	interface connected to the same border router. In both cases, an		interface connected to the same border router. In both cases, an
	admin-local multicast message originating in one network needs to		Admin-Local multicast message originating in one network needs to
	propagate into the other mesh network. The boundary of the admin-		propagate into the other mesh network. The boundary of the
	local scope is administratively configured.		Admin-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 either permits or forbids
	forwarding of MPL messages.		the forwarding of MPL messages.
	The MPL4 router uses the following technique to establish over which		The MPL4 router uses the following technique to establish over which
	links MPL4 messages must be forwarded. The MPL4 router listens on		links MPL4 messages must be forwarded: The MPL4 router listens on its
	its interfaces for arrival of MPL4 messages. When MPL4 messages		interfaces for the arrival of MPL4 messages. When MPL4 messages
	arrive over an interface, the MPL4 router includes this interface to		arrive over an interface, the MPL4 router records this interface in
	the set of interfaces over which incoming MPL4 messages are		the set of interfaces over which incoming MPL4 messages are
	forwarded. Regularly, the MPL4 router sends MPL4 messages over its		forwarded. The MPL4 router regularly sends MPL4 messages over its
	interfaces to provoke the return of MPL4 messages to maintain or		interfaces to provoke the return of MPL4 messages to maintain the set
	remove the interfaces in/from the set of forwarding interfaces.		of forwarding interfaces.
	It is expected that the private network of an organization, building,		It is expected that the private network of an organization, building,
	or home, is connected to the Internet via the edge routers provided		or home is connected to the Internet via the edge routers provided by
	by an ISP. The intention is that MPL messages with multicast		an ISP. The intention is that MPL messages with multicast addresses
	addresses of admin-local scope are freely forwarded within the		of Admin-Local scope are freely forwarded within the private network
	private network, but are never forwarded outside the private network		but are never forwarded outside the private network by edge routers.
	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 [RFC7731] and [RFC7346].
	[I-D.ietf-roll-trickle-mcast] and [RFC7346]. In addition, the		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: 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 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. A MPL4 zone is		MPL messages with Admin-Local scope propagate. An MPL4 zone is
	bounded by a zone as defined in [RFC4007].		bounded by a zone as defined in [RFC4007].
	o MPL4 router: automatically determines the MPL4 zone in which MPL		o MPL4 router: automatically determines the MPL4 zone in which MPL
	messages with admin-local scope can be propagated.		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
	Additionally, for some link technologies, several networks can		frequency. Additionally, for some link technologies, several
	coexist using the same channel. For these link technologies, a		networks can coexist using the same channel. For these link
	network identifier exists. The network identifier is determined by		technologies, a network identifier exists. The network identifier is
	the link technology specification. When no network identifier exists		determined by the link technology specification. When no network
	for a given link, the network identifier has the value "any".		identifier exists 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 Service Set		IP over IEEE 802.11 is described in [RFC5416]. The Service Set
	IDentifier (SSID) identifies a network in the IEEE 802.11 link.		Identifier (SSID) identifies a network in the IEEE 802.11 link.
	Several networks with different SSIDs can coexist on the same channel		Several networks with different SSIDs can coexist on the same channel
	[IEEE802.11]. The SSID of an interface is defined when the interface		[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		is switched on. The value of the network identifier of an IEEE
	link is the value of the SSID.		802.11 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 [RFC7428]. The HomeID
	HomeID identifies a network of connected nodes [G.9959]. Several		identifies a network of connected nodes [G.9959]. Several HomeIDs
	HomeIDs can coexist within communication range, but nodes adhering to		can coexist within communication range, but nodes adhering to a
	a network with a given HomeID cannot communicate with nodes adhering		network with a given HomeID cannot communicate with nodes adhering to
	to a network with a different HomeID. The value of the network		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(R) Low Energy
	IPv6 over BLUETOOTH Low Energy (BTLE) is specified in		IPv6 over Bluetooth low energy (BTLE) is specified in [RFC7668]. The
	[I-D.ietf-6lo-btle]. The medium is specified in [btle]. BTLE does		medium is specified in [BTLE]. BTLE does not know the concept of
	not know the concept of multiple networks in one channel. The value		multiple networks in one channel. The value of the network
	of the network identifier of a BTLE link is "any".		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
	MPL4 zone in which MPL messages with a 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 signaled as not being part of the
	MPL4 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 behavior 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 or not the
	interface belongs to the MPL4 zone.		associated 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 to be received in seconds.		are expected to be received, in seconds.
	3.2. Determination of MPL4 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 the
	parameters coming from MPL protocol [I-D.ietf-roll-trickle-mcast]:		following MPL protocol parameters, as described in [RFC7731]:
	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, and DATA_MESSAGE_TIMER_EXPIRATIONS. Upon startup of
	MPL4 router, the parameters associated with all interfaces are		the 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 [I-D.ietf-roll-trickle-mcast] and is		that includes the MPL Option [RFC7731]; the message is sent to
	sent to multicast address ALL_MPL_FORWARDERS with scope 4.		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 On reception of an MPL4 message, the value of MPL_BLOCKED of the
	scope 4, the value of MPL_BLOCKED of the receiving interface is		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 "Interface A" in the MPL
	the Trickle algorithm [RFC6206] is activated to send the MPL message.		router, the Trickle algorithm [RFC6206] is activated to send the MPL
	The MPL4 message with multicast address ALL_MPL_FORWARDERS scope 4 is		message. The MPL4 message with multicast address ALL_MPL_FORWARDERS
	accepted by every interface connected to the link that has subscribed		scope 4 is accepted by every interface connected to the link that has
	to ALL_MPL_FORWARDERS with scope 4. On acceptance of the MPL4		subscribed to ALL_MPL_FORWARDERS with scope 4. On acceptance of the
	message by an interface -called B-, the MPL4 message is returned with		MPL4 message by an interface called "Interface B", the MPL4 message
	Trickle over interface B. Consequently, the MPL4 message is received		is returned with Trickle over Interface B. Consequently, the MPL4
	by the originating interface A, after which MPL_BLOCKED is set to		message is received by the originating Interface A, after which
	false.		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 it can wait for the reception of an MPL4 message to
	announce its intention to be part of the MPL4 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		This section begins by specifying what types of multicast messages
	at an interface are legal. It continues with a description of		arriving at an interface are legal. It continues with a description
	forwarding legal admin-local multicast messages over other MPL		of 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 an MPL Interface is specified as a 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
	[I-D.ietf-roll-trickle-mcast] and the destination multicast address.		[RFC7731] and the destination multicast address. The state of the
	The state of the MPL interface is determined by the subscribed		MPL Interface is determined by the subscribed multicast addresses,
	multicast addresses, the zone index [RFC4007], and the values of the		the zone index [RFC4007], and the values of the PROACTIVE_FORWARDING
	PROACTIVE_FORWARDING parameter and the MPL_BLOCKED parameter of the		parameter and the MPL_BLOCKED parameter of the MPL Interface.
	MPL interface.
	When zone is undefined or not enabled, all interfaces have the same		When the zone is undefined or not enabled, all interfaces have the
	zone index.		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 [RFC7731].
	[I-D.ietf-roll-trickle-mcast].
	A multicast message received at a given interface is legal when:		A multicast message received at a given interface is legal when:
	o The message carries an MPL option (MPL message) and the incoming		o The message carries an MPL Option (MPL message) and the incoming
	MPL interface is subscribed to the destination multicast address.		MPL Interface is subscribed to the destination multicast address.
	o The message does not carry an MPL option, the multicast address is		o The message does not carry an MPL Option and the interface has
	unequal to ALL_MPL_FORWARDERS scope 4 or scope 3, and the		expressed interest in receiving messages with the specified
	interface has expressed interest to receive messages with the		multicast address via Multicast Listener Discovery (MLD) [RFC3810]
	specified multicast address via MLD [RFC3810] or via IGMP		or IGMP [RFC3376]. The message was forwarded according to
	[RFC3376]. The message was sent on according to PIM-DM [RFC3973]		Protocol Independent Multicast - Dense Mode (PIM-DM) [RFC3973] or
	or according to PIM-SM [RFC4601].		Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601].
	Illegal multicast messages are discarded.		Illegal multicast messages are discarded.
	4.2. Forwarding legal packets		4.2. Forwarding Legal Packets
	A legal multicast message received at a given interface is assigned		A legal multicast message received at a given interface is assigned
	the network identifier of the interface of the incoming link . A		the network identifier of the interface of the incoming link. A
	message that is created within the node is assigned the network		message that is created within the node is assigned the network
	identifier "any".		identifier "any".
	Two types of legal multicast messages are considered: (1) MPL		Two types of legal multicast messages are considered in Section 4.1:
	messages, and (2) multicast messages which do not carry the MPL		(1) MPL messages and (2) multicast messages that do not carry the MPL
	option.		Option.
	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, have		Interfaces where all of the following are true:
	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		* The multicast address to which the MPL Interface subscribes is
	interfaces that are subscribed to the same multicast address, have		the same as the multicast address of the MPL message.
	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		* The zone index of the MPL Interface is the same as the zone
	encapsulate a message with the same multicast address without MPL		index of the MPL Interface on which the MPL message was
	option. The decapsulated message can be forwarded over an		received.
	interface when the interface is subscribed with MLD to the same
	multicast address.
	4.2.2. Multicast messages without MPL option		* The MPL Interface has PROACTIVE_FORWARDING set to TRUE.
	Multicast messages without MPL option are forwarded on MPL interfaces		* The assigned network identifier of the MPL message is "any", or
	according to the following rules:		the assigned network identifier of the MPL message is equal to
			the network identifier of the MPL Interface.
	o Link-local (scope 2) messages or realm-local (scope 3) multicast		o Admin-Local (scope 4) MPL messages are forwarded on all MPL
	messages are not forwarded.		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 Admin-local (scope 4) multicast messages are encapsulated with a		o MPL messages that encapsulate a message with a multicast scope of
	header carrying the MPL option and are forwarded on al MPL		5 or higher are decapsulated and forwarded over the interface when
	interfaces that are subscribed to the multicast address, have the		the interface is subscribed to the multicast address of the
	same zone index, have PROACTIVE_FORWARDING set to true, and have		decapsulated message.
	MPL_BLOCKED set to false.
			4.2.2. Multicast Messages without MPL Option
			Multicast messages without the MPL Option are forwarded on MPL
			Interfaces according to the following rules:
			o Link-Local (scope 2), Realm-Local (scope 3), and Admin-Local
			(scope 4) multicast messages are not forwarded.
	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 in an MPL message with destination address
	forwarded on al MPL interfaces that are subscribed to the		ALL_MPL_FORWARDERS with scope 4. The resulting message is then
	multicast address, have PROACTIVE_FORWARDING set to true, and have		treated as described in Section 4.2.1.
	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		4.3. Encryption Rules
	An incoming message protected at layer-2 MUST be subsequently re-		An incoming message protected at Layer 2 MUST be subsequently
	protected at layer-2 at all outgoing interfaces. Incoming messages		re-protected at Layer 2 at all outgoing interfaces. Incoming
	are integrity checked and optionally decrypted at the incoming		messages are integrity checked and optionally decrypted at the
	interface at layer-2 using the keys and protection algorithm		incoming interface at Layer 2 using the keys and protection algorithm
	appropriate to the incoming interface's network and re-protected at		appropriate to the incoming interface's network and are re-protected
	the outgoing interface using the keys and protection algorithm		at the outgoing interface using the keys and protection algorithm
	appropriate to the outgoing interface's network. It may be necessary		appropriate to the outgoing interface's network. It may be necessary
	to assess the relative levels of protection on the respective		to assess the relative levels of protection on the respective
	interfaces and apply policy rules, for example to avoid downgrading		interfaces and apply policy rules -- for example, to avoid
	security where one network has a lower level of security than		downgrading security where one network has a lower level of security
	another.		than another.
	An incoming MPL4 messages which is not protected at layer-2 MUST NOT		An incoming MPL4 message that is not protected at Layer 2 MUST NOT be
	be re-protected at layer-2 at all outgoing interfaces.		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 [RFC7731]. In accordance with [RFC4007],
	accordance with [RFC4007] a zone boundary passes through a node. For		a zone boundary passes through a node. For example, a small
	example, a small LLN node usually has one MPL mesh interface which is		Low-Power and Lossy Network (LLN) node usually has one MPL mesh
	enabled to the ALL_MPL_FORWARDERS multicast address with a scope		interface that is subscribed to the ALL_MPL_FORWARDERS multicast
	value of 3 (realm-local) [RFC7346]. The node interface belongs to		address with a scope value of 3 (Realm-Local) [RFC7346]. The node
	the zone and the corresponding zone boundary does not pass through		interface belongs to the zone, and the corresponding zone boundary
	this node. In the border router with MPL interfaces enabled to the		does not pass through this node. In the border router with MPL
	multicast address ALL_MPL_FORWARDERS with scope value 3, the zone		Interfaces subscribed to the multicast address ALL_MPL_FORWARDERS
	includes usually this single interface and excludes all other		with scope value 3, the zone usually includes this single interface
	interfaces. A notable exception is provided by a node where MPL		and excludes all other interfaces. A notable exception is provided
	interfaces of the same technology share the same network identifier.		by a node where MPL Interfaces of the same technology share the same
	These interfaces belong to the same MPL4 zone when the interfaces		network identifier. These interfaces belong to the same MPL4 zone
	share the same zone index.		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 in addition 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 MPL4 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 that
	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 MPL4 zone when the		which MPL_BLOCKED is false belong to the same MPL4 zone when the
	interfaces share the same zone index.		interfaces share the same zone index.
	MPL4 messages remain bounded within a zone as defined in [RFC4007].		MPL4 messages remain bounded within a zone as defined in [RFC4007].
	Consequently, MPL4 messages cannot be routed between interfaces		Consequently, MPL4 messages cannot be routed between interfaces
	belonging to different zones. When the concept of zone is unknown or		belonging to different zones. When the concept of zone is unknown or
	disabled in a router, all interfaces belong to the same zone. For		disabled in a router, all interfaces belong to the same zone. For
	example, consider a router with 5 interfaces where interfaces A and B		example, consider a router with five interfaces, where Interfaces A
	belong to zone 1 and interfaces C,D, and E belong to zone 2. MPL4		and B belong to zone 1 and Interfaces C, D, and E belong to zone 2.
	messages can be routed freely between interfaces A and B, and freely		MPL4 messages can be routed freely between Interfaces A and B, and
	between C,D, and E. However, a MPL4 message MUST NOT be routed from		freely between Interfaces C, D, and E. However, an MPL4 message
	Interface A to interface D.		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 by this document. Their values are
	to the Trickle timer intervals.		related to the Trickle timer intervals.
	MPL_TO = DATA_MESSAGE_IMAX times 2. Which leaves the time to receive		o MPL_TO = DATA_MESSAGE_IMAX times 2, which leaves enough time to
	the second response message.		receive the second response message.
	MPL_CHECK_INT = 5 minutes. Which means that a reaction to network		o MPL_CHECK_INT = 5 minutes, which means that a reaction to a
	malfunctioning happens within 5 minutes.		network malfunction happens within 5 minutes.
	MPL_BLOCKED = true. Which means that the interface has not received		o MPL_BLOCKED = TRUE, which means that the interface has not
	MPL-enabled messages to include the interface to the MPL4 zone.		received MPL-enabled messages to include the interface in the
			MPL4 zone.
	7. Security Considerations		7. Security Considerations
	The security considerations of [I-D.ietf-roll-trickle-mcast] also		The security considerations of [RFC7731] also apply to MPL4 routers.
	apply to MPL4 routers.
	The sending of MPL4 messages by a malicious node can have unwanted		The sending of MPL4 messages by a malicious node can have unwanted
	consequences explained with the following example. It is not unusual		consequences, as explained by the following example. It is not
	for a wired (e.g. ethernet) link to be used between two floors or		unusual for a wired (e.g., Ethernet) link to be used between two
	sections of an LLN, as radio propagation through reinforced concrete		floors or sections of an LLN, as radio propagation through reinforced
	is generally poor. The MPL4 zone can thus envelop multiple routers,		concrete is generally poor. The MPL4 zone can thus envelop multiple
	meshes and links. It is possible that a malicious node connects to a		routers, meshes, and links. It is possible that a malicious node
	wired link, on which no MPL enabled nodes are foreseen. In this		could connect to a wired link on which no MPL-enabled nodes are
	example configuration, the malicious node can send MPL4 messages to		foreseen. In this example configuration, the malicious node can send
	the MPL4 router interfaces. When nothing is done, the MPL4 routers		MPL4 messages to the MPL4 router interfaces. When nothing is done,
	will consequently distribute MPL4 messages from one mesh over the		the MPL4 routers will consequently distribute MPL4 messages from one
	wired link to the next mesh, although the wired link was not expected		mesh over the wired link to the next mesh, although the wired link
	to transport MPL4 messages.		was not expected to transport MPL4 messages.
	To understand the consequences of this unwanted behaviour, the		To understand the consequences of this unwanted behavior, the
	following cases should be distinguished:		following cases should be distinguished:
	o The source mesh uses layer-2 encryption.		o The source mesh uses Layer 2 encryption.
	o The MPL4 router can be managed.		o The MPL4 router can be managed.
	The four possible combinations are discussed below:		The four possible combinations are discussed below:
	Layer-2 unsecured, Router unmanaged: In this case MPL4 messages are		Layer 2 unsecured, router unmanaged: In this case, MPL4 messages are
	freely distributed over meshes and links which are interconnected		freely distributed over meshes and links that are interconnected
	by MPL4 routers within a zone. The MPL enabled (malicious) nodes		by MPL4 routers within a zone. The MPL-enabled (malicious) nodes
	can read all MPL4 messages and distribute MPL4 messages over a		can read all MPL4 messages and distribute MPL4 messages over a
	network limited by a zone. This situation can be acceptable for		network limited by a zone. This situation can be acceptable for
	an isolated network, within a clearly defined space, where the		an isolated network within a clearly defined space, where the
	connection of nodes can be tightly controlled. A completely wired		connection of nodes can be tightly controlled. A completely wired
	LLN -- such as is seen in BACnet -- is an example of an		LLN, e.g., such as is seen in BACnet (a protocol for building
	unencrypted LLN which would be considered physically secure.		automation and control networks) [BACnet] is an example of an
			unencrypted LLN that would be considered physically secure.
	Layer-2 secured, Router unmanaged: In this case MPL4 messages are		Layer 2 secured, router unmanaged: In this case, MPL4 messages are
	freely distributed over meshes and links, which are interconnected		freely distributed over meshes and links that are interconnected
	by MPL4 routers within a zone. Following the rules of		by MPL4 routers within a zone. Following the rules of
	Section 4.3, the MPL4 enabled (malicious) nodes can not read the		Section 4.3, the MPL4-enabled (malicious) nodes cannot read the
	MPL4 messages and MPL4 messages sent by the malicious node are not		MPL4 messages, and MPL4 messages sent by the malicious node are
	accepted by other nodes. This situation is acceptable for a home		not accepted by other nodes. This situation is acceptable for a
	network or managed network extending over precisely one zone,		home network or managed network extending over precisely one zone,
	occupying a clearly defined physical space, where ease of		occupying a clearly defined physical space, where ease of
	installation is important. In such a network, the presence of the		installation is important. In such a network, the presence of the
	malicious node is not different from any other malicious node,		malicious node is not different from any other malicious node that
	which tries to send messages over layer-2 protected links.		tries to send messages over Layer 2 protected links. Because the
	Because the network occupies exactly one zone, the MPL4 message		network occupies exactly one zone, the MPL4 message distribution
	distribution cannot be extended outside the network.		cannot be extended outside the network.
	Layer-2 unsecured, Router managed: In this case the distribution of		Layer 2 unsecured, router managed: In this case, the distribution of
	MPL4 messages over MPL4 router interfaces can be limited to those		MPL4 messages over MPL4 router interfaces can be limited to those
	interfaces, which a manager enabled for MPL and a set of multicast		interfaces for which a manager has enabled MPL, as well as a set
	addresses. The malicious node cannot extend the distribution of		of multicast addresses. The malicious node cannot extend the
	MPL4 messages over unwanted interfaces. It is important that the		distribution of MPL4 messages over unwanted interfaces. It is
	handling of the interfaces by the manager is protected. However,		important that the handling of the interfaces by the manager is
	MPL4 messages sent over the mesh can be interpreted by malicious		protected. However, MPL4 messages sent over the mesh can be
	nodes and malicious messages can be injected into the set of		interpreted by malicious nodes, and malicious messages can be
	meshes and links which are connected by the MPL4 routers for which		injected into the set of meshes and links that are connected by
	the manager enabled the interfaces. This situation can be		the MPL4 routers for which the manager enabled the interfaces.
	practical for interconnected links and meshes, which are connected		This situation can be practical for interconnected links and
	to a LAN over a limited period, for example during installation of		meshes that are connected to a LAN over a limited period -- for
	the interconnected meshes and links.		example, during installation of the interconnected meshes and
			links.
	Layer-2 secured, Router managed: In this case the distribution of		Layer 2 secured, router managed: In this case, the distribution of
	MPL4 messages over MPL4 router interfaces can be limited to those		MPL4 messages over MPL4 router interfaces can be limited to those
	interfaces, which a manager enabled for MPL and a set of multicast		interfaces for which a manager has enabled MPL, as well as a set
	addresses. Following the rules of Section 4.3, the malicious node		of multicast addresses. Following the rules of Section 4.3, the
	cannot extend the distribution of MPL4 messages over unwanted		malicious node cannot extend the distribution of MPL4 messages
	interfaces and MPL4 messages sent by the malicious node are not		over unwanted interfaces, and MPL4 messages sent by the malicious
	accepted by other nodes. It is important that the handling of the		node are not accepted by other nodes. It is important that the
	interfaces by the manager is protected. The MPL enabled		handling of the interfaces by the manager is protected. The
	(malicious) nodes can not read the MPL4 messages and MPL4 messages		MPL-enabled (malicious) nodes cannot read the MPL4 messages, and
	sent by the malicious node are not accepted by other nodes.		MPL4 messages sent by the malicious node are not accepted by other
	Dependent on the number of managed interfaces, the network can		nodes. Depending on the number of managed interfaces, the network
	progressively pass from auto-configured to fully administratively		can progressively pass from autoconfigured to fully
	controlled.		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		8. References
	11.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery		[RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener
	Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.		Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
			DOI 10.17487/RFC3810, June 2004,
			<http://www.rfc-editor.org/info/rfc3810>.
	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, February 2006.		Architecture", RFC 4291, DOI 10.17487/RFC4291,
			February 2006, <http://www.rfc-editor.org/info/rfc4291>.
	[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,		[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
	"Transmission of IPv6 Packets over IEEE 802.15.4		"Transmission of IPv6 Packets over IEEE 802.15.4
	Networks", RFC 4944, September 2007.		Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
			<http://www.rfc-editor.org/info/rfc4944>.
	[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.		[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
	Thyagarajan, "Internet Group Management Protocol, Version		Thyagarajan, "Internet Group Management Protocol,
	3", RFC 3376, October 2002.		Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
			<http://www.rfc-editor.org/info/rfc3376>.
	[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.		DOI 10.17487/RFC4007, March 2005,
			<http://www.rfc-editor.org/info/rfc4007>.
	[RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and		[RFC5416] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley,
	Provisioning of Wireless Access Points (CAPWAP) Protocol		Ed., "Control and Provisioning of Wireless Access Points
	Binding for IEEE 802.11", RFC 5416, March 2009.		(CAPWAP) Protocol Binding for IEEE 802.11", RFC 5416,
			DOI 10.17487/RFC5416, March 2009,
			<http://www.rfc-editor.org/info/rfc5416>.
	[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,		[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
	"The Trickle Algorithm", RFC 6206, March 2011.		"The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
			March 2011, <http://www.rfc-editor.org/info/rfc6206>.
	[RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,		[RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,
	August 2014.		DOI 10.17487/RFC7346, August 2014,
			<http://www.rfc-editor.org/info/rfc7346>.
	[I-D.ietf-roll-trickle-mcast]		[RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power
	Hui, J. and R. Kelsey, "Multicast Protocol for Low power		and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731,
	and Lossy Networks (MPL)", draft-ietf-roll-trickle-		February 2016, <http://www.rfc-editor.org/info/rfc7731>.
	mcast-11 (work in progress), November 2014.
	[IEEE802.15.4]		[IEEE802.15.4]
	"IEEE 802.15.4 - Standard for Local and metropolitan area		IEEE, "IEEE 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 (LR-WPANs)", IEEE 802.15.4,
			DOI 10.1109/ieeestd.2011.6012487,
			<http://ieeexplore.ieee.org/servlet/
			opac?punumber=6012485>.
	[IEEE802.11]		[IEEE802.11]
	"IEEE 802.11 - Telecommunications and information exchange		IEEE, "IEEE Standard for Information technology--
	between systems Local and metropolitan area networks --		Telecommunications and information exchange between
	Part 11: Wireless LAN Medium Access Control (MAC) and		systems Local and metropolitan area networks--Specific
	Physical Layer (PHY) Specifications", <IEEE Standard		requirements Part 11: Wireless LAN Medium Access Control
	802.11>.		(MAC) and Physical Layer (PHY) Specifications",
			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 range narrow-band digital		[G.9959] International Telecommunication Union, "Short range
	radiocommunication transceivers - PHY and MAC layer		narrow-band digital radiocommunication transceivers - PHY,
	specifications", <ITU-T G.9959>.		MAC, SAR and LLC layer specifications", ITU-T
			Recommendation G.9959, January 2015,
			<http://www.itu.int/rec/T-REC-G.9959>.
	[btle] "BLUETOOTH Specification Version 4.0", <BLUETOOTH low		[BTLE] Bluetooth Special Interest Group, "Bluetooth Core
	energy>.		Specification Version 4.1", December 2013,
			<https://www.bluetooth.org/en-us/specification/
			adopted-specifications>.
	11.2. Informative References		8.2. Informative References
	[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol		[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
	Independent Multicast - Dense Mode (PIM-DM): Protocol		Independent Multicast - Dense Mode (PIM-DM): Protocol
	Specification (Revised)", RFC 3973, January 2005.		Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973,
			January 2005, <http://www.rfc-editor.org/info/rfc3973>.
	[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,
			DOI 10.17487/RFC4601, August 2006,
			<http://www.rfc-editor.org/info/rfc4601>.
	[I-D.irtf-nmrg-an-gap-analysis]		[RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap
	Jiang, S., Carpenter, B., and M. Behringer, "Gap Analysis		Analysis for Autonomic Networking", RFC 7576,
	for Autonomic Networking", draft-irtf-nmrg-an-gap-		DOI 10.17487/RFC7576, June 2015,
	analysis-03 (work in progress), December 2014.		<http://www.rfc-editor.org/info/rfc7576>.
	[I-D.ietf-6lo-lowpanz]		[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets
	Brandt, A. and J. Buron, "Transmission of IPv6 packets		over ITU-T G.9959 Networks", RFC 7428,
	over ITU-T G.9959 Networks", draft-ietf-6lo-lowpanz-08		DOI 10.17487/RFC7428, February 2015,
	(work in progress), October 2014.		<http://www.rfc-editor.org/info/rfc7428>.
	[I-D.ietf-6lo-btle]		[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
	Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,		Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
	Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets		Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
	over BLUETOOTH(R) Low Energy", draft-ietf-6lo-btle-07		<http://www.rfc-editor.org/info/rfc7668>.
	(work in progress), January 2015.
			[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		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		ARM Ltd.
			110 Fulbourn Road
			Cambridge CB1 9NJ
			United Kingdom
	Email: robert.cragie@gridmerge.com		Email: robert.cragie@arm.com
End of changes. 126 change blocks.
	416 lines changed or deleted		402 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/