< draft-ietf-6lo-dect-ule-06.txt		draft-ietf-6lo-dect-ule-07.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: April 6, 2017 Z. Shelby		Expires: April 27, 2017 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
	October 3, 2016		October 24, 2016
	Transmission of IPv6 Packets over DECT Ultra Low Energy		Transmission of IPv6 Packets over DECT Ultra Low Energy
	draft-ietf-6lo-dect-ule-06		draft-ietf-6lo-dect-ule-07
	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 April 6, 2017.		This Internet-Draft will expire on April 27, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 4, line 20 ¶		skipping to change at page 4, line 20 ¶
	Part is having this role		Part is having this role
	6LN: 6LoWPAN Node as defined in [RFC6775]. The DECT Portable part		6LN: 6LoWPAN Node as defined in [RFC6775]. The DECT Portable part
	is having this role		is having this role
	6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network		6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network
	AES128: Advanced Encryption Standard with key size of 128 bits		AES128: Advanced Encryption Standard with key size of 128 bits
	API: Application Programming Interface		API: Application Programming Interface
	ARO: Address Registration Option [RFC6775]		ARO: Address Registration Option [RFC6775]
	CAT-iq: Cordless Advanced Technology - internet and quality		CAT-iq: Cordless Advanced Technology - internet and quality
	CID: Context Identifier [RFC6775]		CID: Context Identifier [RFC6775]
	DAC: Destination Address Compression		DAC: Destination Address Compression
			DAD: Duplicate Address Detection [RFC4862]
	DAM: Destination Address Mode		DAM: Destination Address Mode
	DHCPv6: Dynamic Host Configuration Protocol for IPv6 [RFC3315]		DHCPv6: Dynamic Host Configuration Protocol for IPv6 [RFC3315]
	DLC: Data Link Control		DLC: Data Link Control
	DSAA2: DECT Standard Authentication Algorithm #2		DSAA2: DECT Standard Authentication Algorithm #2
	DSC: DECT Standard Cipher		DSC: DECT Standard Cipher
	DSC2: DECT Standard Cipher #2		DSC2: DECT Standard Cipher #2
	FDMA: Frequency Division Multiplex		FDMA: Frequency Division Multiplex
	FP: DECT Fixed Part, the gateway		FP: DECT Fixed Part, the gateway
	GAP: Generic Access Profile		GAP: Generic Access Profile
	IID: Interface Identifier		IID: Interface Identifier
	skipping to change at page 7, line 31 ¶		skipping to change at page 7, line 31 ¶
	under routing are not used in DECT ULE networks.		under routing are not used in DECT ULE networks.
	DECT ULE repeaters are considered to operate in the DECT protocol		DECT ULE repeaters are considered to operate in the DECT protocol
	domain and are outside the scope of this document.		domain and are outside the scope of this document.
	2.3. Addressing Model		2.3. Addressing Model
	Each DECT PP is assigned an IPEI during manufacturing. This identity		Each DECT PP is assigned an IPEI during manufacturing. This identity
	has the size of 40 bits and is globally unique within DECT addressing		has the size of 40 bits and is globally unique within DECT addressing
	space and can be used to constitute the MAC address used to derive		space and can be used to constitute the MAC address used to derive
	the IID for link-local address. However, it cannot be used to derive		the IID for link-local address.
	a globally unique IID.
	During a DECT location registration procedure, the FP assigns a 20		During a DECT location registration procedure, the FP assigns a 20
	bit TPUI to a PP. The FP creates a unique mapping between the		bit TPUI to a PP. The FP creates a unique mapping between the
	assigned TPUI and the IPEI of each PP. This TPUI is used for		assigned TPUI and the IPEI of each PP. This TPUI is used for
	addressing (layer 2) in messages between FP and PP. Although the		addressing (layer 2) in messages between FP and PP. Although the
	TPUI is temporary by definition, the same value is usually repeatedly		TPUI is temporary by definition, the same value is usually repeatedly
	assigned to any given PP, hence it seems not suitable for		assigned to any given PP, hence it seems not suitable for
	construction of IID, see [I-D.ietf-6lo-privacy-considerations].		construction of IID, see [I-D.ietf-6lo-privacy-considerations].
	Each DECT FP is assigned a RFPI during manufacturing. This identity		Each DECT FP is assigned a RFPI during manufacturing. This identity
	has the size of 40 bits and is globally unique within DECT addressing		has the size of 40 bits and is globally unique within DECT addressing
	space and can be used to constitute the MAC address used to derive		space and can be used to constitute the MAC address used to derive
	the IID for link-local address. However, it cannot be used to derive		the IID for link-local address.
	a globally unique IID.
	Optionally each DECT PP and DECT FP can be assigned a unique (IEEE)		Optionally each DECT PP and DECT FP can be assigned a unique (IEEE)
	MAC-48 address additionally to the DECT identities to be used by the		MAC-48 address additionally to the DECT identities to be used by the
	6LoWPAN. During the address registration of non-link-local addresses		6LoWPAN. During the address registration of non-link-local addresses
	as specified by this document, the FP and PP can use such MAC-48 to		as specified by this document, the FP and PP can use such MAC-48 to
	construct the IID. However, as these addresses are considered as		construct the IID. However, as these addresses are considered as
	being permanent, such scheme is not recommended as per [I-D.ietf-6lo-		being permanent, such scheme is not recommended as per [I-D.ietf-6lo-
	privacy-considerations].		privacy-considerations].
	2.4. MTU Considerations		2.4. MTU Considerations
	skipping to change at page 11, line 35 ¶		skipping to change at page 11, line 16 ¶
	RFPI and set to zero for addresses derived from the IPEI. From these		RFPI and set to zero for addresses derived from the IPEI. From these
	intermediate 48 bit addresses are derived 64 bit IIDs similar to the		intermediate 48 bit addresses are derived 64 bit IIDs similar to the
	guidance of [RFC4291]. However, because DECT and IEEE address spaces		guidance of [RFC4291]. However, because DECT and IEEE address spaces
	are different, this intermediate address cannot be considered as		are different, this intermediate address cannot be considered as
	unique within IEEE address space. In the derived IIDs the U/L bit		unique within IEEE address space. In the derived IIDs the U/L bit
	(7th bit) will be zero, indicating that derived IID's are not		(7th bit) will be zero, indicating that derived IID's are not
	globally unique, see [RFC7136]. For example from RFPI=11.22.33.44.55		globally unique, see [RFC7136]. For example from RFPI=11.22.33.44.55
	the derived IID is 80:11:22:ff:fe:33:44:55 and from		the derived IID is 80:11:22:ff:fe:33:44:55 and from
	IPEI=01.23.45.67.89 the derived IID is 00:01:23:ff:fe:45:67:89.		IPEI=01.23.45.67.89 the derived IID is 00:01:23:ff:fe:45:67:89.
			Globally uniqueness of IID in link-local addresses are not required
			as they should never be leaked outside the subnet domain.
	As defined in [RFC4291], the IPv6 link-local address is formed by		As defined in [RFC4291], the IPv6 link-local address is formed by
	appending the IID, to the prefix FE80::/64, as shown in Figure 4.		appending the IID, to the prefix FE80::/64, as shown in Figure 4.
	From privacy perspective such constructed link-local address should
	never be used by application layers that could leak it outside the
	subnet domain.
	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 and [RFC6775]
			Section 5.3.
	For non-link-local addresses, 6LNs SHOULD NOT be configured to use		For non-link-local addresses, 6LNs SHOULD NOT be configured to use
	IIDs derived from a MAC-48 device address or DECT device addresses.		IIDs derived from a MAC-48 device address or DECT device addresses.
	Alternative schemes such as Cryptographically Generated Addresses		Alternative schemes such as Cryptographically Generated Addresses
	(CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses		(CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses
	(HBAs) [RFC5535], DHCPv6 [RFC3315], or static, semantically opaque		(HBAs) [RFC5535], DHCPv6 [RFC3315], or static, semantically opaque
	addresses [RFC7217] SHOULD be used by default. See also [I-D.ietf-		addresses [RFC7217] SHOULD be used by default. See also [I-D.ietf-
	6lo-privacy-considerations] for guidance of needed entropy in IIDs.		6lo-privacy-considerations] for guidance of needed entropy in IIDs.
	In situations where the devices address embedded in the IID are		When generated IID's are not globally unique, Duplicate Address
	required to support deployment constraints, 6LN MAY form a 64-bit IID		Detection (DAD) [RFC4862] MUST be used. In situations where the
	by utilizing the MAC-48 device address or DECT device addresses. The		devices address embedded in the IID are required to support
	non-link-local addresses that a 6LN generates MUST be registered with		deployment constraints, 6LN MAY form a 64-bit IID by utilizing the
	6LBR as described in Section 3.2.2.		MAC-48 device address or DECT device addresses. The non-link-local
			addresses that a 6LN generates MUST be registered with 6LBR as
			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 17, line 39 ¶		skipping to change at page 17, line 31 ¶
	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 [TS102.939-1].		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, Samita Chakrabarti, Kerry Lynn, Suresh Krishnan and		Ralph Droms, Samita Chakrabarti, Kerry Lynn, Suresh Krishnan, Pascal
	Pascal Thubert have provided valuable feedback for this draft.		Thubert and Tatuya Jinmei have 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);", March 2015,		(DECT); Common Interface (CI);", March 2015,
	<https://www.etsi.org/deliver/		<https://www.etsi.org/deliver/
	etsi_en/300100_300199/30017501/02.06.01_60/		etsi_en/300100_300199/30017501/02.06.01_60/
End of changes. 12 change blocks.
	20 lines changed or deleted		22 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/