< draft-ietf-6lo-dect-ule-02.txt   draft-ietf-6lo-dect-ule-03.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: January 4, 2016 Z. Shelby Expires: March 18, 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
July 3, 2015 September 15, 2015
Transmission of IPv6 Packets over DECT Ultra Low Energy Transmission of IPv6 Packets over DECT Ultra Low Energy
draft-ietf-6lo-dect-ule-02 draft-ietf-6lo-dect-ule-03
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 January 4, 2016. This Internet-Draft will expire on March 18, 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. Subnets and Internet connectivity scenarios . . . . . . . 12 3.3. Subnets and Internet connectivity scenarios . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. ETSI Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. ETSI Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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 at the expense of data throughput. DECT ULE devices with consumption at the expense of data throughput. DECT ULE devices with
requirements on 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
skipping to change at page 10, line 18 skipping to change at page 10, line 18
+----------+-----------------+----------------------+ +----------+-----------------+----------------------+
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. A 6LN can also use a randomly generated IID a MAC-48 device address. For non-link-local addresses, 6LNs SHOULD
(see Section 3.2.2), for example, as discussed in [I-D.ietf-6man- NOT be configured to use IIDs derived from a MAC-48 device address.
default-iids], or use alternative schemes such as Cryptographically By default a 6LN SHOULD use a randomly generated IID (see
Generated Addresses (CGA) [RFC3972], privacy extensions [RFC4941], Section 3.2.2), for example, as discussed in [I-D.ietf-6man-default-
Hash-Based Addresses (HBA, [RFC5535]), or DHCPv6 [RFC3315]. The non- iids], or use alternative schemes such as Cryptographically Generated
link-local addresses 6LN generates MUST be registered with 6LBR as Addresses (CGA) [RFC3972], privacy extensions [RFC4941], Hash-Based
described in Section 3.2.2. Addresses (HBA, [RFC5535]), DHCPv6 [RFC3315], or static, semantically
opaque addresses [RFC7217]. In situations where the devices address
embedded in the IID are required to support deployment constraints,
6LN MAY form a 64-bit IID by utilizing the MAC-48 device address.
The non-link-local addresses 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 11, line 24 skipping to change at page 11, line 28
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 should 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. To further conserve power, the 6LBR MUST keep track of
or through the 6LBR. Hence, when a 6LN needs to transmit an IPv6 multicast listeners at DECT-ULE link level granularity and it MUST
multicast packet, the 6LN will unicast the corresponding DECT ULE NOT forward multicast packets to 6LNs that have not registered for
packet to the 6LBR. The 6LBR will then forward the multicast packet multicast groups the packets belong to. In the opposite direction, a
to other 6LNs. 6LN can only transmit data to or through the 6LBR. Hence, when a 6LN
needs to transmit an IPv6 multicast packet, the 6LN will unicast the
corresponding DECT ULE packet to the 6LBR. The 6LBR will then
forward the multicast packet to other 6LNs.
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 addess 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
skipping to change at page 14, line 31 skipping to change at page 14, line 48
(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, for example, [I-D.ietf-6man- implementations the choice to support, for example, [I-D.ietf-6man-
default-iids], [RFC3972], [RFC4941] or [RFC5535] for non-link-local default-iids], [RFC3315], [RFC3972], [RFC4941], [RFC5535] or
addresses. [RFC7217] 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
skipping to change at page 15, line 16 skipping to change at page 15, line 35
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.
[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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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, DOI 10.17487/RFC2464, December 1998,
<http://www.rfc-editor.org/info/rfc2464>.
[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. DOI 10.17487/RFC3633, December 2003,
<http://www.rfc-editor.org/info/rfc3633>.
[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, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>.
[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, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[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. DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
[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,
DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>.
[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, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. 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. DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
"Neighbor Discovery Optimization for IPv6 over Low-Power Bormann, "Neighbor Discovery Optimization for IPv6 over
Wireless Personal Area Networks (6LoWPANs)", RFC 6775, Low-Power Wireless Personal Area Networks (6LoWPANs)",
November 2012. RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, February 2014. Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
February 2014, <http://www.rfc-editor.org/info/rfc7136>.
[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)", March 2015. 1)", March 2015.
[TS102.939-2] [TS102.939-2]
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 2: Home Automation Network (phase Communications; Part 2: Home Automation Network (phase
2)", March 2015. 2)", March 2015.
8.2. Informative References 8.2. Informative References
[I-D.ietf-6lo-btle] [I-D.ietf-6lo-btle]
Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", draft-ietf-6lo-btle-14 (work in progress), June Energy", draft-ietf-6lo-btle-17 (work in progress), August
2015. 2015.
[I-D.ietf-6man-default-iids] [I-D.ietf-6man-default-iids]
Gont, F., Cooper, A., Thaler, D., and S. LIU, 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-04 (work in progress), June draft-ietf-6man-default-iids-07 (work in progress), August
2015. 2015.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
and M. Carney, "Dynamic Host Configuration Protocol for C., and M. Carney, "Dynamic Host Configuration Protocol
IPv6 (DHCPv6)", RFC 3315, July 2003. for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, September 2003. CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September
2003, <http://www.rfc-editor.org/info/rfc3610>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, DOI 10.17487/RFC3972, March 2005,
<http://www.rfc-editor.org/info/rfc3972>.
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535,
2009. DOI 10.17487/RFC5535, June 2009,
<http://www.rfc-editor.org/info/rfc5535>.
Authors' Addresses [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>.
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
Jens Toftgaard Petersen (editor) Jens Toftgaard Petersen (editor)
RTX A/S RTX A/S
 End of changes. 31 change blocks. 
48 lines changed or deleted 79 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/