< draft-ietf-roll-routing-dispatch-03.txt		draft-ietf-roll-routing-dispatch-04.txt >
	roll P. Thubert, Ed.		roll P. Thubert, Ed.
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track C. Bormann		Intended status: Standards Track C. Bormann
	Expires: April 28, 2017 Uni Bremen TZI		Expires: April 29, 2017 Uni Bremen TZI
	L. Toutain		L. Toutain
	IMT-TELECOM Bretagne		IMT-TELECOM Bretagne
	R. Cragie		R. Cragie
	ARM		ARM
	October 25, 2016		October 26, 2016
	6LoWPAN Routing Header		6LoWPAN Routing Header
	draft-ietf-roll-routing-dispatch-03		draft-ietf-roll-routing-dispatch-04
	Abstract		Abstract
	This specification introduces a new 6LoWPAN dispatch type for use in		This specification introduces a new 6LoWPAN dispatch type for use in
	6LoWPAN Route-Over topologies, that initially covers the needs of RPL		6LoWPAN Route-Over topologies, that initially covers the needs of RPL
	(RFC6550) data packets compression. Using this dispatch type, this		(RFC6550) data packets compression. Using this dispatch type, this
	specification defines a method to compress RPL Option (RFC6553)		specification defines a method to compress RPL Option (RFC6553)
	information and Routing Header type 3 (RFC6554), an efficient IP-in-		information and Routing Header type 3 (RFC6554), an efficient IP-in-
	IP technique and is extensible for more applications.		IP technique and is extensible for more applications.
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 April 28, 2017.		This Internet-Draft will expire on April 29, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 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
	skipping to change at page 1, line 134 ¶		skipping to change at page 1, line 134 ¶
	Innovative Route-over techniques have been and are still being		Innovative Route-over techniques have been and are still being
	developed for routing inside a LLN. In a general fashion, such		developed for routing inside a LLN. In a general fashion, such
	techniques require additional information in the packet to provide		techniques require additional information in the packet to provide
	loop prevention and to indicate information such as flow		loop prevention and to indicate information such as flow
	identification, source routing information, etc.		identification, source routing information, etc.
	For reasons such as security and the capability to send ICMPv6 errors		For reasons such as security and the capability to send ICMPv6 errors
	(see "Internet Control Message Protocol (ICMPv6)" [RFC4443]) back to		(see "Internet Control Message Protocol (ICMPv6)" [RFC4443]) back to
	the source, an original packet must not be tampered with, and any		the source, an original packet must not be tampered with, and any
	information that must be inserted in or removed from an IPv6 packet		information that must be inserted in or removed from an IPv6 packet
	must be placed in an extra IP-in-IP encapsulation .		must be placed in an extra IP-in-IP encapsulation.
	This is the case when the additional routing information is inserted		This is the case when the additional routing information is inserted
	by a router on the path of a packet, for instance the root of a mesh,		by a router on the path of a packet, for instance the root of a mesh,
	as opposed to the source node, with the non-storing mode of the "IPv6		as opposed to the source node, with the non-storing mode of the "IPv6
	Routing Protocol for Low-Power and Lossy Networks" [RFC6550] (RPL).		Routing Protocol for Low-Power and Lossy Networks" [RFC6550] (RPL).
	This is also the case when some routing information must be removed		This is also the case when some routing information must be removed
	from a packet that flows outside the LLN.		from a packet that flows outside the LLN.
	"When to use RFC 6553, RFC 6554 and IPv6-in-IPv6"		"When to use RFC 6553, RFC 6554 and IPv6-in-IPv6"
	skipping to change at page 1, line 201 ¶		skipping to change at page 1, line 201 ¶
	in packets entering the domain and be removed from packets that leave		in packets entering the domain and be removed from packets that leave
	the domain. In both cases, this operation implies an IP-in-IP		the domain. In both cases, this operation implies an IP-in-IP
	encapsulation.		encapsulation.
	Additionally, in the case of the Non-Storing Mode of Operation (MOP),		Additionally, in the case of the Non-Storing Mode of Operation (MOP),
	RPL requires a Source Routing Header (SRH) in all packets that are		RPL requires a Source Routing Header (SRH) in all packets that are
	routed down a RPL graph. for that purpose, the "IPv6 Routing Header		routed down a RPL graph. for that purpose, the "IPv6 Routing Header
	for Source Routes with RPL" [RFC6554] specification defines the type		for Source Routes with RPL" [RFC6554] specification defines the type
	3 Routing Header for IPv6 (RH3).		3 Routing Header for IPv6 (RH3).
	------+--------- ^		------+--------- ^
	| Internet |		| Internet |
	| | Native IPv6		| | Native IPv6
	+-----+ |		+-----+ |
	| | Border Router (RPL Root) ^ | ^		| | Border Router (RPL Root) + | +
	| | | | |		| | | | |
	+-----+ | | | IPv6 in		+-----+ | | | tunneled
	| | | | IPv6		| | | | using
	o o o o | | | plus		o o o o | | | IPv6-in-
	o o o o o o o o o | | | RPL SRH		o o o o o o o o o | | | IPv6 and
	o o o o o o o o o o | | |		o o o o o o o o o o | | | RPL SRH
	o o o o o o o o o | | |		o o o o o o o o o | | |
	o o o o o o o o v v v		o o o o o o o o | | |
	o o o o		o o o o + v +
	LLN		LLN
	Figure 2: IP-in-IP Encapsulation within the LLN.		Figure 2: IP-in-IP Encapsulation within the LLN.
	With Non-Storing RPL, even if the source is a node in the same LLN,		With Non-Storing RPL, even if the source is a node in the same LLN,
	the packet must first reach up the graph to the root so that the root		the packet must first reach up the graph to the root so that the root
	can insert the SRH to go down the graph. In any fashion, whether the		can insert the SRH to go down the graph. In any fashion, whether the
	packet was originated in a node in the LLN or outside the LLN, and		packet was originated in a node in the LLN or outside the LLN, and
	regardless of whether the packet stays within the LLN or not, as long		regardless of whether the packet stays within the LLN or not, as long
	as the source of the packet is not the root itself, the source-		as the source of the packet is not the root itself, the source-
	routing operation also implies an IP-in-IP encapsulation at the root		routing operation also implies an IP-in-IP encapsulation at the root
	skipping to change at page 29, line 7 ¶		skipping to change at page 29, line 7 ¶
	of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work		of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work
	in progress), June 2016.		in progress), June 2016.
	[I-D.ietf-roll-useofrplinfo]		[I-D.ietf-roll-useofrplinfo]
	Robles, I., Richardson, M., and P. Thubert, "When to use		Robles, I., Richardson, M., and P. Thubert, "When to use
	RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll-		RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll-
	useofrplinfo-09 (work in progress), October 2016.		useofrplinfo-09 (work in progress), October 2016.
	[I-D.thubert-6lo-forwarding-fragments]		[I-D.thubert-6lo-forwarding-fragments]
	Thubert, P. and J. Hui, "LLN Fragment Forwarding and		Thubert, P. and J. Hui, "LLN Fragment Forwarding and
	Recovery", draft-thubert-6lo-forwarding-fragments-02 (work		Recovery", draft-thubert-6lo-forwarding-fragments-03 (work
	in progress), November 2014.		in progress), October 2016.
	[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.		[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
	Bormann, "Neighbor Discovery Optimization for IPv6 over		Bormann, "Neighbor Discovery Optimization for IPv6 over
	Low-Power Wireless Personal Area Networks (6LoWPANs)",		Low-Power Wireless Personal Area Networks (6LoWPANs)",
	RFC 6775, DOI 10.17487/RFC6775, November 2012,		RFC 6775, DOI 10.17487/RFC6775, November 2012,
	<http://www.rfc-editor.org/info/rfc6775>.		<http://www.rfc-editor.org/info/rfc6775>.
	[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and		[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
	Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January		Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
	2014, <http://www.rfc-editor.org/info/rfc7102>.		2014, <http://www.rfc-editor.org/info/rfc7102>.
	skipping to change at page 32, line 12 ¶		skipping to change at page 32, line 12 ¶
	the DODAG are assigned from a same /112 prefix and the last 2 octets		the DODAG are assigned from a same /112 prefix and the last 2 octets
	encoding an identifier such as a IEEE 802.15.4 short address. In		encoding an identifier such as a IEEE 802.15.4 short address. In
	that case, all addresses can be compressed to 2 octets, using the		that case, all addresses can be compressed to 2 octets, using the
	root address as reference. There will be one SRH_6LoRH header, with,		root address as reference. There will be one SRH_6LoRH header, with,
	in this example, 3 compressed addresses:		in this example, 3 compressed addresses:
	+-+ ... -+-+ ... +-+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...		+-+ ... -+-+ ... +-+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
	|11110001|SRH-6LoRH| RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP		|11110001|SRH-6LoRH| RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP
	|Page 1 |Type1 S=2| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld		|Page 1 |Type1 S=2| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld
	+-+ ... -+-+ ... +-+- ... -+-+-- ... -+-+-+ ... +-+-+ ... -+ ... +-...		+-+ ... -+-+ ... +-+- ... -+-+-- ... -+-+-+ ... +-+-+ ... -+ ... +-...
	<-8bytes-> <- RFC 6282 ->		<-8bytes-> <- RFC 6282 ->
	No RPL artifact		No RPL artifact
	Figure 20: Example Compressed Packet with SRH.		Figure 20: Example Compressed Packet with SRH.
	One may note that the RPI is provided. This is because the address		One may note that the RPI is provided. This is because the address
	of the root that is the source of the IP-in-IP header is elided and		of the root that is the source of the IP-in-IP header is elided and
	inferred from the RPLInstanceID in the RPI. Once found from a local		inferred from the RPLInstanceID in the RPI. Once found from a local
	context, that address is used as Compression Reference to expand		context, that address is used as Compression Reference to expand
	addresses in the SRH-6LoRH.		addresses in the SRH-6LoRH.
End of changes. 8 change blocks.
	23 lines changed or deleted		23 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/