< draft-ietf-roll-useofrplinfo-11.txt		draft-ietf-roll-useofrplinfo-12.txt >
	ROLL Working Group M. Robles		ROLL Working Group M. Robles
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Updates: 6550 (if approved) M. Richardson		Updates: 6550 (if approved) M. Richardson
	Intended status: Standards Track SSW		Intended status: Standards Track SSW
	Expires: September 4, 2017 P. Thubert		Expires: September 14, 2017 P. Thubert
	Cisco		Cisco
	March 3, 2017		March 13, 2017
	When to use RFC 6553, 6554 and IPv6-in-IPv6		When to use RFC 6553, 6554 and IPv6-in-IPv6
	draft-ietf-roll-useofrplinfo-11		draft-ietf-roll-useofrplinfo-12
	Abstract		Abstract
	This document looks at different data flows through LLN (Low-Power		This document looks at different data flows through LLN (Low-Power
	and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power		and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power
	and Lossy Networks) is used to establish routing. The document		and Lossy Networks) is used to establish routing. The document
	enumerates the cases where RFC 6553, RFC 6554 and IPv6-in-IPv6		enumerates the cases where RFC 6553, RFC 6554 and IPv6-in-IPv6
	encapsulation is required. This analysis provides the basis on which		encapsulation is required. This analysis provides the basis on which
	to design efficient compression of these headers.		to design efficient compression of these headers.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 September 4, 2017.		This Internet-Draft will expire on September 14, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 49 ¶		skipping to change at page 2, line 49 ¶
	6.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf . . 27		6.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf . . 27
	6.10. Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf 28		6.10. Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf 28
	6.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 29		6.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 29
	6.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware-		6.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware-
	leaf . . . . . . . . . . . . . . . . . . . . . . . . . . 30		leaf . . . . . . . . . . . . . . . . . . . . . . . . . . 30
	7. Observations about the cases . . . . . . . . . . . . . . . . 31		7. Observations about the cases . . . . . . . . . . . . . . . . 31
	7.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 31		7.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 31
	7.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 32		7.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 32
	8. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 32		8. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 32
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 33		10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
	12.1. Normative References . . . . . . . . . . . . . . . . . . 35		12.1. Normative References . . . . . . . . . . . . . . . . . . 35
	12.2. Informative References . . . . . . . . . . . . . . . . . 36		12.2. Informative References . . . . . . . . . . . . . . . . . 36
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
	1. Introduction		1. Introduction
	RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks)		RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks)
	[RFC6550] is a routing protocol for constrained networks. RFC 6553		[RFC6550] is a routing protocol for constrained networks. RFC 6553
	skipping to change at page 13, line 48 ¶		skipping to change at page 13, line 48 ¶
	Note: In this use case we use a node as leaf, but this use case can		Note: In this use case we use a node as leaf, but this use case can
	be also applicable to any RPL-node type (e.g. 6LR)		be also applicable to any RPL-node type (e.g. 6LR)
	+-------------------+------+-------+------+----------------+		+-------------------+------+-------+------+----------------+
	| Header | 6LN | 6LR_i | 6LBR | Internet |		| Header | 6LN | 6LR_i | 6LBR | Internet |
	+-------------------+------+-------+------+----------------+		+-------------------+------+-------+------+----------------+
	| Inserted headers | RPI | -- | -- | -- |		| Inserted headers | RPI | -- | -- | -- |
	| Removed headers | -- | -- | -- | -- |		| Removed headers | -- | -- | -- | -- |
	| Re-added headers | -- | -- | -- | -- |		| Re-added headers | -- | -- | -- | -- |
	| Modified headers | -- | RPI | -- | -- |		| Modified headers | -- | RPI | -- | -- |
	| Untouched headers | -- | -- | -- | RPI (Ignored) |		| Untouched headers | -- | -- | RPI | RPI (Ignored) |
	+-------------------+------+-------+------+----------------+		+-------------------+------+-------+------+----------------+
	Storing: Summary of the use of headers from RPL-aware-leaf to		Storing: Summary of the use of headers from RPL-aware-leaf to
	Internet		Internet
	5.6. Example of Flow from Internet to RPL-aware-leaf		5.6. Example of Flow from Internet to RPL-aware-leaf
	In this case the flow comprises:		In this case the flow comprises:
	Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN)		Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN)
	skipping to change at page 15, line 45 ¶		skipping to change at page 15, line 45 ¶
	Internet		Internet
	5.8. Example of Flow from Internet to non-RPL-aware-leaf		5.8. Example of Flow from Internet to non-RPL-aware-leaf
	In this case the flow comprises:		In this case the flow comprises:
	Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6)		Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6)
	6LR_i are the intermediate routers from source to destination. In		6LR_i are the intermediate routers from source to destination. In
	this case, "1 < i >= n", n is the number of routers (6LR) that the		this case, "1 < i >= n", n is the number of routers (6LR) that the
	packet go through from 6LBR to not-RPL-aware-leaf (IPv6).		packet go through from 6LBR to not-RPL-aware-leaf (IPv6). 6LR_i
			updates the rank in the RPI.
	The 6LBR will have to add an RPI header within an IP-in-IP header.		The 6LBR will have to add an RPI header within an IP-in-IP header.
	The IP-in-IP can be addressed to the not-RPL-aware-leaf, leaving the		The IP-in-IP can be addressed to the not-RPL-aware-leaf, leaving the
	RPI inside.		RPI inside.
	The 6LBR MAY set the flow label on the inner IP-in-IP header to zero		The 6LBR MAY set the flow label on the inner IP-in-IP header to zero
	in order to aid in compression.		in order to aid in compression.
	+-----------+----------+---------------+---------------+------------+		+-----------+----------+---------------+---------------+------------+
	| Header | Internet | 6LBR | 6LR_i | IPv6 |		| Header | Internet | 6LBR | 6LR_i | IPv6 |
	+-----------+----------+---------------+---------------+------------+		+-----------+----------+---------------+---------------+------------+
	| Inserted | -- | IP-in-IP(RPI) | -- | -- |		| Inserted | -- | IP-in-IP(RPI) | -- | -- |
	| headers | | | | |		| headers | | | | |
	| Removed | -- | -- | IP-in-IP(RPI) | -- |		| Removed | -- | -- | -- | -- |
	| headers | | | | |		| headers | | | | |
	| Re-added | -- | -- | -- | -- |		| Re-added | -- | -- | -- | -- |
	| headers | | | | |		| headers | | | | |
	| Modified | -- | -- | IP-in-IP(RPI) | -- |		| Modified | -- | -- | IP-in-IP(RPI) | -- |
	| headers | | | | |		| headers | | | | |
	| Untouched | -- | -- | -- | RPI |		| Untouched | -- | -- | -- | RPI |
	| headers | | | | (Ignored) |		| headers | | | | (Ignored) |
	+-----------+----------+---------------+---------------+------------+		+-----------+----------+---------------+---------------+------------+
	Storing: Summary of the use of headers from Internet to non-RPL-		Storing: Summary of the use of headers from Internet to non-RPL-
	skipping to change at page 20, line 7 ¶		skipping to change at page 20, line 7 ¶
	dst).		dst).
	This flow is identical to Section 5.11		This flow is identical to Section 5.11
	The 6LR_1 receives the packet from the the IPv6 node and inserts the		The 6LR_1 receives the packet from the the IPv6 node and inserts the
	RPI header (RPIa) encapsulated in IPv6-in-IPv6 header. The IPv6-in-		RPI header (RPIa) encapsulated in IPv6-in-IPv6 header. The IPv6-in-
	IPv6 header is addressed to the 6LBR. The 6LBR remove the IPv6-in-		IPv6 header is addressed to the 6LBR. The 6LBR remove the IPv6-in-
	IPv6 header and insert another one (RPIb) with destination to 6LR_m		IPv6 header and insert another one (RPIb) with destination to 6LR_m
	node.		node.
			One of the side-effects of inserting IP-in-IP RPI header at 6LR_1, is
			that now all the packets will go through the 6LBR, even though there
			exists a shorter P2P path to the destination 6LN in storing mode.
			One possible solution is given by the work in
			[I-D.ietf-roll-dao-projection]. Once we have route projection, the
			root can find that this traffic deserves optimization (based on
			volume and path length, or additional knowledge on that particular
			flow) and project a DAO into 6LR_1.
	+-------+-----+-----------+-----------+-----------+-----------+-----+		+-------+-----+-----------+-----------+-----------+-----------+-----+
	| Heade | IPv | 6LR_1 | 6LR_ia | 6LBR | 6LR_m | IPv |		| Heade | IPv | 6LR_1 | 6LR_ia | 6LBR | 6LR_m | IPv |
	| r | 6 | | | | | 6 |		| r | 6 | | | | | 6 |
	| | src | | | | | dst |		| | src | | | | | dst |
	+-------+-----+-----------+-----------+-----------+-----------+-----+		+-------+-----+-----------+-----------+-----------+-----------+-----+
	| Inser | -- | IP-in- | -- | IP-in- | -- | -- |		| Inser | -- | IP-in- | -- | IP-in- | -- | -- |
	| ted h | | IP(RPI_a) | | IP(RPI_b) | | |		| ted h | | IP(RPI_a) | | IP(RPI_b) | | |
	| eader | | | | | | |		| eader | | | | | | |
	| s | | | | | | |		| s | | | | | | |
	| Remov | -- | -- | -- | -- | -- | -- |		| Remov | -- | -- | -- | -- | -- | -- |
	skipping to change at page 24, line 14 ¶		skipping to change at page 24, line 14 ¶
	+------------+------+---------------+---------------+---------------+		+------------+------+---------------+---------------+---------------+
	| Header | IPv6 | 6LR_1 | 6LR_i | 6LBR |		| Header | IPv6 | 6LR_1 | 6LR_i | 6LBR |
	+------------+------+---------------+---------------+---------------+		+------------+------+---------------+---------------+---------------+
	| Inserted | -- | IP-in-IP(RPI) | -- | -- |		| Inserted | -- | IP-in-IP(RPI) | -- | -- |
	| headers | | | | |		| headers | | | | |
	| Removed | -- | -- | -- | IP-in-IP(RPI) |		| Removed | -- | -- | -- | IP-in-IP(RPI) |
	| headers | | | | |		| headers | | | | |
	| Re-added | -- | -- | -- | -- |		| Re-added | -- | -- | -- | -- |
	| headers | | | | |		| headers | | | | |
	| Modified | -- | IP-in-IP(RPI) | IP-in-IP(RPI) | -- |		| Modified | -- | -- | IP-in-IP(RPI) | -- |
	| headers | | | | |		| headers | | | | |
	| Untouched | -- | -- | -- | -- |		| Untouched | -- | -- | -- | -- |
	| headers | | | | |		| headers | | | | |
	+------------+------+---------------+---------------+---------------+		+------------+------+---------------+---------------+---------------+
	Non Storing: Summary of the use of headers from not-RPL-aware-leaf to		Non Storing: Summary of the use of headers from not-RPL-aware-leaf to
	root		root
	6.5. Example of Flow from RPL-aware-leaf to Internet		6.5. Example of Flow from RPL-aware-leaf to Internet
	skipping to change at page 24, line 46 ¶		skipping to change at page 24, line 46 ¶
	the 6LBR will set it to a non-zero value when sending towards the		the 6LBR will set it to a non-zero value when sending towards the
	Internet.		Internet.
	+-------------------+------+-------+------+----------------+		+-------------------+------+-------+------+----------------+
	| Header | 6LN | 6LR_i | 6LBR | Internet |		| Header | 6LN | 6LR_i | 6LBR | Internet |
	+-------------------+------+-------+------+----------------+		+-------------------+------+-------+------+----------------+
	| Inserted headers | RPI | -- | -- | -- |		| Inserted headers | RPI | -- | -- | -- |
	| Removed headers | -- | -- | -- | -- |		| Removed headers | -- | -- | -- | -- |
	| Re-added headers | -- | -- | -- | -- |		| Re-added headers | -- | -- | -- | -- |
	| Modified headers | -- | RPI | -- | -- |		| Modified headers | -- | RPI | -- | -- |
	| Untouched headers | -- | -- | -- | RPI (Ignored) |		| Untouched headers | -- | -- | RPI | RPI (Ignored) |
	+-------------------+------+-------+------+----------------+		+-------------------+------+-------+------+----------------+
	Non Storing: Summary of the use of headers from RPL-aware-leaf to		Non Storing: Summary of the use of headers from RPL-aware-leaf to
	Internet		Internet
	6.6. Example of Flow from Internet to RPL-aware-leaf		6.6. Example of Flow from Internet to RPL-aware-leaf
	In this case the flow comprises:		In this case the flow comprises:
	Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN)		Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN)
	skipping to change at page 28, line 30 ¶		skipping to change at page 28, line 30 ¶
	+---------+-------------+------+--------------+-------+-------------+		+---------+-------------+------+--------------+-------+-------------+
	| Inserte | IP-in- | -- | IP-in-IP(RH3 | -- | -- |		| Inserte | IP-in- | -- | IP-in-IP(RH3 | -- | -- |
	| d | IP(RPI1) | | to 6LN, opt | | |		| d | IP(RPI1) | | to 6LN, opt | | |
	| headers | | | RPI2) | | |		| headers | | | RPI2) | | |
	| Removed | -- | -- | IP-in- | -- | IP-in- |		| Removed | -- | -- | IP-in- | -- | IP-in- |
	| headers | | | IP(RPI1) | | IP(RH3, opt |		| headers | | | IP(RPI1) | | IP(RH3, opt |
	| | | | | | RPI2) |		| | | | | | RPI2) |
	| Re- | -- | -- | -- | -- | -- |		| Re- | -- | -- | -- | -- | -- |
	| added | | | | | |		| added | | | | | |
	| headers | | | | | |		| headers | | | | | |
	| Modifie | -- | -- | -- | -- | -- |		| Modifie | -- | RPI1 | -- | RPI2 | -- |
	| d | | | | | |		| d | | | | | |
	| headers | | | | | |		| headers | | | | | |
	| Untouch | -- | -- | -- | -- | -- |		| Untouch | -- | -- | -- | -- | -- |
	| ed | | | | | |		| ed | | | | | |
	| headers | | | | | |		| headers | | | | | |
	+---------+-------------+------+--------------+-------+-------------+		+---------+-------------+------+--------------+-------+-------------+
	Non Storing: Summary of the use of headers for RPL-aware-leaf to RPL-		Non Storing: Summary of the use of headers for RPL-aware-leaf to RPL-
	aware-leaf		aware-leaf
	skipping to change at page 31, line 41 ¶		skipping to change at page 31, line 41 ¶
	7.1. Storing mode		7.1. Storing mode
	[I-D.ietf-roll-routing-dispatch] shows that the hop-by-hop IP-in-IP		[I-D.ietf-roll-routing-dispatch] shows that the hop-by-hop IP-in-IP
	header can be compressed using IP-in-IP 6LoRH (IP-in-IP-6LoRH) header		header can be compressed using IP-in-IP 6LoRH (IP-in-IP-6LoRH) header
	as described in Section 7 of the document.		as described in Section 7 of the document.
	There are potential significant advantages to having a single code		There are potential significant advantages to having a single code
	path that always processes IP-in-IP headers with no options.		path that always processes IP-in-IP headers with no options.
	Thanks to the relaxation of the RFC2406 rule about discarding unknown		Thanks to the relaxation of the RFC2460 rule about discarding unknown
	Hop-by-Hop options, there is no longer any uncertainty about when to		Hop-by-Hop options, there is no longer any uncertainty about when to
	use an IPIP header in the storing mode case. The RPI header SHOULD		use an IPIP header in the storing mode case. The RPI header SHOULD
	always be added when 6LRs originate packets (without IPIP headers),		always be added when 6LRs originate packets (without IPIP headers),
	and IPIP headers should always be added (addressed to the root when		and IPIP headers should always be added (addressed to the root when
	on the way up, to the end-host when on the way down) when a 6LR finds		on the way up, to the end-host when on the way down) when a 6LR finds
	it needs to insert an RPI header.		it needs to insert an RPI header.
	In order to support the above two cases with full generality, the		In order to support the above two cases with full generality, the
	different situations (always do IP-in-IP vs never use IP-in-IP)		different situations (always do IP-in-IP vs never use IP-in-IP)
	should be signaled in the RPL protocol itself.		should be signaled in the RPL protocol itself.
	skipping to change at page 32, line 17 ¶		skipping to change at page 32, line 17 ¶
	In the non-storing case, dealing with non-RPL aware leaf nodes is		In the non-storing case, dealing with non-RPL aware leaf nodes is
	much easier as the 6LBR (DODAG root) has complete knowledge about the		much easier as the 6LBR (DODAG root) has complete knowledge about the
	connectivity of all DODAG nodes, and all traffic flows through the		connectivity of all DODAG nodes, and all traffic flows through the
	root node.		root node.
	The 6LBR can recognize non-RPL aware leaf nodes because it will		The 6LBR can recognize non-RPL aware leaf nodes because it will
	receive a DAO about that node from the 6LN immediately above that		receive a DAO about that node from the 6LN immediately above that
	node. This means that the non-storing mode case can avoid ever using		node. This means that the non-storing mode case can avoid ever using
	hop-by-hop IP-in-IP headers.		hop-by-hop IP-in-IP headers.
	[I-D.ietf-roll-routing-dispatch] shows how the destination=root, and
	destination=6LN IP-in-IP header can be compressed down to {TBD}
	bytes.
	Unlike in the storing mode case, there is no need for all nodes to		Unlike in the storing mode case, there is no need for all nodes to
	know about the existence of non-RPL aware nodes. Only the 6LBR needs		know about the existence of non-RPL aware nodes. Only the 6LBR needs
	to change when there are non-RPL aware nodes. Further, in the non-		to change when there are non-RPL aware nodes. Further, in the non-
	storing case, the 6LBR is informed by the DAOs when there are non-RPL		storing case, the 6LBR is informed by the DAOs when there are non-RPL
	aware nodes.		aware nodes.
	8. 6LoRH Compression cases		8. 6LoRH Compression cases
	The [I-D.ietf-roll-routing-dispatch] proposes a compression method		The [I-D.ietf-roll-routing-dispatch] proposes a compression method
	for RPI, RH3 and IPv6-in-IPv6.		for RPI, RH3 and IPv6-in-IPv6.
	skipping to change at page 35, line 31 ¶		skipping to change at page 35, line 23 ¶
	[RFC7416] deals with many other threats to LLNs not directly related		[RFC7416] deals with many other threats to LLNs not directly related
	to the use of IPIP headers, and this document does not change that		to the use of IPIP headers, and this document does not change that
	analysis.		analysis.
	11. Acknowledgments		11. Acknowledgments
	This work is partially funded by the FP7 Marie Curie Initial Training		This work is partially funded by the FP7 Marie Curie Initial Training
	Network (ITN) METRICS project (grant agreement No. 607728).		Network (ITN) METRICS project (grant agreement No. 607728).
	The authors would like to acknowledge the review, feedback, and		The authors would like to acknowledge the review, feedback, and
	comments of Robert Cragie, Simon Duquennoy, Cenk Guendogan, Peter van		comments of (alphabetical order): Robert Cragie, Simon Duquennoy,
	der Stok, Xavier Vilajosana and Thomas Watteyne.		Cenk Guendogan, Rahul Jadhav, Peter van der Stok, Xavier Vilajosana
			and Thomas Watteyne.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[I-D.ietf-6man-rfc2460bis]		[I-D.ietf-6man-rfc2460bis]
	Deering, S. and R. Hinden, "Internet Protocol, Version 6		Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", draft-ietf-6man-rfc2460bis-08 (work		(IPv6) Specification", draft-ietf-6man-rfc2460bis-08 (work
	in progress), November 2016.		in progress), November 2016.
	skipping to change at page 37, line 32 ¶		skipping to change at page 37, line 26 ¶
	Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic		Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic
	Control Plane", draft-ietf-anima-autonomic-control-		Control Plane", draft-ietf-anima-autonomic-control-
	plane-05 (work in progress), January 2017.		plane-05 (work in progress), January 2017.
	[I-D.ietf-anima-bootstrapping-keyinfra]		[I-D.ietf-anima-bootstrapping-keyinfra]
	Pritikin, M., Richardson, M., Behringer, M., Bjarnason,		Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
	S., and K. Watsen, "Bootstrapping Remote Secure Key		S., and K. Watsen, "Bootstrapping Remote Secure Key
	Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-		Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
	keyinfra-04 (work in progress), October 2016.		keyinfra-04 (work in progress), October 2016.
			[I-D.ietf-roll-dao-projection]
			Thubert, P. and J. Pylakutty, "Root initiated routing
			state in RPL", draft-ietf-roll-dao-projection-01 (work in
			progress), March 2017.
	[I-D.ietf-roll-routing-dispatch]		[I-D.ietf-roll-routing-dispatch]
	Thubert, P., Bormann, C., Toutain, L., and R. Cragie,		Thubert, P., Bormann, C., Toutain, L., and R. Cragie,
	"6LoWPAN Routing Header", draft-ietf-roll-routing-		"6LoWPAN Routing Header", draft-ietf-roll-routing-
	dispatch-05 (work in progress), October 2016.		dispatch-05 (work in progress), October 2016.
	[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet		[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
	Control Message Protocol (ICMPv6) for the Internet		Control Message Protocol (ICMPv6) for the Internet
	Protocol Version 6 (IPv6) Specification", RFC 4443,		Protocol Version 6 (IPv6) Specification", RFC 4443,
	DOI 10.17487/RFC4443, March 2006,		DOI 10.17487/RFC4443, March 2006,
	<http://www.rfc-editor.org/info/rfc4443>.		<http://www.rfc-editor.org/info/rfc4443>.
End of changes. 16 change blocks.
	18 lines changed or deleted		30 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/