< draft-ietf-lpwan-ipv6-static-context-hc-22.txt		draft-ietf-lpwan-ipv6-static-context-hc-23.txt >
	lpwan Working Group A. Minaburo		lpwan Working Group A. Minaburo
	Internet-Draft Acklio		Internet-Draft Acklio
	Intended status: Standards Track L. Toutain		Intended status: Standards Track L. Toutain
	Expires: May 3, 2020 IMT-Atlantique		Expires: May 31, 2020 IMT-Atlantique
	C. Gomez		C. Gomez
	Universitat Politecnica de Catalunya		Universitat Politecnica de Catalunya
	D. Barthel		D. Barthel
	Orange Labs		Orange Labs
	JC. Zuniga		JC. Zuniga
	SIGFOX		SIGFOX
	October 31, 2019		November 28, 2019
	Static Context Header Compression (SCHC) and fragmentation for LPWAN,		Static Context Header Compression (SCHC) and fragmentation for LPWAN,
	application to UDP/IPv6		application to UDP/IPv6
	draft-ietf-lpwan-ipv6-static-context-hc-22		draft-ietf-lpwan-ipv6-static-context-hc-23
	Abstract		Abstract
	This document defines the Static Context Header Compression (SCHC)		This document defines the Static Context Header Compression (SCHC)
	framework, which provides both header compression and fragmentation		framework, which provides both a header compression mechanism and an
	functionalities. SCHC has been designed for Low Power Wide Area		optional fragmentation mechanism. SCHC has been designed for Low
	Networks (LPWAN).		Power Wide Area Networks (LPWAN).
	SCHC compression is based on a common static context stored both in		SCHC compression is based on a common static context stored both in
	the LPWAN device and in the network infrastructure side. This		the LPWAN device and in the network infrastructure side. This
	document defines a header compression mechanism and its application		document defines a generic header compression mechanism and its
	to compress IPv6/UDP headers.		application to compress IPv6/UDP headers.
	This document also specifies a fragmentation and reassembly mechanism		This document also specifies an optional fragmentation and reassembly
	that is used to support the IPv6 MTU requirement over the LPWAN		mechanism. It can be used to support the IPv6 MTU requirement over
	technologies. Fragmentation is needed for IPv6 datagrams that, after		the LPWAN technologies. Fragmentation is needed for IPv6 datagrams
	SCHC compression or when such compression was not possible, still		that, after SCHC compression or when such compression was not
	exceed the layer-2 maximum payload size.		possible, still exceed the layer-2 maximum payload size.
	The SCHC header compression and fragmentation mechanisms are		The SCHC header compression and fragmentation mechanisms are
	independent of the specific LPWAN technology over which they are		independent of the specific LPWAN technology over which they are
	used. This document defines generic functionalities and offers		used. This document defines generic functionalities and offers
	flexibility with regard to parameter settings and mechanism choices.		flexibility with regard to parameter settings and mechanism choices.
	This document standardizes the exchange over the LPWAN between two		This document standardizes the exchange over the LPWAN between two
	SCHC entities. Settings and choices specific to a technology or a		SCHC entities. Settings and choices specific to a technology or a
	product are expected to be grouped into profiles, which are specified		product are expected to be grouped into profiles, which are specified
	in other documents. Data models for the context and profiles are out		in other documents. Data models for the context and profiles are out
	of scope.		of scope.
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 May 3, 2020.		This Internet-Draft will expire on May 31, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 4, line 17 ¶		skipping to change at page 4, line 17 ¶
	12.2.1. Buffer reservation attack . . . . . . . . . . . . . 58		12.2.1. Buffer reservation attack . . . . . . . . . . . . . 58
	12.2.2. Corrupt Fragment attack . . . . . . . . . . . . . . 59		12.2.2. Corrupt Fragment attack . . . . . . . . . . . . . . 59
	12.2.3. Fragmentation as a way to bypass Network Inspection 59		12.2.3. Fragmentation as a way to bypass Network Inspection 59
	12.2.4. Privacy issues associated with SCHC header fields . 59		12.2.4. Privacy issues associated with SCHC header fields . 59
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 60		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 60
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 60		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
	14.1. Normative References . . . . . . . . . . . . . . . . . . 60		14.1. Normative References . . . . . . . . . . . . . . . . . . 60
	14.2. Informative References . . . . . . . . . . . . . . . . . 61		14.2. Informative References . . . . . . . . . . . . . . . . . 61
	Appendix A. Compression Examples . . . . . . . . . . . . . . . . 61		Appendix A. Compression Examples . . . . . . . . . . . . . . . . 61
	Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 64		Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 64
	Appendix C. Fragmentation State Machines . . . . . . . . . . . . 71		Appendix C. Fragmentation State Machines . . . . . . . . . . . . 72
	Appendix D. SCHC Parameters . . . . . . . . . . . . . . . . . . 77		Appendix D. SCHC Parameters . . . . . . . . . . . . . . . . . . 78
	Appendix E. Supporting multiple window sizes for fragmentation . 79		Appendix E. Supporting multiple window sizes for fragmentation . 80
	Appendix F. ACK-Always and ACK-on-Error on quasi-bidirectional		Appendix F. ACK-Always and ACK-on-Error on quasi-bidirectional
	links . . . . . . . . . . . . . . . . . . . . . . . 79		links . . . . . . . . . . . . . . . . . . . . . . . 80
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82
	1. Introduction		1. Introduction
	This document defines the Static Context Header Compression (SCHC)		This document defines the Static Context Header Compression (SCHC)
	framework, which provides both header compression and fragmentation		framework, which provides both a header compression mechanism and an
	functionalities. SCHC has been designed for Low Power Wide Area		optional fragmentation mechanism. SCHC has been designed for Low
	Networks (LPWAN).		Power Wide Area Networks (LPWAN).
	LPWAN technologies impose some strict limitations on traffic. For		LPWAN technologies impose some strict limitations on traffic. For
	instance, devices sleep most of the time and may only receive data		instance, devices sleep most of the time and may only receive data
	during short periods of time after transmission, in order to preserve		during short periods of time after transmission, in order to preserve
	battery. LPWAN technologies are also characterized by a greatly		battery. LPWAN technologies are also characterized by a greatly
	reduced data unit and/or payload size (see [RFC8376]).		reduced data unit and/or payload size (see [RFC8376]).
	Header compression is needed for efficient Internet connectivity to a		Header compression is needed for efficient Internet connectivity to a
	node within an LPWAN network. The following properties of LPWAN		node within an LPWAN network. The following properties of LPWAN
	networks can be exploited to get an efficient header compression:		networks can be exploited to get an efficient header compression:
	skipping to change at page 28, line 6 ¶		skipping to change at page 28, line 6 ¶
	This field conveys information about the progress in the sequence		This field conveys information about the progress in the sequence
	of tiles being transmitted by SCHC Fragment messages. For		of tiles being transmitted by SCHC Fragment messages. For
	example, it can contain a partial, efficient representation of a		example, it can contain a partial, efficient representation of a
	larger-sized tile index. The description of the exact use of the		larger-sized tile index. The description of the exact use of the
	FCN field is left to each SCHC F/R mode. However, two values are		FCN field is left to each SCHC F/R mode. However, two values are
	reserved for special purposes. They help control the SCHC F/R		reserved for special purposes. They help control the SCHC F/R
	process:		process:
	* The FCN value with all the bits equal to 1 (called All-1)		* The FCN value with all the bits equal to 1 (called All-1)
	signals the very last tile of a SCHC Packet. By extension, if		signals that the very last tile of a SCHC Packet has been
	windows are used, the last window of a packet is called the		transmitted. By extension, if windows are used, the last
	All-1 window.		window of a packet is called the All-1 window.
	* If windows are used, the FCN value with all the bits equal to 0		* If windows are used, the FCN value with all the bits equal to 0
	(called All-0) signals the last tile of a window that is not		(called All-0) signals the last tile of a window that is not
	the last one of the SCHC packet. By extension, such a window		the last one of the SCHC packet. By extension, such a window
	is called an All-0 window.		is called an All-0 window.
	o Reassembly Check Sequence (RCS). This field only appears in the		o Reassembly Check Sequence (RCS). This field only appears in the
	All-1 SCHC Fragments. Its size (called U, in bits) is defined by		All-1 SCHC Fragments. Its size (called U, in bits) is defined by
	each Profile for each Rule ID.		each Profile for each Rule ID.
	skipping to change at page 36, line 8 ¶		skipping to change at page 36, line 8 ¶
	SCHC Packet.		SCHC Packet.
	Each SCHC Fragment MUST contain exactly one tile in its Payload. The		Each SCHC Fragment MUST contain exactly one tile in its Payload. The
	tile MUST be at least the size of an L2 Word. The sender MUST		tile MUST be at least the size of an L2 Word. The sender MUST
	transmit the SCHC Fragments messages in the order that the tiles		transmit the SCHC Fragments messages in the order that the tiles
	appear in the SCHC Packet. Except for the last tile of a SCHC		appear in the SCHC Packet. Except for the last tile of a SCHC
	Packet, each tile MUST be of a size that complements the SCHC		Packet, each tile MUST be of a size that complements the SCHC
	Fragment Header so that the SCHC Fragment is a multiple of L2 Words		Fragment Header so that the SCHC Fragment is a multiple of L2 Words
	without the need for padding bits. Except for the last one, the SCHC		without the need for padding bits. Except for the last one, the SCHC
	Fragments MUST use the Regular SCHC Fragment format specified in		Fragments MUST use the Regular SCHC Fragment format specified in
	Section 8.3.1.1. The last SCHC Fragment MUST use the All-1 format		Section 8.3.1.1. The SCHC Fragment that carries the last tile MUST
	specified in Section 8.3.1.2.		be an All-1 SCHC Fragment, described in Section 8.3.1.2.
	The sender MAY transmit a SCHC Sender-Abort.		The sender MAY transmit a SCHC Sender-Abort.
	Figure 37 shows an example of a corresponding state machine.		Figure 37 shows an example of a corresponding state machine.
	8.4.1.2. Receiver behavior		8.4.1.2. Receiver behavior
	Upon receiving each Regular SCHC Fragment,		Upon receiving each Regular SCHC Fragment,
	o the receiver MUST reset the Inactivity Timer,		o the receiver MUST reset the Inactivity Timer,
	skipping to change at page 55, line 50 ¶		skipping to change at page 55, line 50 ¶
	enable zero-checksum mode for a specific port (or set of ports) for		enable zero-checksum mode for a specific port (or set of ports) for
	sending and/or receiving. [RFC8200] requires any node implementing		sending and/or receiving. [RFC8200] requires any node implementing
	zero-checksum mode to follow the requirements specified in		zero-checksum mode to follow the requirements specified in
	"Applicability Statement for the Use of IPv6 UDP Datagrams with Zero		"Applicability Statement for the Use of IPv6 UDP Datagrams with Zero
	Checksums" [RFC6936].		Checksums" [RFC6936].
	6LoWPAN Header Compression [RFC6282] also specifies that a UDP		6LoWPAN Header Compression [RFC6282] also specifies that a UDP
	checksum can be elided by the compressor and re-computed by the		checksum can be elided by the compressor and re-computed by the
	decompressor when an upper layer guarantees the integrity of the UDP		decompressor when an upper layer guarantees the integrity of the UDP
	payload and pseudo-header. A specific example of this is when a		payload and pseudo-header. A specific example of this is when a
	Message Integrity Check protects the compressed message between the		message integrity check protects the compressed message between the
	compressor that elides the UDP checksum and the decompressor that		compressor that elides the UDP checksum and the decompressor that
	computes it, with a strength that is identical or better to the UDP		computes it, with a strength that is identical or better to the UDP
	checksum.		checksum.
	Similarly, a SCHC compressor MAY elide the UDP checksum when another		Similarly, a SCHC compressor MAY elide the UDP checksum when another
	layer guarantees at least equal integrity protection for the UDP		layer guarantees at least equal integrity protection for the UDP
	payload and the pseudo-header. In this case, the TV is not set, the		payload and the pseudo-header. In this case, the TV is not set, the
	MO is set to "ignore" and the CDA is set to "compute-*".		MO is set to "ignore" and the CDA is set to "compute-*".
	In particular, when SCHC fragmentation is used, a fragmentation RCS		In particular, when SCHC fragmentation is used, a fragmentation RCS
	skipping to change at page 60, line 9 ¶		skipping to change at page 60, line 9 ¶
	However, SCHC F/R is expected to be used over exactly one LPWAN link.		However, SCHC F/R is expected to be used over exactly one LPWAN link.
	As described in Section 5.2, even if the SCHC F/R on the Network		As described in Section 5.2, even if the SCHC F/R on the Network
	infrastructure side is located in the Internet, a tunnel is to be		infrastructure side is located in the Internet, a tunnel is to be
	established between it and the NGW. Therefore, neither the DTag		established between it and the NGW. Therefore, neither the DTag
	field nor any other SCHC-introduced field is visible over the		field nor any other SCHC-introduced field is visible over the
	Internet.		Internet.
	13. Acknowledgements		13. Acknowledgements
	Thanks to Sergio Aguilar Romero, Brian Carpenter, Carsten Bormann,		Thanks to (in alphabetical order) Sergio Aguilar Romero, David Black,
	David Black, Deborah Brungard, Philippe Clavier, Alissa Cooper, Roman		Carsten Bormann, Deborah Brungard, Brian Carpenter, Philippe Clavier,
	Danyliw, Daniel Ducuara Beltran, Diego Dujovne, Eduardo Ingles		Alissa Cooper, Roman Danyliw, Daniel Ducuara Beltran, Diego Dujovne,
	Sanchez, Benjamin Kaduk, Arunprabhu Kandasamy, Suresh Krishnan, Mirja		Eduardo Ingles Sanchez, Rahul Jadhav, Benjamin Kaduk,
	Kuehlewind, Rahul Jadhav, Barry Leiba, Sergio Lopez Bernal, Antony		Arunprabhu Kandasamy, Suresh Krishnan, Mirja Kuehlewind, Barry Leiba,
	Markovski, Alexey Melnikov, Alexander Pelov, Charles Perkins, Edgar		Sergio Lopez Bernal, Antoni Markovski, Alexey Melnikov,
	Ramos, Alvaro Retana, Adam Roach, Shoichi Sakane, Joseph Salowey,		Georgios Papadopoulos, Alexander Pelov, Charles Perkins, Edgar Ramos,
			Alvaro Retana, Adam Roach, Shoichi Sakane, Joseph Salowey,
	Pascal Thubert, and Eric Vyncke for useful design considerations,		Pascal Thubert, and Eric Vyncke for useful design considerations,
	reviews and comments.		reviews and comments.
	Carles Gomez has been funded in part by the Spanish Government		Carles Gomez has been funded in part by the Spanish Government
	(Ministerio de Educacion, Cultura y Deporte) through the Jose		(Ministerio de Educacion, Cultura y Deporte) through the Jose
	Castillejo grant CAS15/00336, and by the ERDF and the Spanish		Castillejo grant CAS15/00336, and by the ERDF and the Spanish
	Government through project TEC2016-79988-P. Part of his contribution		Government through project TEC2016-79988-P. Part of his contribution
	to this work has been carried out during his stay as a visiting		to this work has been carried out during his stay as a visiting
	scholar at the Computer Laboratory of the University of Cambridge.		scholar at the Computer Laboratory of the University of Cambridge.
	skipping to change at page 62, line 31 ¶		skipping to change at page 62, line 35 ¶
	+------------------------------+		+------------------------------+
	Dev or NGW		Dev or NGW
	Figure 25: Simplified Protocol Stack for LP-WAN		Figure 25: Simplified Protocol Stack for LP-WAN
	In some LPWAN technologies, only the Devs have a device ID. When		In some LPWAN technologies, only the Devs have a device ID. When
	such technologies are used, it is necessary to statically define an		such technologies are used, it is necessary to statically define an
	IID for the Link Local address for the SCHC C/D.		IID for the Link Local address for the SCHC C/D.
	Rule 0		Rule 0
			Special Rule ID used to tag an uncompressed UDP/IPV6 packet.
			Rule 1
	+----------------+--+--+--+---------+--------+------------++------+		+----------------+--+--+--+---------+--------+------------++------+
	| Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent |		| Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent |
	| | | | | | Opera. | Action ||[bits]|		| | | | | | Opera. | Action ||[bits]|
	+----------------+--+--+--+---------+---------------------++------+		+----------------+--+--+--+---------+---------------------++------+
	|IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || |		|IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || |
	|IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || |		|IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || |
	|IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || |		|IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || |
	|IPv6 Length |16|1 |Bi| | ignore | compute-* || |		|IPv6 Length |16|1 |Bi| | ignore | compute-* || |
	|IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || |		|IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || |
	|IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || |		|IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || |
	|IPv6 DevPrefix |64|1 |Bi|FE80::/64| equal | not-sent || |		|IPv6 DevPrefix |64|1 |Bi|FE80::/64| equal | not-sent || |
	|IPv6 DevIID |64|1 |Bi| | ignore | DevIID || |		|IPv6 DevIID |64|1 |Bi| | ignore | DevIID || |
	|IPv6 AppPrefix |64|1 |Bi|FE80::/64| equal | not-sent || |		|IPv6 AppPrefix |64|1 |Bi|FE80::/64| equal | not-sent || |
	|IPv6 AppIID |64|1 |Bi|::1 | equal | not-sent || |		|IPv6 AppIID |64|1 |Bi|::1 | equal | not-sent || |
	+================+==+==+==+=========+========+============++======+		+================+==+==+==+=========+========+============++======+
	|UDP DevPort |16|1 |Bi|123 | equal | not-sent || |		|UDP DevPort |16|1 |Bi|123 | equal | not-sent || |
	|UDP AppPort |16|1 |Bi|124 | equal | not-sent || |		|UDP AppPort |16|1 |Bi|124 | equal | not-sent || |
	|UDP Length |16|1 |Bi| | ignore | compute-* || |		|UDP Length |16|1 |Bi| | ignore | compute-* || |
	|UDP checksum |16|1 |Bi| | ignore | compute-* || |		|UDP checksum |16|1 |Bi| | ignore | compute-* || |
	+================+==+==+==+=========+========+============++======+		+================+==+==+==+=========+========+============++======+
	Rule 1
			Rule 2
	+----------------+--+--+--+---------+--------+------------++------+		+----------------+--+--+--+---------+--------+------------++------+
	| Field |FL|FP|DI| Value | Match | Action || Sent |		| Field |FL|FP|DI| Value | Match | Action || Sent |
	| | | | | | Opera. | Action ||[bits]|		| | | | | | Opera. | Action ||[bits]|
	+----------------+--+--+--+---------+--------+------------++------+		+----------------+--+--+--+---------+--------+------------++------+
	|IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || |		|IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || |
	|IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || |		|IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || |
	|IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || |		|IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || |
	|IPv6 Length |16|1 |Bi| | ignore | compute-* || |		|IPv6 Length |16|1 |Bi| | ignore | compute-* || |
	|IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || |		|IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || |
	|IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || |		|IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || |
	skipping to change at page 63, line 29 ¶		skipping to change at page 63, line 37 ¶
	| | | | |alpha/64,| mapping| || |		| | | | |alpha/64,| mapping| || |
	| | | | |fe80::64]| | || |		| | | | |fe80::64]| | || |
	|IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || |		|IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || |
	+================+==+==+==+=========+========+============++======+		+================+==+==+==+=========+========+============++======+
	|UDP DevPort |16|1 |Bi|5683 | equal | not-sent || |		|UDP DevPort |16|1 |Bi|5683 | equal | not-sent || |
	|UDP AppPort |16|1 |Bi|5683 | equal | not-sent || |		|UDP AppPort |16|1 |Bi|5683 | equal | not-sent || |
	|UDP Length |16|1 |Bi| | ignore | compute-* || |		|UDP Length |16|1 |Bi| | ignore | compute-* || |
	|UDP checksum |16|1 |Bi| | ignore | compute-* || |		|UDP checksum |16|1 |Bi| | ignore | compute-* || |
	+================+==+==+==+=========+========+============++======+		+================+==+==+==+=========+========+============++======+
	Rule 2		Rule 3
	+----------------+--+--+--+---------+--------+------------++------+		+----------------+--+--+--+---------+--------+------------++------+
	| Field |FL|FP|DI| Value | Match | Action || Sent |		| Field |FL|FP|DI| Value | Match | Action || Sent |
	| | | | | | Opera. | Action ||[bits]|		| | | | | | Opera. | Action ||[bits]|
	+----------------+--+--+--+---------+--------+------------++------+		+----------------+--+--+--+---------+--------+------------++------+
	|IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || |		|IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || |
	|IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || |		|IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || |
	|IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || |		|IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || |
	|IPv6 Length |16|1 |Bi| | ignore | compute-* || |		|IPv6 Length |16|1 |Bi| | ignore | compute-* || |
	|IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || |		|IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || |
	|IPv6 Hop Limit |8 |1 |Up|255 | ignore | not-sent || |		|IPv6 Hop Limit |8 |1 |Up|255 | ignore | not-sent || |
	skipping to change at page 64, line 4 ¶		skipping to change at page 64, line 11 ¶
	|IPv6 DevPrefix |64|1 |Bi|alpha/64 | equal | not-sent || |		|IPv6 DevPrefix |64|1 |Bi|alpha/64 | equal | not-sent || |
	|IPv6 DevIID |64|1 |Bi| | ignore | DevIID || |		|IPv6 DevIID |64|1 |Bi| | ignore | DevIID || |
	|IPv6 AppPrefix |64|1 |Bi|gamma/64 | equal | not-sent || |		|IPv6 AppPrefix |64|1 |Bi|gamma/64 | equal | not-sent || |
	|IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || |		|IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || |
	+================+==+==+==+=========+========+============++======+		+================+==+==+==+=========+========+============++======+
	|UDP DevPort |16|1 |Bi|8720 | MSB(12)| LSB || 4 |		|UDP DevPort |16|1 |Bi|8720 | MSB(12)| LSB || 4 |
	|UDP AppPort |16|1 |Bi|8720 | MSB(12)| LSB || 4 |		|UDP AppPort |16|1 |Bi|8720 | MSB(12)| LSB || 4 |
	|UDP Length |16|1 |Bi| | ignore | compute-* || |		|UDP Length |16|1 |Bi| | ignore | compute-* || |
	|UDP checksum |16|1 |Bi| | ignore | compute-* || |		|UDP checksum |16|1 |Bi| | ignore | compute-* || |
	+================+==+==+==+=========+========+============++======+		+================+==+==+==+=========+========+============++======+
	Figure 26: Context Rules		Figure 26: Context Rules
	All the fields described in the three Rules depicted on Figure 26 are		Figure 26 describes a example of a Rule set.
	present in the IPv6 and UDP headers. The DevIID-DID value is found
	in the L2 header.
	The second and third Rules use global addresses. The way the Dev		In this example, 0 was chosen as the special Rule ID that tags
	learns the prefix is not in the scope of the document.		packets that cannot be compressed with any compression Rule.
	The third Rule compresses each port number to 4 bits.		All the fields described in Rules 1-3 are present in the IPv6 and UDP
			headers. The DevIID-DID value is found in the L2 header.
			Rules 2-3 use global addresses. The way the Dev learns the prefix is
			not in the scope of the document.
			Rule 3 compresses each port number to 4 bits.
	Appendix B. Fragmentation Examples		Appendix B. Fragmentation Examples
	This section provides examples for the various fragment reliability		This section provides examples for the various fragment reliability
	modes specified in this document. In the drawings, Bitmaps are shown		modes specified in this document. In the drawings, Bitmaps are shown
	in their uncompressed form.		in their uncompressed form.
	Figure 27 illustrates the transmission in No-ACK mode of a SCHC		Figure 27 illustrates the transmission in No-ACK mode of a SCHC
	Packet that needs 11 SCHC Fragments. FCN is 1 bit wide.		Packet that needs 11 SCHC Fragments. FCN is 1 bit wide.
End of changes. 21 change blocks.
	43 lines changed or deleted		53 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/