GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8105

Internet Engineering Task Force (IETF) P. Mariager Request for Comments: 8105 J. Petersen, Ed. Category: Standards Track RTX A/S ISSN: 2070-1721 Z. Shelby

                                                                   ARM
                                                        M. van de Logt
                                                  Bosch Sensortec GmbH
                                                            D. Barthel
                                                           Orange Labs
                                                              May 2017
    Transmission of IPv6 Packets over Digital Enhanced Cordless
          Telecommunications (DECT) Ultra Low Energy (ULE)

Abstract

 Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy
 (ULE) is a low-power air interface technology that is proposed by the
 DECT Forum and is defined and specified by ETSI.
 The DECT air interface technology has been used worldwide in
 communication devices for more than 20 years.  It has primarily been
 used to carry voice for cordless telephony but has also been deployed
 for data-centric services.
 DECT ULE is a recent addition to the DECT interface primarily
 intended for low-bandwidth, low-power applications such as sensor
 devices, smart meters, home automation, etc.  As the DECT ULE
 interface inherits many of the capabilities from DECT, it benefits
 from operation that is long-range and interference-free, worldwide-
 reserved frequency band, low silicon prices, and maturity.  There is
 an added value in the ability to communicate with IPv6 over DECT ULE,
 such as for Internet of Things applications.
 This document describes how IPv6 is transported over DECT ULE using
 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
 techniques.

Mariager, et al. Standards Track [Page 1] RFC 8105 IPv6 over DECT ULE May 2017

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc8105.

Copyright Notice

 Copyright (c) 2017 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Mariager, et al. Standards Track [Page 2] RFC 8105 IPv6 over DECT ULE May 2017

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   1.1.  Requirements Notation . . . . . . . . . . . . . . . . . .   5
   1.2.  Terms Used  . . . . . . . . . . . . . . . . . . . . . . .   5
 2.  DECT Ultra Low Energy . . . . . . . . . . . . . . . . . . . .   6
   2.1.  The DECT ULE Protocol Stack . . . . . . . . . . . . . . .   6
   2.2.  Link Layer Roles and Topology . . . . . . . . . . . . . .   8
   2.3.  Addressing Model  . . . . . . . . . . . . . . . . . . . .   8
   2.4.  MTU Considerations  . . . . . . . . . . . . . . . . . . .   9
   2.5.  Additional Considerations . . . . . . . . . . . . . . . .   9
 3.  Specification of IPv6 over DECT ULE . . . . . . . . . . . . .   9
   3.1.  Protocol Stack  . . . . . . . . . . . . . . . . . . . . .  10
   3.2.  Link Model  . . . . . . . . . . . . . . . . . . . . . . .  11
   3.3.  Subnets and Internet Connectivity Scenarios . . . . . . .  15
 4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
 5.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
 6.  ETSI Considerations . . . . . . . . . . . . . . . . . . . . .  18
 7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
   7.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
   7.2.  Informative References  . . . . . . . . . . . . . . . . .  20
 Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  21
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

Mariager, et al. Standards Track [Page 3] RFC 8105 IPv6 over DECT ULE May 2017

1. Introduction

 Digital Enhanced Cordless Telecommunications (DECT) is a standard
 series [EN300.175-part1-7] specified by ETSI, and CAT-iq (Cordless
 Advanced Technology - internet and quality) is a set of product
 certification and interoperability profiles [CAT-iq] defined by DECT
 Forum.  DECT Ultra Low Energy (DECT ULE or just ULE) is an air
 interface technology building on the key fundamentals of traditional
 DECT/CAT-iq but with specific changes to significantly reduce the
 power consumption at the expense of data throughput.  DECT ULE
 devices with requirements on power consumption, as specified by ETSI
 in [TS102.939-1] and [TS102.939-2], will operate on special power-
 optimized silicon but can connect to a DECT Gateway supporting
 traditional DECT/CAT-iq for cordless telephony and data as well as
 the ULE extensions.
 DECT terminology has two major role definitions: the Portable Part
 (PP) is the power-constrained device 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 ULE is a home-security sensor
 transmitting small amounts of data (few bytes) at periodic intervals
 through the FP but that is able to wake up upon an external event
 (e.g., a break-in) and communicate with the FP.  Another example
 incorporating both DECT ULE and traditional CAT-iq telephony would be
 a pendant (brooch) for the elderly that generally transmits periodic
 status messages to a care provider using very little battery, but in
 the event of an emergency, the elderly person can establish a voice
 connection through the pendant to an alarm service.  It is expected
 that DECT ULE will be integrated into many residential gateways, as
 many of these already implement DECT CAT-iq 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
 large address space and well-known infrastructure.  This document
 describes how IPv6 is used on DECT ULE links to optimize power while
 maintaining the many benefits of IPv6 transmission.  [RFC4944],
 [RFC6282], and [RFC6775] specify the transmission of IPv6 over IEEE
 802.15.4.  DECT ULE has many characteristics similar to those of IEEE
 802.15.4, but it also has differences.  A subset of mechanisms
 defined for 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
 [RFC4944], [RFC6282], [RFC6775], and [RFC7668].

Mariager, et al. Standards Track [Page 4] RFC 8105 IPv6 over DECT ULE May 2017

1.1. Requirements Notation

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
 "OPTIONAL" in this document are to be interpreted as described in
 [RFC2119].

1.2. Terms Used

 6CO      6LoWPAN Context Option [RFC6775]
 6BBR     6loWPAN Backbone Router
 6LBR     6LoWPAN Border Router, as defined in [RFC6775].
          The DECT Fixed Part has this role.
 6LN      6LoWPAN Node as defined in [RFC6775].
          The DECT Portable Part has this role
 6LoWPAN  IPv6 over Low-Power Wireless Personal Area Network
 AES128   Advanced Encryption Standard with a key size of 128 bits
 API      Application Programming Interface
 ARO      Address Registration Option [RFC6775]
 CAT-iq   Cordless Advanced Technology - internet and quality
 CID      Context Identifier [RFC6775]
 DAC      Destination Address Compression
 DAD      Duplicate Address Detection [RFC4862]
 DAM      Destination Address Mode
 DHCPv6   Dynamic Host Configuration Protocol for IPv6 [RFC3315]
 DLC      Data Link Control
 DSAA2    DECT Standard Authentication Algorithm #2
 DSC      DECT Standard Cipher
 DSC2     DECT Standard Cipher #2
 FDMA     Frequency-Division Multiple Access
 FP       DECT Fixed Part; the Gateway
 GAP      Generic Access Profile
 IID      Interface Identifier
 IPEI     International Portable Equipment Identity; DECT identity
 MAC-48   48-bit global unique MAC address managed by IEEE
 MAC      Media Access Control
 MTU      Maximum Transmission Unit
 NBMA     Non-Broadcast Multi-Access
 ND       Neighbor Discovery [RFC4861] [RFC6775]
 PDU      Protocol Data Unit
 PHY      Physical Layer
 PMID     Portable MAC Identity; DECT identity
 PP       DECT Portable Part; typically the sensor node (6LN)
 PVC      Permanent Virtual Circuit
 RFPI     Radio Fixed Part Identity; DECT identity
 SAC      Source Address Compression
 SAM      Source Address Mode
 TDD      Time Division Duplex

Mariager, et al. Standards Track [Page 5] RFC 8105 IPv6 over DECT ULE May 2017

 TDMA     Time-Division Multiple Access
 TPUI     Temporary Portable User Identity; DECT identity
 UAK      User Authentication Key; DECT master security key
 ULA      Unique Local Address [RFC4193]

2. DECT Ultra Low Energy

 DECT ULE is a low-power air interface technology that is designed to
 support both circuit-switched services, such as voice communication,
 and packet-mode data services at a modest data rate.  This document
 is only addressing the packet-mode data service of DECT ULE.

2.1. The DECT ULE Protocol Stack

 The DECT ULE Protocol Stack contains a PHY layer operating at
 frequencies in the 1880 - 1920 MHz frequency band depending on the
 region and uses a symbol rate of 1.152 Mbaud.  Radio bearers are
 allocated by use of FDMA/TDMA/TDD techniques.
 In its generic network topology, DECT is defined as a cellular
 network technology.  However, the most common configuration is a star
 network with a single FP defining the network with a number of PPs
 attached.  The MAC layer supports both traditional DECT circuit mode
 operation, as this is used for services like discovery, pairing,
 security features, etc., and it supports new ULE packet-mode
 operation.  The circuit-mode features have been reused from DECT.
 The DECT ULE device can switch to the ULE mode of operation,
 utilizing the new ULE MAC layer features.  The DECT ULE Data Link
 Control (DLC) provides multiplexing as well as segmentation and
 reassembly for larger packets from layers above.  The DECT ULE layer
 also implements per-message authentication and encryption.  The DLC
 layer ensures packet integrity and preserves packet order, but
 delivery is based on best effort.
 The current DECT ULE MAC layer standard supports low-bandwidth data
 broadcast.  However, this document is not considering usage of the
 DECT ULE MAC layer broadcast service for IPv6 over DECT ULE.
 In general, communication sessions can be initiated from both the FP
 side and the PP side.  Depending on power-down modes employed in the
 PP, latency may occur when initiating sessions from the FP side.  MAC
 layer communication can take place using either connection-oriented
 packet transfer with low overhead for short sessions or connection-
 oriented bearers including media reservation.  The MAC layer
 autonomously selects the radio-spectrum positions that are available

Mariager, et al. Standards Track [Page 6] RFC 8105 IPv6 over DECT ULE May 2017

 within the band and can rearrange these to avoid interference.  The
 MAC layer has built-in retransmission procedures in order to improve
 transmission reliability.
 The DECT ULE device will typically incorporate an Application
 Programming Interface (API), as well as common elements known as
 Generic Access Profiles (GAPs), for enrolling into the network.  The
 DECT ULE Stack establishes a Permanent Virtual Circuit (PVC) for the
 application layers and provides support for a range of different
 application protocols.  The application protocol is negotiated
 between the PP and FP when the PVC communication service is
 established.  [TS102.939-1] defines this negotiation and specifies an
 Application Protocol Identifier set to 0x06 for 6LoWPAN.  This
 document defines the behavior of that application protocol.
            +----------------------------------------+
            |          Application Layers            |
            +----------------------------------------+
            | Generic Access     |     ULE Profile   |
            |       Profile      |                   |
            +----------------------------------------+
            | DECT/Service API   | ULE Data API      |
            +--------------------+-------------------+
            | LLME  | NWK (MM,CC)|                   |
            +--------------------+-------------------+
            | DECT DLC           | DECT ULE DLC      |
            +--------------------+-------------------+
            |                MAC Layer               |
            +--------------------+-------------------+
            |                PHY Layer               |
            +--------------------+-------------------+
                  (C-plane)             (U-plane)
                   Figure 1: DECT ULE Protocol Stack
 Figure 1 shows the DECT ULE Stack divided into the Control Plane
 (C-plane) and User Data Plane (U-plane), to the left and to the
 right, respectively.  The shown entities in the Stack are the
 Physical Layer (PHY), Media Access Control (MAC) Layer, Data Link
 Control (DLC) Layer, and Network Layer (NWK), along with following
 subcomponents: Lower-Layer Management Entity (LLME), Mobility
 Management (MM), and Call Control (CC).  Above there are the typical
 Application Programmers Interface (API) and application-profile-
 specific layers.

Mariager, et al. Standards Track [Page 7] RFC 8105 IPv6 over DECT ULE May 2017

2.2. Link Layer Roles and Topology

 An FP is assumed to be less constrained than a PP.  Hence, in the
 primary scenario, the FP and PP will act as 6LBR and a 6LN,
 respectively.  This document only addresses this primary scenario,
 and all other scenarios with different roles of an FP and PP are out
 of scope.
 In DECT ULE, at the link layer, the communication only takes place
 between an FP and a PP.  An FP is able to handle multiple
 simultaneous connections with a number of PPs.  Hence, in a DECT ULE
 network using IPv6, a radio hop is equivalent to an IPv6 link and
 vice versa (see Section 3.3).
     [DECT ULE PP]-----\                 /-----[DECT ULE PP]
                        \               /
     [DECT ULE PP]-------+[DECT ULE FP]+-------[DECT ULE PP]
                        /               \
     [DECT ULE PP]-----/                 \-----[DECT ULE PP]
                   Figure 2: DECT ULE Star Topology
 A significant difference between IEEE 802.15.4 and DECT ULE is that
 the former supports both star and mesh topology (and requires a
 routing protocol), whereas DECT ULE in its primary configuration does
 not support the formation of multihop networks at the link layer.  In
 consequence, the mesh header defined in [RFC4944] is not used in DECT
 ULE networks.
 DECT ULE repeaters are considered to operate transparently in the
 DECT protocol domain and are outside the scope of this document.

2.3. Addressing Model

 Each DECT PP is assigned an IPEI during manufacturing.  This identity
 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
 the IID for link-local address.
 During a DECT location registration procedure, the FP assigns a
 20-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
 addressing (Layer 2) in messages between the FP and PP.  Although the
 TPUI is temporary by definition, many implementations assign the same
 value repeatedly to any given PP, hence it seems not suitable for
 construction of the IID (see [RFC8065]).

Mariager, et al. Standards Track [Page 8] RFC 8105 IPv6 over DECT ULE May 2017

 Each DECT FP is assigned an RFPI during manufacturing.  This identity
 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
 the IID for link-local address.
 Optionally, each DECT PP and DECT FP can be assigned a unique (IEEE)
 MAC-48 address in addition to the DECT identities to be used by the
 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
 construct the IID.  However, as these addresses are considered as
 being permanent, such a scheme is NOT RECOMMENDED as per [RFC8065].

2.4. MTU Considerations

 Ideally, the DECT ULE FP and PP may generate data that fits into a
 single MAC layer packet (38 octets) for periodically transferred
 information, depending on application.  However, IP packets may be
 much larger.  The DECT ULE DLC procedures natively support
 segmentation and reassembly and provide any MTU size below 65536
 octets.  The default MTU size defined in DECT ULE [TS102.939-1] is
 500 octets.  In order to support complete IPv6 packets, the DLC layer
 of DECT ULE SHALL, per this specification, be configured with an MTU
 size of 1280 octets, hence [RFC4944] fragmentation/reassembly is not
 required.
 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
 Stack will be fragmented into several or many MAC layer packets, each
 consuming power to transmit/receive.  The increased MTU size does not
 change the MAC layer packet and PDU size.

2.5. Additional Considerations

 The DECT ULE standard allows the PP to be DECT-registered (bound) to
 multiple FP and to roam between them.  These FP and their 6LBR
 functionalities can operate either individually or connected through
 a Backbone Router as per [BACKBONE-ROUTER].

3. Specification of IPv6 over DECT ULE

 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 establish a suitable link layer connection.  The obtain-access-
 rights registration and location registration procedures are
 documented by ETSI in the specifications [EN300.175-part1-7],
 [TS102.939-1], and [TS102.939-2].

Mariager, et al. Standards Track [Page 9] RFC 8105 IPv6 over DECT ULE May 2017

 DECT ULE technology sets strict requirements for low power
 consumption and, thus, limits the allowed protocol overhead. 6LoWPAN
 standards [RFC4944], [RFC6775], and [RFC6282] provide useful
 functionality for reducing overhead that can be applied to DECT ULE.
 This functionality comprises link-local IPv6 addresses and stateless
 IPv6 address autoconfiguration, Neighbor Discovery, and header
 compression.
 The ULE 6LoWPAN adaptation layer can run directly on this U-plane DLC
 layer.  Figure 3 illustrates an IPv6 over DECT ULE Stack.
 Because DECT ULE in its primary configuration does not support the
 formation of multihop networks at the link layer, the mesh header
 defined in [RFC4944] for mesh under routing MUST NOT be used.  In
 addition, the role of a 6LoWPAN Router (6LR) is not defined per this
 specification.

3.1. Protocol Stack

 In order to enable data transmission over DECT ULE, a Permanent
 Virtual Circuit (PVC) has to be configured and opened between the FP
 and PP.  This is done by setting up a DECT service call between the
 PP and FP.  In the DECT protocol domain, the PP SHALL specify the
 <<IWU-ATTRIBUTES>> in a service-change (other) message before sending
 a service-change (resume) message as defined in [TS102.939-1].  The
 <<IWU-ATTRIBUTES>> SHALL set the ULE Application Protocol Identifier
 to 0x06 and the MTU size to 1280 octets or larger.  The FP sends a
 service-change-accept (resume) that MUST contain a valid paging
 descriptor.  The PP MUST listen to paging messages from the FP
 according to the information in the received paging descriptor.
 Following this, transmission of IPv6 packets can start.
                   +-------------------+
                   |    UDP/TCP/other  |
                   +-------------------+
                   |       IPv6        |
                   +-------------------+
                   |6LoWPAN adapted to |
                   |    DECT ULE       |
                   +-------------------+
                   |  DECT ULE DLC     |
                   +-------------------+
                   |  DECT ULE MAC     |
                   +-------------------+
                   |  DECT ULE PHY     |
                   +-------------------+
                  Figure 3: IPv6 over DECT ULE Stack

Mariager, et al. Standards Track [Page 10] RFC 8105 IPv6 over DECT ULE May 2017

3.2. Link Model

 The general model is that IPv6 is Layer 3 and DECT ULE MAC and DECT
 ULE DLC are Layer 2.  DECT ULE already implements fragmentation and
 reassembly functionality; hence, the fragmentation and reassembly
 function described in [RFC4944] MUST NOT be used.
 After the FPs and PPs have connected at the DECT ULE level, the link
 can be considered up and IPv6 address configuration and transmission
 can begin.  The 6LBR ensures address collisions do not occur.
 Per this specification, the IPv6 header compression format specified
 in [RFC6282] MUST be used.  The IPv6 payload length can be derived
 from the ULE DLC packet length.  The possibly elided IPv6 address can
 be reconstructed from the lower layer address (see Section 3.2.4).
 Due to the DECT ULE star topology (see Section 2.2), each PP has a
 separate link to the FP; thus, the PPs cannot directly hear one
 another and cannot talk to one another.  As discussed in [RFC4903],
 conventional usage of IPv6 anticipates IPv6 subnets spanning a single
 link at the link layer.  In order to avoid the complexity of
 implementing a separate subnet for each DECT ULE link, a Multi-Link
 Subnet model [RFC4903] has been chosen, specifically Non-Broadcast
 Multi-Access (NBMA) at Layer 2.  Because of this, link-local
 multicast communications can happen only within a single DECT ULE
 connection; thus, 6LN-to-6LN communications using link-local
 addresses are not possible. 6LNs connected to the same 6LBR have to
 communicate with each other utilizing the shared prefix used on the
 subnet.  The 6LBR forwards packets sent by one 6LN to another.

3.2.1. Stateless Address Autoconfiguration

 At network interface initialization, both 6LN and 6LBR SHALL generate
 and assign IPv6 link-local addresses to the DECT ULE network
 interfaces [RFC4862] based on the DECT device addresses (see
 Section 2.3) that were used for establishing the underlying DECT ULE
 connection.
 The DECT device addresses IPEI and RFPI MUST be used to derive the
 IPv6 link-local 64-bit Interface Identifiers (IIDs) for 6LN and 6LBR,
 respectively.
 The rule for deriving IIDs from DECT device addresses is as follows:
 the DECT device addresses that consist of 40 bits each MUST be
 expanded with leading zero bits to form 48-bit intermediate
 addresses.  The most significant bit in this newly formed 48-bit
 intermediate address is set to one for addresses derived from the
 RFPI and set to zero for addresses derived from the IPEI. 64-bit IIDs

Mariager, et al. Standards Track [Page 11] RFC 8105 IPv6 over DECT ULE May 2017

 are derived from these intermediate 48-bit addresses following the
 guidance in Appendix A of [RFC4291].  However, because DECT and IEEE
 address spaces are different, this intermediate address cannot be
 considered to be unique within an IEEE address space.  In the derived
 IIDs, the Universal/Local (U/L) bit (7th bit) will be zero, which
 indicates that derived IIDs are not 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; from IPEI=01.23.45.67.89, the derived IID is
 00:01:23:ff:fe:45:67:89.
 Global uniqueness of an IID in link-local addresses is not required
 as they should never be leaked outside the subnet domain.
 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.
              10 bits       54 bits            64 bits
           +----------+-----------------+----------------------+
           |1111111010|       zeros     | Interface Identifier |
           +----------+-----------------+----------------------+
             Figure 4: IPv6 Link-Local Address in DECT ULE
 A 6LN MUST join the all-nodes multicast address.
 After link-local address configuration, 6LN sends Router Solicitation
 messages as described in Section 6.3.7 of [RFC4861] and Section 5.3
 of [RFC6775].
 For non-link-local addresses, 6LNs SHOULD NOT be configured to use
 IIDs derived from a MAC-48 device address or DECT device addresses.
 Alternative schemes such as Cryptographically Generated Addresses
 (CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses
 (HBAs) [RFC5535], DHCPv6 [RFC3315], or static, semantically opaque
 addresses [RFC7217] SHOULD be used by default.  See also [RFC8065]
 for guidance of needed entropy in IIDs and the recommended lifetime
 of used IIDs.  When generated IIDs are not globally unique, Duplicate
 Address Detection (DAD) [RFC4862] MUST be used.  In situations where
 deployment constraints require the device's address to be embedded in
 the IID, the 6LN MAY form a 64-bit IID by utilizing the 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
 ULE network is out of scope of this document, but a prefix can be,
 for example, assigned via DHCPv6 Prefix Delegation [RFC3633] or using
 IPv6 Unicast Unique Local Addresses (ULAs) [RFC4193].  Due to the

Mariager, et al. Standards Track [Page 12] RFC 8105 IPv6 over DECT ULE May 2017

 link model of the DECT ULE, the 6LBR MUST set the "on-link" (L) flag
 to zero in the Prefix Information Option [RFC4861].  This will cause
 6LNs to always send packets to the 6LBR, including the case when the
 destination is another 6LN using the same prefix.

3.2.2. Neighbor Discovery

 "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
 Personal Area Networks (6LoWPANs)" [RFC6775] describes the Neighbor
 Discovery approach as adapted for use in several 6LoWPAN topologies,
 including the mesh topology.  As DECT ULE does not support mesh
 networks, only those aspects of [RFC6775] that apply to star topology
 are considered.
 The following aspects of the Neighbor Discovery optimizations
 [RFC6775] are applicable to DECT ULE 6LNs:
 1.  For sending Router Solicitations and processing Router
     Advertisements the DECT ULE 6LNs MUST, respectively, follow
     Sections 5.3 and 5.4 of the [RFC6775].
 2.  A DECT ULE 6LN MUST NOT register its link-local address.  Because
     the IIDs used in link-local addresses are derived from DECT
     addresses, there will always exist a unique mapping between link-
     local and Layer 2 addresses.
 3.  A DECT ULE 6LN MUST register its non-link-local addresses with
     the 6LBR by sending a Neighbor Solicitation (NS) message with the
     Address Registration Option (ARO) and process the Neighbor
     Advertisement (NA) accordingly.  The NS with the ARO option MUST
     be sent irrespective of the method used to generate the IID.

3.2.3. Unicast and Multicast Address Mapping

 The DECT MAC layer broadcast service is considered inadequate for IP
 multicast because it does not support the MTU size required by IPv6.
 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
 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
 and unicast it on each link.  However, this may not be energy
 efficient and particular care should be taken if the FP is battery-
 powered.  To further conserve power, the 6LBR MUST keep track of
 multicast listeners at DECT ULE link-level granularity, and it MUST
 NOT forward multicast packets to 6LNs that have not registered for
 multicast groups the packets belong to.  In the opposite direction, a
 6LN can only transmit data to or through the 6LBR.  Hence, when a 6LN

Mariager, et al. Standards Track [Page 13] RFC 8105 IPv6 over DECT ULE May 2017

 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

 As defined in [RFC6282], which specifies the compression format for
 IPv6 datagrams on top of IEEE 802.15.4, header compression is
 REQUIRED in this document as the basis for IPv6 header compression on
 top of DECT ULE.  All headers MUST be compressed according to
 encoding formats as described in [RFC6282].  The DECT ULE's star
 topology structure, ARO and 6CO, can be exploited in order to provide
 a mechanism for address compression.  The following text describes
 the principles of IPv6 address compression on top of DECT ULE.

3.2.4.1. Link-Local Header Compression

 In a link-local communication terminated at 6LN and 6LBR, both the
 IPv6 source and destination addresses MUST be elided since the used
 IIDs map uniquely into the DECT link end-point addresses.  A 6LN or
 6LBR that receives a PDU containing an IPv6 packet can infer the
 corresponding IPv6 source address.  For the unicast type of
 communication considered in this paragraph, the following settings
 MUST be used in the IPv6 compressed header: CID=0, SAC=0, SAM=11,
 DAC=0, and DAM=11.

3.2.4.2. Non-link-local Header Compression

 To enable efficient header compression, the 6LBR MUST include the
 6LoWPAN Context Option (6CO) [RFC6775] for all prefixes the 6LBR
 advertises in Router Advertisements for use in stateless address
 autoconfiguration.
 When a 6LN transmits an IPv6 packet to a destination using global
 unicast IPv6 addresses, if a context is defined for the prefix of the
 6LNs global IPv6 address, the 6LN MUST indicate this context in the
 corresponding source fields of the compressed IPv6 header as per
 Section 3.1 of [RFC6282] and MUST fully elide the latest registered
 IPv6 source address.  For this, the 6LN MUST use the following
 settings in the IPv6 compressed header: CID=1, SAC=1, and SAM=11.  In
 this case, the 6LBR can infer the elided IPv6 source address since 1)
 the 6LBR has previously assigned the prefix to the 6LNs and 2) the
 6LBR maintains a Neighbor Cache that relates the device address and
 the IID of the corresponding PP.  If a context is defined for the
 IPv6 destination address, the 6LN MUST also indicate this context in
 the corresponding destination fields of the compressed IPv6 header
 and MUST elide the prefix of the destination IPv6 address.  For this,
 the 6LN MUST set the DAM field of the compressed IPv6 header as

Mariager, et al. Standards Track [Page 14] RFC 8105 IPv6 over DECT ULE May 2017

 CID=1, DAC=1, and DAM=01 or DAM=11.  Note that when a context is
 defined for the IPv6 destination address, the 6LBR can infer the
 elided destination prefix by using the context.
 When a 6LBR receives an IPv6 packet having a global unicast IPv6
 address and the destination of the packet is a 6LN, if a context is
 defined for the prefix of the 6LN's global IPv6 address, the 6LBR
 MUST indicate this context in the corresponding destination fields of
 the compressed IPv6 header and MUST fully elide the IPv6 destination
 address of the packet if the destination address is the latest
 registered by the 6LN for the indicated context.  For this, the 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 for
 the prefix of the IPv6 source address, the 6LBR MUST indicate 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 field
 of the IPv6 compressed header as CID=1, SAC=1, and SAM=01 or SAM=11.

3.3. Subnets and Internet Connectivity Scenarios

 In the DECT ULE star topology (see Section 2.2), each PP has a
 separate link to the FP, and the FP acts as an IPv6 router rather
 than a link layer switch.  A Multi-Link Subnet model [RFC4903] has
 been chosen, specifically Non-Broadcast Multi-Access (NBMA) at Layer
 2, as is further illustrated in Figure 5.  The 6LBR forwards packets
 sent by one 6LN to another.  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 network is deployed as one subnet using
 one /64 IPv6 prefix.  The 6LBR acts as a router and forwards packets
 between 6LNs to and from Internet.
                        6LN
                         \               ____________
                          \             /            \
                  6LN ---- 6LBR ------ |  Internet    |
                          /             \____________/
                         /
                        6LN
              <--  One subnet -->
              <--   DECT ULE  -->
         Figure 5: DECT ULE Network Connected to the Internet
 In some scenarios, the DECT ULE network may transiently or
 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.

Mariager, et al. Standards Track [Page 15] RFC 8105 IPv6 over DECT ULE May 2017

                       6LN      6LN
                        \      /
                         \    /
                  6LN --- 6LBR --- 6LN
                         /    \
                        /      \
                       6LN      6LN
                  <----  One subnet ---->
                  <------ DECT ULE ----->
                  Figure 6: Isolated DECT ULE Network
 In the isolated network scenario, communications between 6LN and 6LBR
 can use IPv6 link-local methodology, but for communications between
 different PP, the FP has to act as 6LBR, number the network with a
 ULA prefix [RFC4193], and route packets between the PP.
 In other more advanced systems scenarios with multiple FPs and 6LBR,
 each DECT ULE FP constitutes a wireless cell.  The network can be
 configured as a Multi-Link Subnet in which the 6LN can operate within
 the same /64 subnet prefix in multiple cells as shown in the
 Figure 7.  The FPs in such a scenario should behave as Backbone
 Routers (6BBR) as defined in [BACKBONE-ROUTER].
                         ____________
                        /            \
                       |  Internet    |
                        \____________/
                              |
                              |
                              |
                              |
                  6BBR/       |        6BBR/
         6LN ---- 6LBR -------+------- 6LBR ---- 6LN
                 /  \                   /  \
                /    \                 /    \
               6LN   6LN              6LN   6LN
   <------------------ One subnet ------------------>
   <-- DECT ULE Cell -->       <-- DECT ULE Cell -->
    Figure 7: Multiple DECT ULE Cells in a Single Multi-link Subnet

Mariager, et al. Standards Track [Page 16] RFC 8105 IPv6 over DECT ULE May 2017

4. IANA Considerations

 This document does not require any IANA actions.

5. Security Considerations

 The secure transmission of circuit mode services in DECT is based on
 the DSAA2 and DSC/DSC2 specifications developed by ETSI Technical
 Committee (TC) DECT and the ETSI Security Algorithms Group of Experts
 (SAGE).
 DECT ULE communications are secured at the link layer (DLC) by
 encryption and per-message authentication through CCM (Counter with
 Cipher Block Chaining Message Authentication Code (CBC-MAC)) mode
 similar to [RFC3610].  The underlying algorithm for providing
 encryption and authentication is AES128.
 The DECT ULE pairing procedure generates a master User Authentication
 Key (UAK).  During the location registration procedure, or when the
 permanent virtual circuits are established, the session security keys
 are generated.  Both the master authentication key and session
 security keys are generated by use of the DSAA2 algorithm
 [EN300.175-part1-7], which uses AES128 as the underlying algorithm.
 Session security keys may be renewed regularly.  The generated
 security keys (UAK and session security keys) are individual for each
 FP-PP binding; hence, all PPs in a system have different security
 keys.  DECT ULE PPs do not use any shared encryption key.
 Even though DECT ULE offers link layer security, it is still
 recommended to use secure transport or application protocols above
 6LoWPAN.
 From the privacy point of view, the IPv6 link-local address
 configuration described in Section 3.2.1 only reveals information
 about the 6LN to the 6LBR that the 6LBR already knows from the link
 layer connection.  For non-link-local IPv6 addresses, by default, a
 6LN SHOULD use a randomly generated IID, for example, as discussed in
 [RFC8064], or use alternative schemes such as Cryptographically
 Generated Addresses (CGAs) [RFC3972], privacy extensions [RFC4941],
 Hash-Based Addresses (HBAs, [RFC5535]), or static, semantically
 opaque addresses [RFC7217].

Mariager, et al. Standards Track [Page 17] RFC 8105 IPv6 over DECT ULE May 2017

6. ETSI Considerations

 ETSI is standardizing a list of known application-layer protocols
 that can use the DECT ULE permanent virtual circuit packet data
 service.  Each protocol is identified by a unique known identifier,
 which is exchanged in the service-change procedure as defined in
 [TS102.939-1].  The IPv6/6LoWPAN as described in this document is
 considered to be an application-layer protocol on top of DECT ULE.
 In order to provide interoperability between 6LoWPAN / DECT ULE
 devices, a common protocol identifier for 6LoWPAN is standardized by
 ETSI.
 The ETSI DECT ULE Application Protocol Identifier is set to 0x06 for
 6LoWPAN [TS102.939-1].

7. References

7.1. Normative References

 [EN300.175-part1-7]
            ETSI, "Digital Enhanced Cordless Telecommunications
            (DECT); Common Interface (CI); Part 1: Overview", European
            Standard, ETSI EN 300 175-1, V2.6.1, July 2015,
            <https://www.etsi.org/deliver/
            etsi_en/300100_300199/30017501/02.06.01_60/
            en_30017501v020601p.pdf>.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <http://www.rfc-editor.org/info/rfc2119>.
 [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
            Host Configuration Protocol (DHCP) version 6", RFC 3633,
            DOI 10.17487/RFC3633, December 2003,
            <http://www.rfc-editor.org/info/rfc3633>.
 [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
            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
            Architecture", RFC 4291, DOI 10.17487/RFC4291, February
            2006, <http://www.rfc-editor.org/info/rfc4291>.

Mariager, et al. Standards Track [Page 18] RFC 8105 IPv6 over DECT ULE May 2017

 [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
            "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
            DOI 10.17487/RFC4861, September 2007,
            <http://www.rfc-editor.org/info/rfc4861>.
 [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
            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
            Extensions for Stateless Address Autoconfiguration in
            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,
            "Transmission of IPv6 Packets over IEEE 802.15.4
            Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
            <http://www.rfc-editor.org/info/rfc4944>.
 [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
            Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
            DOI 10.17487/RFC6282, September 2011,
            <http://www.rfc-editor.org/info/rfc6282>.
 [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
            Bormann, "Neighbor Discovery Optimization for IPv6 over
            Low-Power Wireless Personal Area Networks (6LoWPANs)",
            RFC 6775, DOI 10.17487/RFC6775, November 2012,
            <http://www.rfc-editor.org/info/rfc6775>.
 [RFC7136]  Carpenter, B. and S. Jiang, "Significance of IPv6
            Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
            February 2014, <http://www.rfc-editor.org/info/rfc7136>.
 [TS102.939-1]
            ETSI, "Digital Enhanced Cordless Telecommunications
            (DECT); Ultra Low Energy (ULE); Machine to Machine
            Communications; Part 1: Home Automation Network (phase
            1)", Technical Specification, ETSI TS 102 939-1, V1.2.1,
            March 2015, <https://www.etsi.org/deliver/
            etsi_ts/102900_102999/10293901/01.02.01_60/
            ts_10293901v010201p.pdf>.

Mariager, et al. Standards Track [Page 19] RFC 8105 IPv6 over DECT ULE May 2017

 [TS102.939-2]
            ETSI, "Digital Enhanced Cordless Telecommunications
            (DECT); Ultra Low Energy (ULE); Machine to Machine
            Communications; Part 2: Home Automation Network (phase
            2)", Technical Specification, ETSI TS 102 939-2, V1.1.1,
            March 2015, <https://www.etsi.org/deliver/
            etsi_ts/102900_102999/10293902/01.01.01_60/
            ts_10293902v010101p.pdf>.

7.2. Informative References

 [BACKBONE-ROUTER]
            Thubert, P., "IPv6 Backbone Router", Work in Progress,
            draft-ietf-6lo-backbone-router-03, January 2017.
 [CAT-iq]   DECT Forum, "CAT-iq at a Glance", January 2016,
            <http://www.dect.org/userfiles/Public/
            DF_CAT-iq%20at%20a%20Glance.pdf>.
 [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
            C., and M. Carney, "Dynamic Host Configuration Protocol
            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
            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)",
            RFC 3972, DOI 10.17487/RFC3972, March 2005,
            <http://www.rfc-editor.org/info/rfc3972>.
 [RFC4903]  Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
            DOI 10.17487/RFC4903, June 2007,
            <http://www.rfc-editor.org/info/rfc4903>.
 [RFC5535]  Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535,
            DOI 10.17487/RFC5535, June 2009,
            <http://www.rfc-editor.org/info/rfc5535>.
 [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>.

Mariager, et al. Standards Track [Page 20] RFC 8105 IPv6 over DECT ULE May 2017

 [RFC7668]  Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
            Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
            Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
            <http://www.rfc-editor.org/info/rfc7668>.
 [RFC8064]  Gont, F., Cooper, A., Thaler, D., and W. Liu,
            "Recommendation on Stable IPv6 Interface Identifiers",
            RFC 8064, DOI 10.17487/RFC8064, February 2017,
            <http://www.rfc-editor.org/info/rfc8064>.
 [RFC8065]  Thaler, D., "Privacy Considerations for IPv6 Adaptation-
            Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
            February 2017, <http://www.rfc-editor.org/info/rfc8065>.

Acknowledgements

 We are grateful to the members of the IETF 6lo working group; this
 document borrows liberally from their work.
 Ralph Droms, Samita Chakrabarti, Kerry Lynn, Suresh Krishnan, Pascal
 Thubert, Tatuya Jinmei, Dale Worley, and Robert Sparks have provided
 valuable feedback for this document.

Mariager, et al. Standards Track [Page 21] RFC 8105 IPv6 over DECT ULE May 2017

Authors' Addresses

 Peter B. Mariager
 RTX A/S
 Stroemmen 6
 DK-9400 Noerresundby
 Denmark
 Email: pm@rtx.dk
 Jens Toftgaard Petersen (editor)
 RTX A/S
 Stroemmen 6
 DK-9400 Noerresundby
 Denmark
 Email: jtp@rtx.dk
 Zach Shelby
 ARM
 150 Rose Orchard
 San Jose, CA 95134
 United States of America
 Email: zach.shelby@arm.com
 Marco van de Logt
 Bosch Sensortec GmbH
 Gerhard-Kindler-Str. 9
 72770 Reutlingen
 Germany
 Email: marco.vandelogt@bosch-sensortec.com
 Dominique Barthel
 Orange Labs
 28 chemin du Vieux Chene
 38243 Meylan
 France
 Email: dominique.barthel@orange.com

Mariager, et al. Standards Track [Page 22]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8105.txt · Last modified: 2017/05/03 01:26 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki