[要約] RFC 8105は、DECT Ultra Low Energy (ULE)を介してIPv6パケットを転送するための仕様です。このRFCの目的は、IPv6ネットワークを使用してDECT ULEデバイス間で通信を可能にすることです。
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)
デジタル拡張コードレス通信（DECT）超低エネルギー（ULE）を介したIPv6パケットの送信
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.
Digital Enhanced Cordless Telecommunications（DECT）Ultra Low Energy（ULE）は、DECTフォーラムによって提案され、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エアインターフェース技術は、20年以上にわたって世界中の通信デバイスで使用されています。コードレステレフォニーの音声伝送に主に使用されていますが、データ中心のサービスにも展開されています。
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.
DECT ULEは、主にセンサーデバイス、スマートメーター、ホームオートメーションなどの低帯域幅、低電力アプリケーションを対象としたDECTインターフェイスへの最近の追加です。DECTULEインターフェイスは、DECTから多くの機能を継承しているため、長距離で干渉のない運用、世界中で予約された周波数帯域、低シリコン価格、成熟度。モノのインターネットアプリケーションなど、DECT ULEを介してIPv6と通信する機能には付加価値があります。
This document describes how IPv6 is transported over DECT ULE using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques.
このドキュメントでは、IPv6が低電力ワイヤレスパーソナルエリアネットワーク（6LoWPAN）技術を介してIPv6を使用してDECT ULEで転送される方法について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
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.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、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.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
Digital Enhanced Cordless Telecommunications（DECT）は、ETSIによって指定された標準シリーズ[EN300.175-part1-7]であり、CAT-iq（Cordless Advanced Technology-internet and quality）は、一連の製品認証と相互運用性プロファイル[CAT-iq ] DECTフォーラムによって定義されています。 DECT超低エネルギー（DECT ULEまたはULEのみ）は、従来のDECT / CAT-iqの主要な基礎に基づいて構築されたエアインターフェーステクノロジーですが、データスループットを犠牲にして電力消費を大幅に削減する特定の変更が加えられています。 [TS102.939-1]および[TS102.939-2]のETSIで指定されている、電力消費に関する要件を持つDECT ULEデバイスは、特別な電力最適化シリコンで動作しますが、従来のDECT / CATをサポートするDECTゲートウェイに接続できます-コードレステレフォニーとデータ、およびULE拡張のiq
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.
DECTの用語には2つの主要な役割の定義があります。ポータブルパーツ（PP）は電力に制約のあるデバイスであり、固定パーツ（FP）はゲートウェイまたはベースステーションです。このFPはインターネットに接続されている可能性があります。 DECT ULEの使用例は、FPを介して定期的な間隔で少量のデータ（数バイト）を送信するが、外部イベント（侵入など）でウェイクアップできるホームセキュリティセンサーであり、 FPと通信します。 DECT ULEと従来のCAT-iqテレフォニーの両方を組み込んだもう1つの例は、一般に非常に少ないバッテリーを使用して定期的なステータスメッセージを介護プロバイダーに送信する高齢者用のペンダント（ブローチ）ですが、緊急の場合、高齢者はペンダントを介したアラームサービスへの音声接続。これらの多くはすでにコードレス電話用のDECT CAT-iqを実装しているため、DECT ULEは多くの住宅用ゲートウェイに統合されることが期待されています。 DECT ULEは、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.
大きなアドレス空間とよく知られているインフラストラクチャのため、DECT ULEデバイスにはIPv6を検討することが望ましいです。このドキュメントでは、IPv6送信の多くの利点を維持しながら、電力を最適化するためにDECT ULEリンクでIPv6を使用する方法について説明します。 [RFC4944]、[RFC6282]、および[RFC6775]は、IEEE 802.15.4を介したIPv6の伝送を指定します。 DECT ULEには、IEEE 802.15.4に似た多くの特性がありますが、違いもあります。 IEEE 802.15.4でのIPv6の送信用に定義されたメカニズムのサブセットは、DECT ULEリンクでのIPv6の送信に適用できます。
This document specifies how to map IPv6 over DECT ULE inspired by [RFC4944], [RFC6282], [RFC6775], and [RFC7668].
このドキュメントは、[RFC4944]、[RFC6282]、[RFC6775]、および[RFC7668]に着想を得たIPv6 over DECT ULEのマッピング方法を指定します。
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].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
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
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]
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.
DECT ULEは、音声通信などの回線交換サービスと適度なデータレートでのパケットモードデータサービスの両方をサポートするように設計された、低電力のエアインターフェイステクノロジーです。このドキュメントでは、DECT ULEのパケットモードデータサービスのみを扱います。
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.
DECT ULEプロトコルスタックには、地域に応じて1880〜1920 MHzの周波数帯域の周波数で動作するPHY層が含まれており、1.152 Mbaudのシンボルレートを使用します。無線ベアラは、FDMA / TDMA / TDD技術を使用して割り当てられます。
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.
一般的なネットワークトポロジでは、DECTはセルラーネットワークテクノロジーとして定義されています。ただし、最も一般的な構成は、複数のPPが接続されたネットワークを定義する単一のFPを持つスターネットワークです。 MAC層は、検出、ペアリング、セキュリティ機能などのサービスに使用されるため、従来のDECT回路モード操作の両方をサポートし、新しいULEパケットモード操作をサポートします。回路モード機能は、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.
DECT ULEデバイスは、新しいULE MACレイヤー機能を利用して、操作のULEモードに切り替えることができます。 DECT ULEデータリンクコントロール（DLC）は、上のレイヤーからのより大きなパケットに対して、多重化とセグメント化および再構成を提供します。 DECT ULE層は、メッセージごとの認証と暗号化も実装します。 DLCレイヤーはパケットの整合性を保証し、パケットの順序を維持しますが、配信はベストエフォートに基づいています。
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.
現在のDECT ULE MACレイヤー標準は、低帯域幅のデータブロードキャストをサポートしています。ただし、このドキュメントでは、DECT ULEを介したIPv6のDECT ULE MACレイヤーブロードキャストサービスの使用については考慮していません。
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 within the band and can rearrange these to avoid interference. The MAC layer has built-in retransmission procedures in order to improve transmission reliability.
一般に、通信セッションはFP側とPP側の両方から開始できます。 PPで採用されているパワーダウンモードによっては、FP側からセッションを開始するときに遅延が発生する場合があります。 MAC層の通信は、短いセッションのオーバーヘッドが少ない接続指向のパケット転送、またはメディア予約を含む接続指向のベアラを使用して行うことができます。 MAC層は、帯域内で利用可能な無線スペクトル位置を自律的に選択し、干渉を回避するためにこれらを再配置できます。 MAC層には、伝送の信頼性を向上させるために、再伝送手順が組み込まれています。
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.
DECT ULEデバイスは通常、ネットワークに登録するために、アプリケーションプログラミングインターフェイス（API）と、一般アクセスプロファイル（GAP）と呼ばれる一般的な要素を組み込みます。 DECT ULEスタックは、アプリケーションレイヤーのPermanent Virtual Circuit（PVC）を確立し、さまざまな異なるアプリケーションプロトコルをサポートします。アプリケーションプロトコルは、PVC通信サービスが確立されると、PPとFPの間でネゴシエートされます。 [TS102.939-1]はこのネゴシエーションを定義し、6LoWPANに対して0x06に設定されたアプリケーションプロトコル識別子を指定します。このドキュメントでは、そのアプリケーションプロトコルの動作を定義します。
+----------------------------------------+
| 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
図1：DECT ULEプロトコルスタック
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.
図1は、コントロールプレーン（Cプレーン）とユーザーデータプレーン（Uプレーン）にそれぞれ左側と右側に分割されたDECT ULEスタックを示しています。スタックに示されているエンティティは、物理層（PHY）、メディアアクセス制御（MAC）層、データリンク制御（DLC）層、およびネットワーク層（NWK）であり、次のサブコンポーネントがあります。下位層管理エンティティ（LLME） 、モビリティ管理（MM）、およびコール制御（CC）。上には、典型的なアプリケーションプログラマーインターフェイス（API）とアプリケーションプロファイル固有のレイヤーがあります。
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.
FPはPPよりも制約が少ないと見なされます。したがって、主なシナリオでは、FPとPPはそれぞれ6LBRと6LNとして機能します。このドキュメントでは、この主要なシナリオのみを扱います。FPとPPの役割が異なる他のすべてのシナリオは範囲外です。
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では、リンク層では、FPとPPの間でのみ通信が行われます。 FPは、多数のPPで複数の同時接続を処理できます。したがって、IPv6を使用するDECT ULEネットワークでは、無線ホップはIPv6リンクと同等であり、その逆も同様です（セクション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
図2：DECT ULEスタートポロジ
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.
IEEE 802.15.4とDECT ULEの大きな違いは、前者はスタートポロジとメッシュトポロジの両方をサポートし（ルーティングプロトコルが必要）、一方、プライマリ構成のDECT ULEはリンク層でのマルチホップネットワークの形成をサポートしないことです。その結果、[RFC4944]で定義されたメッシュヘッダーは、DECT ULEネットワークでは使用されません。
DECT ULE repeaters are considered to operate transparently in the DECT protocol domain and are outside the scope of this document.
DECT ULEリピーターは、DECTプロトコルドメインで透過的に動作すると見なされ、このドキュメントの範囲外です。
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.
各DECT PPには、製造時にIPEIが割り当てられます。このIDのサイズは40ビットで、DECTアドレス空間内でグローバルに一意であり、リンクローカルアドレスのIIDを導出するために使用されるMACアドレスを構成するために使用できます。
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]).
DECT位置登録手順中に、FPは20ビットのTPUIをPPに割り当てます。 FPは、割り当てられたTPUIと各PPのIPEIの間の一意のマッピングを作成します。このTPUIは、FPとPP間のメッセージのアドレス指定（レイヤー2）に使用されます。 TPUIは定義により一時的なものですが、多くの実装は同じPPに繰り返し同じ値を割り当てるため、IIDの構築には適さないようです（[RFC8065]を参照）。
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.
各DECT FPには、製造時にRFPIが割り当てられます。このIDのサイズは40ビットで、DECTアドレス空間内でグローバルに一意であり、リンクローカルアドレスのIIDを導出するために使用されるMACアドレスを構成するために使用できます。
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].
オプションで、6LoWPANで使用されるDECT IDに加えて、各DECT PPおよびDECT FPに一意の（IEEE）MAC-48アドレスを割り当てることができます。このドキュメントで指定されている非リンクローカルアドレスのアドレス登録中に、FPおよびPPはそのようなMAC-48を使用してIIDを構築できます。ただし、これらのアドレスは永続的であると見なされているため、[RFC8065]のようにそのようなスキームは推奨されません。
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.
理想的には、DECT ULE FPおよびPPは、アプリケーションに応じて、定期的に転送される情報の単一のMACレイヤーパケット（38オクテット）に適合するデータを生成します。ただし、IPパケットははるかに大きくなる場合があります。 DECT ULE DLCプロシージャは、セグメンテーションと再構成をネイティブにサポートし、65536オクテット未満のMTUサイズを提供します。 DECT ULE [TS102.939-1]で定義されているデフォルトのMTUサイズは500オクテットです。完全なIPv6パケットをサポートするために、DECT ULE SHALLのDLC層は、この仕様に従って、1280オクテットのMTUサイズで構成されているため、[RFC4944]フラグメンテーション/再構成は必要ありません。
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.
DECT ULEスタック内の大きなパケットは複数または複数のMACレイヤーパケットにフラグメント化され、それぞれが送受信に電力を消費するため、大きなパケットを使用するとバッテリーの寿命が犠牲になることを認識することが重要です。 MTUサイズを増やしても、MAC層のパケットとPDUのサイズは変わりません。
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].
DECT ULE標準では、PPを複数のFPにDECT登録（バインド）し、それらの間でローミングすることができます。これらのFPとその6LBR機能は、個別に動作するか、[BACKBONE-ROUTER]のようにバックボーンルーターを介して接続できます。
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].
DECT ULEを介してIP層通信を行う前に、6LNや6LBRなどのDECT-ULE対応ノードは、お互いを検出して適切なリンク層接続を確立する必要があります。アクセス権の取得登録と位置登録手順は、ETSIの仕様[EN300.175-part1-7]、[TS102.939-1]、および[TS102.939-2]に記載されています。
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.
DECT ULEテクノロジーは、低消費電力の厳しい要件を設定し、許可されるプロトコルのオーバーヘッドを制限します。 6LoWPAN標準[RFC4944]、[RFC6775]、および[RFC6282]は、DECT ULEに適用できるオーバーヘッドを削減するための便利な機能を提供します。この機能は、リンクローカルIPv6アドレスとステートレスIPv6アドレスの自動構成、ネイバー探索、ヘッダー圧縮で構成されています。
The ULE 6LoWPAN adaptation layer can run directly on this U-plane DLC layer. Figure 3 illustrates an IPv6 over DECT ULE Stack.
ULE 6LoWPANアダプテーションレイヤーは、このUプレーンDLCレイヤーで直接実行できます。図3は、IPv6 over DECT ULEスタックを示しています。
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.
プライマリ構成のDECT ULEはリンク層でのマルチホップネットワークの形成をサポートしていないため、[RFC4944]で定義されているルーティング用メッシュのメッシュヘッダーを使用してはなりません（MUST NOT）。さらに、6LoWPANルーター（6LR）の役割は、この仕様では定義されていません。
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.
DECT ULEを介したデータ送信を可能にするには、FPとPPの間でパーマネントバーチャルサーキット（PVC）を構成して開く必要があります。これは、PPとFPの間にDECTサービス呼び出しをセットアップすることによって行われます。 DECTプロトコルドメインでは、PPは[TS102.939-1]で定義されているように、サービス変更（再開）メッセージを送信する前に、サービス変更（その他）メッセージで<< IWU-ATTRIBUTES >>を指定する必要があります（SHALL）。 << IWU-ATTRIBUTES >>は、ULEアプリケーションプロトコル識別子を0x06に設定し、MTUサイズを1280オクテット以上に設定する必要があります。 FPは、有効なページング記述子を含む必要があるservice-change-accept（再開）を送信します。 PPは、受信したページング記述子の情報に従って、FPからのページングメッセージをリッスンする必要があります。これに続いて、IPv6パケットの送信を開始できます。
+-------------------+
| 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
図3：IPv6 over DECT ULEスタック
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.
一般的なモデルは、IPv6がレイヤー3、DECT ULE MACとDECT ULE DLCがレイヤー2であるというものです。DECTULEはすでにフラグメンテーションおよび再構成機能を実装しています。したがって、[RFC4944]で説明されている断片化および再構成機能を使用してはなりません（MUST NOT）。
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.
FPとPPがDECT ULEレベルで接続された後、リンクはアップと見なされ、IPv6アドレスの設定と送信を開始できます。 6LBRは、アドレスの衝突が発生しないようにします。
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).
この仕様に従って、[RFC6282]で指定されたIPv6ヘッダー圧縮形式を使用する必要があります。 IPv6ペイロード長は、ULE DLCパケット長から導出できます。省略された可能性のあるIPv6アドレスは、下位層アドレスから再構築できます（セクション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.
DECT ULEスター型トポロジー（セクション2.2を参照）により、各PPにはFPへの個別のリンクがあります。したがって、PPは直接互いに聞くことはできず、互いに話すこともできません。 [RFC4903]で説明されているように、IPv6の従来の使用法は、リンク層で単一のリンクにまたがるIPv6サブネットを想定しています。各DECT ULEリンクに個別のサブネットを実装する複雑さを回避するために、マルチリンクサブネットモデル[RFC4903]、特にレイヤー2の非ブロードキャストマルチアクセス（NBMA）が選択されました。このため、リンク-ローカルマルチキャスト通信は、単一のDECT ULE接続内でのみ発生します。したがって、リンクローカルアドレスを使用した6LNから6LNへの通信はできません。同じ6LBRに接続された6LNは、サブネットで使用される共有プレフィックスを使用して互いに通信する必要があります。 6LBRは、6LNによって送信されたパケットを別の6LNに転送します。
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.
ネットワークインターフェースの初期化時に、6LNと6LBRの両方が、基盤となるDECT ULE接続の確立に使用されたDECTデバイスアドレス（セクション2.3を参照）に基づいてIPv6リンクローカルアドレスを生成し、DECT ULEネットワークインターフェース[RFC4862]に割り当てます。
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.
DECTデバイスアドレスIPEIおよびRFPIを使用して、それぞれ6LNおよび6LBRのIPv6リンクローカル64ビットインターフェイス識別子（IID）を導出する必要があります。
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 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.
DECTデバイスアドレスからIIDを導出するためのルールは次のとおりです。それぞれ40ビットで構成されるDECTデバイスアドレスは、先行ゼロビットで拡張して48ビットの中間アドレスを形成する必要があります。この新しく形成された48ビットの中間アドレスの最上位ビットは、RFPIから導出されたアドレスに対して1に設定され、IPEIから導出されたアドレスに対して0に設定されます。 64ビットIIDは、[RFC4291]の付録Aのガイダンスに従って、これらの中間の48ビットアドレスから導出されます。ただし、DECTアドレススペースとIEEEアドレススペースは異なるため、この中間アドレスはIEEEアドレススペース内で一意であると見なすことはできません。派生IIDでは、ユニバーサル/ローカル（U / L）ビット（7番目のビット）はゼロであり、これは派生IIDがグローバルに一意ではないことを示します。[RFC7136]を参照してください。たとえば、RFPI = 11.22.33.44.55から派生したIIDは80：11：22：ff：fe：33：44：55です。 IPEI = 01.23.45.67.89から、派生IIDは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.
リンクローカルアドレスでのIIDのグローバルな一意性は、サブネットドメインの外部に漏出してはならないため、必要ありません。
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.
[RFC4291]で定義されているように、IPv4リンクローカルアドレスは、図4に示すように、プレフィックスFE80 :: / 64にIIDを追加することによって形成されます。
10 bits 54 bits 64 bits
+----------+-----------------+----------------------+
|1111111010| zeros | Interface Identifier |
+----------+-----------------+----------------------+
Figure 4: IPv6 Link-Local Address in DECT ULE
図4：DECT ULEのIPv6リンクローカルアドレス
A 6LN MUST join the all-nodes multicast address.
6LNはすべてのノードのマルチキャストアドレスに参加する必要があります。
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].
リンクローカルアドレスの設定後、6LNは[RFC4861]のセクション6.3.7と[RFC6775]のセクション5.3で説明されているようにルーター要請メッセージを送信します。
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.
非リンクローカルアドレスの場合、6LNは、MAC-48デバイスアドレスまたはDECTデバイスアドレスから派生したIIDを使用するように構成してはなりません（SHOULD NOT）。暗号生成アドレス（CGA）[RFC3972]、プライバシー拡張[RFC4941]、ハッシュベースアドレス（HBA）[RFC5535]、DHCPv6 [RFC3315]、または静的な意味的に不透明なアドレス[RFC7217]などの代替スキームは、デフォルトで使用する必要があります（SHOULD） 。 IIDで必要なエントロピーと使用済みIIDの推奨寿命のガイダンスについては、[RFC8065]も参照してください。生成されたIIDがグローバルに一意でない場合、重複アドレス検出（DAD）[RFC4862]を使用する必要があります。配備の制約によりデバイスのアドレスをIIDに埋め込む必要がある場合、6LNはMAC-48デバイスアドレスまたはDECTデバイスアドレスを利用して64ビットIIDを形成する場合があります。 6LNが生成する非リンクローカルアドレスは、セクション3.2.2で説明されているように6LBRに登録する必要があります。
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 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.
6LBRがDECT ULEネットワークに番号を付けるためにIPv6プレフィックスを取得する方法は、このドキュメントの範囲外ですが、たとえば、DHCPv6プレフィックス委任[RFC3633]またはIPv6ユニキャストユニークローカルアドレス（ULAs）を使用してプレフィックスを割り当てることができます。 ）[RFC4193]。 DECT ULEのリンクモデルにより、6LBRは、プレフィックス情報オプション[RFC4861]で「オンリンク」（L）フラグをゼロに設定する必要があります。これにより、宛先が同じプレフィックスを使用する別の6LNである場合を含め、6LNは常に6LBRにパケットを送信します。
"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.
「IPv6 over Low-Power Wireless Personal Area Networks（6LoWPANs）のネイバー探索最適化」[RFC6775]では、メッシュトポロジーを含むいくつかの6LoWPANトポロジーでの使用に適合したネイバー探索アプローチについて説明しています。 DECT ULEはメッシュネットワークをサポートしていないため、スタートポロジに適用される[RFC6775]の側面のみが考慮されます。
The following aspects of the Neighbor Discovery optimizations [RFC6775] are applicable to DECT ULE 6LNs:
近隣探索最適化[RFC6775]の次の側面は、DECT ULE 6LNに適用できます。
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].
1. ルーター要請の送信とルーターアドバタイズの処理については、DECT ULE 6LNはそれぞれ、[RFC6775]のセクション5.3と5.4に従う必要があります。
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.
2. DECT ULE 6LNは、リンクローカルアドレスを登録してはなりません。リンクローカルアドレスで使用されるIIDはDECTアドレスから取得されるため、リンクローカルアドレスとレイヤ2アドレスの間に一意のマッピングが常に存在します。
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. DECT ULE 6LNは、アドレス登録オプション（ARO）を使用してNeighbor Solicitation（NS）メッセージを送信することにより、その非リンクローカルアドレスを6LBRに登録し、それに応じてNeighbor Advertisement（NA）を処理する必要があります。 ARIの生成に使用された方法に関係なく、AROオプションを使用したNSを送信する必要があります。
The DECT MAC layer broadcast service is considered inadequate for IP multicast because it does not support the MTU size required by IPv6.
DECT MACレイヤーブロードキャストサービスは、IPv6で必要なMTUサイズをサポートしていないため、IPマルチキャストには不十分と見なされます。
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 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.
したがって、トラフィックは常に2つのDECT ULEノード間でユニキャストされます。 6LBRが複数の6LNに接続されている場合でも、6LBRは接続されているすべての6LNに対してマルチキャストを実行できません。 6LBRがそのすべての6LNにマルチキャストパケットを送信する必要がある場合、6LBRはパケットを複製し、各リンクでユニキャストする必要があります。ただし、これはエネルギー効率が良くない場合があり、FPが電池式の場合は特に注意が必要です。さらに電力を節約するために、6LBRはDECT ULEリンクレベルの粒度でマルチキャストリスナーを追跡しなければならず、また、パケットが属するマルチキャストグループに登録されていない6LNにマルチキャストパケットを転送してはなりません（MUST NOT）。反対方向では、6LNは6LBRに、または6LBRを介してのみデータを送信できます。したがって、6LNがIPv6マルチキャストパケットを送信する必要がある場合、6LNは対応するDECT ULEパケットを6LBRにユニキャストします。その後、6LBRはマルチキャストパケットを他の6LNに転送します。
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.
IEEE 802.15.4上のIPv6データグラムの圧縮形式を指定する[RFC6282]で定義されているように、このドキュメントでは、DECT ULE上のIPv6ヘッダー圧縮の基礎としてヘッダー圧縮が必要です。 [RFC6282]で説明されているように、すべてのヘッダーはエンコード形式に従って圧縮する必要があります。 DECT ULEのスタートポロジ構造であるAROおよび6COは、アドレス圧縮のメカニズムを提供するために利用できます。次のテキストは、DECT ULEに基づくIPv6アドレス圧縮の原理を説明しています。
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.
6LNおよび6LBRで終了するリンクローカル通信では、使用されるIIDがDECTリンクのエンドポイントアドレスに一意にマッピングされるため、IPv6の送信元アドレスと宛先アドレスの両方を省略しなければなりません。 IPv6パケットを含むPDUを受信する6LNまたは6LBRは、対応するIPv6送信元アドレスを推測できます。この段落で検討するユニキャストタイプの通信では、IPv6圧縮ヘッダーで次の設定を使用する必要があります：CID = 0、SAC = 0、SAM = 11、DAC = 0、およびDAM = 11。
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.
効率的なヘッダー圧縮を有効にするために、6LBRは、6LBRがステートレスアドレス自動構成で使用するためにルーターアドバタイズメントでアドバタイズするすべてのプレフィックスに6LoWPANコンテキストオプション（6CO）[RFC6775]を含める必要があります。
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 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.
6LNがグローバルユニキャストIPv6アドレスを使用して宛先にIPv6パケットを送信する場合、6LNのグローバルIPv6アドレスのプレフィックスにコンテキストが定義されている場合、6LNはセクションに従って、圧縮されたIPv6ヘッダーの対応するソースフィールドでこのコンテキストを示さなければなりません（MUST）。 [RFC6282]の3.1。最新の登録済みIPv6送信元アドレスを完全に排除する必要があります。このため、6LNはIPv6圧縮ヘッダーで次の設定を使用する必要があります：CID = 1、SAC = 1、およびSAM = 11。この場合、6LBRは省略されたIPv6送信元アドレスを推測できます。これは、1）6LBRが以前に6LNにプレフィックスを割り当てており、2）6LBRが、対応するPPのデバイスアドレスとIIDを関連付けるネイバーキャッシュを維持しているためです。 IPv6宛先アドレスに対してコンテキストが定義されている場合、6LNは、圧縮されたIPv6ヘッダーの対応する宛先フィールドでこのコンテキストを示し、宛先IPv6アドレスのプレフィックスを省略しなければなりません（MUST）。このため、6LNは、圧縮されたIPv6ヘッダーのDAMフィールドをCID = 1、DAC = 1、およびDAM = 01またはDAM = 11として設定する必要があります。 IPv6宛先アドレスにコンテキストが定義されている場合、6LBRはコンテキストを使用して省略された宛先プレフィックスを推測できます。
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.
6LBRがグローバルユニキャストIPv6アドレスを持つIPv6パケットを受信し、パケットの宛先が6LNである場合、6LNのグローバルIPv6アドレスのプレフィックスに対してコンテキストが定義されている場合、6LBRは対応する宛先フィールドでこのコンテキストを示さなければなりません（MUST）。圧縮されたIPv6ヘッダー。宛先アドレスが指定されたコンテキストの6LNによって登録された最新のものである場合、パケットのIPv6宛先アドレスを完全に除外する必要があります。このため、6LBRはIPv6圧縮ヘッダーのDAMフィールドをDAM = 11として設定する必要があります。 CIDおよびDACは、CID = 1およびDAC = 1に設定する必要があります。 IPv6ソースアドレスのプレフィックスにコンテキストが定義されている場合、6LBRは、圧縮されたIPv6ヘッダーのソースフィールドでこのコンテキストを示し、そのプレフィックスも省略しなければなりません（MUST）。このため、6LBRはIPv6圧縮ヘッダーのSAMフィールドをCID = 1、SAC = 1、およびSAM = 01またはSAM = 11として設定する必要があります。
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.
DECT ULEスタートポロジー（セクション2.2を参照）では、各PPにFPへの個別のリンクがあり、FPはリンクレイヤースイッチではなくIPv6ルーターとして機能します。図5にさらに示すように、マルチリンクサブネットモデル[RFC4903]、具体的にはレイヤー2の非ブロードキャストマルチアクセス（NBMA）が選択されています。6LBRは、6LNによって送信されたパケットを別の6LNに転送します。典型的なシナリオでは、図5に示すように、DECT ULEネットワークがインターネットに接続されます。このシナリオでは、DECT ULEネットワークは、1つの/ 64 IPv6プレフィックスを使用して1つのサブネットとして展開されます。 6LBRはルーターとして機能し、6LN間でインターネットとの間でパケットを転送します。
6LN
\ ____________
\ / \
6LN ---- 6LBR ------ | Internet |
/ \____________/
/
6LN
<-- One subnet -->
<-- DECT ULE -->
Figure 5: DECT ULE Network Connected to the Internet
図5：インターネットに接続されたDECT ULEネットワーク
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.
一部のシナリオでは、図6に示すように、DECT ULEネットワークが一時的または永続的に分離されたネットワークになる場合があります。この場合、DECT ULEネットワーク全体が複数のリンクを持つ単一のサブネットで構成され、6LBRは6LN間でパケットをルーティングします。
6LN 6LN
\ /
\ /
6LN --- 6LBR --- 6LN
/ \
/ \
6LN 6LN
<---- One subnet ---->
<------ DECT ULE ----->
Figure 6: Isolated DECT ULE Network
図6：分離されたDECT ULEネットワーク
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.
分離されたネットワークシナリオでは、6LNと6LBR間の通信はIPv6リンクローカル方法論を使用できますが、異なるPP間の通信の場合、FPは6LBRとして機能し、ULAプレフィックス[RFC4193]でネットワークに番号を付け、 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].
複数のFPと6LBRを使用する他のより高度なシステムシナリオでは、各DECT ULE FPがワイヤレスセルを構成します。ネットワークは、図7に示すように、6LNが複数のセルの同じ/ 64サブネットプレフィックス内で動作できるマルチリンクサブネットとして構成できます。このようなシナリオのFPは、定義どおりにバックボーンルーター（6BBR）として動作する必要があります。 [バックボーンルーター]
____________
/ \
| 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
図7：単一のマルチリンクサブネット内の複数のDECT ULEセル
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
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でのサーキットモードサービスの安全な送信は、ETSI Technical Committee（TC）DECTおよびETSI Security Algorithms Group of Experts（SAGE）によって開発されたDSAA2およびDSC / DSC2仕様に基づいています。
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.
DECT ULE通信は、[RFC3610]と同様の暗号化とCCM（暗号ブロック連鎖メッセージ認証コード（CBC-MAC）を備えたカウンター）モードによるメッセージごとの認証によってリンク層（DLC）で保護されます。暗号化と認証を提供するための基本的なアルゴリズムは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.
DECT ULEペアリング手順は、マスターユーザー認証キー（UAK）を生成します。ロケーション登録手順の間、または永続的な仮想回線が確立されると、セッションセキュリティキーが生成されます。マスター認証キーとセッションセキュリティキーの両方は、基礎となるアルゴリズムとしてAES128を使用するDSAA2アルゴリズム[EN300.175-part1-7]を使用して生成されます。セッションセキュリティキーは定期的に更新される場合があります。生成されたセキュリティキー（UAKおよびセッションセキュリティキー）は、FP-PPバインディングごとに異なります。したがって、システム内のすべてのPPには異なるセキュリティキーがあります。 DECT ULE PPは、共有暗号化キーを使用しません。
Even though DECT ULE offers link layer security, it is still recommended to use secure transport or application protocols above 6LoWPAN.
DECT ULEはリンク層セキュリティを提供しますが、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].
プライバシーの観点から、セクション3.2.1で説明されているIPv6リンクローカルアドレス構成は、6LBRがリンク層接続からすでに知っている6LNから6LBRへの情報のみを明らかにします。非リンクローカルIPv6アドレスの場合、デフォルトでは、6LNは[RFC8064]で説明されているように、ランダムに生成されたIIDを使用するか、暗号化アドレス（CGA）[RFC3972]、プライバシー拡張[ RFC4941]、ハッシュベースのアドレス（HBA、[RFC5535]）、または静的な意味的に不透明なアドレス[RFC7217]。
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.
ETSIは、DECT ULE永久仮想回線パケットデータサービスを使用できる既知のアプリケーション層プロトコルのリストを標準化しています。各プロトコルは、[TS102.939-1]で定義されているサービス変更手順で交換される一意の既知の識別子によって識別されます。このドキュメントで説明されているIPv6 / 6LoWPANは、DECT ULE上のアプリケーション層プロトコルと見なされます。 6LoWPAN / DECT ULEデバイス間の相互運用性を提供するために、6LoWPANの共通プロトコル識別子がETSIによって標準化されています。
The ETSI DECT ULE Application Protocol Identifier is set to 0x06 for 6LoWPAN [TS102.939-1].
ETSI DECT ULEアプリケーションプロトコル識別子は、6LoWPAN [TS102.939-1]の0x06に設定されています。
[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>.
[EN300.175-part1-7] ETSI、「Digital Enhanced Cordless Telecommunications（DECT）; Common Interface（CI）; Part 1：Overview」、ヨーロッパ規格、ETSI EN 300 175-1、V2.6.1、2015年7月、< 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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.
[RFC3633] Troan、O。およびR. Droms、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、DOI 10.17487 / RFC3633、2003年12月、<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>.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、DOI 10.17487 / RFC4193、2005年10月、<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>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<http://www.rfc-editor.org/info/rfc4291>。
[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>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<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>.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<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>.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6でのステートレスアドレス自動構成のプライバシー拡張」、RFC 4941、DOI 10.17487 / RFC4941、2007年9月、<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>.
[RFC4944]モンテネグロ、G。、クシャルナガル、N。、ホイ、J。、およびD.キュラー、「IEEE 802.15.4ネットワークを介したIPv6パケットの送信」、RFC 4944、DOI 10.17487 / RFC4944、2007年9月、<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>.
[RFC6282]ホイ、J、エド。およびP. Thubert、「IEEE 802.15.4ベースのネットワーク上のIPv6データグラムの圧縮形式」、RFC 6282、DOI 10.17487 / RFC6282、2011年9月、<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>.
[RFC6775]シェルビー、Z。、編、チャクラバルティ、S。、ノードマーク、E。、およびC.ボーマン、「ローパワーワイヤレスパーソナルエリアネットワーク（6LoWPANs）を介したIPv6のネイバー探索最適化」、RFC 6775、DOI 10.17487 / RFC6775、2012年11月、<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>.
[RFC7136] Carpenter、B。およびS. Jiang、「Significance of IPv6 Interface Identifiers」、RFC 7136、DOI 10.17487 / RFC7136、2014年2月、<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>.
[TS102.939-1] ETSI、「Digital Enhanced Cordless Telecommunications（DECT）; Ultra Low Energy（ULE）; Machine to Machine Communications; Part 1：Home Automation Network（phase 1）」、技術仕様、ETSI TS 102 939- 1、V1.2.1、2015年3月、<https://www.etsi.org/deliver/ etsi_ts / 102900_102999 / 10293901 / 01.02.01_60 / ts_10293901v010201p.pdf>。
[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>.
[TS102.939-2] ETSI、「Digital Enhanced Cordless Telecommunications（DECT）; Ultra Low Energy（ULE）; Machine to Machine Communications; Part 2：Home Automation Network（phase 2）」、技術仕様、ETSI TS 102 939- 2、V1.1.1、2015年3月、<https://www.etsi.org/deliver/ etsi_ts / 102900_102999 / 10293902 / 01.01.01_60 / ts_10293902v010101p.pdf>。
[BACKBONE-ROUTER] Thubert, P., "IPv6 Backbone Router", Work in Progress, draft-ietf-6lo-backbone-router-03, January 2017.
[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>.
[CAT-iq] DECTフォーラム、「CAT-iq at a Glance」、2016年1月、<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>.
[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、2003年7月、<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>.
[RFC3610] Whiting、D.、Housley、R。、およびN. Ferguson、「Counter with CBC-MAC（CCM）」、RFC 3610、DOI 10.17487 / RFC3610、2003年9月、<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>.
[RFC3972] Aura、T。、「Cryptographically Generated Addresses（CGA）」、RFC 3972、DOI 10.17487 / RFC3972、2005年3月、<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>.
[RFC4903]ターラー、D。、「マルチリンクサブネットの問題」、RFC 4903、DOI 10.17487 / RFC4903、2007年6月、<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>.
[RFC5535] Bagnulo、M。、「ハッシュベースアドレス（HBA）」、RFC 5535、DOI 10.17487 / RFC5535、2009年6月、<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>.
[RFC7217] Gont、F。、「IPv6ステートレスアドレス自動構成（SLAAC）を使用してセマンティックに不透明なインターフェース識別子を生成する方法」、RFC 7217、DOI 10.17487 / RFC7217、2014年4月、<http://www.rfc-editor.org / info / rfc7217>。
[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>.
[RFC7668] Nieminen、J.、Savolainen、T.、Isomaki、M.、Patil、B.、Shelby、Z。、およびC. Gomez、「IPv6 over BLUETOOTH（R）Low Energy」、RFC 7668、DOI 10.17487 / RFC7668、2015年10月、<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>.
[RFC8064] Gont、F.、Cooper、A.、Thaler、D。、およびW. Liu、「Recommendation on Stable IPv6 Interface Identifiers」、RFC 8064、DOI 10.17487 / RFC8064、2017年2月、<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>.
[RFC8065]ターラーD。、「IPv6アダプテーションレイヤーメカニズムのプライバシーに関する考慮事項」、RFC 8065、DOI 10.17487 / RFC8065、2017年2月、<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.
IETF 6loワーキンググループのメンバーに感謝します。この文書は彼らの仕事から寛大に借りています。
Ralph Droms, Samita Chakrabarti, Kerry Lynn, Suresh Krishnan, Pascal Thubert, Tatuya Jinmei, Dale Worley, and Robert Sparks have provided valuable feedback for this document.
Ralph Droms、Samita Chakrabarti、Kerry Lynn、Suresh Krishnan、Pascal Thubert、Tatuya Jinmei、Dale Worley、およびRobert Sparksは、このドキュメントに貴重なフィードバックを提供しています。
Authors' Addresses
著者のアドレス
Peter B. Mariager RTX A/S Stroemmen 6 DK-9400 Noerresundby Denmark
Peter B. Mariager RTX A / S Stroemmen 6 DK-9400 Noerresundbyデンマーク
Email: pm@rtx.dk
Jens Toftgaard Petersen (editor) RTX A/S Stroemmen 6 DK-9400 Noerresundby Denmark
イェンストフトガードピーターセン（編集者）RTX A / S Stroemmen 6 DK-9400 Noerresundbyデンマーク
Email: jtp@rtx.dk
Zach Shelby ARM 150 Rose Orchard San Jose, CA 95134 United States of America
Zach Shelby ARM 150 Rose Orchard San Jose、CA 95134アメリカ合衆国
Email: zach.shelby@arm.com
Marco van de Logt Bosch Sensortec GmbH Gerhard-Kindler-Str. 9 72770 Reutlingen Germany
Marco van de Logt Bosch Sensortec GmbH Gerhard-Kindler-Str。 9 72770ロイトリンゲンドイツ
Email: marco.vandelogt@bosch-sensortec.com
Dominique Barthel Orange Labs 28 chemin du Vieux Chene 38243 Meylan France
ドミニクバルテルオレンジラボ28 chemin du Vieux Chene 38243メランフランス
Email: dominique.barthel@orange.com