< draft-ietf-6lo-dect-ule-04.txt   draft-ietf-6lo-dect-ule-05.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: August 29, 2016 Z. Shelby Expires: November 17, 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
February 26, 2016 May 16, 2016
Transmission of IPv6 Packets over DECT Ultra Low Energy Transmission of IPv6 Packets over DECT Ultra Low Energy
draft-ietf-6lo-dect-ule-04 draft-ietf-6lo-dect-ule-05
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 August 29, 2016. This Internet-Draft will expire on November 17, 2016.
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 2, line 34 skipping to change at page 2, line 34
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . 4
2. DECT Ultra Low Energy . . . . . . . . . . . . . . . . . . . . 4 2. DECT Ultra Low Energy . . . . . . . . . . . . . . . . . . . . 4
2.1. The DECT ULE Protocol Stack . . . . . . . . . . . . . . . 5 2.1. The DECT ULE Protocol Stack . . . . . . . . . . . . . . . 5
2.2. Link layer roles and topology . . . . . . . . . . . . . . 6 2.2. Link Layer Roles and Topology . . . . . . . . . . . . . . 6
2.3. Addressing Model . . . . . . . . . . . . . . . . . . . . 7 2.3. Addressing Model . . . . . . . . . . . . . . . . . . . . 7
2.4. MTU Considerations . . . . . . . . . . . . . . . . . . . 7 2.4. MTU Considerations . . . . . . . . . . . . . . . . . . . 7
2.5. Additional Considerations . . . . . . . . . . . . . . . . 8 2.5. Additional Considerations . . . . . . . . . . . . . . . . 8
3. Specification of IPv6 over DECT ULE . . . . . . . . . . . . . 8 3. Specification of IPv6 over DECT ULE . . . . . . . . . . . . . 8
3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 9 3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 9
3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Link Model . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Subnets and Internet connectivity scenarios . . . . . . . 13 3.3. Subnets and Internet Connectivity Scenarios . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. ETSI Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. ETSI Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 (Digital consumption at the expense of data throughput. DECT (Digital
Enhanced Cordless Telecommunications) is a standard series Enhanced Cordless Telecommunications) is a standard series
[EN300.175-part1-7] specificed by ETSI and CAT-iq (Cordless Advanced [EN300.175-part1-7] specified by ETSI and CAT-iq (Cordless Advanced
Technology - internet and quality) is a set of product certication Technology - internet and quality) is a set of product certication
and interoperability profiles [CAT-iq] defined by DECT Forum. DECT and interoperability profiles [CAT-iq] defined by DECT Forum. DECT
ULE devices with requirements on power consumption as specified by ULE devices with requirements on power consumption as specified by
ETSI in [TS102.939-1] and [TS102.939-2], will operate on special ETSI in [TS102.939-1] and [TS102.939-2], will operate on special
power optimized silicon, but can connect to a DECT Gateway supporting power 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
skipping to change at page 4, line 14 skipping to change at page 4, line 14
1.2. Terms Used 1.2. Terms Used
6CO: 6LoWPAN Context Option [RFC6775] 6CO: 6LoWPAN Context Option [RFC6775]
6LBR: DECT Fixed Part having a role as defined in [RFC6775] 6LBR: DECT Fixed Part having a role as defined in [RFC6775]
6LN: DECT Portable part having a role as defined in [RFC6775] 6LN: DECT Portable part having a role as defined in [RFC6775]
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: Corless Advanced Technologi - 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
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
skipping to change at page 6, line 30 skipping to change at page 6, line 30
+--------------------+-------------------+ +--------------------+-------------------+
(C-plane) (U-plane) (C-plane) (U-plane)
Figure 1: DECT ULE Protocol Stack Figure 1: DECT ULE Protocol Stack
Figure 1 above shows the DECT ULE Stack divided into the Control- Figure 1 above shows the DECT ULE Stack divided into the Control-
plane and User-data path, to left and to the right, respectively. plane and User-data path, to left and to the right, respectively.
The shown entities in the Stack are the (PHY) Physical Layer, (MAC) The shown entities in the Stack are the (PHY) Physical Layer, (MAC)
Media Access Control Layer, (DLC) Data Link Control Layer, (NWK) Media Access Control Layer, (DLC) Data Link Control Layer, (NWK)
Network Layer with subcomponents: (LLME) Lower Layer Management Network Layer with subcomponents: (LLME) Lower Layer Management
Entity, (MM) Mobility Management and (CC) Call Control. Aboves there Entity, (MM) Mobility Management and (CC) Call Control. Above there
are the typically (API) Application Programmers Interface and are the typically (API) Application Programmers Interface and
application profile specific layers. application profile specific layers.
2.2. Link layer roles and topology 2.2. Link Layer Roles and Topology
A FP is assumed to be less constrained than a PP. Hence, in the A FP is assumed to be less constrained than a PP. Hence, in the
primary scenario FP and PP will act as 6LBR and a 6LN, respectively. primary scenario FP and PP will act as 6LBR and a 6LN, respectively.
This document does only address this primary scenario. This document does only address this primary scenario.
In DECT ULE, at link layer the communication only takes place between In DECT ULE, at link layer the communication only takes place between
a FP and a PP. A FP is able to handle multiple simultaneous a FP and a PP. A FP is able to handle multiple simultaneous
connections with a number of PP. Hence, in a DECT ULE network using connections with a number of PP. Hence, in a DECT ULE network using
IPv6, a radio hop is equivalent to an IPv6 link and vice versa. IPv6, a radio hop is equivalent to an IPv6 link and vice versa.
skipping to change at page 7, line 47 skipping to change at page 7, line 47
unique IID. 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. construct the IID.
2.4. MTU Considerations 2.4. MTU Considerations
Idially the DECT ULE FP and PP may generate data that fits into a Ideally the DECT ULE FP and PP may generate data that fits into a
single MAC Layer packets (38 octets) for periodically transferred single MAC Layer packets (38 octets) for periodically transferred
information, depending on application. However, IP packets may be information, depending on application. However, IP packets may be
much larger. The DECT ULE DLC procedures supports segmentation and much larger. The DECT ULE DLC procedures supports segmentation and
reassembly of any MTU size below 65536 octets, but the default MTU reassembly of any MTU size below 65536 octets, but the default MTU
size defined in DECT ULE [TS102.939-1] is 500 octets. In order to size defined in DECT ULE [TS102.939-1] is 500 octets. In order to
support complete IP packets, the DLC layer of DECT ULE SHALL per this support complete IP packets, the DLC layer of DECT ULE SHALL per this
specification be configured with a MTU size that fits the specification be configured with a MTU size that fits the
requirements from IPv6 data packets, hence [RFC4944] fragmentation/ requirements from IPv6 data packets, hence [RFC4944] 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 fulfil 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
at 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
skipping to change at page 9, line 7 skipping to change at page 9, line 7
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
layer. Figure 3 illustrates IPv6 over DECT ULE stack. layer. Figure 3 illustrates IPv6 over DECT ULE stack.
As consequence of DECT ULE in it's primary configuration does not As consequence of DECT ULE in it's primary configuration does not
support the formation of multihop networks at the link layer, the support the formation of multihop networks at the link layer, the
mesh header defined in [RFC4944] for mesh under routing MUST NOT be mesh header defined in [RFC4944] for mesh under routing MUST NOT be
used. In addition, a DECT ULE PP node MUST NOT play the role of a used. In addition, a DECT ULE PP node MUST NOT play the role of a
6LoWPAN Router (6LR). 6LoWPAN Router (6LR).
3.1. Protocol stack 3.1. Protocol Stack
In order to enable transmission of IPv6 packets over DECT ULE, a In order to enable transmission of IPv6 packets over DECT ULE, a
Permanent Virtual Circuit (PVC) has to be opened between FP and PP. Permanent Virtual Circuit (PVC) has to be opened between FP and PP.
This MUST be done by setting up a service call from PP to FP. The PP This MUST be done by setting up a service call from PP to FP. The PP
SHALL specify the <<IWU-ATTRIBUTES>> in a service-change (other) SHALL specify the <<IWU-ATTRIBUTES>> in a service-change (other)
message before sending a service-change (resume) message as defined message before sending a service-change (resume) message as defined
in [TS102.939-1]. The <<IWU-ATTRIBTES>> SHALL define the ULE in [TS102.939-1]. The <<IWU-ATTRIBTES>> SHALL define the ULE
Application Protocol Identifier to 0x06 and the MTU size to 1280 Application Protocol Identifier to 0x06 and the MTU size to 1280
octets or larger. The FP MUST send a service-change-accept (resume) octets or larger. The FP MUST send a service-change-accept (resume)
containing a valid paging descriptor. The PP MUST be pageable. containing a valid paging descriptor. The PP MUST be pageable.
skipping to change at page 9, line 36 skipping to change at page 9, line 36
+-------------------+ +-------------------+
| DECT ULE DLC | | DECT ULE DLC |
+-------------------+ +-------------------+
| DECT ULE MAC | | DECT ULE MAC |
+-------------------+ +-------------------+
| DECT ULE PHY | | DECT ULE PHY |
+-------------------+ +-------------------+
Figure 3: IPv6 over DECT ULE Stack Figure 3: IPv6 over DECT ULE Stack
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 already fragmentation and layer 2. The DECT ULE implements already fragmentation and
reassembly functionality, hence [RFC4944] fragmentation and reassembly functionality, hence [RFC4944] fragmentation and
reassembly function MUST NOT be used. The DECT ULE DLC link (PVC) reassembly function MUST NOT be used. The DECT ULE DLC link (PVC)
MUST be configured with a minimum MTU size of at least 1280 octers in MUST be configured with a minimum MTU size of at least 1280 octets in
order to meet the size requirements of IPv6. order to meet the size requirements of IPv6.
Per this specification, the IPv6 header compression format specified Per this specification, the IPv6 header compression format specified
in [RFC6282] MUST be used. The IPv6 payload length can be derived in [RFC6282] MUST be used. The IPv6 payload length can be derived
from the ULE DLC packet length and the possibly elided IPv6 address from the ULE DLC packet length and the possibly elided IPv6 address
can be reconstructed from the link-layer address, used at the time of can be reconstructed from the link-layer address, used at the time of
DECT ULE connection establishment, from the ULE MAC packet address, DECT ULE connection establishment, from the ULE MAC packet address,
compression context if any, and from address registration information compression context if any, and from address registration information
(see Section 3.2.2). (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
At network interface initialization, both 6LN and 6LBR SHALL generate At network interface initialization, both 6LN and 6LBR SHALL generate
and assign to the DECT ULE network interface IPv6 link-local and assign to the DECT ULE network interface IPv6 link-local
addresses [RFC4862] based on the DECT device addresses (see addresses [RFC4862] based on the DECT device addresses (see
Section 2.3) that were used for establishing the underlying DECT ULE Section 2.3) that were used for establishing the underlying DECT ULE
connection. connection.
The DECT device addresses IPEI and RFPI MUST be used to derive the The DECT device addresses IPEI and RFPI MUST be used to derive the
IPv6 link-local 64 bit Interface Identifiers (IID) for 6LN and 6LBR, IPv6 link-local 64 bit Interface Identifiers (IID) for 6LN and 6LBR,
respectively. respectively.
The rule for deriving IID from DECT device addresses is as follows: The rule for deriving IID from DECT device addresses is as follows:
The DECT device addresses that are consisting of 40 bits each, MUST The DECT device addresses that are consisting of 40 bits each, MUST
be expanded with leading zero bits to form 48 bit intermediate be expanded with leading zero bits to form 48 bit intermediate
addresses. Least significant bit of this address is the last bit in addresses. Most significant bit in this newly formed 48-bit
network order. First bit is set to a one for addresses derived from intermediate address is set to one for addresses derived from the
the RFPI and first bit is set to zero for addresses derived from the RFPI and set to zero for addresses derived from the IPEI. From these
IPEI. From these intermediate 48 bit addresses are derived 64 bit intermediate 48 bit addresses are derived 64 bit IIDs according to
IIDs accordig to the guidance of [RFC4291]. In the derived IIDs the the guidance of [RFC4291]. In the derived IIDs the U/L bit (7th bit)
7th bit is set to one to indicate that the addresses are not global will be zero, indicating that derived IID's are not globally unique,
unique. For example from RFPI=11.22.33.44.55 the derived IID is see [RFC7136]. For example from RFPI=11.22.33.44.55 the derived IID
82:11:22:FF:FE:33:44:55 and from IPEI=01.23.45.67.89 the derived IID is 80:11:22:ff:fe:33:44:55 and from IPEI=01.23.45.67.89 the derived
is 02:01:23:FF:FE:45:67:89. IID is 00:01:23:ff:fe:45:67:89.
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.
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
skipping to change at page 11, line 31 skipping to change at page 11, line 31
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.
A 6LN MUST NOT register more than one non-link-local addres on the A 6LN MUST NOT register more than one non-link-local address on the
same prefix. same prefix.
3.2.2. Neighbor discovery 3.2.2. Neighbor Discovery
'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor
discovery approach as adapted for use in several 6LoWPAN topologies, discovery approach as adapted for use in several 6LoWPAN topologies,
including the mesh topology. As DECT ULE is considered not to including the mesh topology. As DECT ULE is considered not to
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:
skipping to change at page 12, line 9 skipping to change at page 12, line 9
5.3 and 5.4 of the [RFC6775]. 5.3 and 5.4 of the [RFC6775].
2. A DECT ULE 6LN MUST NOT register its link-local address. A DECT 2. A DECT ULE 6LN MUST NOT register its link-local address. A DECT
ULE 6LN MUST register its non-link-local addresses with the 6LBR by ULE 6LN MUST register its non-link-local addresses with the 6LBR 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 should be taken if the FP is battery- efficient and particular care should be taken if the FP is battery-
skipping to change at page 13, line 45 skipping to change at page 13, line 45
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. Subnets and 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. In this scenario, the DECT ULE 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 network is deployed as one subnet, using one /64 IPv6 prefix. The
6LBR is acting as router and forwarding packets between 6LNs and to 6LBR is acting as router and forwarding packets between 6LNs and to
and from Internet. and from Internet.
Other scenarios can be imagined where a PP is acting as 6LBR and Other scenarios can be imagined where a PP is acting as 6LBR and
providing Internet connectivity for the FP. How the FP could then providing Internet connectivity for the FP. How the FP could then
further provide Internet connectivity to other PP, possibly connected further provide Internet connectivity to other PP, possibly connected
skipping to change at page 16, line 10 skipping to change at page 16, line 10
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 and Samita Chakrabarti have provided valuable feedback Ralph Droms, Samita Chakrabarti and Kerry Lynn have provided valuable
for this draft. 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/
en_30017501v020601p.pdf>. en_30017501v020601p.pdf>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
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,
DOI 10.17487/RFC3633, December 2003, DOI 10.17487/RFC3633, December 2003,
<http://www.rfc-editor.org/info/rfc3633>. <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, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>. <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
 End of changes. 24 change blocks. 
38 lines changed or deleted 34 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/