< draft-ietf-6lo-dect-ule-01.txt		draft-ietf-6lo-dect-ule-02.txt >
	6Lo Working Group P. Mariager		6Lo Working Group P. Mariager
	Internet-Draft J. Petersen, Ed.		Internet-Draft J. Petersen, Ed.
	Intended status: Standards Track RTX A/S		Intended status: Standards Track RTX A/S
	Expires: July 31, 2015 Z. Shelby		Expires: January 4, 2016 Z. Shelby
	ARM		ARM
	M. Van de Logt		M. Van de Logt
	Gigaset Communications GmbH		Gigaset Communications GmbH
	D. Barthel		D. Barthel
	Orange Labs		Orange Labs
	January 27, 2015		July 3, 2015
	Transmission of IPv6 Packets over DECT Ultra Low Energy		Transmission of IPv6 Packets over DECT Ultra Low Energy
	draft-ietf-6lo-dect-ule-01		draft-ietf-6lo-dect-ule-02
	Abstract		Abstract
	DECT Ultra Low Energy is a low power air interface technology that is		DECT Ultra Low Energy is a low power air interface technology that is
	defined by the DECT Forum and specified by ETSI.		defined by the DECT Forum and specified by ETSI.
	The DECT air interface technology has been used world-wide in		The DECT air interface technology has been used world-wide in
	communication devices for more than 20 years, primarily carrying		communication devices for more than 20 years, primarily carrying
	voice for cordless telephony but has also been deployed for data		voice for cordless telephony but has also been deployed for data
	centric services.		centric services.
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	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 July 31, 2015.		This Internet-Draft will expire on January 4, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 41 ¶
	1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . 3
	2. DECT Ultra Low Energy . . . . . . . . . . . . . . . . . . . . 4		2. DECT Ultra Low Energy . . . . . . . . . . . . . . . . . . . . 4
	2.1. The DECT ULE Protocol Stack . . . . . . . . . . . . . . . 4		2.1. The DECT ULE Protocol Stack . . . . . . . . . . . . . . . 4
	2.2. Link layer roles and topology . . . . . . . . . . . . . . 6		2.2. Link layer roles and topology . . . . . . . . . . . . . . 6
	2.3. Addressing Model . . . . . . . . . . . . . . . . . . . . 6		2.3. Addressing Model . . . . . . . . . . . . . . . . . . . . 6
	2.4. MTU Considerations . . . . . . . . . . . . . . . . . . . 7		2.4. MTU Considerations . . . . . . . . . . . . . . . . . . . 7
	2.5. Additional Considerations . . . . . . . . . . . . . . . . 7		2.5. Additional Considerations . . . . . . . . . . . . . . . . 7
	3. Specification of IPv6 over DECT ULE . . . . . . . . . . . . . 7		3. Specification of IPv6 over DECT ULE . . . . . . . . . . . . . 7
	3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 8		3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 8
	3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . 8		3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . 8
	3.3. Internet connectivity scenarios . . . . . . . . . . . . . 12		3.3. Subnets and Internet connectivity scenarios . . . . . . . 12
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 13		5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	6. ETSI Considerations . . . . . . . . . . . . . . . . . . . . . 14		6. ETSI Considerations . . . . . . . . . . . . . . . . . . . . . 14
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	8.1. Normative References . . . . . . . . . . . . . . . . . . 14		8.1. Normative References . . . . . . . . . . . . . . . . . . 15
	8.2. Informative References . . . . . . . . . . . . . . . . . 15		8.2. Informative References . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	DECT Ultra Low Energy (DECT ULE or just ULE) is an air interface		DECT Ultra Low Energy (DECT ULE or just ULE) is an air interface
	technology building on the key fundamentals of traditional DECT /		technology building on the key fundamentals of traditional DECT /
	CAT-iq but with specific changes to significantly reduce the power		CAT-iq but with specific changes to significantly reduce the power
	consumption on the expense of data throughput. DECT ULE devices with		consumption at the expense of data throughput. DECT ULE devices with
	requirements to power consumption will operate on special power		requirements on power consumption will operate on special power
	optimized silicon, but can connect to a DECT Gateway supporting		optimized silicon, but can connect to a DECT Gateway supporting
	traditional DECT / CAT-iq for cordless telephony and data as well as		traditional DECT / CAT-iq for cordless telephony and data as well as
	the ULE extensions. DECT terminology operates with two major role		the ULE extensions. DECT terminology operates with two major role
	definitions: The Portable Part (PP) is the power constrained device,		definitions: The Portable Part (PP) is the power constrained device,
	while the Fixed Part (FP) is the Gateway or base station. This FP		while the Fixed Part (FP) is the Gateway or base station. This FP
	may be connected to the Internet. An example of a use case for DECT		may be connected to the Internet. An example of a use case for DECT
	ULE is a home security sensor transmitting small amounts of data (few		ULE is a home security sensor transmitting small amounts of data (few
	bytes) at periodic intervals through the FP, but is able to wake up		bytes) at periodic intervals through the FP, but is able to wake up
	upon an external event (burglar) and communicate with the FP.		upon an external event (burglar) and communicate with the FP.
	Another example incorporating both DECT ULE as well as traditional		Another example incorporating both DECT ULE as well as traditional
	CAT-iq telephony is an elderly pendant (broche) which can transmit		CAT-iq telephony is an elderly pendant (broche) which can transmit
	periodic status messages to a care provider using very little		periodic status messages to a care provider using very little
	battery, but in the event of urgency, the elderly person can		battery, but in the event of urgency, the elderly person can
	establish a voice connection through the pendant to an alarm service.		establish a voice connection through the pendant to an alarm service.
	It is expected that DECT ULE will be integrated into many residential		It is expected that DECT ULE will be integrated into many residential
	gateways, as many of these already implements DECT CAT-iq for		gateways, as many of these already implements DECT CAT-iq for
	cordless telephony. DECT ULE can be added as a software option for		cordless telephony. DECT ULE can be added as a software option for
	the FP. It is desirable to consider IPv6 for DECT ULE devices due to		the FP. It is desirable to consider IPv6 for DECT ULE devices due to
	the large address space and well-known infrastructure. This document		the large address space and well-known infrastructure. This document
	describes how IPv6 is used on DECT ULE links to optimize power while		describes how IPv6 is used on DECT ULE links to optimize power while
	maintaining the many benefits of IPv6 transmission. [RFC4944]		maintaining the many benefits of IPv6 transmission. [RFC4944],
	specifies the transmission of IPv6 over IEEE 802.15.4. DECT ULE has		[RFC6282] and [RFC6775] specify the transmission of IPv6 over IEEE
	in many ways similar characteristics of IEEE 802.15.4, but also		802.15.4. DECT ULE has many characteristics similar to those of IEEE
	differences. Many of the mechanisms defined in [RFC4944] can be		802.15.4, but also differences. Many of the mechanisms defined for
	applied to the transmission of IPv6 on DECT ULE links.		transmission of IPv6 over IEEE 802.15.4 can be applied to the
			transmission of IPv6 on DECT ULE links.
	This document specifies how to map IPv6 over DECT ULE inspired by		This document specifies how to map IPv6 over DECT ULE inspired by
	[RFC4944].		[RFC4944], [RFC6282], [RFC6775] and [I-D.ietf-6lo-btle].
	1.1. Requirements Notation		1.1. Requirements Notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	1.2. Terms Used		1.2. Terms Used
	PP: DECT Portable Part, typically the sensor node		PP: DECT Portable Part, typically the sensor node
	FP: DECT Fixed Part, the gateway		FP: DECT Fixed Part, the gateway
	LLME: Lower Layer Management Entity		LLME: Lower Layer Management Entity
	NWK: Network		RFPI: Radio Fixed Part Identity
			IPEI: International Portable Equipment Identity
			TPUI: Temporary Portable User Identity
			PMID: Portable MAC Identity
	PVC: Permanent Virtual Circuit		PVC: Permanent Virtual Circuit
	6LN: DECT Portable part having a role as defined in [RFC6775]		6LN: DECT Portable part having a role as defined in [RFC6775]
	6LBR: DECT Fixed Part having a role as defined in [RFC6775]		6LBR: DECT Fixed Part having a role as defined in [RFC6775]
	2. DECT Ultra Low Energy		2. DECT Ultra Low Energy
	DECT ULE is a low power air interface technology that is designed to		DECT ULE is a low power air interface technology that is designed to
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 11 ¶
	The current DECT ULE MAC layer standard supports low bandwidth data		The current DECT ULE MAC layer standard supports low bandwidth data
	broadcast. However the usage of this broadcast service has not yet		broadcast. However the usage of this broadcast service has not yet
	been standardized for higher layers. This document is not		been standardized for higher layers. This document is not
	considering usage of this DECT ULE MAC broadcast service in current		considering usage of this DECT ULE MAC broadcast service in current
	version.		version.
	In general, communication sessions can be initiated from both FP and		In general, communication sessions can be initiated from both FP and
	PP side. Depending on power down modes employed in the PP, latency		PP side. Depending on power down modes employed in the PP, latency
	may occur when initiating sessions from FP side. MAC layer		may occur when initiating sessions from FP side. MAC layer
	communication can either take place using connection oriented packet		communication can take place using either connection oriented packet
	transfer with low overhead for short sessions or take place using		transfer with low overhead for short sessions or take place using
	connection oriented bearers including media reservation. The MAC		connection oriented bearers including media reservation. The MAC
	layer autonomously selects the radio spectrum positions that are		layer autonomously selects the radio spectrum positions that are
	available within the band and can rearrange these to avoid		available within the band and can rearrange these to avoid
	interference. The MAC layer has built-in retransmission procedures		interference. The MAC layer has built-in retransmission procedures
	in order to improve transmission reliability.		in order to improve transmission reliability.
	The DECT ULE device will typically incorporate an Application		The DECT ULE device will typically incorporate an Application
	Programmers Interface (API) as well as common elements known as		Programmers Interface (API) as well as common elements known as
	Generic Access Profile (GAP) for enrolling into the network. The		Generic Access Profile (GAP) for enrolling into the network. The
	skipping to change at page 6, line 28 ¶		skipping to change at page 6, line 32 ¶
	[DECT ULE PP]-------+[DECT ULE FP]+-------[DECT ULE PP]		[DECT ULE PP]-------+[DECT ULE FP]+-------[DECT ULE PP]
	/ \		/ \
	[DECT ULE PP]-----/ \-----[DECT ULE PP]		[DECT ULE PP]-----/ \-----[DECT ULE PP]
	Figure 2: DECT ULE star topology		Figure 2: DECT ULE star topology
	DECT ULE repeaters are not considered in this document.		DECT ULE repeaters are not considered in this document.
	2.3. Addressing Model		2.3. Addressing Model
	Each DECT PP is assigned an <IPEI> (International Portable Equipment		Each DECT PP is assigned an IPEI during manufacturing. This identity
	Identity) during manufacturing. This identity has the size of 40		has the size of 40 bits and is DECT globally unique for the PP and
	bits and is DECT globally unique for the PP and can be used to		can be used to constitute the MAC address. However, it cannot be
	constitute the MAC address. However, it cannot be used to derive a		used to derive a globally unique IID.
	globally unique IID.
	When bound to a FP, a PP is assigned a 20 bit TPUI (Temporary		When bound to a FP, a PP is assigned a 20 bit TPUI which is unique
	Portable User Identity) which is unique within the FP. This TPUI is		within the FP. This TPUI is used for addressing (layer 2) in
	used for addressing (layer 2) in messages between FP and PP.		messages between FP and PP.
	Each DECT FP is assigned a <RFPI> (Radio Fixed Part Identity) during		Each DECT FP is assigned a RFPI during manufacturing. This identity
	manufacturing. This identity has the size of 40 bits and is globally		has the size of 40 bits and is globally unique for a FP and can be
	unique for a FP and can be used to constitute the MAC address.		used to constitute the MAC address. However, it cannot be used to
	However, it cannot be used to derive a globally unique IID.		derive a globally unique IID.
	Alternatively each DECT PP and DECT FP can be assigned a unique		Alternatively each DECT PP and DECT FP can be assigned a unique
	(IEEE) MAC-48 address additionally to the DECT identities to be used		(IEEE) MAC-48 address additionally to the DECT identities to be used
	by the 6LoWPAN. With such an approach, the FP and PP have to		by the 6LoWPAN. With such an approach, the FP and PP have to
	implement a mapping between used MAC-48 addresses and DECT		implement a mapping between used MAC-48 addresses and DECT
	identities.		identities.
	2.4. MTU Considerations		2.4. MTU Considerations
	Generally the DECT ULE FP and PP may be generating data that fits		Generally the DECT ULE FP and PP may be generating data that fits
	into a single MAC Layer packet (38 bytes) for periodically		into a single MAC Layer packet (38 octets) for periodically
	transferred information, depending on application. IP data packets		transferred information, depending on application. IP data packets
	may be much larger and hence MTU size should be the size of the IP		may be much larger and hence MTU size should be the size of the IP
	data packet. The DECT ULE DLC procedures supports segmentation and		data packet. The DECT ULE DLC procedures supports segmentation and
	reassembly of any MTU size below 65536 bytes, but most		reassembly of any MTU size below 65536 octets, but most
	implementations do only support smaller values. The default MTU size		implementations do only support smaller values. The default MTU size
	in DECT ULE is 500 octets, but it is assumed it is configured to fit		in DECT ULE is 500 octets, but it SHALL be configured to fit the
	the requirements from IPv6 data packets, hence [RFC4944]		requirements from IPv6 data packets, hence [RFC4944] fragmentation/
	fragmentation/reassembly is not required.		reassembly is not required.
	It is expected that the LOWPAN_IPHC packet will fulfill all the		It is expected that the LOWPAN_IPHC packet will fulfill all the
	requirements for header compression without spending unnecessary		requirements for header compression without spending unnecessary
	overhead for mesh addressing.		overhead for mesh addressing.
	It is important to realize that the usage of larger packets will be		It is important to realize that the usage of larger packets will be
	on the expense of battery life, as a large packet inside the DECT ULE		at the expense of battery life, as a large packet inside the DECT ULE
	stack will be fragmented into several or many MAC layer packets, each		stack will be fragmented into several or many MAC layer packets, each
	consuming power to transmit / receive.		consuming power to transmit / receive.
	2.5. Additional Considerations		2.5. Additional Considerations
	The DECT ULE standard allows PP to be registered (bind) to multiple		The DECT ULE standard allows PP to be registered (bind) to multiple
	FP and roaming between these FP. This draft does not consider the		FP and roaming between these FP. This draft does not consider the
	scenarios of PP roaming between multiple FP. The use of repeater		scenarios of PP roaming between multiple FP. The use of repeater
	functionality is also not considered in this draft.		functionality is also not considered in this draft.
	3. Specification of IPv6 over DECT ULE		3. Specification of IPv6 over DECT ULE
	Before any IP-layer communications can take place over DECT ULE, DECT		Before any IP-layer communications can take place over DECT ULE, DECT
	ULE enabled nodes such as 6LNs and 6LBRs have to find each other and		ULE enabled nodes such as 6LNs and 6LBRs have to find each other and
	establish a suitable link-layer connection. The obtain-access-rights		establish a suitable link-layer connection. The obtain-access-rights
	registration and location registration procedures are documented by		registration and location registration procedures are documented by
	ETSI in the specifications [EN300.175-part1-7] and [TS102.939-1].		ETSI in the specifications [EN300.175-part1-7], [TS102.939-1] and
			[TS102.939-2].
	DECT ULE technology sets strict requirements for low power		DECT ULE technology sets strict requirements for low power
	consumption and thus limits the allowed protocol overhead. 6LoWPAN		consumption and thus limits the allowed protocol overhead. 6LoWPAN
	standards [RFC4944], [RFC6775], and [RFC6282] provide useful		standards [RFC4944], [RFC6775], and [RFC6282] provide useful
	functionality for reducing overhead which can be applied to DECT ULE.		functionality for reducing overhead which can be applied to DECT ULE.
	This functionality comprises link-local IPv6 addresses and stateless		This functionality comprises link-local IPv6 addresses and stateless
	IPv6 address autoconfiguration, Neighbor Discovery and header		IPv6 address autoconfiguration, Neighbor Discovery and header
	compression.		compression.
	The ULE 6LoWPAN adaptation layer can run directly on this U-plane DLC		The ULE 6LoWPAN adaptation layer can run directly on this U-plane DLC
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 7 ¶
	3.2. Link model		3.2. Link model
	The general model is that IPv6 is layer 3 and DECT ULE MAC+DLC is		The general model is that IPv6 is layer 3 and DECT ULE MAC+DLC is
	layer 2. The DECT ULE implements fragmentation and reassembly		layer 2. The DECT ULE implements fragmentation and reassembly
	functionality and [RFC4944] fragmentation and reassembly function		functionality and [RFC4944] fragmentation and reassembly function
	MUST NOT be used. Since IPv6 requires MTU size of at least 1280		MUST NOT be used. Since IPv6 requires MTU size of at least 1280
	octets, the DECT ULE connection (PVC) MUST be configured with		octets, the DECT ULE connection (PVC) MUST be configured with
	equivalent MTU size.		equivalent MTU size.
	This specification also assumes the IPv6 header compression format		Per this specification, the IPv6 header compression format specified
	specified in [RFC6282]. It is also assumed that the IPv6 payload		in [RFC6282] MUST be used. The IPv6 payload length can be derived
	length can be inferred from the ULE DLC packet length and the IID		from the ULE DLC packet length and the possibly elided IPv6 address
	value inferred from the link-layer address.		can be reconstructed from the link-layer address, used at the time of
			DECT ULE connection establishment, from the ULE MAC packet address,
			compression context if any, and from address registration information
			(see Section 3.2.2).
	Due to DECT ULE star topology, each branch of the star is considered		Due to DECT ULE star topology, each branch of the star is considered
	to be an individual link and thus the PPs cannot directly hear one		to be an individual link and thus the PPs cannot directly hear one
	another and cannot talk to one another with link-local addresses.		another and cannot talk to one another with link-local addresses.
	However, the FP acts as a 6LBR for communication between the PPs.		However, the FP acts as a 6LBR for communication between the PPs.
	After the FP and PPs have connected at the DECT ULE level, the link		After the FP and PPs have connected at the DECT ULE level, the link
	can be considered up and IPv6 address configuration and transmission		can be considered up and IPv6 address configuration and transmission
	can begin. The FP ensures address collisions do not occur.		can begin. The FP ensures address collisions do not occur.
	3.2.1. Stateless address autoconfiguration		3.2.1. Stateless address autoconfiguration
	A DECT ULE 6LN performs stateless address autoconfiguration as per		A DECT ULE 6LN performs stateless address autoconfiguration as per
	[RFC4862]. A 64-bit Interface identifier (IID) for a DECT ULE		[RFC4862]. Following the guidance of [RFC7136], a 64-bit Interface
	interface MAY be formed by utilizing a MAC-48 device address as		identifier (IID) for a DECT ULE interface MAY be formed by utilizing
	defined in [RFC2464] "IPv6 over Ethernet" specification.		a MAC-48 device address as defined in [RFC2464] "IPv6 over Ethernet"
			specification.
	Alternatively, the DECT device addresses IPEI, RFPI or TPUI, MAY be		Alternatively, the DECT device addresses IPEI, RFPI or TPUI, MAY be
	used instead to derive the IID.		used instead to derive the IID. These DECT devices addresses
			consisting of 40, 40 and 20 bits respectively, MUST be expanded with
			leading bits to form a 48 bit address. Least significant bit of this
			address is the last bit in network order. The expanded leading bits
			are all zeros except for 7th bit indicating not global unique. First
			bit is set to a one for addresses derived from the RFPI and 2nd bit
			is set to one when the address is derived from the PMID. For example
			from IPEI=01.23.45.67.89 is derived MAC address equal
			02:01:23:45:67:89 and from PMID=0.01.23 is derived MAC address equal
			42:00:00:00:01:23.
	As defined in [RFC4291], the IPv6 link-local address for a DECT ULE		As defined in [RFC4291], the IPv6 link-local address for a DECT ULE
	node is formed by appending the IID, to the prefix FE80::/64, as		node is formed by appending the IID, to the prefix FE80::/64, as
	shown in Figure 4.		shown in Figure 4.
	10 bits 54 bits 64 bits		10 bits 54 bits 64 bits
	+----------+-----------------+----------------------+		+----------+-----------------+----------------------+
	|1111111010| zeros | Interface Identifier |		|1111111010| zeros | Interface Identifier |
	+----------+-----------------+----------------------+		+----------+-----------------+----------------------+
	Figure 4: IPv6 link-local address in DECT ULE		Figure 4: IPv6 link-local address in DECT ULE
	A 6LN MUST join the all-nodes multicast address.		A 6LN MUST join the all-nodes multicast address.
	After link-local address configuration, 6LN sends Router Solicitation		After link-local address configuration, 6LN sends Router Solicitation
	messages as described in [RFC4861] Section 6.3.7.		messages as described in [RFC4861] Section 6.3.7.
	For non-link-local addresses a 64-bit IID MAY be formed by utilizing		For non-link-local addresses a 64-bit IID MAY be formed by utilizing
	a MAC-48 device address. Alternatively, a randomly generated IID		a MAC-48 device address. A 6LN can also use a randomly generated IID
	(see Section 3.2.2) can be used instead, for example, as discussed in		(see Section 3.2.2), for example, as discussed in [I-D.ietf-6man-
	[I-D.ietf-6man-default-iids]. The non-link-local addresses 6LN		default-iids], or use alternative schemes such as Cryptographically
	generates must be registered with 6LBR as described in Section 3.2.2.		Generated Addresses (CGA) [RFC3972], privacy extensions [RFC4941],
			Hash-Based Addresses (HBA, [RFC5535]), or DHCPv6 [RFC3315]. The non-
	Only if the device address is known to be a public address the		link-local addresses 6LN generates MUST be registered with 6LBR as
	"Universal/Local" bit can be set to 1 [RFC4291].		described in Section 3.2.2.
	The means for a 6LBR to obtain an IPv6 prefix for numbering the DECT		The means for a 6LBR to obtain an IPv6 prefix for numbering the DECT
	ULE network is out of scope of this document, but can be, for		ULE network is out of scope of this document, but can be, for
	example, accomplished via DHCPv6 Prefix Delegation [RFC3633] or by		example, accomplished via DHCPv6 Prefix Delegation [RFC3633] or by
	using Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to		using Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to
	the link model of the DECT ULE the 6LBR MUST set the "on-link" flag		the link model of the DECT ULE the 6LBR MUST set the "on-link" flag
	(L) to zero in the Prefix Information Option [RFC4861]. This will		(L) to zero in the Prefix Information Option [RFC4861]. This will
	cause 6LNs to always send packets to the 6LBR, including the case		cause 6LNs to always send packets to the 6LBR, including the case
	when the destination is another 6LN using the same prefix.		when the destination is another 6LN using the same prefix.
	skipping to change at page 10, line 30 ¶		skipping to change at page 11, line 5 ¶
	support mesh networks, hence only those aspects that apply to a star		support mesh networks, hence only those aspects that apply to a star
	topology are considered.		topology are considered.
	The following aspects of the Neighbor Discovery optimizations		The following aspects of the Neighbor Discovery optimizations
	[RFC6775] are applicable to DECT ULE 6LNs:		[RFC6775] are applicable to DECT ULE 6LNs:
	1. For sending Router Solicitations and processing Router		1. For sending Router Solicitations and processing Router
	Advertisements the DECT ULE 6LNs MUST, respectively, follow Sections		Advertisements the DECT ULE 6LNs MUST, respectively, follow Sections
	5.3 and 5.4 of the [RFC6775].		5.3 and 5.4 of the [RFC6775].
	2. A DECT ULE 6LN SHOULD NOT register its link-local address. A		2. A DECT ULE 6LN MUST NOT register its link-local address. A DECT
	DECT ULE 6LN MUST register its non-link-local addresses with the 6LBR		ULE 6LN MUST register its non-link-local addresses with the 6LBR by
	by sending a Neighbor Solicitation (NS) message with the Address		sending a Neighbor Solicitation (NS) message with the Address
	Registration Option (ARO) and process the Neighbor Advertisement (NA)		Registration Option (ARO) and process the Neighbor Advertisement (NA)
	accordingly. The NS with the ARO option MUST be sent irrespective of		accordingly. The NS with the ARO option MUST be sent irrespective of
	the method used to generate the IID. The 6LN MUST register only one		the method used to generate the IID. The 6LN MUST register only one
	IPv6 address per available IPv6 prefix.		IPv6 address per available IPv6 prefix.
	3.2.3. Unicast and Multicast address mapping		3.2.3. Unicast and Multicast address mapping
	The DECT MAC layer broadcast service is considered inadequate for IP		The DECT MAC layer broadcast service is considered inadequate for IP
	multicast.		multicast.
	Hence traffic is always unicast between two DECT ULE nodes. Even in		Hence traffic is always unicast between two DECT ULE nodes. Even in
	the case where a 6LBR is attached to multiple 6LNs, the 6LBR cannot		the case where a 6LBR is attached to multiple 6LNs, the 6LBR cannot
	do a multicast to all the connected 6LNs. If the 6LBR needs to send		do a multicast to all the connected 6LNs. If the 6LBR needs to send
	a multicast packet to all its 6LNs, it has to replicate the packet		a multicast packet to all its 6LNs, it has to replicate the packet
	and unicast it on each link. However, this may not be energy-		and unicast it on each link. However, this may not be energy-
	efficient and particular care must be taken if the FP is battery-		efficient and particular care should be taken if the FP is battery-
	powered. In the opposite direction, a 6LN can only transmit data to		powered. In the opposite direction, a 6LN can only transmit data to
	or through the 6LBR. Hence, when a 6LN needs to transmit an IPv6		or through the 6LBR. Hence, when a 6LN needs to transmit an IPv6
	multicast packet, the 6LN will unicast the corresponding DECT ULE		multicast packet, the 6LN will unicast the corresponding DECT ULE
	packet to the 6LBR. The 6LBR will then forward the multicast packet		packet to the 6LBR. The 6LBR will then forward the multicast packet
	to other 6LNs. To avoid excess of unwanted multicast traffic being		to other 6LNs.
	sent to 6LNs, the 6LBR SHOULD implement MLD Snooping feature
	[RFC4541].
	3.2.4. Header Compression		3.2.4. Header Compression
	Header compression as defined in [RFC6282], which specifies the		Header compression as defined in [RFC6282], which specifies the
	compression format for IPv6 datagrams on top of IEEE 802.15.4, is		compression format for IPv6 datagrams on top of IEEE 802.15.4, is
	REQUIRED in this document as the basis for IPv6 header compression on		REQUIRED in this document as the basis for IPv6 header compression on
	top of DECT ULE. All headers MUST be compressed according to		top of DECT ULE. All headers MUST be compressed according to
	[RFC6282] encoding formats. The DECT ULE's star topology structure		[RFC6282] encoding formats. The DECT ULE's star topology structure
	and ARO can be exploited in order to provide a mechanism for IID		and ARO can be exploited in order to provide a mechanism for addess
	compression. The following text describes the principles of IPv6		compression. The following text describes the principles of IPv6
	address compression on top of DECT ULE.		address compression on top of DECT ULE.
	3.2.4.1. Link-local Header Compression		3.2.4.1. Link-local Header Compression
	In a link-local communication terminated at 6LN and 6LBR, both the		In a link-local communication terminated at 6LN and 6LBR, both the
	IPv6 source and destination addresses MUST be elided, since the node		IPv6 source and destination addresses MUST be elided, since the node
	knows that the packet is destined for it even if the packet does not		knows that the packet is destined for it even if the packet does not
	have destination IPv6 address. A node SHALL learn the IID of the		have destination IPv6 address. A node SHALL learn the IID of the
	other endpoint of each DECT ULE connection it participates in. By		other endpoint of each DECT ULE connection it participates in. By
	skipping to change at page 12, line 26 ¶		skipping to change at page 12, line 47 ¶
	the compressed IPv6 header, and MUST elide the IPv6 destination		the compressed IPv6 header, and MUST elide the IPv6 destination
	address of the packet before forwarding it to the 6LN. For this, the		address of the packet before forwarding it to the 6LN. For this, the
	6LBR MUST set the DAM field of the IPv6 compressed header as DAM=11.		6LBR MUST set the DAM field of the IPv6 compressed header as DAM=11.
	CID and DAC MUST be set to CID=1 and DAC=1. If a context is defined		CID and DAC MUST be set to CID=1 and DAC=1. If a context is defined
	for the prefix of the IPv6 source address, the 6LBR MUST indicate		for the prefix of the IPv6 source address, the 6LBR MUST indicate
	this context in the source fields of the compressed IPv6 header, and		this context in the source fields of the compressed IPv6 header, and
	MUST elide that prefix as well. For this, the 6LBR MUST set the SAM		MUST elide that prefix as well. For this, the 6LBR MUST set the SAM
	field of the IPv6 compressed header as CID=1, SAC=1 and SAM=01 or		field of the IPv6 compressed header as CID=1, SAC=1 and SAM=01 or
	SAM=11.		SAM=11.
	3.3. Internet connectivity scenarios		3.3. Subnets and Internet connectivity scenarios
	In a typical scenario, the DECT ULE network is connected to the		In a typical scenario, the DECT ULE network is connected to the
	Internet as shown in the Figure 5.		Internet as shown in the Figure 5. In this scenario, the DECT ULE
			network is deployed as one subnet, using one /64 IPv6 prefix. The
			6LBR is acting as router and forwarding packets between 6LNs and to
			and from Internet.
	A degenerate scenario can be imagined where a PP is acting as 6LBR		A degenerate scenario can be imagined where a PP is acting as 6LBR
	and providing Internet connectivity for the FP. How the FP could		and providing Internet connectivity for the FP. How the FP could
	then further provide Internet connectivity to other PP, possibly		then further provide Internet connectivity to other PP, possibly
	connected to the FP, is out of the scope of this document.		connected to the FP, is out of the scope of this document.
	6LN		6LN
	\ ____________		\ ____________
	\ / \		\ / \
	6LN ---- 6LBR --- | Internet |		6LN ---- 6LBR --- | Internet |
	/ \____________/		/ \____________/
	/		/
	6LN		6LN
	<-- DECT ULE -->		<-- DECT ULE -->
	Figure 5: DECT ULE network connected to the Internet		Figure 5: DECT ULE network connected to the Internet
	In some scenarios, the DECT ULE network may transiently or		In some scenarios, the DECT ULE network may transiently or
	permanently be an isolated network as shown in the Figure 6.		permanently be an isolated network as shown in the Figure 6. In this
			case the whole DECT ULE network consists of a single subnet with
			multiple links, where 6LBR is routing packets between 6LNs.
	6LN 6LN		6LN 6LN
	\ /		\ /
	\ /		\ /
	6LN --- 6LBR --- 6LN		6LN --- 6LBR --- 6LN
	/ \		/ \
	/ \		/ \
	6LN 6LN		6LN 6LN
	<------ DECT ULE ----->		<------ DECT ULE ----->
	skipping to change at page 14, line 6 ¶		skipping to change at page 14, line 30 ¶
	The DECT ULE pairing procedure generates a master authentication key		The DECT ULE pairing procedure generates a master authentication key
	(UAK) and during location registration procedure or when the		(UAK) and during location registration procedure or when the
	permanent virtual circuit are established, the session security keys		permanent virtual circuit are established, the session security keys
	are generated. Session security keys may be renewed regularly. The		are generated. Session security keys may be renewed regularly. The
	generated security keys (UAK and session security keys) are		generated security keys (UAK and session security keys) are
	individual for each FP-PP binding, hence all PP in a system have		individual for each FP-PP binding, hence all PP in a system have
	different security keys. DECT ULE PPs do not use any shared		different security keys. DECT ULE PPs do not use any shared
	encryption key.		encryption key.
	The IPv6 address configuration as described in Section 3.2.1 allows		The IPv6 address configuration as described in Section 3.2.1 allows
	implementations the choice to support [I-D.ietf-6man-default-iids]		implementations the choice to support, for example, [I-D.ietf-6man-
	for non-link addresses.		default-iids], [RFC3972], [RFC4941] or [RFC5535] for non-link-local
			addresses.
	6. ETSI Considerations		6. ETSI Considerations
	ETSI is standardizing a list of known application layer protocols		ETSI is standardizing a list of known application layer protocols
	that can use the DECT ULE permanent virtual circuit packet data		that can use the DECT ULE permanent virtual circuit packet data
	service. Each protocol is identified by a unique known identifier,		service. Each protocol is identified by a unique known identifier,
	which is exchanged in the service-change procedure as defined in		which is exchanged in the service-change procedure as defined in
	[TS102.939-1]. The IPv6/6LoWPAN as described in this document is		[TS102.939-1]. The IPv6/6LoWPAN as described in this document is
	considered as an application layer protocol on top of DECT ULE. In		considered as an application layer protocol on top of DECT ULE. In
	order to provide interoperability between 6LoWPAN / DECT ULE devices		order to provide interoperability between 6LoWPAN / DECT ULE devices
	a common protocol identifier for 6LoWPAN is standardized by ETSI.		a common protocol identifier for 6LoWPAN is standardized by ETSI.
	The ETSI DECT ULE Application Protocol Identifier is specified to		The ETSI DECT ULE Application Protocol Identifier is specified to
	0x06 for 6LoWPAN.		0x06 for 6LoWPAN [TS102.939-1].
	7. Acknowledgements		7. Acknowledgements
	We are grateful to the members of the IETF 6lo working group; this		We are grateful to the members of the IETF 6lo working group; this
	document borrows liberally from their work.		document borrows liberally from their work.
	Ralph Droms has provided valuable feedback for this draft.		Ralph Droms has provided valuable feedback for this draft.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[EN300.175-part1-7]		[EN300.175-part1-7]
	ETSI, "Digital Enhanced Cordless Telecommunications		ETSI, "Digital Enhanced Cordless Telecommunications
	(DECT); Common Interface (CI);", August 2013.		(DECT); Common Interface (CI);", March 2015.
	[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.
	[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.
	[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
	CBC-MAC (CCM)", RFC 3610, September 2003.
	[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic		[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
	Host Configuration Protocol (DHCP) version 6", RFC 3633,		Host Configuration Protocol (DHCP) version 6", RFC 3633,
	December 2003.		December 2003.
	[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast		[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
	Addresses", RFC 4193, October 2005.		Addresses", RFC 4193, October 2005.
	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, February 2006.		Architecture", RFC 4291, February 2006.
	[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
	"Considerations for Internet Group Management Protocol
	(IGMP) and Multicast Listener Discovery (MLD) Snooping
	Switches", RFC 4541, May 2006.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	September 2007.		September 2007.
	[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless		[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
	Address Autoconfiguration", RFC 4862, September 2007.		Address Autoconfiguration", RFC 4862, September 2007.
	[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy		[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
	Extensions for Stateless Address Autoconfiguration in		Extensions for Stateless Address Autoconfiguration in
	IPv6", RFC 4941, September 2007.		IPv6", RFC 4941, September 2007.
	skipping to change at page 15, line 37 ¶		skipping to change at page 16, line 10 ¶
	[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.
			[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
			Interface Identifiers", RFC 7136, February 2014.
	[TS102.939-1]		[TS102.939-1]
	ETSI, "Digital Enhanced Cordless Telecommunications		ETSI, "Digital Enhanced Cordless Telecommunications
	(DECT); Ultra Low Energy (ULE); Machine to Machine		(DECT); Ultra Low Energy (ULE); Machine to Machine
	Communications; Part 1: Home Automation Network (phase		Communications; Part 1: Home Automation Network (phase
	1)", April 2013.		1)", March 2015.
			[TS102.939-2]
			ETSI, "Digital Enhanced Cordless Telecommunications
			(DECT); Ultra Low Energy (ULE); Machine to Machine
			Communications; Part 2: Home Automation Network (phase
			2)", March 2015.
	8.2. Informative References		8.2. Informative References
			[I-D.ietf-6lo-btle]
			Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
			Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
			Energy", draft-ietf-6lo-btle-14 (work in progress), June
			2015.
	[I-D.ietf-6man-default-iids]		[I-D.ietf-6man-default-iids]
	Gont, F., Cooper, A., Thaler, D., and W. Will,		Gont, F., Cooper, A., Thaler, D., and S. LIU,
	"Recommendation on Stable IPv6 Interface Identifiers",		"Recommendation on Stable IPv6 Interface Identifiers",
	draft-ietf-6man-default-iids-02 (work in progress),		draft-ietf-6man-default-iids-04 (work in progress), June
	January 2015.		2015.
			[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
			and M. Carney, "Dynamic Host Configuration Protocol for
			IPv6 (DHCPv6)", RFC 3315, July 2003.
			[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
			CBC-MAC (CCM)", RFC 3610, September 2003.
			[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
			RFC 3972, March 2005.
			[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June
			2009.
	Authors' Addresses		Authors' Addresses
	Peter B. Mariager		Peter B. Mariager
	RTX A/S		RTX A/S
	Stroemmen 6		Stroemmen 6
	DK-9400 Noerresundby		DK-9400 Noerresundby
	Denmark		Denmark
	Email: pm@rtx.dk		Email: pm@rtx.dk
	skipping to change at page 16, line 41 ¶		skipping to change at page 17, line 41 ¶
	Marco van de Logt		Marco van de Logt
	Gigaset Communications GmbH		Gigaset Communications GmbH
	Frankenstrasse 2		Frankenstrasse 2
	D-46395 Bocholt		D-46395 Bocholt
	Germany		Germany
	Email: marco.van-de-logt@gigaset.com		Email: marco.van-de-logt@gigaset.com
	Dominique Barthel		Dominique Barthel
	Orange Labs		Orange Labs
			28 chemin du Vieux Chene
			38243 Meylan
			France
	Email: dominique.barthel@orange.com		Email: dominique.barthel@orange.com
End of changes. 41 change blocks.
	82 lines changed or deleted		130 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/