doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc8105.txt b/doc/rfc/rfc8105.txt
new file mode 100644
index 0000000..7e4e5a8
--- /dev/null
+++ b/doc/rfc/rfc8105.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+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]
+