< draft-ietf-6lo-lowpanz-00.txt		draft-ietf-6lo-lowpanz-01.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: May 29, 2014 November 25, 2013		Expires: July 25, 2014 January 21, 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-00		draft-ietf-6lo-lowpanz-01
	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 May 29, 2014.		This Internet-Draft will expire on July 25, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 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
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	1. Author's notes . . . . . . . . . . . . . . . . . . . . . . . 2		1. Author's notes . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Reader's guidance . . . . . . . . . . . . . . . . . . . . 2		1.1. Reader's guidance . . . . . . . . . . . . . . . . . . . . 2
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Terms used . . . . . . . . . . . . . . . . . . . . . . . 3		2.1. Terms used . . . . . . . . . . . . . . . . . . . . . . . 3
	3. G.9959 parameters to use for IPv6 transport . . . . . . . . . 4		3. G.9959 parameters to use for IPv6 transport . . . . . . . . . 4
	3.1. Addressing mode . . . . . . . . . . . . . . . . . . . . . 4		3.1. Addressing mode . . . . . . . . . . . . . . . . . . . . . 4
	3.2. IPv6 Multicast support . . . . . . . . . . . . . . . . . 4		3.2. IPv6 Multicast support . . . . . . . . . . . . . . . . . 4
	3.3. G.9959 MAC PDU size and IPv6 MTU . . . . . . . . . . . . 5		3.3. G.9959 MAC PDU size and IPv6 MTU . . . . . . . . . . . . 5
	3.4. Transmission status indications . . . . . . . . . . . . . 5		3.4. Transmission status indications . . . . . . . . . . . . . 5
	3.5. Transmission security . . . . . . . . . . . . . . . . . . 5		3.5. Transmission security . . . . . . . . . . . . . . . . . . 6
	4. LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . 6		4. LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . 6
	4.1. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 6		4.1. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 6
	5. LoWPAN addressing . . . . . . . . . . . . . . . . . . . . . . 7		5. LoWPAN addressing . . . . . . . . . . . . . . . . . . . . . . 8
	5.1. Stateless Address Autoconfiguration of routable IPv6		5.1. Stateless Address Autoconfiguration of routable IPv6
	addresses . . . . . . . . . . . . . . . . . . . . . . . . 8		addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
	5.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 8		5.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 8
	5.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 8		5.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 9
	5.4. On the use of Neighbor Discovery technologies . . . . . . 9		5.4. On the use of Neighbor Discovery technologies . . . . . . 9
	5.4.1. Prefix and CID management (Route-over) . . . . . . . 10		5.4.1. Prefix and CID management (Route-over) . . . . . . . 10
	5.4.2. Prefix and CID management (Mesh-under) . . . . . . . 10		5.4.2. Prefix and CID management (Mesh-under) . . . . . . . 10
	6. Header Compression . . . . . . . . . . . . . . . . . . . . . 10		6. Header Compression . . . . . . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 11		8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	10.1. Normative References . . . . . . . . . . . . . . . . . . 12		10.1. Normative References . . . . . . . . . . . . . . . . . . 13
	10.2. Informative References . . . . . . . . . . . . . . . . . 13		10.2. Informative References . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Author's notes		1. Author's notes
	This chapter MUST be deleted before going for document last call.		This chapter MUST be deleted before going for document last call.
	1.1. Reader's guidance		1.1. Reader's guidance
	This document borrows heavily from RFC4944, "Transmission of IPv6		This document borrows heavily from RFC4944, "Transmission of IPv6
	Packets over IEEE 802.15.4 Networks". The process of creating this		Packets over IEEE 802.15.4 Networks". The process of creating this
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 33 ¶
	[RFC6775] updates [RFC4944] by specifying 6LoWPAN optimizations for		[RFC6775] updates [RFC4944] by specifying 6LoWPAN optimizations for
	IPv6 Neighbor Discovery (ND) (originally defined by [RFC4861]). This		IPv6 Neighbor Discovery (ND) (originally defined by [RFC4861]). This
	document limits the use of [RFC6775] to prefix and Context ID		document limits the use of [RFC6775] to prefix and Context ID
	assignment. It is described how to construct an IID from a G.9959		assignment. It is described how to construct an IID from a G.9959
	link-layer address. Refer to Section 5. If using that method,		link-layer address. Refer to Section 5. If using that method,
	Duplicate Address Detection (DAD) is not needed. Address		Duplicate Address Detection (DAD) is not needed. Address
	registration is only needed in certain cases.		registration is only needed in certain cases.
	In addition to IPv6 application communication, the frame format		In addition to IPv6 application communication, the frame format
	defined in this document may be used by IPv6 routing protocols such		defined in this document may be used by IPv6 routing protocols such
	as RPL [RFC6550] or P2P-RPL [P2P-RPL] to implement IPv6 routing over		as RPL [RFC6550] or P2P-RPL [RFC6997] to implement IPv6 routing over
	G.9959 networks.		G.9959 networks.
	G.9959 networks may implement mesh routing between nodes below the IP		The encapsulation frame defined by this specification may optionally
	layer. Mesh routing is out of scope of this document.		be transported via mesh routing below the 6LoWPAN layer. Actual
			routing protocols are out of scope of this document.
	2.1. Terms used		2.1. Terms used
	ABR: Authoritative Border Router ([RFC6775])		ABR: Authoritative Border Router ([RFC6775])
	AES: Advanced Encryption Scheme		AES: Advanced Encryption Scheme
	EUI-64: Extended Unique Identifier		EUI-64: Extended Unique Identifier
	HomeID: G.9959 Link-Layer Network Identifier		HomeID: G.9959 Link-Layer Network Identifier
	skipping to change at page 4, line 49 ¶		skipping to change at page 5, line 4 ¶
	controller suggests that deployers of high-reliability applications		controller suggests that deployers of high-reliability applications
	should carefully consider adding redundancy to the network controller		should carefully consider adding redundancy to the network controller
	function.		function.
	3.2. IPv6 Multicast support		3.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
	protocol operating below the 6LoWPAN layer. Routing protocols are		protocol operating below the 6LoWPAN layer. Routing protocol
	out of scope of this document.		specifications are out of scope of this document.
	IPv6 multicast packets MUST be carried via G.9959 broadcast.		IPv6 multicast packets MUST be carried via G.9959 broadcast.
	As per [G.9959], this is accomplished as follows:		As per [G.9959], this is accomplished as follows:
	1. The destination HomeID of the G.9959 MAC PDU MUST be the HomeID		1. The destination HomeID of the G.9959 MAC PDU MUST be the HomeID
	of the logical network		of the logical network
	2. The destination NodeID of the G.9959 MAC PDU MUST be the		2. The destination NodeID of the G.9959 MAC PDU MUST be the
	broadcast NodeID (0xff)		broadcast NodeID (0xff)
	skipping to change at page 5, line 32 ¶		skipping to change at page 5, line 34 ¶
	G.9959 profiles R1 and R2 only supports MPDU payloads around 40 bytes		G.9959 profiles R1 and R2 only supports MPDU payloads around 40 bytes
	and the transmission speed is down to 9.6kbit/s.		and the transmission speed is down to 9.6kbit/s.
	[RFC2460] specifies that IPv6 packets may be up to 1280 octets.		[RFC2460] specifies that IPv6 packets may be up to 1280 octets.
	However, a full IPv6 packet does not fit in an G.9959 MAC PDU. The		However, a full IPv6 packet does not fit in an G.9959 MAC PDU. The
	maximum G.9959 R3 MAC PDU payload size is 158 octets. Link-layer		maximum G.9959 R3 MAC PDU payload size is 158 octets. Link-layer
	security imposes an overhead, which in the extreme case leaves 130		security imposes an overhead, which in the extreme case leaves 130
	octets available.		octets available.
	G.9959 provides Segmentation And Reassembly for payloads up to 1350		G.9959 provides Segmentation And Reassembly for payloads up to 1350
	octets. Segmentation however adds further overhead. It is therefore		octets. Segmentation however adds further overhead. It is desirable
	desirable that datagrams can fit into a single G.9959 MAC PDU. IPv6		that datagrams can fit into a single G.9959 MAC PDU. IPv6 Header
	Header Compression [RFC6282] improves the chances that a short IPv6		Compression [RFC6282] improves the chances that a short IPv6 packet
	packet can fit into a single G.9959 frame.		can fit into a single G.9959 frame. Therefore, section Section 4
			specifies that [RFC6282] MUST be supported.
	3.4. Transmission status indications		3.4. Transmission status indications
	The G.9959 MAC layer provides native acknowledgement and		The G.9959 MAC layer provides native acknowledgement and
	retransmission of MAC PDUs. The G.9959 SAR layer does the same for		retransmission of MAC PDUs. The G.9959 SAR layer does the same for
	larger datagrams. A mesh routing layer may provide a similar feature		larger datagrams. A mesh routing layer may provide a similar feature
	for routed communication. Acknowledgment and retransmission improves		for routed communication. Acknowledgment and retransmission improves
	the transmission success rate and frees higher layers from the burden		the transmission success rate and frees higher layers from the burden
	of implementing individual retransmission schemes. An IPv6 routing		of implementing individual retransmission schemes. An IPv6 routing
	stack communicating over G.9959 may utilize link-layer status		stack communicating over G.9959 may utilize link-layer status
	skipping to change at page 6, line 42 ¶		skipping to change at page 7, line 5 ¶
	structure provides a mechanism to address future demands on the		structure provides a mechanism to address future demands on the
	6LoWPAN adaptation layer, it is not intended to provide general		6LoWPAN adaptation layer, it is not intended to provide general
	purpose extensibility. This document specifies a small set of		purpose extensibility. This document specifies a small set of
	6LoWPAN header types using the 6LoWPAN header stack for clarity,		6LoWPAN header types using the 6LoWPAN header stack for clarity,
	compactness, and orthogonality.		compactness, and orthogonality.
	4.1. Dispatch Header		4.1. Dispatch Header
	The dispatch header is shown below:		The dispatch header is shown below:
	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 1: Dispatch Type and Header		Figure 1: 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 specifies that the
	following bits are a 6LoWPAN encapsulated datagram. Non-6LoWPAN		following bits are a 6LoWPAN encapsulated datagram. Non-6LoWPAN
	protocols MUST ignore the contents following the 6LoWPAN Command		protocols MUST ignore the contents following the 6LoWPAN Command
	Class identifier.		Class identifier.
	Dispatch: Identifies the header type immediately following the		Dispatch: Identifies the header type immediately following the
	skipping to change at page 7, line 23 ¶		skipping to change at page 7, line 34 ¶
	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
	measures would tend to constrain the ability to address future		measures would tend to constrain the ability to address future
	alternatives.		alternatives.
	Dispatch values used in this specification are compatible with the		Dispatch values used in this specification are compatible with the
	dispatch values defined by [RFC4944] and [RFC6282].		dispatch values defined by [RFC4944] and [RFC6282].
	+------------+------------------------------------------+-----------+		+------------+------------------------------------------+-----------+
	| Pattern | Header Type | Reference |		| Pattern | Header Type | Reference |
	+------------+------------------------------------------+-----------+		+------------+------------------------------------------+-----------+
	| 01 000001 | IPv6 - Uncompressed IPv6 Addresses| [RFC4944] |		| 01 000001 | IPv6 - Uncompressed IPv6 Addresses| [RFC4944] |
	| 01 1xxxxx | 6LoWPAN_IPHC - 6LoWPAN_IPHC compressed IPv6| [RFC6282] |		| 01 1xxxxx | 6LoWPAN_IPHC - 6LoWPAN_IPHC compressed IPv6| [RFC6282] |
	+------------+------------------------------------------+-----------+		+------------+------------------------------------------+-----------+
	All other Dispatch values are unassigned in this document.		All other Dispatch values are unassigned in this document.
	Figure 2: Dispatch values		Figure 2: Dispatch values
	IPv6: Specifies that the following header is an uncompressed IPv6		IPv6: Specifies that the following header is an uncompressed IPv6
	header.		header.
	6LoWPAN_IPHC: IPv6 Header Compression. Refer to [RFC6282].		6LoWPAN_IPHC: IPv6 Header Compression. Refer to [RFC6282].
	5. LoWPAN addressing		5. LoWPAN addressing
	IPv6 addresses are autoconfigured from IIDs which are again		IPv6 addresses are autoconfigured from IIDs which are again
	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].
	A G.9959 NodeID is 8 bits in length. A NodeID is mapped into an IEEE		A G.9959 NodeID is 8 bits in length. A NodeID is mapped into an IEEE
	EUI-64 identifier as follows:		EUI-64 identifier as follows:
	IID = 0000:00ff:fe00:YYXX		IID = 0000:00ff:fe00:YYXX
	Figure 3: Constructing a compressible IID		Figure 3: 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
	to instantiate multiple IPv6 interfaces. The YY value MUST be		to instantiate multiple IPv6 interfaces. The YY value MUST be
	ignored when computing the corresponding NodeID (the XX value) from		ignored when computing the corresponding NodeID (the XX value) from
	an IID.		an IID.
	skipping to change at page 9, line 7 ¶		skipping to change at page 9, line 19 ¶
	Figure 4: IPv6 Link Local Address		Figure 4: IPv6 Link Local Address
	5.3. Unicast Address Mapping		5.3. Unicast Address Mapping
	The address resolution procedure for mapping IPv6 unicast addresses		The address resolution procedure for mapping IPv6 unicast addresses
	into G.9959 link-layer addresses follows the general description in		into G.9959 link-layer addresses follows the general description in
	Section 7.2 of [RFC4861]. The Source/Target Link-layer Address		Section 7.2 of [RFC4861]. The Source/Target Link-layer Address
	option MUST have the following form when the link layer is G.9959.		option MUST have the following form when the link layer is G.9959.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length=1 |		| Type | Length=1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 0x00 | NodeID |		| 0x00 | NodeID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Padding |		| Padding |
	+- -+		+- -+
	| (All zeros) |		| (All zeros) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5: IPv6 Unicast Address Mapping		Figure 5: IPv6 Unicast Address Mapping
	Option fields:		Option fields:
	Type: The value 1 signifies the Source Link-layer address. The value		Type: The value 1 signifies the Source Link-layer address. The value
	2 signifies the Destination Link-layer address.		2 signifies the Destination Link-layer address.
	Length: This is the length of this option (including the type and		Length: This is the length of this option (including the type and
	length fields) in units of 8 octets. The value of this field is		length fields) in units of 8 octets. The value of this field is
	skipping to change at page 9, line 40 ¶		skipping to change at page 10, line 5 ¶
	NodeID: This is the G.9959 NodeID the actual interface currently		NodeID: This is the G.9959 NodeID the actual interface currently
	responds to. The link-layer address may change if the interface		responds to. The link-layer address may change if the interface
	joins another network at a later time.		joins another network at a later time.
	5.4. On the use of Neighbor Discovery technologies		5.4. On the use of Neighbor Discovery technologies
	[RFC4861] specifies how IPv6 nodes may resolve link layer addresses		[RFC4861] specifies how IPv6 nodes may resolve link layer addresses
	from IPv6 addresses via the use of link-local IPv6 multicast.		from IPv6 addresses via the use of link-local IPv6 multicast.
	[RFC6775] is an optimization of [RFC4861], specifically targeting		[RFC6775] is an optimization of [RFC4861], specifically targeting
	6LoWPAN networks. [RFC6775] defines how a 6LoWPAN node may register		6LoWPAN networks. [RFC6775] defines how a 6LoWPAN node may register
	IPv6 addresses with an authoritative border router (ABR). Generally,		IPv6 addresses with an authoritative border router (ABR). Mesh-under
	nodes SHOULD NOT use [RFC6775] address registration. However,		networks SHOULD NOT use [RFC6775] address registration. However,
	address registration MUST be used if the first 6 bytes of the IID do		[RFC6775] address registration MUST be used if the first 6 bytes of
	not comply with the format defined in Figure 3.		the IID do not comply with the format defined in Figure 3.
	In route-over environments, IPv6 hosts MUST use [RFC6775] address		In route-over environments, IPv6 hosts MUST use [RFC6775] address
	registration. [RFC6775] Duplicate Address Detection (DAD) SHOULD NOT		registration. [RFC6775] Duplicate Address Detection (DAD) SHOULD NOT
	be used, since the link-layer inclusion process of G.9959 ensures		be used, since the link-layer inclusion process of G.9959 ensures
	that a NodeID is unique for a given HomeID.		that a NodeID is unique for a given HomeID.
	5.4.1. Prefix and CID management (Route-over)		5.4.1. Prefix and CID management (Route-over)
	A node implementation for route-over operation MAY use RFC6775		A node implementation for route-over operation MAY use RFC6775
	mechanisms for obtaining IPv6 prefixes and corresponding header		mechanisms for obtaining IPv6 prefixes and corresponding header
	compression context information [RFC6282]. RFC6775 Route-over		compression context information [RFC6282]. RFC6775 Route-over
	requirements apply with no modifications.		requirements apply with no modifications.
	5.4.2. Prefix and CID management (Mesh-under)		5.4.2. Prefix and CID management (Mesh-under)
	An implementation for mesh-under operation MUST use [RFC6775]		An implementation for mesh-under operation MUST use [RFC6775]
	mechanisms for managing IPv6 prefixes and corresponding header		mechanisms for managing IPv6 prefixes and corresponding header
	compression context information [RFC6282]. When using [RFC6775]		compression context information [RFC6282]. Except for the specific
	mechanisms for sending RAs, the M flag MUST NOT be set. As stated by		redefinition of the RA Router Lifetime value 0xFFFF (refer to
	[RFC6775], an ABR is responsible for managing prefix(es). Global		Section 5.4.2.3), the text of the following subsections is in
	prefixes may change over time. It is RECOMMENDED that a ULA prefix		compliance with [RFC6775].
	is always assigned to the 6LoWPAN subnet to facilitate stable site-
	local application associations based on IPv6 addresses. Prefixes		5.4.2.1. Prefix assignment considerations
	used in the 6LoWPAN subnet are distributed by normal RA mechanisms.
			When using [RFC6775] mechanisms for sending RAs, the M flag MUST NOT
			be set. As stated by [RFC6775], an ABR is responsible for managing
			prefix(es). Global prefixes may change over time. It is RECOMMENDED
			that a ULA prefix is always assigned to the 6LoWPAN subnet to
			facilitate stable site-local application associations based on IPv6
			addresses. Prefixes used in the 6LoWPAN subnet are distributed by
			normal RA mechanisms.
			5.4.2.2. Robust and efficient CID management
	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.
	Prefixes and corresponding Context IDs MUST be assigned during		Prefixes and corresponding Context IDs MUST be assigned during
	initial node inclusion. Nodes MUST renew the prefix and CID		initial node inclusion.
	according to the lifetime signaled by the ABR. [RFC6775] specifies
	that the maximum value of the RA Router Lifetime field MAY be up to		CIDs SHOULD be used in a cyclic fashion to assist battery powered
	0xFFFF. This document further specifies that the value 0xFFFF MUST		nodes with no real-time clock. When updating context information, a
	be interpreted as infinite lifetime. This value SHOULD NOT be used		CID may have its lifetime set to zero to obsolete it. The CID SHOULD
	by ABRs. Its use is only intended for a sleeping network controller;		NOT be reused immediately; rather the next vacant CID should be
	for instance a battery powered remote control being master for a		assigned. An ABR detecting the use of an obsoleted CID SHOULD
	small island-mode network of light modules. CIDs SHOULD be used in a		immediately send an RA with updated Context Information. Header
	cyclic fashion to assist battery powered nodes with no real-time		compression based on CIDs MUST NOT be used for RA messages carrying
	clock. When updating context information, a CID may have its		Context Information. An expired CID and the associated prefix SHOULD
	lifetime set to zero to obsolete it. The CID SHOULD NOT be reused		NOT be reset but rather retained in receive-only mode if there is no
	immediately; rather the next vacant CID should be assigned. An ABR		other current need for the CID value. This will allow an ABR to
	detecting the use of an obsoleted CID SHOULD immediately send an RA		detect if a sleeping node without clock uses an expired CID and in
	with updated Context Information. Header compression based on CIDs		response, the LBR SHOULD immediately return an RA with fresh Context
	MUST NOT be used for RA messages carrying Context Information. An		Information to the originator.
	expired CID and the associated prefix SHOULD NOT be reset but rather
	retained in receive-only mode if there is no other current need for		5.4.2.3. Infinite prefix lifetime support for island-mode networks
	the CID value. This will allow an ABR to detect if a sleeping node
	without clock uses an expired CID and in response, the LBR SHOULD		Nodes MUST renew the prefix and CID according to the lifetime
	immediately return an RA with fresh Context Information to the		signaled by the ABR. [RFC6775] specifies that the maximum value of
	originator. Except for the specific redefinition of the RA Router		the RA Router Lifetime field MAY be up to 0xFFFF. This document
	Lifetime value 0xFFFF, the above text is in compliance with		further specifies that the value 0xFFFF MUST be interpreted as
	[RFC6775].		infinite lifetime. This value SHOULD NOT be used by ABRs. Its use
			is only intended for a sleeping network controller; for instance a
			battery powered remote control being master for a small island-mode
			network of light modules.
	6. Header Compression		6. Header Compression
	IPv6 header fields SHOULD be compressed. If IPv6 header compression
	is used, it MUST be according to [RFC6282]. This section will simply		IPv6 header compression [RFC6282] MUST be supported by
	identify substitutions that should be made when interpreting the text		implementations of this specification. IPv6 header fields SHOULD be
	of [RFC6282].		compressed by default. When IPv6 header compression is used, it MUST
			be according to [RFC6282]. This section will simply identify
			substitutions that should be made 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
	address") it MUST be formed by prepending an Interface label byte to		address") it MUST be formed by prepending an Interface label byte to
	the G.9959 NodeID:		the G.9959 NodeID:
	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 MUST be ignored. This document only		64 bit 802.15.4 address details MUST be ignored. This document only
	specifies the use of short addresses.		specifies the use of short addresses.
	skipping to change at page 12, line 27 ¶		skipping to change at page 13, line 9 ¶
	safety critical products) will implement coordination or integration		safety critical products) will implement coordination or integration
	functions. These may communicate regularly with IPv6 peers outside		functions. These may communicate regularly with IPv6 peers outside
	the subnet. Such IPv6 devices are expected to secure their end-to-		the subnet. Such IPv6 devices are expected to secure their end-to-
	end communications with standard security mechanisms (e.g., IPsec,		end communications with standard security mechanisms (e.g., IPsec,
	TLS, etc).		TLS, etc).
	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 Kerry Lynn, Tommas Jess Christensen and Erez		their work. Thanks to Erez Ben-Tovim, Kerry Lynn, Michael
	Ben-Tovim for useful discussions. Thanks to Carsten Bormann for		Richardson, Tommas Jess Christensen for useful comments. Thanks to
	extensive feedback which improved this document significantly.		Carsten Bormann for extensive feedback which improved this document
			significantly.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[EUI64] IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)		[EUI64] IEEE, "communicationIDELINES FOR 64-BIT GLOBAL IDENTIFIER
	REGISTRATION AUTHORITY", IEEE Std http://		(EUI-64) 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.
	[G.9959.llc]		[G.9959] "G.9959 (02/12) + G.9959 Amendment 1 (10/13): Short range,
	ITU-T, "G.9959 Contribution: Logical Link Control (LLC)		narrow-band digital radiocommunication transceivers",
	layer", ITU-T draft contribution 2013-04-Q15-023.doc,		February 2012.
	April 2013.
	[G.9959.sar]
	ITU-T, "G.9959 Contribution: Segmentation And Reassembly
	(SAR) adaptation layer", ITU-T draft contribution
	2013-04-Q15-024.doc, April 2013.
	[G.9959] ITU-T, "G.9959: Low-Power, narrowband radio for control
	applications", January 2012.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, December 1998.		(IPv6) Specification", RFC 2460, December 1998.
	[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet		[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
	Networks", RFC 2464, December 1998.		Networks", RFC 2464, December 1998.
	skipping to change at page 13, line 46 ¶		skipping to change at page 14, line 20 ¶
	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.
	10.2. Informative References		10.2. Informative References
	[P2P-RPL] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J.
	Martocci, "IETF, I-D.ietf-roll-p2p-rpl-15, Reactive
	Discovery of Point-to-Point Routes in Low Power and Lossy
	Networks", December 2012.
	[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor		[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
	Discovery (ND) Trust Models and Threats", RFC 3756, May		Discovery (ND) Trust Models and Threats", RFC 3756, May
	2004.		2004.
	[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,		[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
	Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.		Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
	Wood, "Advice for Internet Subnetwork Designers", BCP 89,		Wood, "Advice for Internet Subnetwork Designers", BCP 89,
	RFC 3819, July 2004.		RFC 3819, July 2004.
	[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,		[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
	Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.		Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
	Alexander, "RPL: IPv6 Routing Protocol for Low-Power and		Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
	Lossy Networks", RFC 6550, March 2012.		Lossy Networks", RFC 6550, March 2012.
			[RFC6997] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J.
			Martocci, "Reactive Discovery of Point-to-Point Routes in
			Low-Power and Lossy Networks", RFC 6997, August 2013.
	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
	Jakob Buron		Jakob Buron
	Sigma Designs		Sigma Designs
	Emdrupvej 26A, 1.		Emdrupvej 26A, 1.
	Copenhagen O 2100		Copenhagen O 2100
	Denmark		Denmark
	Email: jakob_buron@sigmadesigns.com		Email: jakob_buron@sigmadesigns.com
End of changes. 27 change blocks.
	113 lines changed or deleted		121 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/