<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2464 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2464.xml">
<!ENTITY RFC3610 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3610.xml">
<!ENTITY RFC3633 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml">
<!ENTITY RFC4193 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4862 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC4941 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4941.xml">
<!ENTITY RFC4944 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY RFC6282 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6282.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC6775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6775.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- used by XSLT processors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<!-- For a complete list and description of PIs,
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable PIs that most I-Ds might want to use. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC): -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="2"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references: -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space: 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of popular PIs -->
<rfc category="std" docName="draft-mariager-6lo-v6over-dect-ule-03"
     ipr="trust200902">
  <front>
    <title abbrev="IPv6 over DECT ULE">Transmission of IPv6 Packets over DECT
    Ultra Low Energy</title>

    <author fullname="Peter B. Mariager" initials="P.M." role="editor"
            surname="Mariager">
      <organization abbrev="RTX A/S">RTX A/S</organization>

      <address>
        <postal>
          <street>Stroemmen 6</street>

          <code>DK-9400 Noerresundby</code>

          <country>Denmark</country>
        </postal>

        <email>pm@rtx.dk</email>
      </address>
    </author>

    <author fullname="Jens Toftgaard Petersen" initials="J.T.P."
            surname="Petersen">
      <organization abbrev="RTX A/S">RTX A/S</organization>

      <address>
        <postal>
          <street>Stroemmen 6</street>

          <code>DK-9400 Noerresundby</code>

          <country>Denmark</country>
        </postal>

        <email>jtp@rtx.dk</email>
      </address>
    </author>

    <author fullname="Zach Shelby" initials="Z.S." surname="Shelby">
      <organization abbrev="Sensinode">Sensinode</organization>

      <address>
        <postal>
          <street>Hallituskatu 13-17D</street>

          <code>FI-90100 Oulu</code>

          <country>Finland</country>
        </postal>

        <email>zach.shelby@sensinode.com</email>
      </address>
    </author>

    <author fullname="Marco van de Logt" initials="M.L." surname="Van de Logt">
      <organization abbrev="Gigaset Communications GmbH">Gigaset
      Communications GmbH</organization>

      <address>
        <postal>
          <street>Frankenstrasse 2</street>

          <code>D-46395 Bocholt</code>

          <country>Germany</country>
        </postal>

        <email>marco.van-de-logt@gigaset.com</email>
      </address>
    </author>

    <author fullname="Dominique Barthel" initials="D" surname="Barthel">
      <organization>Orange Labs</organization>

      <address>
        <postal>
          <street/>
        </postal>

        <email>dominique.barthel@orange.com</email>
      </address>
    </author>

    <date year="2014"/>

    <!-- <area/> -->

    <workgroup>6Lo Working Group</workgroup>

    <!-- <keyword/> -->

    <!-- <keyword/> -->

    <!-- <keyword/> -->

    <!-- <keyword/> -->

    <abstract>
      <t>DECT Ultra Low Energy is a low power air interface technology that is
      defined by the DECT Forum and specified by ETSI.</t>

      <t>The DECT air interface technology has been used world-wide in
      communication devices for more than 15 years, primarily carrying voice
      for cordless telephony but has also been deployed for data centric
      services.</t>

      <t>The DECT Ultra Low Energy 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 Ultra Low
      Energy interface inherits many of the capabilities from DECT, it
      benefits from long range, interference free operation, world wide
      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.</t>

      <t>This document describes how IPv6 is transported over DECT ULE using
      6LoWPAN techniques.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>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
      on the expense of data throughput. DECT ULE devices with requirements to
      power consumption 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 operates with 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 is able to wake up upon an external event (burglar)
      and communicate with the FP. Another example incorporating both DECT ULE
      as well as traditional CAT-iq telephony is an elderly pendant (broche)
      which can transmit periodic status messages to a care provider using
      very little battery, but in the event of urgency, 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 implements 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] specifies the transmission of
      IPv6 over IEEE 802.15.4. DECT ULE has in many ways similar
      characteristics of IEEE 802.15.4, but also differences. Many of the
      mechanisms defined in [RFC4944] can be applied to the transmission of
      IPv6 on DECT ULE links.</t>

      <t>This document specifies how to map IPv6 over DECT ULE inspired by
      [RFC4944].</t>

      <section title="Requirements Notation">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in <xref
        target="RFC2119"/>.</t>
      </section>

      <section title="Terms Used">
        <t>PP: DECT Portable Part, typically the sensor node</t>

        <t>FP: DECT Fixed Part, the gateway</t>

        <t>LLME: Lower Layer Management Entity</t>

        <t>NWK: Network</t>

        <t>PVC: Permanent Virtual Circuit</t>

        <t>FAR: Fragmentation and Reassembly</t>
      </section>
    </section>

    <section title="DECT Ultra Low Energy">
      <t>DECT ULE is a low power air interface technology that is designed to
      support both circuit switched for service, such as voice communication,
      and for packet mode data services at modest data rate. This draft is
      only addressing the packet mode data service of DECT ULE.</t>

      <section title="The DECT ULE Protocol Stack">
        <t>The DECT ULE protocol stack consists of the PHY layer operating at
        frequencies in the 1880 - 1920 MHz frequency band depending on the
        region and uses a symbol rate of 1.152 Mbps. Radio bearers are
        allocated by use of FDMA/TDMA/TDD technics.</t>

        <t>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 PP
        attached. The MAC layer supports both traditional DECT as this is used
        for services like discovery, pairing, security features etc. All these
        features have been reused from DECT.</t>

        <t>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
        re-assembly 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.</t>

        <t>The current DECT ULE MAC layer standard supports low bandwidth data
        broadcast. However the usage of this broadcast service has not yet
        been standardized for higher layers. This document is not considering
        usage of this DECT ULE MAC broadcast service in current version.</t>

        <t>In general, communication sessions can be initiated from both FP
        and PP side. Depending of power down modes employed in the PP, latency
        may occur when initiating sessions from FP side. MAC layer
        communication can either take place using connection oriented packet
        transfer with low overhead for short sessions or take place using
        connection oriented bearers including media reservation. The MAC layer
        autonomously selects the radio spectrum positions that are available
        within the band and can rearrange these to avoid interference. The MAC
        layer has built-in retransmission procedures in order to improve
        transmission reliability.</t>

        <t>The DECT ULE device will typically incorporate an Application
        Programmers Interface (API) as well as common elements known as
        Generic Access Profile (GAP) 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 used application protocol is negotiated
        between the PP and FP when the PVC communication service is
        established. This draft proposes to define 6LoWPAN as one of the
        possible protocols to negotiate.</t>

        <t><figure>
            <artwork>    +----------------------------------------+ 
    |             Applications               | 
    +----------------------------------------+ 
    | Generic Access     |     ULE Profile   |
    |       Profile      |                   |
    +----------------------------------------+ 
    | DECT/Service API   | ULE Data API      | 
    +--------------------+-------------------+ 
    | LLME  | NWK (MM,CC)|                   | 
    +--------------------+-------------------+ 
    | DECT DLC           | DECT ULE DLC      | 
    +--------------------+-------------------+ 
    |              MAC Layer                 | 
    +--------------------+-------------------+ 
    |              Physical Layer            | 
    +--------------------+-------------------+ 
          (C-plane)             (U-plane)

    Figure 1: DECT ULE Protocol Stack 


</artwork>
          </figure></t>

        <t>The DECT ULE stack can be divided into control (C-plane) and
        user-data (U-plane) parts shown to the left and to the right in figure
        1, respectively.</t>
      </section>

      <section title="Link layer roles and topology">
        <t>A FP is assumed to be less constrained than a PP. Hence, in the
        primary scenario FP and PP will act as 6LoWPAN Border Router (6LBR)
        and a 6LoWPAN Node (6LN), respectively. This document does only
        address this primary scenario.</t>

        <t>In DECT ULE, communication only takes place between a FP and a PP.
        A FP is able to handle multiple simultaneous connections with a number
        of PP. Hence, in a DECT ULE network using IPv6, a radio hop is
        equivalent to an IPv6 link and vice versa. <figure>
            <artwork>

    [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


</artwork>
          </figure></t>

        <t>DECT ULE repeaters are not considered in this proposal.</t>

        <t/>
      </section>

      <section title="Addressing Model">
        <t>Each DECT PP is assigned an &lt;IPEI&gt; (International Portable
        Equipment Identity) during manufacturing. This identity has the size
        of 40 bits and is DECT globally unique for the PP and can be used to
        constitute the MAC address. However, it can not be used to derive a
        globally unique IID.</t>

        <t>When bound to a FP, a PP is assigned a 20 bit TPUI (Temporary
        Portable User Identity) which is unique within the FP. This TPUI is
        used for addressing (layer 2) in messages between FP and PP.</t>

        <t>Each DECT FP is assigned a &lt;RFPI&gt; (Radio Fixed Part Identity)
        during manufacturing. This identity has the size of 40 bits and is
        globally unique for a FP and can be used to constitute the MAC
        address. However, it can not be used to derive a globally unique
        IID.</t>

        <t>Alternatively each DECT PP and DECT FP can be assigned a unique
        (IEEE) MAC-48 address additionally to the DECT identities to be used
        by the 6LoWPAN. With such an approach, the FP and PP have to implement
        a mapping between used MAC-48 addresses and DECT identities.</t>

        <t/>
      </section>

      <section title="MTU Considerations">
        <t>Generally the DECT ULE FP and PP may be generating data that fits
        into one MAC Layer packet (38 bytes) for periodically transferred
        information, depending on application. IP data packets may be much
        larger and hence MTU size should be the size of the IP data packet.
        The DECT ULE DLC procedures supports segmentation and reassembly of
        any MTU size below 65536 bytes, but most implementations do only
        support smaller values.</t>

        <t>It is expected that the LOWPAN_IPHC packet will fulfill all the
        requirements for header compression without spending unnecessary
        overhead for mesh addressing.</t>

        <t>It is important to realize that the support of larger packets will
        be on the expense of battery life, as a large packet will be
        fragmented into several or many MAC layer packets, each consuming
        power to transmit / receive.</t>

        <t/>
      </section>

      <section title="Additional Considerations">
        <t>The DECT ULE standard allows PP to be registered (bind) to multiple
        FP and roaming between these FP. This draft does not consider the
        scenarios of PP roaming between multiple FP. The use of repeater
        functionality is also not considered in this draft.</t>
      </section>
    </section>

    <section title="Specification of IPv6 over DECT ULE">
      <t>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 which can be applied to DECT ULE.
      This functionality comprises link-local IPv6 addresses and stateless
      IPv6 address autoconfiguration, Neighbor Discovery and header
      compression.</t>

      <t>The ULE 6LoWPAN adaptation layer can run directly on this U-plane DLC
      layer. Figure 3 illustrates IPv6 over DECT ULE stack.</t>

      <t>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 it's primary configuration does not
      support the formation of multihop networks at the link layer. In
      consequence, the mesh header defined in [RFC4944] for mesh under routing
      MUST NOT be used in DECT ULE networks. In addition, a DECT ULE PP node
      MUST NOT play the role of a 6LoWPAN Router (6LR).</t>

      <section title="Protocol stack">
        <t>In order to enable transmission of IPv6 packets over DECT ULE, a
        Permanent Virtual Circuit (PVC) has to be opened between FP and PP.
        This MUST be done by setting up a service call from PP to FP. The PP
        SHALL specify the &lt;&lt;IWU-ATTRIBUTES&gt;&gt; in a service-change
        (other) message before sending a service-change (resume) message as
        defined in [TS102.939-1]. The &lt;&lt;IWU-ATTRIBTES&gt;&gt; SHALL
        define the ULE Application Protocol Identifier to 0x06 (reserved for
        6LoWPAN and has to be standardized by ETSI) and the MTU size to 1280
        octets or larger. The FP MUST send a service-change-accept (resume)
        containing a valid paging descriptor. The PP MUST be pageable.</t>

        <t><figure>
            <artwork>                  +-------------------+
                  |    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

</artwork>
          </figure></t>
      </section>

      <section title="Link model">
        <t>The general model is that IPv6 is layer 3 and DECT ULE MAC+DLC is
        layer 2. The DECT ULE implements FAR functionality and [RFC4944] MUST
        NOT be used. Since IPv6 requires MTU size of at least 1280 octets, the
        DECT ULE connection (PVC) must be configured with configured with
        equivalent MTU size.</t>

        <t>This specification also assumes the IPv6 header compression format
        specified in [RFC6282]. It is also assumed that the IPv6 payload
        length can be inferred from the ULE DLC packet length and the IID
        value inferred from the link-layer address.</t>

        <t>Due to DECT ULE star topology, each branch of the star is
        considered to be an individual link and thus the PPs cannot directly
        hear one another and also cannot talk to one another with link-local
        addresses. After the FP and PPs have connected at the DECT ULE level,
        the link can be considered up and IPv6 address configuration and
        transmission can begin. The FP ensures address collisions do not
        occur.</t>

        <t/>

        <section title="Stateless address autoconfiguration">
          <t>A DECT ULE 6LN performs stateless address autoconfiguration as
          per [RFC4862]. A 64-bit Interface identifier (IID) for a DECT ULE
          interface MAY be formed by utilizing a MAC-48 device address as
          defined in [RFC2464] "IPv6 over Ethernet" specification.
          Alternatively, the DECT device addresses IPEI, RFPI or TPUI, MAY be
          used instead to derive the IID. In the case of randomly generated
          IID or use of IID derived from DECT devices addresses, the
          "Universal/Local" bit MUST be set to 0. Only if a global unique
          MAC-48 is used the "Universal/Local" bit can be set to 1.</t>

          <t>As defined in [RFC4291], the IPv6 link-local address for a DECT
          ULE node is formed by appending the IID, to the prefix FE80::/64, as
          shown in Figure 4.</t>

          <t><figure>
              <artwork>

             10 bits       54 bits            64 bits
          +----------+-----------------+----------------------+
          |1111111010|       zeros     | Interface Identifier |
          +----------+-----------------+----------------------+

                Figure 4: IPv6 link-local address in DECT ULE

</artwork>
            </figure></t>

          <t>The means for a 6LBR to obtain an IPv6 prefix for numbering the
          DECT ULE network is out of scope of this document, but can be, for
          example, accomplished via DHCPv6 Prefix Delegation [RFC3633] or by
          using Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to
          the link model of the DECT ULE the 6LBR MUST set the "on-link" flag
          (L) 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.</t>

          <t/>
        </section>

        <section title="Neighbor discovery">
          <t>'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 is considered not to
          support mesh networks, hence only those aspects that apply to a star
          topology are considered.</t>

          <t>The following aspects of the Neighbor Discovery optimizations
          [RFC6775] are applicable to DECT ULE 6LNs:</t>

          <t>1. A DECT ULE 6LN MUST register its address with the 6LBR by
          sending a Neighbor Solicitation (NS) message with the ARO option and
          process the Neighbor Advertisement (NA) accordingly. The NS with the
          ARO option SHOULD be sent irrespective of whether the IID is derived
          from a unique MAC-48 bit device address, from the DECT ULE device
          addresses or the IID is a random value that is generated as per the
          privacy extensions for stateless address autoconfiguration
          [RFC4941]. Although [RFC4941] permits the use of deprecated
          addresses for old connections, in this specification we mandate that
          one interface MUST NOT use more than one IID at any one time.</t>

          <t>2. For sending Router Solicitations and processing Router
          Advertisements the DECT ULE 6LNs MUST, respectively, follow Sections
          5.3 and 5.4 of the [RFC6775].</t>
        </section>

        <section title="Unicast and Multicast address mapping">
          <t>The DECT MAC layer broadcast service is considered inadequate for
          IP multicast.</t>

          <t>Hence traffic is always unicast between two DECT ULE nodes. Even
          in the case where a FP is attached to multiple PPs, the FP cannot do
          a multicast to all the connected PPs. If the FP needs to send a
          multicast packet to all its PPs, it has to replicate the packet and
          unicast it on each link. However, this may not be energy-efficient
          and particular care must be taken if the FP is battery-powered. In
          the opposite direction, a PP can only transmit data to a single
          destination (i.e. the FP). Hence, when a PP needs to transmit an
          IPv6 multicast packet, the PP will unicast the corresponding DECT
          ULE packet to the FP. As described in the linkmodel section, the FP
          will not forward link-local multicast messages to other PPs
          connected to the FP.</t>

          <t/>
        </section>

        <section title="Header Compression">
          <t>Header compression as defined in [RFC6282], which specifies the
          compression format for IPv6 datagrams on top of IEEE 802.15.4, is
          REQUIRED in this document as the basis for IPv6 header compression
          on top of DECT ULE. All headers MUST be compressed according to
          [RFC6282] encoding formats. The DECT ULE's star topology structure
          can be exploited in order to provide a mechanism for IID
          compression. The following text describes the principles of IPv6
          address compression on top of DECT ULE.</t>

          <t>In a link-local communication, both the IPv6 source and
          destination addresses MUST be elided [RFC6282], since the node knows
          that the packet is destined for it even if the packet does not have
          destination IPv6 address. A node SHALL learn the IID of the other
          endpoint of each DECT ULE connection it participates in. By
          exploiting this information, a node that receives a PDU containing
          an IPv6 packet can infer the corresponding IPv6 source address. A
          node MUST maintain a Neighbor Cache, in which the entries include
          both the IID of the neighbor and the Device Address that identifies
          the neighbor. For the 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, DAM=11.</t>

          <t>When a 6LN transmits an IPv6 packet to a remote 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 elide the IPv6
          source address. For this, the 6LN MUST use the following settings in
          the IPv6 compressed header: CID=1, SAC=1, 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 DAM=01
          (if the context covers a 64-bit prefix) or as DAM=11 (if the context
          covers a full, 128-bit address). CID and DAC MUST be set to CID=1
          and DAC=1. Note that when a context is defined for the IPv6
          destination address, the 6LBR can infer the elided destination
          prefix by using the context.</t>

          <t>When a 6LBR receives an IPv6 packet sent by a remote node outside
          the DECT ULE network, 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 elide the
          IPv6 destination address of the packet before forwarding it to the
          6LN. For this, the 6LBR MUST set the DAM field of the IPv6
          compressed header as DAM=11. 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 SAM=01 (if the context covers a 64-bit prefix) or SAM=11 (if the
          context covers a full, 128-bit address). CID and SAC MUST be set to
          CID=1 and SAC=1.</t>
        </section>
      </section>

      <section title="Internet connectivity scenarios">
        <t>In a typical scenario, the DECT ULE network is connected to the
        Internet as shown in the Figure 5.</t>

        <t>A degenerate scenario can be imagined where a PP is acting as 6LBR
        and providing Internet connectivity for the FP. How the FP could then
        further provide Internet connectivity to other PP, possibly connected
        to the FP, is out of the scope of this document.</t>

        <figure>
          <artwork>

                       6LN
                        \            ____________
                         \          /            \
                 6LN ---- 6LBR --- |  Internet    |
                         /          \____________/
                        /
                       6LN

                 &lt;-- DECT ULE --&gt;


           Figure 5: DECT ULE network connected to the Internet

</artwork>
        </figure>

        <t>In some scenarios, the DECT ULE network may transiently or
        permanently be an isolated network as shown in the Figure 6.</t>

        <figure>
          <artwork>

                      6LN      6LN
                       \      /
                        \    /
                 6LN --- 6LBR --- 6LN
                        /    \
                       /      \
                      6LN      6LN

                 &lt;------ DECT ULE -----&gt;


                   Figure 6: Isolated DECT ULE network

</artwork>
        </figure>

        <t>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 ULA prefix [RFC4193], and route packets between PP.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>There are no IANA considerations related to this document.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The secure transmission of speech over DECT will be based on the
      DSAA2 and DSC2 work being developed by the DF Security group / ETSI TC
      DECT and the ETSI SAGE Security expert group.</t>

      <t>DECT ULE communications are secured at the link-layer (DLC) by
      encryption and per-message authentication through CCM mode (Counter with
      CBC-MAC) similar to [RFC3610]. The underlying algorithm for providing
      encryption and authentication is AES128.</t>

      <t>The DECT ULE pairing procedure generates a master authentication key
      (UAK) and during location registration procedure or when the permanent
      virtual circuit are established, the session security keys are
      generated. 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 PP in a system have different security keys.
      DECT ULE PPs do not use any shared encryption key.</t>
    </section>

    <section anchor="ETSI" title="ETSI Considerations">
      <t>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 as 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 has to be standardized by ETSI.</t>

      <t>It is proposed to use ETSI DECT ULE Application Protocol Identifier
      equal 0x06 for 6LoWPAN.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements"/>
  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;

      &RFC2464;

      &RFC3610;

      &RFC3633;

      &RFC4193;

      &RFC4861;

      &RFC4862;

      &RFC4941;

      &RFC4944;

      &RFC6282;

      &RFC4291;

      &RFC6775;

      <reference anchor="EN300.175-part1-7">
        <front>
          <title>Digital Enhanced Cordless Telecommunications (DECT); Common
          Interface (CI);</title>

          <author>
            <organization abbrev="ETSI">ETSI</organization>
          </author>

          <date month="August" year="2013"/>
        </front>
      </reference>

      <reference anchor="TS102.939-1">
        <front>
          <title>Digital Enhanced Cordless Telecommunications (DECT); Ultra
          Low Energy (ULE); Machine to Machine Communications; Part 1: Home
          Automation Network (phase 1)</title>

          <author>
            <organization abbrev="ETSI">ETSI</organization>
          </author>

          <date month="April" year="2013"/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
