draft-ietf-roll-admin-local-policy-00.txt		draft-ietf-roll-admin-local-policy-01.txt
	roll P. van der Stok		roll P. van der Stok
	Internet-Draft Consultant		Internet-Draft Consultant
	Intended status: Informational R. Cragie		Intended status: Informational R. Cragie
	Expires: October 10, 2014 Gridmerge		Expires: April 25, 2015 Gridmerge
	April 8, 2014		October 22, 2014
	MPL forwarder policy for multicast with admin-local scope		MPL forwarder policy for multicast with admin-local scope
	draft-ietf-roll-admin-local-policy-00		draft-ietf-roll-admin-local-policy-01
	Abstract		Abstract
	The purpose of this document is to specify an automated policy for		The purpose of this document is to specify an automated policy for
	the routing of MPL multicast messages with admin-local scope in a		the routing of MPL multicast messages with admin-local scope in a
	border router.		border router.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 33		skipping to change at page 1, line 33
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on October 10, 2014.		This Internet-Draft will expire on April 25, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	skipping to change at page 2, line 19		skipping to change at page 2, line 19
	1.2. Terminology and Acronyms . . . . . . . . . . . . . . . . 3		1.2. Terminology and Acronyms . . . . . . . . . . . . . . . . 3
	2. Network identifier . . . . . . . . . . . . . . . . . . . . . 4		2. Network identifier . . . . . . . . . . . . . . . . . . . . . 4
	2.1. IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . 4		2.1. IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . 4
	2.2. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . 4		2.2. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . 4
	2.3. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 4		2.3. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 4
	2.4. BLUETOOTH Low Energy . . . . . . . . . . . . . . . . . . 5		2.4. BLUETOOTH Low Energy . . . . . . . . . . . . . . . . . . 5
	3. MPL4 router . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. MPL4 router . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. MPL interface parameters . . . . . . . . . . . . . . . . 5		3.1. MPL interface parameters . . . . . . . . . . . . . . . . 5
	3.2. Determination of MPL zone . . . . . . . . . . . . . . . . 5		3.2. Determination of MPL zone . . . . . . . . . . . . . . . . 5
	4. Admin-Local policy . . . . . . . . . . . . . . . . . . . . . 6		4. Admin-Local policy . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Legal multicast messages . . . . . . . . . . . . . . . . 7		4.1. Legal multicast messages . . . . . . . . . . . . . . . . 6
	4.2. Forwarding legal packets . . . . . . . . . . . . . . . . 7		4.2. Forwarding legal packets . . . . . . . . . . . . . . . . 7
	4.2.1. MPL message . . . . . . . . . . . . . . . . . . . . . 7		4.2.1. MPL message . . . . . . . . . . . . . . . . . . . . . 7
	4.2.2. Multicast messages without MPL option . . . . . . . . 8		4.2.2. Multicast messages without MPL option . . . . . . . . 8
	5. MPL domains and zones . . . . . . . . . . . . . . . . . . . . 8		5. MPL domains and zones . . . . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Default parameter values . . . . . . . . . . . . . . . . . . 9
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	9. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 9		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		10. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10.1. Normative References . . . . . . . . . . . . . . . . . . 9		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10.2. Informative References . . . . . . . . . . . . . . . . . 11		11.1. Normative References . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		11.2. Informative References . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	Multicast scopes are defined in [RFC4291]. The		Multicast scopes are defined in [RFC4291]. The [RFC7346] extends the
	[I-D.ietf-6man-multicast-scopes] extends the scope definition with		scope definition with the text:
	the text:
	"Interface-Local, Link-Local, and Realm-Local scope boundaries are		"Interface-Local, Link-Local, and Realm-Local scope boundaries are
	automatically derived from physical connectivity or other, non-		automatically derived from physical connectivity or other, non-
	multicast related configuration. Global scope has no boundary. The		multicast related configuration. Global scope has no boundary. The
	boundaries of all other non-reserved scopes of Admin-Local or larger		boundaries of all other non-reserved scopes of Admin-Local or larger
	are administratively configured."		are administratively configured."
	The admin-local scope must therefore be administratively configured.		The admin-local scope must therefore be administratively configured.
	This draft describes an automated policy for the MPL forwarding of		This draft describes an automated policy for the MPL forwarding of
	multicast messages with admin-local scope within a border router.		multicast messages with admin-local scope within a border router.
			This wish is in line with the autonomous networking ideas presented
			in [I-D.irtf-nmrg-an-gap-analysis].
	The realm-local multicast address is currently used by MPL to		The realm-local multicast address is currently used by MPL to
	propagate the multicast message to all receivers and forwarders		propagate the multicast message to all receivers and forwarders
	within a mesh network. The multicast propagation is limited to a		within a mesh network. The multicast propagation is limited to a
	mesh network with a common layer-2. For example, a LoWPAN is defined		mesh network with a common layer-2. For example, a LoWPAN is defined
	by an IEEE 802.15.4 layer-2 mesh network, composed of all connected		by an IEEE 802.15.4 layer-2 mesh network, composed of all connected
	nodes sharing the same PAN ID [RFC4944].		nodes sharing the same 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
	skipping to change at page 3, line 36		skipping to change at page 3, line 38
	connected to links that connect to other MPL enabled interfaces. The		connected to links that connect to other MPL enabled interfaces. The
	MPL4 router enables all its interfaces for MPL messages and allocates		MPL4 router enables all its interfaces for MPL messages and allocates
	an additional variable MPL_BLOCKED that permits(forbids) the		an additional variable MPL_BLOCKED that permits(forbids) the
	forwarding of MPL messages.		forwarding of MPL messages.
	It is expected that the network of an organization, building, or		It is expected that the network of an organization, building, or
	home, is connected to the Internet via the edge routers provided by		home, is connected to the Internet via the edge routers provided by
	an ISP. The intention is that within the network of an organization,		an ISP. The intention is that within the network of an organization,
	building, or home, MPL messages with multicast addresses of admin-		building, or home, MPL messages with multicast addresses of admin-
	local scope are freely forwarded but are never forwarded to edge		local scope are freely forwarded but are never forwarded to edge
	routers which do not enable their interfaces for MPL messages.		routers which MUST not enable their interfaces for MPL messages.
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	1.2. Terminology and Acronyms		1.2. Terminology and Acronyms
	This document uses terminology defined in		This document uses terminology defined in
	[I-D.ietf-roll-trickle-mcast] and [I-D.ietf-6man-multicast-scopes].		[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 message: an MPL DATA message with a destination multicast		o MPL4 message: an MPL DATA message with a destination multicast
	address of scope 4.		address of scope 4.
	o MPL4 router: automatically determines the zone in which MPL		o MPL4 router: automatically determines the zone in which MPL
	messages with admin-local scope can be propagated.		messages with admin-local scope can be propagated.
	o MPL4 zone: a convex zone of interconnected interfaces over which		o MPL4 zone: a convex zone of interconnected interfaces over which
	MPL messages with admin-local scope propagate. [RFC4007].		MPL messages with admin-local scope propagate. [RFC4007].
	skipping to change at page 6, line 22		skipping to change at page 6, line 22
	set to false.		set to false.
	This protocol leads to a state where for each interface MPL_BLOCKED		This protocol leads to a state where for each interface MPL_BLOCKED
	is set to false if and only if MPL enabled interfaces are connected		is set to false if and only if MPL enabled interfaces are connected
	to the link associated with the interface. When an MPL message is		to the link associated with the interface. When an MPL message is
	submitted to an MPL-enabled interface -called A- in the MPL router,		submitted to an MPL-enabled interface -called A- in the MPL router,
	the TRICKLE algorithm is activated to send the MPL message. The MPL4		the TRICKLE algorithm is activated to send the MPL message. The MPL4
	message with multicast address ALL_MPL_FORWARDERS scope 4 is accepted		message with multicast address ALL_MPL_FORWARDERS scope 4 is accepted
	by every interface connected to the link that has subscribed to		by every interface connected to the link that has subscribed to
	ALL_MPL_FORWARDERS with scope 4. On acceptance of the MPL4 message		ALL_MPL_FORWARDERS with scope 4. On acceptance of the MPL4 message
	by interface B, the MPL4 message is returned with Trickle over		by an interface -called B-, the MPL4 message is returned with Trickle
	interface B. Consequently, the MPL4 message is received by the		over interface B. Consequently, the MPL4 message is received by the
	originating interface A, after which MPL_BLOCKED is set to false.		originating interface A, after which MPL_BLOCKED is set to false.
	When a new node is connected to the link, it can immediately send an		When a new node is connected to the link, it can immediately send an
	MPL4 message, or can wait for the reception of an MPL4 message to		MPL4 message, or can wait for the reception of an MPL4 message to
	announce its intention to be part of the MPL zone.		announce its intention to be part of the MPL zone.
	TODO?: payload of message used for MPL parameter value negotiation.
	4. Admin-Local policy		4. Admin-Local policy
	The section starts with specifying what multicast messages arriving		The section starts with specifying what multicast messages arriving
	at an interface are legal. It continues with a description of		at an interface are legal. It continues with a description of
	forwarding legal admin-local multicast messages over other MPL		forwarding legal admin-local multicast messages over other MPL
	interfaces.		interfaces.
	The policy for forwarding admin-local multicast messages		The policy for forwarding admin-local multicast messages
	automatically to a MPL interface is specified as function of the		automatically to a MPL interface is specified as function of the
	state of the MPL interface and the multicast message. The state of		state of the MPL interface and the multicast message. The state of
	skipping to change at page 7, line 19		skipping to change at page 7, line 14
	A multicast message created at a source (MPL seed) is legal when it		A multicast message created at a source (MPL seed) is legal when it
	conforms to the properties described in section 9.1 of		conforms to the properties described in section 9.1 of
	[I-D.ietf-roll-trickle-mcast].		[I-D.ietf-roll-trickle-mcast].
	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 and the interface has		o The message does not carry an MPL option, the multicast address is
	expressed interest to receive messages with the specified		unequal to ALL_MPL_FORWARDERS scope 4 or scope 3, and the
	multicast address via MLD [RFC3810] or via IGMP [RFC3376]. The		interface has expressed interest to receive messages with the
	message was sent on according to PIM-DM [RFC3973] or according to		specified multicast address via MLD [RFC3810] or via IGMP
	PIM-SM [RFC4601].		[RFC3376]. The message was sent on according to PIM-DM [RFC3973]
			or according to 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 locally is assigned the network identifier		message that is created within the node is assigned the network
	"any".		identifier "any".
	Two types of legal multicast messages are considered: (1) MPL		Two types of legal multicast messages are considered: (1) MPL
	messages, and (2) multicast messages which do not carry the MPL		messages, and (2) multicast messages which 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:
	skipping to change at page 8, line 10		skipping to change at page 8, line 5
	have PROACTIVE-FORWARDING set to true, and the assigned network		have PROACTIVE-FORWARDING set to true, and the assigned network
	identifier of the multicast message is identical to the network		identifier of the multicast message is identical to the network
	identifier of the MPL interface, or the assigned network		identifier of the MPL interface, or the assigned network
	identifier of the multicast message is "any".		identifier of the multicast message is "any".
	o Admin-local (scope 4) MPL messages are forwarded on all MPL		o Admin-local (scope 4) MPL messages are forwarded on all MPL
	interfaces that are subscribed to the same multicast address, have		interfaces that are subscribed to the same multicast address, have
	PROACTIVE-FORWARDING set to true, and have MPL_BLOCKED set to		PROACTIVE-FORWARDING set to true, and have MPL_BLOCKED set to
	false.		false.
	o MPL messages with a multicast scope of 5 or higher are out of		o MPL messages with a multicast scope of 5 or higher MUST
	scope for this specification. (TODO: decapsulation of MPL		encapsulate a message with the same multicast address without MPL
	option?)		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		4.2.2. Multicast messages without MPL option
	Multicast messages without MPL option are forwarded on MPL interfaces		Multicast messages without MPL option are forwarded on MPL interfaces
	according to the following rules:		according to the following rules:
	o Link-local (scope 2) messages or realm-local (scope 3) multicast		o Link-local (scope 2) messages or realm-local (scope 3) multicast
	messages are not forwarded.		messages are not forwarded.
	o Admin-local (scope 4) multicast messages are encapsulated with a		o Admin-local (scope 4) multicast messages are encapsulated with a
	header carrying the MPL option and are forwarded on al MPL		header carrying the MPL option and are forwarded on al MPL
	interfaces that are subscribed to the multicast address, have		interfaces that are subscribed to the multicast address, have
	PROACTIVE_FORWARDING set to true, and have MPL_BLOCKED set to		PROACTIVE_FORWARDING set to true, and have MPL_BLOCKED set to
	false.		false.
	o Multicast messages with a multicast scope of 5 or higher follow		o Multicast messages with a multicast scope of 5 or higher are
	the Multicast forwarding rules as specified by PIM [RFC3973],		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		[RFC4601] according to group specifications enabled by MLD
	[RFC3810] or IGMP [RFC3376].		[RFC3810] or IGMP [RFC3376].
	5. MPL domains and zones		5. MPL domains and zones
	An MPL domain is a scope zone in which MPL interfaces subscribe to		An MPL domain is a scope zone in which MPL interfaces subscribe to
	the same MPL Domain Address [I-D.ietf-roll-trickle-mcast]. In		the same MPL Domain Address [I-D.ietf-roll-trickle-mcast]. In
	accordance with [RFC4007] a zone boundary passes through a node. For		accordance with [RFC4007] a zone boundary passes through a node. For
	example, a small LLN node usually has one MPL mesh interface which is		example, a small LLN node usually has one MPL mesh interface which is
	enabled to the ALL_MPL_FORWARDERS multicast address with a scope		enabled to the ALL_MPL_FORWARDERS multicast address with a scope
	value of 3 (realm-local) [I-D.ietf-6man-multicast-scopes]. The node		value of 3 (realm-local) [RFC7346]. The node interface belongs to
	interface belongs to the zone and the corresponding zone boundary		the zone and the corresponding zone boundary does not pass through
	does not pass through this node. In the border router with MPL		this node. In the border router with MPL interfaces enabled to the
	interfaces enabled to the multicast address ALL_MPL_FORWARDERS with		multicast address ALL_MPL_FORWARDERS with scope value 3, the zone
	scope value 3, the zone includes usually this single interface and		includes usually this single interface and excludes all other
	excludes all other interfaces. A notable exception is provided by a		interfaces. A notable exception is provided by a node where MPL
	node where MPL interfaces of the same technology share the same		interfaces of the same technology share the same network identifier.
	network identifier. These interfaces belong to the same zone.		These interfaces belong to the same zone.
	In an MPL4 router, every MPL interface subscribes to the admin_local		In an MPL4 router, every MPL interface subscribes to the admin_local
	ALL_MPL_FORWARDERS multicast address next to the realm-local		ALL_MPL_FORWARDERS multicast address next to the realm-local
	ALL_MPL_FORWARDERS address.		ALL_MPL_FORWARDERS address.
	Every interface that belongs to an MPL domain that extends over		Every interface that belongs to an MPL domain that extends over
	border routers MUST subscribe the admin-local ALL_MPL_FORWARDERS		border routers MUST be subscribed to the admin-local
	address.		ALL_MPL_FORWARDERS address.
	The zone corresponding with the MPL multicast address		The zone corresponding with the MPL multicast address
	ALL_MPL_FORWARDERS with scope 4 (Admin-local) applies to border		ALL_MPL_FORWARDERS with scope 4 (Admin-local) applies to border
	routers with multiple interfaces, of which at least one interface is		routers with multiple interfaces, of which at least one interface is
	MPL enabled and is subscribed to multicast address ALL_MPL_FORWARDERS		MPL enabled and is subscribed to multicast address ALL_MPL_FORWARDERS
	with scope 4. In a border router, all MPL enabled interfaces which		with scope 4. In a border router, all MPL enabled interfaces which
	subscribe to the ALL_MPL_FORWARDERS address with scope 4 and for		subscribe to the ALL_MPL_FORWARDERS address with scope 4 and for
	which MPL_BLOCKED is false belong to the same zone.		which MPL_BLOCKED is false belong to the same zone.
	6. Security Considerations		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 must have
			received MPL-enabled messages to include the interface to the zone.
			7. Security Considerations
	Refer to the security considerations of		Refer to the security considerations of
	[I-D.ietf-roll-trickle-mcast].		[I-D.ietf-roll-trickle-mcast].
	7. IANA Considerations		MPL enabled interfaces MUST subscribe to the ALL_MPL_FORWARDERS
			address with scope 3 and scope 4. In the latter case the nodes may
			become flooded by multicast messages with as destination
			ALL_MPL_FORWARDERS address with scope 4 coming from outside the zone
			corresponding with the connected mesh networks. Therefore, Multicast
			messages with address ALL_MPL_FORWADERS scope 4 and scope 3 cannot be
			forwarded from sources out of the zone corresponding with the scope 4
			address.
			The enabling of the interfaces for a given set of multicast addresses
			and the setting of the MPL parameter values must be done in a secure
			way, such that they cannot be set or modified by unauthorized nodes.
			That means a setting of the parameters with secured means, or
			initializing the parameter values in the factory without
			possibilities for change afterwards.
			8. IANA Considerations
	No considerations for IANA are formulated in this document.		No considerations for IANA are formulated in this document.
	8. Acknowledgements		9. Acknowledgements
	This document reflects discussions and remarks from several		This document reflects discussions and remarks from several
	individuals including (in alphabetical order): Esko Dijk, Matthew		individuals including (in alphabetical order): Esko Dijk, Matthew
	Gillmore, and Michael Richardson.		Gillmore, Michael Richardson, and Pascal Thubert.
	9. Change log		10. Change log
	Changes from personal version to WG version.		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		o Aligned terminology with MPL terminology
	[I-D.ietf-roll-trickle-mcast]		[I-D.ietf-roll-trickle-mcast]
	o Text on MPL4 router included		o Text on MPL4 router included
	10. References		11. References
	10.1. Normative References		11.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, March 1997.
	[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery		[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
	Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.		Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
	[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, February 2006.
	skipping to change at page 10, line 21		skipping to change at page 11, line 17
	3", RFC 3376, October 2002.		3", RFC 3376, October 2002.
	[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and		[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
	B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,		B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
	March 2005.		March 2005.
	[RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and		[RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and
	Provisioning of Wireless Access Points (CAPWAP) Protocol		Provisioning of Wireless Access Points (CAPWAP) Protocol
	Binding for IEEE 802.11", RFC 5416, March 2009.		Binding for IEEE 802.11", RFC 5416, March 2009.
	[I-D.ietf-6lo-lowpanz]		[RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,
	Brandt, A. and J. Buron, "Transmission of IPv6 packets		August 2014.
	over ITU-T G.9959 Networks", draft-ietf-6lo-lowpanz-04
	(work in progress), March 2014.
	[I-D.ietf-roll-trickle-mcast]		[I-D.ietf-roll-trickle-mcast]
	Hui, J. and R. Kelsey, "Multicast Protocol for Low power		Hui, J. and R. Kelsey, "Multicast Protocol for Low power
	and Lossy Networks (MPL)", draft-ietf-roll-trickle-		and Lossy Networks (MPL)", draft-ietf-roll-trickle-
	mcast-08 (work in progress), March 2014.		mcast-09 (work in progress), April 2014.
	[I-D.ietf-6man-multicast-scopes]
	Droms, R., "IPv6 Multicast Address Scopes", draft-ietf-
	6man-multicast-scopes-04 (work in progress), March 2014.
	[I-D.ietf-6lo-btle]
	Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
	Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets
	over BLUETOOTH Low Energy", draft-ietf-6lo-btle-00 (work
	in progress), November 2013.
	[IEEE802.15.4]		[IEEE802.15.4]
	"IEEE 802.15.4 - Standard for Local and metropolitan area		"IEEE 802.15.4 - Standard for Local and metropolitan area
	networks -- Part 15.4: Low-Rate Wireless Personal Area		networks -- Part 15.4: Low-Rate Wireless Personal Area
	Networks", <IEEE Standard 802.15.4>.		Networks", <IEEE Standard 802.15.4>.
	[IEEE802.11]		[IEEE802.11]
	"IEEE 802.11 - Telecommunications and information exchange		"IEEE 802.11 - Telecommunications and information exchange
	between systems Local and metropolitan area networks --		between systems Local and metropolitan area networks --
	Part 11: Wireless LAN Medium Access Control (MAC) and		Part 11: Wireless LAN Medium Access Control (MAC) and
	Physical Layer (PHY) Specifications", <IEEE Standard		Physical Layer (PHY) Specifications", <IEEE Standard
	802.11>.		802.11>.
	[G.9959] "ITU-T G.9959 Short range narrow-band digital		[G.9959] "ITU-T G.9959 Short range narrow-band digital
	radiocommunication transceivers - PHY and MAC layer		radiocommunication transceivers - PHY and MAC layer
	specifications", <ITU-T G.9959>.		specifications", <ITU-T G.9959>.
	[btle] "BLUETOOTH Specification Version 4.0", <BLUETOOTH low		[btle] "BLUETOOTH Specification Version 4.0", <BLUETOOTH low
	energy>.		energy>.
	10.2. Informative References		11.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, January 2005.
	[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,		[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
	"Protocol Independent Multicast - Sparse Mode (PIM-SM):		"Protocol Independent Multicast - Sparse Mode (PIM-SM):
	Protocol Specification (Revised)", RFC 4601, August 2006.		Protocol Specification (Revised)", RFC 4601, August 2006.
			[I-D.irtf-nmrg-an-gap-analysis]
			Jiang, S., Carpenter, B., and M. Behringer, "Gap Analysis
			for Autonomic Networking", draft-irtf-nmrg-an-gap-
			analysis-02 (work in progress), October 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-07
			(work in progress), September 2014.
			[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-03
			(work in progress), September 2014.
	Authors' Addresses		Authors' Addresses
	Peter van der Stok		Peter van der Stok
	Consultant		Consultant
	Email: consultancy@vanderstok.org		Email: consultancy@vanderstok.org
	Robert Cragie		Robert Cragie
	Gridmerge		Gridmerge
End of changes. 29 change blocks.
	69 lines changed or deleted		121 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/