< draft-ietf-6lo-lowpanz-05.txt		draft-ietf-6lo-lowpanz-06.txt >
	IPv6 over Networks of Resource-constrained Nodes (6lo) WG A. Brandt		IPv6 over Networks of Resource-constrained Nodes (6lo) WG A. Brandt
	Internet-Draft J. Buron		Internet-Draft J. Buron
	Intended status: Standards Track Sigma Designs		Intended status: Standards Track Sigma Designs
	Expires: November 6, 2014 May 5, 2014		Expires: March 22, 2015 September 18, 2014
	Transmission of IPv6 packets over ITU-T G.9959 Networks		Transmission of IPv6 packets over ITU-T G.9959 Networks
	draft-ietf-6lo-lowpanz-05		draft-ietf-6lo-lowpanz-06
	Abstract		Abstract
	This document describes the frame format for transmission of IPv6		This document describes the frame format for transmission of IPv6
	packets and a method of forming IPv6 link-local addresses and		packets and a method of forming IPv6 link-local addresses and
	statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks.		statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	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 November 6, 2014.		This Internet-Draft will expire on March 22, 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terms used . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terms used . . . . . . . . . . . . . . . . . . . . . . . 3
	2. G.9959 parameters to use for IPv6 transport . . . . . . . . . 4		2. G.9959 parameters to use for IPv6 transport . . . . . . . . . 5
	2.1. Addressing mode . . . . . . . . . . . . . . . . . . . . . 4		2.1. Addressing mode . . . . . . . . . . . . . . . . . . . . . 5
	2.2. IPv6 Multicast support . . . . . . . . . . . . . . . . . 5		2.2. IPv6 Multicast support . . . . . . . . . . . . . . . . . 6
	2.3. G.9959 MAC PDU size and IPv6 MTU . . . . . . . . . . . . 6		2.3. G.9959 MAC PDU size and IPv6 MTU . . . . . . . . . . . . 6
	2.4. Transmission status indications . . . . . . . . . . . . . 6		2.4. Transmission status indications . . . . . . . . . . . . . 6
	2.5. Transmission security . . . . . . . . . . . . . . . . . . 6		2.5. Transmission security . . . . . . . . . . . . . . . . . . 7
	3. 6LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . 7		3. 6LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . 7
	3.1. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 7		3.1. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 8
	4. 6LoWPAN addressing . . . . . . . . . . . . . . . . . . . . . 8		4. 6LoWPAN addressing . . . . . . . . . . . . . . . . . . . . . 9
	4.1. Stateless Address Autoconfiguration of routable IPv6		4.1. Stateless Address Autoconfiguration of routable IPv6
	addresses . . . . . . . . . . . . . . . . . . . . . . . . 9		addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 9		4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 9
	4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 9		4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 10
	4.4. On the use of Neighbor Discovery technologies . . . . . . 10		4.4. On the use of Neighbor Discovery technologies . . . . . . 10
	4.4.1. Prefix and CID management (Route-over) . . . . . . . 10		4.4.1. Prefix and CID management (Route-over) . . . . . . . 11
	4.4.2. Prefix and CID management (Mesh-under) . . . . . . . 11		4.4.2. Prefix and CID management (Mesh-under) . . . . . . . 11
	5. Header Compression . . . . . . . . . . . . . . . . . . . . . 12		5. Header Compression . . . . . . . . . . . . . . . . . . . . . 12
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 12		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	10.1. Normative References . . . . . . . . . . . . . . . . . . 14		10.1. Normative References . . . . . . . . . . . . . . . . . . 14
	10.2. Informative References . . . . . . . . . . . . . . . . . 15		10.2. Informative References . . . . . . . . . . . . . . . . . 15
	Appendix A. G.9959 6LoWPAN datagram example . . . . . . . . . . 15		Appendix A. G.9959 6LoWPAN datagram example . . . . . . . . . . 16
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19
	B.1. Changes since -00 . . . . . . . . . . . . . . . . . . . . 19		B.1. Changes since -00 . . . . . . . . . . . . . . . . . . . . 19
	B.2. Changes since -01 . . . . . . . . . . . . . . . . . . . . 19		B.2. Changes since -01 . . . . . . . . . . . . . . . . . . . . 20
	B.3. Changes since -02 . . . . . . . . . . . . . . . . . . . . 20		B.3. Changes since -02 . . . . . . . . . . . . . . . . . . . . 20
	B.4. Changes since -03 . . . . . . . . . . . . . . . . . . . . 20		B.4. Changes since -03 . . . . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21		B.5. Changes since -04 . . . . . . . . . . . . . . . . . . . . 21
			B.6. Changes since -05 . . . . . . . . . . . . . . . . . . . . 21
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	The ITU-T G.9959 recommendation [G.9959] targets low-power Personal		The ITU-T G.9959 recommendation [G.9959] targets low-power Personal
	Area Networks (PANs). This document defines the frame format for		Area Networks (PANs). This document defines the frame format for
	transmission of IPv6 [RFC2460] packets as well as the formation of		transmission of IPv6 [RFC2460] packets as well as the formation of
	IPv6 link-local addresses and statelessly autoconfigured IPv6		IPv6 link-local addresses and statelessly autoconfigured IPv6
	addresses on G.9959 networks.		addresses on G.9959 networks.
	The general approach is to adapt elements of [RFC4944] to G.9959		The general approach is to adapt elements of [RFC4944] to G.9959
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 35 ¶
	The encapsulation frame defined by this specification may optionally		The encapsulation frame defined by this specification may optionally
	be transported via mesh routing below the 6LoWPAN layer. Mesh-under		be transported via mesh routing below the 6LoWPAN layer. Mesh-under
	and route-over routing protocol specifications are out of scope of		and route-over routing protocol specifications are out of scope of
	this document.		this document.
	1.1. Terms used		1.1. Terms used
	6LoWPAN: IPv6-based Low-power Personal Area Network		6LoWPAN: IPv6-based Low-power Personal Area Network
	ABR: Authoritative Border Router ([RFC6775])		ABR: Authoritative 6LBR ([RFC6775])
	Ack: Acknowedgement		Ack: Acknowedgement
	AES: Advanced Encryption Scheme		AES: Advanced Encryption Scheme
	CID: Context Identifier ([RFC6775])		CID: Context Identifier ([RFC6775])
	DAD: Duplicate Address Detection ([RFC6775])		DAD: Duplicate Address Detection ([RFC6775])
	DHCPv6: Dynamic Host Configuration Protocol for IPv6 ([RFC3315])		DHCPv6: Dynamic Host Configuration Protocol for IPv6 ([RFC3315])
	EUI-64: Extended Unique Identifier ([EUI64])		EUI-64: Extended Unique Identifier ([EUI64])
			G.9959: Short range, narrow-band digital radiocommunication
			transceiver ([G.9959])
			GHC: Generic Header Compression ([RFC_TBD_GHC])
	HomeID: G.9959 Link-Layer Network Identifier		HomeID: G.9959 Link-Layer Network Identifier
	IID: Interface IDentifier		IID: Interface IDentifier
	ITU G.9959: Short range, narrow-band digital radiocommunication
	transceiver ([G.9959])
	Link-layer-derived address: IPv6 Address constructed on basis of link		Link-layer-derived address: IPv6 Address constructed on basis of link
	layer address information		layer address information
	MAC: Media Access Control		MAC: Media Access Control
	Mesh-under: Forwarding via mesh routing below the 6LoWPAN layer		Mesh-under: Forwarding via mesh routing below the 6LoWPAN layer
	MTU: Maximum Transmission Unit		MTU: Maximum Transmission Unit
	ND: Neighbor discovery ([RFC4861], [RFC6775])		ND: Neighbor discovery ([RFC4861], [RFC6775])
	NodeID: G.9959 Link-Layer Node Identifier		NodeID: G.9959 Link-Layer Node Identifier
	Non-link-layer-derived address: IPv6 Address assigned by a managed		Non-link-layer-derived address: IPv6 Address assigned by a managed
	process, e.g. DHCPv6.		process, e.g. DHCPv6.
			NVM: Non-volatile Memory
	P2P-RPL: Reactive Discovery of Point-to-Point Routes in Low-Power and		P2P-RPL: Reactive Discovery of Point-to-Point Routes in Low-Power and
	Lossy Networks ([RFC6997])		Lossy Networks ([RFC6997])
	PAN: Personal Area Network		PAN: Personal Area Network
	PDU: Protocol Data Unit		PDU: Protocol Data Unit
			PHY: Physical Layer
	RA: Router Advertisement ([RFC4861], [RFC6775])		RA: Router Advertisement ([RFC4861], [RFC6775])
	Route-over: Forwarding via IP routing above the 6LoWPAN layer		Route-over: Forwarding via IP routing above the 6LoWPAN layer
	RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks		RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
	([RFC6550])		([RFC6550])
	SAR: G.9959 Segmentation And Reassembly		SAR: G.9959 Segmentation And Reassembly
	ULA: Unique Local Address [RFC4193]		ULA: Unique Local Address [RFC4193]
	2. G.9959 parameters to use for IPv6 transport		2. G.9959 parameters to use for IPv6 transport
	This chapter outlines properties applying to the PHY and MAC of		This chapter outlines properties applying to the PHY and MAC of
	G.9959 and how to use these for IPv6 transport.		G.9959 and how to use these for IPv6 transport.
	2.1. Addressing mode		2.1. Addressing mode
	G.9959 defines how a unique 32-bit HomeID network identifier is		G.9959 defines how a unique 32-bit HomeID network identifier is
	assigned by a network controller and how an 8-bit NodeID host		assigned by a network controller and how an 8-bit NodeID host
	identifier is allocated. NodeIDs are unique within the network		identifier is allocated to each node. NodeIDs are unique within the
	identified by the HomeID. The G.9959 network controller function		network identified by the HomeID. The G.9959 HomeID represents an
	SHOULD be integrated in the ABR. The G.9959 HomeID represents an
	IPv6 subnet which is identified by one or more IPv6 prefixes.		IPv6 subnet which is identified by one or more IPv6 prefixes.
	An IPv6 host MUST construct its link-local IPv6 address from the		An IPv6 host MUST construct its link-local IPv6 address from the
	link-layer-derived IID in order to facilitate IP header compression		link-layer-derived IID in order to facilitate IP header compression
	as described in [RFC6282].		as described in [RFC6282].
	A node interface MAY support the M flag of the RA message for the		A node interface MAY support the M flag of the RA message for the
	construction of routable IPv6 addresses. The M flag MUST be		construction of routable IPv6 addresses. A cost optimized node
	interpreted as defined in Figure 1.		implementation may save memory by skipping support for the M flag.
			The M flag MUST be interpreted as defined in Figure 1.
	+--------+--------+---------------------------------------------+		+--------+--------+---------------------------------------------+
	| M Flag | M flag | Required node behavior |		| M Flag | M flag | Required node behavior |
	| support| value | |		| support| value | |
	+--------+--------+---------------------------------------------+		+--------+--------+---------------------------------------------+
	| No |(ignore)| Node MUST use link-layer-derived addressing |		| No |(ignore)| Node MUST use link-layer-derived addressing |
	+--------+--------+---------------------------------------------+		+--------+--------+---------------------------------------------+
	| Yes | 0 | Node MUST use link-layer-derived addressing |		| Yes | 0 | Node MUST use link-layer-derived addressing |
	| +--------+---------------------------------------------+		| +--------+---------------------------------------------+
	| | 1 | Node MUST use DHCPv6 based addressing and |		| | 1 | Node MUST use DHCPv6 based addressing and |
	skipping to change at page 5, line 35 ¶		skipping to change at page 5, line 49 ¶
	Figure 1: RA M flag support and interpretation		Figure 1: RA M flag support and interpretation
	A node that uses DHCPv6 based addressing MUST comply fully with the		A node that uses DHCPv6 based addressing MUST comply fully with the
	text of [RFC6775].		text of [RFC6775].
	A word of caution: since HomeIDs and NodeIDs are handed out by a		A word of caution: since HomeIDs and NodeIDs are handed out by a
	network controller function during inclusion, identifier validity and		network controller function during inclusion, identifier validity and
	uniqueness is limited by the lifetime of the network membership.		uniqueness is limited by the lifetime of the network membership.
	This can be cut short by a mishap occurring to the network		This can be cut short by a mishap occurring to the network
	controller. Having a single point of failure at the network		controller. Having a single point of failure at the network
	controller suggests that deployers of high-reliability applications		controller suggests that high-reliability network deployments may
	should carefully consider adding redundancy to the network controller		benefit from a redundant network controller function.
	function.
	This warning applies to link-layer-derived addressing as well as to		This warning applies to link-layer-derived addressing as well as to
	non-link-layer-derived addressing deployments.		non-link-layer-derived addressing deployments.
	2.2. IPv6 Multicast support		2.2. IPv6 Multicast support
	[RFC3819] recommends that IP subnetworks support (subnet-wide)		[RFC3819] recommends that IP subnetworks support (subnet-wide)
	multicast. G.9959 supports direct-range IPv6 multicast while subnet-		multicast. G.9959 supports direct-range IPv6 multicast while subnet-
	wide multicast is not supported natively by G.9959. Subnet-wide		wide multicast is not supported natively by G.9959. Subnet-wide
	multicast may be provided by an IP routing protocol or a mesh routing		multicast may be provided by an IP routing protocol or a mesh routing
	skipping to change at page 6, line 21 ¶		skipping to change at page 6, line 35 ¶
	broadcast NodeID (0xff)		broadcast NodeID (0xff)
	G.9959 broadcast MAC PDUs are only intercepted by nodes within the		G.9959 broadcast MAC PDUs are only intercepted by nodes within the
	network identified by the HomeID.		network identified by the HomeID.
	2.3. G.9959 MAC PDU size and IPv6 MTU		2.3. G.9959 MAC PDU size and IPv6 MTU
	IPv6 packets MUST be transmitted using G.9959 transmission profile R3		IPv6 packets MUST be transmitted using G.9959 transmission profile R3
	or higher.		or higher.
	[RFC2460] specifies that IPv6 packets may be up to 1280 octets.		[RFC2460] specifies that any link that cannot convey a 1280-octet
			packet in one piece, must provide link-specific fragmentation and
			reassembly at a layer below IPv6.
	G.9959 provides Segmentation And Reassembly for payloads up to 1350		G.9959 provides Segmentation And Reassembly for payloads up to 1350
	octets. IPv6 Header Compression [RFC6282] improves the chances that		octets. IPv6 Header Compression [RFC6282] improves the chances that
	a short IPv6 packet can fit into a single G.9959 frame. Therefore,		a short IPv6 packet can fit into a single G.9959 frame. Therefore,
	section Section 3 specifies that [RFC6282] MUST be supported. With		section Section 3 specifies that [RFC6282] MUST be supported. With
	the mandatory link-layer security enabled, a G.9959 R3 MAC PDU may		the mandatory link-layer security enabled, a G.9959 R3 MAC PDU may
	accommodate 6LoWPAN datagrams of up to 130 octets without triggering		accommodate 6LoWPAN datagrams of up to 130 octets without triggering
	G.9959 Segmentation and Reassembly (SAR). Longer 6LoWPAN datagrams		G.9959 Segmentation and Reassembly (SAR). Longer 6LoWPAN datagrams
	will lead to the transmission of multiple G.9959 PDUs.		will lead to the transmission of multiple G.9959 PDUs.
	skipping to change at page 7, line 9 ¶		skipping to change at page 7, line 25 ¶
	applications with high or very high requirements on confidentiality		applications with high or very high requirements on confidentiality
	and/or integrity, additional application layer security measures for		and/or integrity, additional application layer security measures for
	end-to-end authentication and encryption may need to be applied.		end-to-end authentication and encryption may need to be applied.
	(The availability of the network relies on the security properties of		(The availability of the network relies on the security properties of
	the network key in any case)		the network key in any case)
	3. 6LoWPAN Adaptation Layer and Frame Format		3. 6LoWPAN Adaptation Layer and Frame Format
	The 6LoWPAN encapsulation formats defined in this chapter are carried		The 6LoWPAN encapsulation formats defined in this chapter are carried
	as payload in the G.9959 MAC PDU. IPv6 header compression [RFC6282]		as payload in the G.9959 MAC PDU. IPv6 header compression [RFC6282]
	MUST be supported by implementations of this specification.		MUST be supported by implementations of this specification. Further,
			implementations MAY support Generic Header Compression (GHC)
			[RFC_TBD_GHC]. A node implementing [RFC_TBD_GHC] MUST probe its
			peers for GHC support before applying GHC compression.
	All 6LoWPAN datagrams transported over G.9959 are prefixed by a		All 6LoWPAN datagrams transported over G.9959 are prefixed by a
	6LoWPAN encapsulation header stack. The 6LoWPAN payload follows this		6LoWPAN encapsulation header stack. The 6LoWPAN payload follows this
	encapsulation header stack. Each header in the header stack contains		encapsulation header stack. Each header in the header stack contains
	a header type followed by zero or more header fields. An IPv6 header		a header type followed by zero or more header fields. An IPv6 header
	stack may contain, in the following order, addressing, hop-by-hop		stack may contain, in the following order, addressing, hop-by-hop
	options, routing, fragmentation, destination options, and finally		options, routing, fragmentation, destination options, and finally
	payload [RFC2460]. The 6LoWPAN header format is structured the same		payload [RFC2460]. The 6LoWPAN header format is structured the same
	way. Currently only one payload option is defined for the G.9959		way. Currently only one payload option is defined for the G.9959
	6LoWPAN header format.		6LoWPAN header format.
	skipping to change at page 7, line 44 ¶		skipping to change at page 8, line 18 ¶
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 6LoWPAN CmdCls| Dispatch | Type-specific header |		| 6LoWPAN CmdCls| Dispatch | Type-specific header |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Dispatch Type and Header		Figure 2: Dispatch Type and Header
	6LoWPAN CmdCls: 6LoWPAN Command Class identifier. This field MUST		6LoWPAN CmdCls: 6LoWPAN Command Class identifier. This field MUST
	carry the value 0x4F [G.9959]. The value specifies that the		carry the value 0x4F [G.9959]. The value is assigned by the ITU-T
	following bits are a 6LoWPAN encapsulated datagram. 6LoWPAN protocols		and specifies that the following bits are a 6LoWPAN encapsulated
	MUST ignore the G.9959 frame if the 6LoWPAN Command Class identifier		datagram. 6LoWPAN protocols MUST ignore the G.9959 frame if the
	deviates from 0x4F.		6LoWPAN Command Class identifier deviates from 0x4F.
	Dispatch: Identifies the header type immediately following the		Dispatch: Identifies the header type immediately following the
	Dispatch Header.		Dispatch Header.
	Type-specific header: A header determined by the Dispatch Header.		Type-specific header: A header determined by the Dispatch Header.
	The dispatch value may be treated as an unstructured namespace. Only		The dispatch value may be treated as an unstructured namespace. Only
	a few symbols are required to represent current 6LoWPAN		a few symbols are required to represent current 6LoWPAN
	functionality. Although some additional savings could be achieved by		functionality. Although some additional savings could be achieved by
	encoding additional functionality into the dispatch byte, these		encoding additional functionality into the dispatch byte, these
	skipping to change at page 8, line 30 ¶		skipping to change at page 9, line 7 ¶
	| 01 1xxxxx | 6LoWPAN_IPHC - Compressed IPv6 Addresses | [RFC6282] |		| 01 1xxxxx | 6LoWPAN_IPHC - Compressed IPv6 Addresses | [RFC6282] |
	+------------+------------------------------------------+-----------+		+------------+------------------------------------------+-----------+
	All other Dispatch values are unassigned in this document.		All other Dispatch values are unassigned in this document.
	Figure 3: Dispatch values		Figure 3: Dispatch values
	6LoWPAN_IPHC: IPv6 Header Compression. Refer to [RFC6282].		6LoWPAN_IPHC: IPv6 Header Compression. Refer to [RFC6282].
	4. 6LoWPAN addressing		4. 6LoWPAN addressing
	IPv6 addresses are autoconfigured from IIDs which are again		IPv6 addresses may be autoconfigured from IIDs which may again be
	constructed from link-layer address information to save memory in		constructed from link-layer address information to save memory in
	devices and to facilitate efficient IP header compression as per		devices and to facilitate efficient IP header compression as per
	[RFC6282].		[RFC6282]. Link-layer-derived addresses have a static nature and may
			involuntarily expose private usage data on public networks. Refer to
			Section 8.
	A NodeID is mapped into an IEEE EUI-64 identifier as follows:		A NodeID is mapped into an IEEE EUI-64 identifier as follows:
	IID = 0000:00ff:fe00:YYXX		IID = 0000:00ff:fe00:YYXX
	Figure 4: Constructing a compressible IID		Figure 4: Constructing a compressible IID
	where XX carries the G.9959 NodeID and YY is a one byte value chosen		where XX carries the G.9959 NodeID and YY is a one byte value chosen
	by the individual node. The default YY value MUST be zero. A node		by the individual node. The default YY value MUST be zero. A node
	MAY use other values of YY than zero to form additional IIDs in order		MAY use other values of YY than zero to form additional IIDs in order
	skipping to change at page 11, line 39 ¶		skipping to change at page 12, line 4 ¶
	The 6LoWPAN Context Option (6CO) is used according to [RFC6775] in an		The 6LoWPAN Context Option (6CO) is used according to [RFC6775] in an
	RA to disseminate Context IDs (CID) to use for compressing prefixes.		RA to disseminate Context IDs (CID) to use for compressing prefixes.
	One or more prefixes and corresponding Context IDs MUST be assigned		One or more prefixes and corresponding Context IDs MUST be assigned
	during initial node inclusion.		during initial node inclusion.
	When updating context information, a CID may have its lifetime set to		When updating context information, a CID may have its lifetime set to
	zero to obsolete it. The CID MUST NOT be reused immediately; rather		zero to obsolete it. The CID MUST NOT be reused immediately; rather
	the next vacant CID should be assigned. Header compression based on		the next vacant CID should be assigned. Header compression based on
	CIDs MUST NOT be used for RA messages carrying Context Information.		CIDs MUST NOT be used for RA messages carrying Context Information.
	An expired CID and the associated prefix MUST NOT be reset but rather		An expired CID and the associated prefix MUST NOT be reset but rather
	retained in receive-only mode if there is no other current need for		retained in receive-only mode if there is no other current need for
	the CID value. This will allow an ABR to detect if a sleeping node		the CID value. This will allow an ABR to detect if a sleeping node
	without clock uses an expired CID and in response, the ABR MUST		without clock uses an expired CID and in response, the ABR MUST
	return an RA with fresh Context Information to the originator.		return an RA with fresh Context Information to the originator.
	4.4.2.3. Infinite prefix lifetime support for island-mode networks		4.4.2.3. Infinite prefix lifetime support for island-mode networks
	Nodes MUST renew the prefix and CID according to the lifetime		Nodes MUST renew the prefix and CID according to the lifetime
	signaled by the ABR. [RFC6775] specifies that the maximum value of		signaled by the ABR. [RFC6775] specifies that the maximum value of
	the RA Router Lifetime field MAY be up to 0xFFFF. This document		the RA Router Lifetime field MAY be up to 0xFFFF. This document
	further specifies that the value 0xFFFF MUST be interpreted as		further specifies that the value 0xFFFF MUST be interpreted as
	infinite lifetime. This value MUST NOT be used by ABRs. Its use is		infinite lifetime. This value MUST NOT be used by ABRs. Its use is
	only intended for a sleeping network controller; for instance a		only intended for a sleeping network controller; for instance a
	battery powered remote control being master for a small island-mode		battery powered remote control being master for a small island-mode
	network of light modules.		network of light modules.
	5. Header Compression		5. Header Compression
	IPv6 header compression [RFC6282] MUST be implemented according to		IPv6 header compression MUST be implemented according to [RFC6282].
	[RFC6282]. This section will simply identify substitutions that		This section will simply identify substitutions that should be made
	should be made when interpreting the text of [RFC6282].		when interpreting the text of [RFC6282].
	In general the following substitutions should be made:		In general the following substitutions should be made:
	o Replace "802.15.4" with "G.9959"		o Replace "802.15.4" with "G.9959"
	o Replace "802.15.4 short address" with "<Interface><G.9959 NodeID>"		o Replace "802.15.4 short address" with "<Interface><G.9959 NodeID>"
	o Replace "802.15.4 PAN ID" with "G.9959 HomeID"		o Replace "802.15.4 PAN ID" with "G.9959 HomeID"
	When a 16-bit address is called for (i.e., an IEEE 802.15.4 "short		When a 16-bit address is called for (i.e., an IEEE 802.15.4 "short
	skipping to change at page 12, line 35 ¶		skipping to change at page 12, line 50 ¶
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Interface | NodeID |		| Interface | NodeID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	A transmitting node may be sending to an IPv6 destination address		A transmitting node may be sending to an IPv6 destination address
	which can be reconstructed from the link-layer destination address.		which can be reconstructed from the link-layer destination address.
	If the Interface number is zero (the default value), all IPv6 address		If the Interface number is zero (the default value), all IPv6 address
	bytes may be elided. Likewise, the Interface number of a fully		bytes may be elided. Likewise, the Interface number of a fully
	elided IPv6 address (i.e. SAM/DAM=11) may be reconstructed to the		elided IPv6 address (i.e. SAM/DAM=11) may be reconstructed to the
	value zero by a receiving node.		value zero by a receiving node.
	64 bit 802.15.4 address details do not apply.		64 bit 802.15.4 address details do not apply.
	6. IANA Considerations		6. IANA Considerations
	This document makes no request of IANA.		This document makes no request of IANA.
	Note to RFC Editor: this section may be removed on publication as an		Note to RFC Editor: this section may be removed on publication as an
	RFC.		RFC.
	skipping to change at page 14, line 16 ¶		skipping to change at page 14, line 30 ¶
	increased traffic but also may affect the battery lifetime of		increased traffic but also may affect the battery lifetime of
	sleeping nodes.		sleeping nodes.
	9. Acknowledgements		9. Acknowledgements
	Thanks to the authors of RFC 4944 and RFC 6282 and members of the		Thanks to the authors of RFC 4944 and RFC 6282 and members of the
	IETF 6LoWPAN working group; this document borrows extensively from		IETF 6LoWPAN working group; this document borrows extensively from
	their work. Thanks to Erez Ben-Tovim, Erik Nordmark, Kerry Lynn,		their work. Thanks to Erez Ben-Tovim, Erik Nordmark, Kerry Lynn,
	Michael Richardson, Tommas Jess Christensen for useful comments.		Michael Richardson, Tommas Jess Christensen for useful comments.
	Thanks to Carsten Bormann for extensive feedback which improved this		Thanks to Carsten Bormann for extensive feedback which improved this
	document significantly.		document significantly. Thanks to Brian Haberman for pointing out
			unclear details.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[G.9959] "G.9959 (02/12) + G.9959 Amendment 1 (10/13): Short range,		[G.9959] "G.9959 (02/12) + G.9959 Amendment 1 (10/13): Short range,
	narrow-band digital radiocommunication transceivers",		narrow-band digital radiocommunication transceivers",
	February 2012.		February 2012.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 15, line 10 ¶		skipping to change at page 15, line 22 ¶
	[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6		[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
	Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,		Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
	September 2011.		September 2011.
	[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,		[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
	"Neighbor Discovery Optimization for IPv6 over Low-Power		"Neighbor Discovery Optimization for IPv6 over Low-Power
	Wireless Personal Area Networks (6LoWPANs)", RFC 6775,		Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
	November 2012.		November 2012.
			[RFC_TBD_GHC]
			"draft-ietf-6lo-ghc: 6LoWPAN Generic Compression of
			Headers and Header-like Payloads", September 2014.
	10.2. Informative References		10.2. Informative References
	[EUI64] IEEE, "GUIIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)		[EUI64] IEEE, "GUIIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)
	REGISTRATION AUTHORITY", IEEE Std http://		REGISTRATION AUTHORITY", IEEE Std http://
	standards.ieee.org/regauth/oui/tutorials/EUI64.html,		standards.ieee.org/regauth/oui/tutorials/EUI64.html,
	November 2012.		November 2012.
	[KW03] Elsevier's AdHoc Networks Journal, ""Secure Routing in		[KW03] Elsevier's AdHoc Networks Journal, ""Secure Routing in
	Sensor Networks: Attacks and Countermeasures", Special		Sensor Networks: Attacks and Countermeasures", Special
	Issue on Sensor Network Applications and Protocols vol 1,		Issue on Sensor Network Applications and Protocols vol 1,
	skipping to change at page 20, line 32 ¶		skipping to change at page 20, line 45 ¶
	o Changed SHOULD NOT to MUST NOT: An expired CID and the associated		o Changed SHOULD NOT to MUST NOT: An expired CID and the associated
	prefix MUST NOT be reset but rather retained in receive-only mode		prefix MUST NOT be reset but rather retained in receive-only mode
	o Changed LBR -> ABR		o Changed LBR -> ABR
	o Changed SHOULD to MUST: , the ABR MUST return an RA with fresh		o Changed SHOULD to MUST: , the ABR MUST return an RA with fresh
	Context Information to the originator.		Context Information to the originator.
	o Changed SHOULD NOT to MUST NOT: This value MUST NOT be used by		o Changed SHOULD NOT to MUST NOT: This value MUST NOT be used by
	ABRs. Its use is only intended for a sleeping network controller;		ABRs. Its use is only intended for a sleeping network controller.
	B.3. Changes since -02		B.3. Changes since -02
	o Editorial nits.		o Editorial nits.
	o Moved text to the right section so that it does not prohibit DAD		o Moved text to the right section so that it does not prohibit DAD
	for Route-Over deployments.		for Route-Over deployments.
	o Introduced RA m flag support so that nodes may be instructed to		o Introduced RA M flag support so that nodes may be instructed to
	use DHCPv6 for centralized address assignment.		use DHCPv6 for centralized address assignment.
	o Added example appendix: Complete G.9959 6LoWPAN datagram		o Added example appendix: Complete G.9959 6LoWPAN datagram
	composition with CID-based header compression		composition with CID-based header compression.
	B.4. Changes since -03		B.4. Changes since -03
	o Corrected error in 6LoWPAN datagram example appendix: 64 hop limit		o Corrected error in 6LoWPAN datagram example appendix: 64 hop limit
	in comment => also 64 hop limit in actual frame format.		in comment => also 64 hop limit in actual frame format.
	o Added section "Privacy Considerations"		o Added section "Privacy Considerations"
			B.5. Changes since -04
			o Text on RA M flag support was replaced with a table to improve
			clarity.
			o Added further details to text on achieving privacy addressing with
			DHCP.
			B.6. Changes since -05
			o Term ABR now points to Authoritative 6LBR as defined by RFC6775.
			o Removed sentence "The G.9959 network controller function SHOULD be
			integrated in the ABR." as this was an implementation guideline
			with no relevance to network performance.
			o Clarifying that network controller function redundancy is relevant
			for network deployers; not user-level application designers.
			o Clarified that RFC2460 specifies that link layer must provide
			fragmentation if 1280 octet packets cannot be carried in one piece
			by the link layer.
			o Clarified that the 6LoWPAN CmdCls identifier value is assigned by
			the ITU-T.
			o Added reference to Privacy Considerations section from 6LoWPAN
			Addressing section.
			o Introducing optional GHC header compression.
	Authors' Addresses		Authors' Addresses
	Anders Brandt		Anders Brandt
	Sigma Designs		Sigma Designs
	Emdrupvej 26A, 1.		Emdrupvej 26A, 1.
	Copenhagen O 2100		Copenhagen O 2100
	Denmark		Denmark
	Email: anders_brandt@sigmadesigns.com		Email: anders_brandt@sigmadesigns.com
End of changes. 34 change blocks.
	45 lines changed or deleted		96 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/