[要約] RFC 9159は、Bluetooth Low Energy (BLE) ネットワーク上でIPv6通信を可能にするための標準であり、Internet Protocol Support Profile (IPSP) を使用します。この技術は、IoTデバイス間の接続性とインターネットアクセスを向上させることを目的としています。利用場面としては、スマートホーム、ウェアラブルデバイス、その他の低電力IoT環境が挙げられます。
Internet Engineering Task Force (IETF) C. Gomez
Request for Comments: 9159 S.M. Darroudi
Category: Standards Track Universitat Politecnica de Catalunya
ISSN: 2070-1721 T. Savolainen
Unaffiliated
M. Spoerk
Graz University of Technology
December 2021
IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet Protocol Support Profile (IPSP)
インターネットプロトコルサポートプロファイルを使用したBluetooth（R）低エネルギー上のIPv6メッシュ（IPSP）
Abstract
概要
RFC 7668 describes the adaptation of IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques to enable IPv6 over Bluetooth Low Energy (Bluetooth LE) networks that follow the star topology. However, recent Bluetooth specifications allow the formation of extended topologies as well. This document specifies mechanisms that are needed to enable IPv6 mesh over Bluetooth LE links established by using the Bluetooth Internet Protocol Support Profile (IPSP). This document does not specify the routing protocol to be used in an IPv6 mesh over Bluetooth LE links.
RFC 7668は、スタートポロジーに従うBluetooth低エネルギー（Bluetooth LE）ネットワークを介してIPv6を有効にするための、低電力無線パーソナルエリアネットワーク（6lowPan）技術を介したIPv6の適応を説明している。ただし、最近のBluetooth仕様では、拡張トポロジーの形成を可能にします。このドキュメントは、Bluetooth Internet Protocol Supportプロファイル（IPSP）を使用して確立されたBluetooth LEリンクを介してIPv6メッシュを有効にするために必要なメカニズムを指定します。この文書は、Bluetooth LEリンクを介してIPv6メッシュで使用されるルーティングプロトコルを指定しません。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書はインターネットエンジニアリングタスクフォース（IETF）の製品です。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 https://www.rfc-editor.org/info/rfc9159.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc9159で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2021 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。
Table of Contents
目次
1. Introduction
1.1. Terminology and Requirements Language
2. Bluetooth LE Networks and the IPSP
3. Specification of IPv6 Mesh over Bluetooth LE Links
3.1. Protocol Stack
3.2. Subnet Model
3.3. Link Model
3.3.1. Stateless Address Autoconfiguration
3.3.2. Neighbor Discovery
3.3.3. Header Compression
3.3.4. Unicast and Multicast Mapping
4. IANA Considerations
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Appendix A. Bluetooth LE Connection Establishment Example
Appendix B. Node-Joining Procedure
Acknowledgements
Contributors
Authors' Addresses
Bluetooth Low Energy (hereinafter, Bluetooth LE) was first introduced in the Bluetooth 4.0 specification. Bluetooth LE (which has been marketed as Bluetooth Smart) is a low-power wireless technology designed for short-range control and monitoring applications. Bluetooth LE is currently implemented in a wide range of consumer electronics devices, such as smartphones and wearable devices. Given the high potential of this technology for the Internet of Things, the Bluetooth Special Interest Group (Bluetooth SIG) and the IETF have produced specifications in order to enable IPv6 over Bluetooth LE, such as the Internet Protocol Support Profile (IPSP) [IPSP] and RFC 7668 [RFC7668], respectively. Bluetooth 4.0 only supports Bluetooth LE networks that follow the star topology. As a consequence, RFC 7668 [RFC7668] was specifically developed and optimized for that type of network topology. However, the functionality described in RFC 7668 [RFC7668] is not sufficient and would fail to enable an IPv6 mesh over Bluetooth LE links. This document specifies mechanisms that are needed to enable IPv6 mesh over Bluetooth LE links. This document does not specify the routing protocol to be used in an IPv6 mesh over Bluetooth LE links.
Bluetooth Low Energy（以下、Bluetooth LE）を最初にBluetooth 4.0仕様で導入しました。 Bluetooth LE（Bluetooth Smartとして市販されています）は、短距離制御や監視用途向けに設計された低電力の無線技術です。 Bluetooth LEは現在、スマートフォンやウェアラブルデバイスなどの幅広い消費者電子機器で実装されています。本物のインターネットのためのこの技術の可能性の高い可能性を考えると、Bluetooth特別興味グループ（Bluetooth SIG）とIETFはインターネットプロトコルサポートプロファイル（IPSP）[IPSP]のようなBluetooth LEを介してIPv6を有効にするために仕様を生み出しました。 RFC 7668 [RFC7668]。 Bluetooth 4.0は、スタートポロジに従うBluetooth LEネットワークのみをサポートしています。結果として、RFC 7668 [RFC7668]はそのタイプのネットワークトポロジのために特に開発され最適化されました。ただし、RFC 7668 [RFC7668]に記載されている機能は十分ではなく、Bluetooth LEリンクを介してIPv6メッシュを有効にできません。このドキュメントでは、Bluetooth LEリンクを介してIPv6メッシュを有効にするために必要なメカニズムを指定します。この文書は、Bluetooth LEリンクを介してIPv6メッシュで使用されるルーティングプロトコルを指定しません。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The terms "6LoWPAN Node" (6LN), "6LoWPAN Router" (6LR), and "6LoWPAN Border Router" (6LBR) are defined as in [RFC6775], with an addition that Bluetooth LE central and Bluetooth LE peripheral (see Section 2) can both be adopted by a 6LN, a 6LR, or a 6LBR.
「6lowpanノード」（6LN）、「6LOWPAN Router」（6LR）、および「6LRPAN BORDER Router」（6LBR）は、Bluetooth Le CentralおよびBluetooth Le Peripheralが追加されている（RFC6775]のように定義されています（セクション2を参照）。6LN、6LR、または6LBRで両方とも採用することができます。
Bluetooth LE defines two Generic Access Profile (GAP) roles of relevance herein: the Bluetooth LE central role and the Bluetooth LE peripheral role. In Bluetooth 4.0, a device in the central role, which is called "central" from now on, was able to manage multiple simultaneous connections with a number of devices in the peripheral role, called "peripherals" hereinafter. Bluetooth 4.1 (now deprecated) introduced the possibility for a peripheral to be connected to more than one central simultaneously, therefore allowing extended topologies beyond the star topology for a Bluetooth LE network [BTCorev4.1]. In addition, a device may simultaneously be a central in a set of link-layer connections, as well as a peripheral in others.
Bluetooth LEは、Bluetooth Le Central役割とBluetooth LE周辺役割の2つの一般的なアクセスプロファイル（ギャップ）の役割を定義します。Bluetooth 4.0では、今後の「中央」と呼ばれる中央役割の装置は、以下の「周辺機器」と呼ばれる周辺役割の多数の装置との複数の同時接続を管理することができました。Bluetooth 4.1（今非推奨）は、周辺機器を複数の中央に同時に接続する可能性を導入し、したがって、Bluetooth LEネットワークのスタートポロジを超えて拡張トポロジを紹介しました[BTCOREV4.1]。さらに、装置は、一組のリンク層接続内の中央、ならびに他の人の周辺機器を同時に中央にすることができる。
On the other hand, the IPSP enables discovery of IP-enabled devices and the establishment of a link-layer connection for transporting IPv6 packets. The IPSP defines the Node and Router roles for devices that consume/originate IPv6 packets and for devices that can route IPv6 packets, respectively. Consistent with Bluetooth 4.1, Bluetooth 4.2 [BTCorev4.2], and subsequent Bluetooth versions, a device may implement both roles simultaneously.
一方、IPSPは、IP対応デバイスの発見とIPv6パケットを転送するためのリンクレイヤ接続の確立を可能にします。IPSPは、IPv6パケットを消費/発信するデバイスおよびIPv6パケットをルーティングできるデバイスのノードとルータの役割を定義します。Bluetooth 4.1、Bluetooth 4.2 [BTCOREV4.2]、およびその後のBluetoothバージョンと一致して、デバイスは同時に両方の役割を実装することができます。
This document assumes a mesh network composed of Bluetooth LE links, where link-layer connections are established between neighboring IPv6-enabled devices (see Section 3.3.2, item 3.b, and an example in Appendix A). The IPv6 forwarding devices of the mesh have to implement both IPSP Node and Router roles, while simpler leaf-only nodes can implement only the Node role. In an IPv6 mesh over Bluetooth LE links, a node is a neighbor of another node, and vice versa, if a link-layer connection has been established between both by using the IPSP functionality for discovery and link-layer connection establishment for IPv6 packet transport.
この文書はBluetooth LEリンクからなるメッシュネットワークを想定しています。ここで、リンクレイヤ接続は、隣接するIPv6対応デバイス間で確立されます（セクション3.3.2、項目3.B、および付録Aの例）。メッシュのIPv6転送装置は、IPSPノードとルータの役割の両方を実装し、より単純なリーフのみのノードはノードロールのみを実装できます。Bluetooth LEリンク上のIPv6メッシュでは、ノードは別のノードの近隣、およびIPv6パケット転送のためのディスカバリおよびリンク層接続確立のためのIPSP機能とリンク層接続確立を使用してリンク層接続が確立された場合、。
Figure 1 illustrates the protocol stack for IPv6 mesh over Bluetooth LE links. The core Bluetooth LE protocol stack comprises two main sections: the Controller and the Host. The former includes the Physical Layer and the Link Layer, whereas the latter is composed of the Logical Link Control and Adaptation Protocol (L2CAP), the Attribute Protocol (ATT), and the Generic Attribute Profile (GATT). The Host and the Controller sections are connected by means of the Host-Controller Interface (HCI). A device that supports the IPSP Node role instantiates one Internet Protocol Support Service (IPSS), which runs atop GATT. The protocol stack shown in Figure 1 shows two main differences with the IPv6 over Bluetooth LE stack in [RFC7668]:
図1は、Bluetooth LEリンクを介したIPv6メッシュのプロトコルスタックを示しています。コアBluetooth LEプロトコルスタックは、コントローラとホストの2つの主要セクションを備えています。前者は物理層とリンク層とを含み、後者は論理リンク制御および適応プロトコル（L2CAP）、属性プロトコル（ATT）、および汎用属性プロファイル（GATT）からなる。ホストとコントローラのセクションは、ホストコントローラインタフェース（HCI）によって接続されています。IPSPノードロールをサポートするデバイスは、ATOP GATTを実行する1つのインターネットプロトコルサポートサービス（IPSS）をインスタンス化します。図1に示すプロトコルスタックは、[RFC7668]のBluetooth LEスタックのIPv6との2つの主な違いを示しています。
a) the adaptation layer below IPv6 (labeled as "6Lo for IPv6 mesh over Bluetooth LE") is now adapted for IPv6 mesh over Bluetooth LE links, and
a) IPv6の下の適応層（Bluetooth LE上のIPv6メッシュの場合は「610」と表示されている）は、Bluetooth LEリンクを介したIPv6メッシュに適しています。
b) the protocol stack for IPv6 mesh over Bluetooth LE links includes IPv6 routing functionality.
b) Bluetooth LEリンク上のIPv6メッシュのプロトコルスタックには、IPv6ルーティング機能が含まれています。
+------------------------------------+
| Application |
+---------+ +------------------------------------+
| IPSS | | UDP/TCP/other |
+---------+ +------------------------------------+
| GATT | | IPv6 |routing| |
+---------+ +------------------------------------+
| ATT | | 6Lo for IPv6 mesh over Bluetooth LE|
+---------+--+------------------------------------+
| Bluetooth LE L2CAP |
HCI - - +-------------------------------------------------+ - -
| Bluetooth LE Link Layer |
+-------------------------------------------------+
| Bluetooth LE Physical Layer |
+-------------------------------------------------+
Figure 1: Protocol Stack for IPv6 Mesh over Bluetooth LE Links
図1：Bluetooth LEリンク上のIPv6メッシュのプロトコルスタック
Bluetooth 4.2 defines a default MTU for Bluetooth LE of 251 bytes. Excluding the L2CAP header of 4 bytes, a protocol data unit (PDU) size of 247 bytes is available for the layer above L2CAP. (Note: Earlier Bluetooth LE versions offered a maximum amount of 23 bytes for the layer atop L2CAP.) The L2CAP provides a fragmentation and reassembly solution for transmitting or receiving larger PDUs. At each link, the IPSP defines means for negotiating a link-layer connection that provides an MTU of 1280 octets or higher for the IPv6 layer [IPSP]. As per the present specification, the MTU size for IPv6 mesh over BLE links is 1280 octets.
Bluetooth 4.2は、251バイトのBluetooth LE用のデフォルトのMTUを定義します。4バイトのL2CAPヘッダーを除くと、L2CAPの上のレイヤーにはプロトコルデータユニット（PDU）サイズが247バイトのサイズがあります。（注：以前のBluetooth LEバージョンは、L2CAPのレイヤーの最大数23バイトを提供していました。）L2CAPは、より大きなPDUを送受信するための断片化と再構成ソリューションを提供します。各リンクで、IPSPは、IPv6レイヤ[IPSP]に対して1280オクテット以上のMTUを提供するリンクレイヤ接続をネゴシエートするための手段を定義します。本明細書に従って、BLEリンク上のIPv6メッシュのMTUサイズは1280オクテットです。
Similarly to [RFC7668], fragmentation functionality from 6LoWPAN standards is not used for IPv6 mesh over Bluetooth LE links. Bluetooth LE's fragmentation support provided by L2CAP is used.
[RFC7668]と同様に、6LOWPAN規格からのフラグメンテーション機能はBluetooth LEリンクの上のIPv6メッシュには使用されません。L2CAPによって提供されるBluetooth LEの断片化サポートが使用されています。
For IPv6 mesh over Bluetooth LE links, a multilink model has been chosen, as further illustrated in Figure 2. As IPv6 over Bluetooth LE is intended for constrained nodes and for Internet of Things use cases and environments, the complexity of implementing a separate subnet on each peripheral-central link and routing between the subnets appears to be excessive. In this specification, the benefits of treating the collection of point-to-point links between a central and its connected peripherals as a single multilink subnet rather than a multiplicity of separate subnets are considered to outweigh the multilink model's drawbacks as described in [RFC4903]. With the multilink subnet model, the routers have to take on the responsibility of tracking the multicast state and forwarding multicast in a loop-free manner. Note that the route-over functionality defined in [RFC6775] is essential to enabling the multilink subnet model for IPv6 mesh over Bluetooth LE links.
Bluetooth LEリンクの上のIPv6メッシュの場合、図2にさらに示すように、Bluetooth LEを介したIPv6が制約されたノードおよびインターネットの使用・ケースおよび環境のためのものであるため、マルチリンクモデルが選択されました。サブネット間の各周辺リンクとルーティングは過剰になるようです。本明細書では、多数の個別のサブネットではなく単一のマルチリンクサブネットとしての中央とその接続周辺機器との間のポイントツーポイントリンクのコレクションを扱うことの利点は、[RFC4903]に記載されているようにマルチリンクモデルの欠点を上回ると考えられています。。マルチリンクサブネットモデルでは、ルータはマルチキャスト状態を追跡し、ループフリーの方法でマルチキャストを転送する責任を負う必要があります。[RFC6775]で定義されているルートオーバー機能は、Bluetooth LEリンクを介してIPv6メッシュのマルチリンクサブネットモデルを有効にするために不可欠です。
/
/
6LR 6LN 6LN /
\ \ \ /
\ \ \ /
6LN ----- 6LR --------- 6LR ------ 6LBR ----- | Internet
<--Link--> <---Link--->/<--Link->/ |
/ / \
6LN ---- 6LR ----- 6LR \
\
\
<------------ Subnet -----------------><---- IPv6 connection -->
to the Internet
Figure 2: Example of an IPv6 Mesh over a Bluetooth LE Network Connected to the Internet
図2：インターネットに接続されているBluetooth LEネットワーク上のIPv6メッシュの例
One or more 6LBRs are connected to the Internet. 6LNs are connected to the network through a 6LR or a 6LBR. Note that in some scenarios and/or for some time intervals, a 6LR may remain at the edge of the network (e.g., the top left node in Figure 2). This may happen when a 6LR has no neighboring 6LNs. A single global unicast prefix is used on the whole subnet.
1つ以上の6LBRがインターネットに接続されています。6LNは6LRまたは6LBRを介してネットワークに接続されています。いくつかのシナリオおよび/またはある時間間隔では、6LRはネットワークのエッジ（例えば、図2の左上ノード）に残ることがあることに留意されたい。これは、6LRに隣接する6LNSがない場合に発生する可能性があります。サブネット全体では、単一のグローバルユニキャストプレフィックスが使用されます。
IPv6 mesh over Bluetooth LE links MUST follow a route-over approach. This document does not specify the routing protocol to be used in an IPv6 mesh over Bluetooth LE links.
Bluetooth LEリンク上のIPv6メッシュは、経路上のアプローチに従わなければなりません。この文書は、Bluetooth LEリンクを介してIPv6メッシュで使用されるルーティングプロトコルを指定しません。
6LN, 6LR, and 6LBR IPv6 addresses in an IPv6 mesh over Bluetooth LE links are configured as per Section 3.2.2 of [RFC7668].
Bluetooth LEリンク上のIPv6メッシュ内の6LN、6LR、および6LBR IPv6アドレスは、[RFC7668]のセクション3.2.2に従って構成されています。
Multihop Duplicate Address Detection (DAD) functionality as defined in Section 8.2 of [RFC6775] and updated by [RFC8505], or some substitute mechanism (see Section 3.3.2), MAY be supported.
マルチホップ重複アドレス検出（DAD）機能8.2 [RFC6775]のセクション8.2で定義され、[RFC8505]、または一部の代替メカニズム（セクション3.3.2参照）がサポートされる可能性があります。
"Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775], subsequently updated by "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery" [RFC8505], describes the neighbor discovery functionality adapted for use in several 6LoWPAN topologies, including the mesh topology. The route-over functionality of [RFC6775] and [RFC8505] MUST be supported.
"低電力無線パーソナルエリアネットワーク（6lowpans）" [RFC6775]「RFC6775」、その後、「低電力無線パーソナルエリアネットワーク（6LOWPAN）隣接ディスカバリ」[RFC8505]で更新された[RFC6775]。メッシュトポロジを含む、いくつかの6LOWPANトポロジでの使用に適応された近隣検出機能。[RFC6775]と[RFC8505]のルートオーバー機能をサポートする必要があります。
The following aspects of the Neighbor Discovery optimizations for 6LoWPAN [RFC6775] [RFC8505] are applicable to Bluetooth LE 6LNs:
6lowpan [RFC6775] [RFC8505]の近隣探索最適化の様視は、Bluetooth LE 6LNSに適用されます。
1. A Bluetooth LE 6LN MUST register its non-link-local addresses with its routers by sending a Neighbor Solicitation (NS) message with the Extended Address Registration Option (EARO) and process the Neighbor Advertisement (NA) accordingly. The EARO option includes a Registration Ownership Verifier (ROVR) field [RFC8505]. In the case of Bluetooth LE, by default, the ROVR field is filled with the 48-bit device address used by the Bluetooth LE node converted into 64-bit Modified EUI-64 format [RFC4291]. Optionally, a cryptographic ID (see RFC 8928 [RFC8928]) MAY be placed in the ROVR field. If a cryptographic ID is used, address registration and multihop DAD formats and procedures defined in [RFC8928] MUST be used unless an alternative mechanism offering equivalent protection is used.
1. Bluetooth LE 6LNは、拡張アドレス登録オプション（EARO）を使用して隣接勧誘（NS）メッセージを送信し、それに応じて隣接アドバタイズメント（NA）を処理することによって、その非リンクローカルアドレスをそのルータに登録する必要があります。EAROオプションには、登録所有権検証者（ROVR）フィールド[RFC8505]が含まれています。Bluetooth LEの場合、デフォルトでは、ROVRフィールドは、Bluetooth LEノードが64ビット変更されたEUI-64フォーマット[RFC4291]に変換された48ビットのデバイスアドレスで埋められます。任意選択で、暗号ID（RFC 8928 [RFC8928]参照）をROVRフィールドに配置することができる。暗号化IDを使用する場合は、同等の保護を提供する代替メカニズムが使用されない限り、[RFC8928]で定義されているアドレス登録とマルチホップDADフォーマットとプロシージャを使用する必要があります。
As per [RFC8505], a 6LN link-local address does not need to be unique in the multilink subnet. A link-local address only needs to be unique from the perspective of the two nodes that use it to communicate (e.g., the 6LN and the 6LR in an NS/NA exchange). Therefore, the exchange of Extended Duplicate Address Request (EDAR) and Extended Duplicate Address Confirmation (EDAC) messages between the 6LR and a 6LBR, which ensures that an address is unique across the domain covered by the 6LBR, does not need to take place for link-local addresses.
[RFC8505]によると、6LNリンクローカルアドレスはマルチリンクサブネットで一意である必要はありません。リンク - ローカルアドレスは、それを使用して通信するために使用する2つのノードの観点から一意である必要がある（例えば、NS / NA交換内の6LRと6LR）。そのため、6LRと6LBRの間の拡張重複アドレス要求（EDAR）と拡張された重複アドレス確認（EDAC）メッセージの交換は、6LRと6LBRとの間のメッセージが6LBRでカバーされているドメインにわたって一意であることを確認します。リンクローカルアドレス
If the 6LN registers multiple addresses that are not based on the Bluetooth device address using the same compression context, the header compression efficiency may decrease, since only the last registered address can be fully elided (see Section 3.2.4 of [RFC7668]).
6LNが同じ圧縮コンテキストを使用してBluetoothデバイスアドレスに基づいていない複数のアドレスを登録すると、最後の登録アドレスのみを完全に推定できるため、ヘッダの圧縮効率が低下する可能性があります（[RFC7668]のセクション3.2.4を参照）。
2. For sending Router Solicitations and processing Router Advertisements, the hosts that participate in an IPv6 mesh over BLE MUST, respectively, follow Sections 5.3 and 5.4 of [RFC6775], and Section 5.6 of [RFC8505].
2. ルータの勧誘と処理ルータ広告を送信するには、BLE上でIPv6メッシュに参加しているホストがそれぞれ、[RFC6775]のセクション5.3と5.4、および[RFC8505]のセクション5.6に従う必要があります。
3. The router behavior for 6LRs and 6LBRs is described in Section 6 of [RFC6775] and updated by [RFC8505]. However, as per this specification:
3. 6LRSおよび6LBRのルータの動作は、[RFC6775]の第6章で説明し、[RFC8505]によって更新されています。ただし、この仕様に従って
a. Routers SHALL NOT use multicast NSs to discover other routers' link-layer addresses.
a. ルータは他のルータのリンク層アドレスを検出するためにマルチキャストNSSを使用してはならない。
b. As per Section 6.2 of [RFC6775], in a dynamic configuration scenario, a 6LR comes up as a non-router and waits to receive a Router Advertisement for configuring its own interface address first before setting its interfaces to advertising interfaces and turning into a router. In order to support such an operation in an IPv6 mesh over Bluetooth LE links, a 6LR first uses the IPSP Node role only. Once the 6LR has established a connection with another node currently running as a router and receives a Router Advertisement from that router, the 6LR configures its own interface address, turns into a router, and runs as an IPSP Router. In contrast with a 6LR, a 6LBR uses the IPSP Router role since the 6LBR is initialized; that is, the 6LBR uses both the IPSP Node and IPSP Router roles at all times. See an example in Appendix B.
b. [RFC6775]のセクション6.2と同様に、ダイナミックな構成シナリオでは、6LRは非ルータとして起き、そのインターフェイスを広告インタフェースに設定してルータに変換する前に最初に独自のインターフェイスアドレスを設定するためのルータアドバタイズメントを受信するのを待ちます。。Bluetooth LEリンクを介したIPv6メッシュでそのような操作をサポートするために、6LRは最初にIPSPノードの役割を使用します。6LRが現在ルータとして実行されている別のノードとの接続を確立し、そのルータからルータアドバタイズメントを受信すると、6LRは独自のインターフェイスアドレスを設定し、ルータに変換し、IPSPルータとして実行されます。6LRとは対照的に、6LBRは初期化されているため、IPSPルータの役割を使用します。つまり、6LBRは常にIPSPノードとIPSPルーターの役割の両方を使用します。付録Bの例を参照してください。
4. Border router behavior is described in Section 7 of [RFC6775] and updated by [RFC8505].
4. ボーダールータの動作は[RFC6775]のセクション7で説明され、[RFC8505]によって更新されています。
[RFC6775] defines substitutable mechanisms for distributing prefixes and context information (Section 8.1 of [RFC6775]), as well as for duplicate address detection across a route-over 6LoWPAN (Section 8.2 of [RFC6775]). [RFC8505] updates those mechanisms and the related message formats. Implementations of this specification MUST either support the features described in Sections 8.1 and 8.2 of [RFC6775], as updated by [RFC8505] or some alternative ("substitute") mechanism.
[RFC6775]プレフィックスとコンテキスト情報（[RFC6775]のセクション8.1）、および経路上の6LOWPAN全体での重複アドレス検出のための代替メカニズムと、（RFC6775]のセクション8.2）。[RFC8505]これらのメカニズムと関連メッセージフォーマットを更新します。この仕様の実装は、[RFC8505]または「代替案（「代替」）メカニズムによって更新された[RFC6775]のセクション8.1および8.2のセクション8.1および8.2に記載されている機能をサポートする必要があります。
Header compression as defined in RFC 6282 [RFC6282], which specifies the compression format for IPv6 datagrams on top of IEEE 802.15.4, is REQUIRED as the basis for IPv6 header compression on top of Bluetooth LE. All headers MUST be compressed according to RFC 6282 [RFC6282] encoding formats.
IEEE 802.15.4の上のIPv6データグラムの圧縮形式を指定するRFC 6282 [RFC6282]で定義されているヘッダー圧縮は、Bluetooth LEの上のIPv6ヘッダー圧縮の基礎として必要です。すべてのヘッダーは、RFC 6282 [RFC6282]エンコードフォーマットに従って圧縮されている必要があります。
To enable efficient header compression, when the 6LBR sends a Router Advertisement, it MAY include a 6LoWPAN Context Option (6CO) [RFC6775] matching each address prefix advertised via a Prefix Information Option (PIO) [RFC4861] for use in stateless address autoconfiguration. Note that 6CO is not needed for context-based compression when the context is pre-provisioned or provided by out-of-band means as, in these cases, the in-band indication (6CO) becomes superfluous.
効率的なヘッダ圧縮を有効にするには、6LBRがルータアドバタイズメントを送信すると、ステートレスアドレスの自動設定で使用するために、プレフィックス情報オプション（PIO）[RFC4861]を介してアドバタイズされた各アドレスプレフィックスと一致する6LOWPANコンテキストオプション（6CO）[RFC6775]を含めることができます。コンテキストがプリプロビジョニングされている場合、コンテキストベースの圧縮には、コンテキストがプリプロビジョニングされたり、帯域外の平均によって提供されたり、インバンド表示（6CO）が不要になることに注意してください。
The specific optimizations of [RFC7668] for header compression, which exploited the star topology and Address Registration Option (ARO) (note that the latter has been updated by EARO as per [RFC8505]), cannot be generalized in an IPv6 mesh over Bluetooth LE links. Still, a subset of those optimizations can be applied in some cases in such a network. These cases comprise link-local interactions, non-link-local packet transmissions originated by a 6LN (i.e., the first hop from a 6LN), and non-link-local packets intended for a 6LN that are originated or forwarded by a neighbor of that 6LN (i.e., the last hop toward a 6LN). For all other packet transmissions, context-based compression MAY be used.
スタートポロジとアドレス登録オプション（ARO）を利用したヘッダー圧縮のための[RFC7668]の[RFC7668]の特定の最適化（RFC8505]に従って後者が更新されていることに注意してください）、Bluetooth LE上のIPv6メッシュで一般化することはできませんリンクそれでも、これらの最適化のサブセットは、場合によってはそのようなネットワークで適用できます。これらのケースは、6LN（すなわち、6LNからの最初のホップ）によって発信されたリンクローカルのインタラクション、非リンクローカルパケット送信を含み、その近隣によって発信されたまたは発信された6LNを対象とした非リンクローカルパケットを含む。その6LN（すなわち、最後のホップは6LNに向かって）。他のすべてのパケット送信のために、コンテキストベースの圧縮が使用されてもよい。
When a device transmits a packet to a neighbor, the sender MUST fully elide the source Interface Identifier (IID) if the source IPv6 address is the link-local address based on the sender's Bluetooth device address (SAC=0, SAM=11). The sender also MUST fully elide the destination IPv6 address if it is the link-local address based on the neighbor's Bluetooth device address (DAC=0, DAM=11).
装置がパケットを隣接に送信すると、送信元IPv6アドレスが送信者のBluetoothデバイスアドレスに基づくリンクローカルアドレスである場合（SAC = 0、SAM = 11）の場合、送信者は送信元インターフェイスID（IID）を完全に除外しなければなりません。隣接のBluetoothデバイスアドレスに基づくリンクローカルアドレスであれば、送信側は宛先IPv6アドレスも完全に除外する必要があります（DAC = 0、DAM = 11）。
When a 6LN transmits a packet with a non-link-local source address that the 6LN has registered with EARO in the next-hop router for the indicated prefix, the source address MUST be fully elided if it is the latest address that the 6LN has registered for the indicated prefix (SAC=1, SAM=11). If the source non-link-local address is not the latest registered by the 6LN and the first 48 bits of the IID match the latest address are registered by the 6LN, then the last 16 bits of the IID SHALL be carried inline (SAC=1, SAM=10). Otherwise, if the first 48 bits of the IID do not match, then the 64 bits of the IID SHALL be fully carried inline (SAC=1, SAM=01).
6LNが示されているプレフィックスのネクストホップルータで6LNがEAROに登録されているリンクローカルソースアドレスを持つパケットを送信すると、6LNが6LNが持つ最新のアドレスである場合は、ソースアドレスを完全に想定する必要があります。指示されたプレフィックス（SAC = 1、SAM = 11）に登録されています。ソース以外のローカルアドレスが6LNで最新の登録されておらず、最新のアドレスの最初の48ビットが6LNによって登録されている場合、そのIIDの最後の16ビットはインラインで実行されます（SAC =1、SAM = 10）。そうでなければ、IIDの最初の48ビットが一致しない場合、IIDの64ビットは完全にインラインで搭載されなければならない（SAC = 1、SAM = 01）。
When a router transmits a packet to a neighboring 6LN with a non-link-local destination address, the router MUST fully elide the destination IPv6 address if the destination address is the latest registered by the 6LN with EARO for the indicated context (DAC=1, DAM=11). If the destination address is a non-link-local address and not the latest registered and if the first 48 bits of the IID match those of the latest registered address, then the last 16 bits of the IID SHALL be carried inline (DAC=1, DAM=10). Otherwise, if the first 48 bits of the IID do not match, then the 64 bits of the IID SHALL be fully carried in-line (DAC=1, DAM=01).
ルータがリンクローカル宛先アドレスを持つ隣接6LNにパケットを送信すると、宛先アドレスが示されているコンテキストのための最初のIPv6アドレスを完全に除外する必要があります（DAC = 1、ダム= 11）。宛先アドレスが最新の登録ではなく、IIDの最初の48ビットが最新の登録アドレスの最初の48ビットと一致した場合、IIDの最後の16ビットをインラインで実行する（DAC = 1）。、ダム= 10）。それ以外の場合、IIDの最初の48ビットが一致しない場合、IIDの64ビットは完全にインラインで搭載されなければならない（DAC = 1、DAM = 01）。
The Bluetooth LE Link Layer does not support multicast. Hence, traffic is always unicast between two Bluetooth LE neighboring nodes. If a node needs to send a multicast packet to several neighbors, 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 node is battery powered. A router (i.e., a 6LR or a 6LBR) MUST keep track of neighboring multicast listeners, and it MUST NOT forward multicast packets to neighbors that have not registered as listeners for multicast groups to which the packets are destined.
Bluetooth LEリンク層はマルチキャストをサポートしていません。したがって、トラフィックは常に2つのBluetooth LE隣接ノード間でユニキャストです。ノードが複数のネイバーにマルチキャストパケットを送信する必要がある場合は、パケットを各リンクに複製してユニキャストを複製する必要があります。ただし、これはエネルギー効率が悪くなる可能性があり、ノードがバッテリーの電源を供給されている場合は特に注意を払う必要があります。ルータ（すなわち、6LRまたは6LR）は、隣接マルチキャストリスナを追跡しなければならず、パケットが宛てられているマルチキャストグループのリスナとして登録されていないネイバーにマルチキャストパケットを転送してはなりません。
This document has no IANA actions.
この文書にはIANAの行動がありません。
The security considerations in [RFC7668] apply.
[RFC7668]のセキュリティ上の考慮事項が適用されます。
IPv6 mesh over BLE requires a routing protocol to find end-to-end paths. Unfortunately, the routing protocol may generate additional opportunities for threats and attacks to the network.
BLE上のIPv6メッシュでは、エンドツーエンドパスを見つけるためのルーティングプロトコルが必要です。残念ながら、ルーティングプロトコルは、ネットワークへの脅威と攻撃のための追加の機会を生み出すことがあります。
RFC 7416 [RFC7416] provides a systematic overview of threats and attacks on the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), as well as countermeasures. In that document, described threats and attacks comprise threats due to failures to authenticate, threats due to failure to keep routing information, threats and attacks on integrity, and threats and attacks on availability. Reported countermeasures comprise confidentiality attack, integrity attack, and availability attack countermeasures.
RFC 7416 [RFC7416]は、低電力および非損失ネットワーク（RPL）のためのIPv6ルーティングプロトコルに関する脅威と攻撃の概略的な概要と対策を提供します。その文書では、説明された脅威と攻撃は、情報を認証し、脅威と整合性、攻撃、および脅威と脅威と攻撃との脅威のための脅威と脅威となる。報告された対策は、機密性攻撃、整合性攻撃、および可用性攻撃対策を含む。
While this specification does not state the routing protocol to be used in IPv6 mesh over Bluetooth LE links, the guidance of [RFC7416] is useful when RPL is used in such scenarios. Furthermore, such guidance may partly apply for other routing protocols as well.
この仕様では、Bluetooth LEリンクを介してIPv6メッシュで使用されるルーティングプロトコルを述べていないが、[RFC7416]のガイダンスは、そのようなシナリオでRPLが使用されている場合に役立ちます。さらに、そのようなガイダンスは他のルーティングプロトコルにも一部適用され得る。
The ROVR can be derived from the Bluetooth device address. However, such a ROVR can be spoofed; therefore, any node connected to the subnet and aware of a registered-address-to-ROVR mapping could perform address theft and impersonation attacks. Use of Address Protected Neighbor Discovery [RFC8928] provides protection against such attacks.
ROVRはBluetoothデバイスアドレスから派生できます。しかしながら、そのようなROVRは偽造することができる。したがって、サブネットに接続されているノードと登録アドレスからROVRマッピングを認識しても、アドレスの盗難および偽装攻撃を実行できます。アドレス保護されたネイバーディスカバリの使用[RFC8928]そのような攻撃に対する保護を提供します。
[BTCorev4.2] Bluetooth, "Core Specification 4.2", 2 December 2014, <https://www.bluetooth.com/specifications/specs/core-specification-4-2/>.
[BTCOREV4.2] Bluetooth、 "Core Specification 4.2"、2014年12月2日、<https：//www.bluetooth.com/specifications/specs/core-specification-4-2/>。
[IPSP] Bluetooth, "Internet Protocol Support Profile 1.0", 16 December 2014, <https://www.bluetooth.com/specifications/specs/internet-protocol-support-profile-1-0/>.
[IPSP] Bluetooth、2014年12月16日、<https：//www.bluetooth.com/specifications/specs/internet-protocol-support-profile-0- /> ./>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R.およびS.Theering、 "IPバージョン6アドレッシングアーキテクチャ"、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<https：//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, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W.、およびH. Soliman、「IPバージョン6の隣接発見（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<https：//www.rfc-editor.org/info/rfc4861>。
[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, <https://www.rfc-editor.org/info/rfc6282>.
[RFC6282] HUI、J.、ED。2011年9月、<https://www.rfc-editor.org/info/rfc6282、<https：//www.rfc-editor.org/info/rfc6282、<https://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, <https://www.rfc-editor.org/info/rfc6775>.
[RFC6775] Shelby、Z.、ED。、Chakrabarti、S.、Nordmark、E.、およびC. Bormann、「低電力無線パーソナルエリアネットワークにおけるIPv6の近隣探索最適化（6lowpans）」、RFC 6775、DOI 10.17487/ RFC6775、2012年11月、<https://www.rfc-editor.org/info/rfc6775>。
[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, <https://www.rfc-editor.org/info/rfc7668>.
[RFC7668] Nieminen、J.、Savolainen、T.、Isomaki、M.、Patil、B.、Shelby、Z.、およびC.Gomez、「Bluetooth（R）低エネルギー上のIPv6」、RFC 7668、DOI 10.17487 /RFC7668、2015年10月、<https://www.rfc-editor.org/info/rfc7668>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. Perkins, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, <https://www.rfc-editor.org/info/rfc8505>.
[RFC8505] Thubert、P.、Ed。、Nordmark、E.、Chakrabarti、S。、およびC.Perkins、「低電力無線パーソナルエリアネットワークにおけるIPv6の登録拡張」、RFC 8505、DOI10.17487 / RFC8505、2018年11月、<https：//www.rfc-editor.org/info/rfc8505>。
[RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November 2020, <https://www.rfc-editor.org/info/rfc8928>.
[RFC8928] Thubert、P.、Ed。、Sarikaya、B.、Sethi、M.、およびR. Struik、「低消費電力損失ネットワークのための住所保護隣接発見」、RFC 8928、DOI 10.17487 / RFC8928、11月2020、<https://www.rfc-editor.org/info/rfc8928>。
[BTCorev4.1] Bluetooth, "Core Specification 4.1", 3 December 2013, <https://www.bluetooth.com/specifications/specs/core-specification-4-1/>.
[BTCOREV4.1] Bluetooth、 "Core Specification 4.1"、2013年12月3日、<https://www.bluetooth.com/specifications/specs/core-specification-4-1/>。
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, DOI 10.17487/RFC4903, June 2007, <https://www.rfc-editor.org/info/rfc4903>.
[RFC4903] Thaler、D.、「マルチリンクサブネットの問題」、RFC 4903、DOI 10.17487 / RFC4903、2007年6月、<https://www.rfc-editor.org/info/rfc4903>。
[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., and M. Richardson, Ed., "A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, <https://www.rfc-editor.org/info/rfc7416>.
[RFC7416] Tsao、T.、Alexander、R.、Dohler、M.、Daza、V.、Lozano、A.、およびM. Richardson、「低電力のためのルーティングプロトコルのためのセキュリティ脅威解析」。損失のあるネットワーク（RPLS） "、RFC 7416、DOI 10.17487 / RFC7416、2015年1月、<https：//www.rfc-editor.org/info/rfc7416>。
This appendix provides an example of Bluetooth LE connection establishment and use of IPSP roles in an IPv6 mesh over BLE that uses dynamic configuration. The example follows text in Section 3.3.2, item 3.b.
この付録では、Bluetooth LE接続確立と動的構成を使用するBLE上のIPv6メッシュ内のIPSPロールの使用例を示します。この例は3.3.2項の項目3.Bのテキストに従います。
The example assumes a network with one 6LBR, two 6LRs, and three 6LNs, as shown in Figure 3. Connectivity between the 6LNs and the 6LBR is only possible via the 6LRs.
この例では、図3に示すように、1つの6LBR、6LRS、および3つの6LNを持つネットワークを想定しています.6LNSと6LBRの接続性は6LRを介してのみ可能です。
The following text describes the different steps in the example as time evolves. Note that other sequences of events that may lead to the same final scenario are also possible.
次のテキストでは、時間の進展として例のさまざまなステップについて説明します。同じ最終シナリオにつながる可能性がある他のイベントのシーケンスも可能であることに注意してください。
At the beginning, the 6LBR starts running as an IPSP router, whereas the rest of devices are not yet initialized (Step 1). Next, the 6LRs start running as IPSP nodes, i.e., they use Bluetooth LE advertisement packets to announce their presence and support of IPv6 capabilities (Step 2). The 6LBR (already running as an IPSP router) discovers the presence of the 6LRs and establishes one Bluetooth LE connection with each 6LR (Step 3). After establishment of those link-layer connections (and after reception of Router Advertisements from the 6LBR), the 6LRs start operating as routers and also initiate the IPSP Router role (Step 4). (Note: whether the IPSP Node role is kept running simultaneously is an implementation decision). Then, 6LNs start running the IPSP Node role (Step 5). Finally, the 6LRs discover the presence of the 6LNs and establish connections with the latter (Step 6).
最初は、6LBRはIPSPルータとして実行されますが、残りのデバイスはまだ初期化されていません（ステップ1）。次に、6LRSはIPSPノードとして実行を開始する、すなわち、Bluetooth LEアドバタイズメントパケットを使用して、IPv6機能のプレゼンスとサポートを発表する（ステップ2）。6LBR（IPSPルータとして稼働している）は6LRの存在を検出し、各6LRと1つのBluetooth LE接続を確立します（ステップ3）。これらのリンク層接続を確立した後（および6LBRからルータアドバタイズメントの受信後）、6LRSはルータとして動作し始め、IPSPルータロールも開始します（ステップ4）。（注：IPSPノードの役割が同時に実行されているかどうかは実装の決定です）。その後、6LNSはIPSPノードロールの実行を開始します（ステップ5）。最後に、6LRSは6LNSの存在を発見し、後者との接続を確立する（ステップ6）。
Step 1
******
6LBR
(IPSP: Router)
6LR 6LR (not initialized) (not initialized)
6LR 6LR（初期化されていません）（初期化されていません）
6LN 6LN 6LN (not initialized) (not initialized) (not initialized)
6LN 6LN 6LN（初期化されていない）（初期化されていない）（初期化されていません）
Step 2
******
6LBR
(IPSP: Router)
6LR 6LR (IPSP: Node) (IPSP: Node)
6LR 6LR（IPSP：ノード）（IPSP：ノード）
6LN 6LN 6LN (not initialized) (not initialized) (not initialized)
6LN 6LN 6LN（初期化されていない）（初期化されていない）（初期化されていません）
Step 3
******
6LBR
(IPSP: Router)
Bluetooth LE connection --> / \
/ \
6LR 6LR
(IPSP: Node) (IPSP: Node)
6LN 6LN 6LN (not initialized) (not initialized) (not initialized)
6LN 6LN 6LN（初期化されていない）（初期化されていない）（初期化されていません）
Step 4
******
6LBR
(IPSP: Router)
/ \
/ \
6LR 6LR
(IPSP: Router) (IPSP: Router)
6LN 6LN 6LN (not initialized) (not initialized) (not initialized)
6LN 6LN 6LN（初期化されていない）（初期化されていない）（初期化されていません）
Step 5
******
6LBR
(IPSP: Router)
/ \
/ \
6LR 6LR
(IPSP: Router) (IPSP: Router)
6LN 6LN 6LN
(IPSP: Node) (IPSP: Node) (IPSP: Node)
Step 6
******
6LBR
(IPSP: Router)
/ \
/ \
6LR 6LR
(IPSP: Router) (IPSP: Router)
/ \ / \
/ \ / \
/ \ / \
6LN 6LN 6LN
(IPSP: Node) (IPSP: Node) (IPSP: Node)
Figure 3: Example of Connection Establishment and Use of IPSP Roles in an IPv6 Mesh over Bluetooth LE Links
図3：Bluetooth LEリンクの上のIPv6メッシュにおける接続確立の例とIPSPロールの使用例
This appendix provides a diagram that illustrates the node-joining procedure. First of all, the joining node advertises its presence in order to allow establishment of Bluetooth LE connections with neighbors that already belong to a network. The neighbors typically run as a 6LR or as a 6LBR. After Bluetooth LE connection establishment, the joining node starts acting as a 6LN.
この付録では、ノード結合手順を説明する図を示します。まず、接合ノードは、すでにネットワークに属する隣接者とのBluetooth LE接続を確立することを可能にするために、そのプレゼンスをアドバタイズします。隣接者は通常6LRまたは6LBRとして実行されます。Bluetooth LE接続確立後、接合ノードは6LNとして機能し始める。
Figure 4 shows the sequence of messages that are exchanged by the 6LN and a neighboring 6LR that already belongs to the network after the establishment of a Bluetooth LE connection between both devices. Initially, the 6LN sends a Router Solicitation (RS) message (1). Then, the 6LR replies with an RA, which includes the PIO (2). After discovering the non-link-local prefix in use in the network, the 6LN creates its non-link-local address and registers that address with EARO (3) in the 6LR, and then multihop DAD is performed (4). The next step is the transmission of the NA message sent by the 6LR in response to the NS previously sent by the 6LN (5). If the non-link-local address of the 6LN has been successfully validated, the 6LN can operate as a member of the network it has joined.
図4は、両方のデバイス間のBluetooth LE接続の確立後にすでにネットワークに属している隣接6LRと交換されるメッセージのシーケンスを示しています。最初に、6LNはルータ要請（RS）メッセージ（1）を送信します。その後、6LRはRAで返信し、PIO（2）を含む。ネットワークで使用中の非リンクローカルプレフィックスを検出した後、6LNはリンクされていないローカルアドレスを作成し、そのアドレスが6LRのEaro（3）でアドレスを登録し、次にマルチホップDADを実行します（4）。次のステップは、6LR（5）によって以前に送信されたNSに応答して6LRによって送信されたNAメッセージの送信である。6LNの非リンクローカルアドレスが正常に検証された場合、6LNは結合されたネットワークのメンバーとして動作することができます。
(1) 6LN ----(RS)-------> 6LR
(2) 6LN <---(RA-PIO)---- 6LR
(3) 6LN ----(NS-EARO)--> 6LR
(4) [Multihop DAD procedure]
(5) 6LN <---(NA)-------- 6LR
Figure 4: Message Exchange Diagram for a Joining Node
図4：結合ノードのメッセージ交換図
Acknowledgements
謝辞
The Bluetooth, Bluetooth Smart, and Bluetooth Smart Ready marks are registered trademarks owned by Bluetooth SIG, Inc.
Bluetooth、Bluetooth Smart、Bluetoothスマートレディマークは、Bluetooth Sig、Inc。が所有する登録商標です。
The authors of this document are grateful to all authors of [RFC7668], since this document borrows many concepts (albeit with necessary extensions) from [RFC7668].
この文書の著者は[RFC7668]から多くの概念（RFC7668]から多くの概念を借りているため、[RFC7668]のすべての著者に感謝しています。
The authors also thank Alain Michaud, Mark Powell, Martin Turon, Bilhanan Silverajan, Rahul Jadhav, Pascal Thubert, Acee Lindem, Catherine Meadows, and Dominique Barthel for their reviews and comments, which helped improve the document.
著者らはまた、Alain Michaud、Mark Powell、Martin Turon、Bilhanan Silverajan、Rahul Jadhav、Pascal Thubert、Acee Lindem、Catherine Meadows、およびDominique Barthelで、ドキュメントの改善に役立ちました。
Carles Gomez has been supported in part by the Spanish Government Ministerio de Economia y Competitividad through projects TEC2012-32531, TEC2016-79988-P, PID2019-106808RA-I00, and FEDER and Secretaria d'Universitats i Recerca del Departament d'Empresa i Coneixement de la Generalitat de Catalunya 2017 through grant SGR 376.
Carles Gomezは、スペイン政府の政府政府De Econialia y CompentItividaD、TEC2016-79988- P、PID2016-79988- P、PID2019-106808RA-I00、およびCederca and Secretaria D'Universits I Recerca Del Deverament D'Empresa I ConeiximentDe La Generalitat de Catalunya 2017からGRANT SGR 376。
Contributors
貢献者
Carlo Alberto Boano (Graz University of Technology) contributed to the design and validation of this document.
Carlo Alberto Boano（Graz Technology大学）この文書の設計と検証に貢献しました。
Authors' Addresses
著者の住所
Carles Gomez Universitat Politecnica de Catalunya C/Esteve Terradas, 7 08860 Castelldefels Spain
Carles Gomez Universitat Politecnica de Catalunya C / Esteve Terradas、Castelldefelsスペイン
Email: carlesgo@entel.upc.edu
Seyed Mahdi Darroudi Universitat Politecnica de Catalunya C/Esteve Terradas, 7 08860 Castelldefels Spain
Seyed Mahdi Darroudi Universitat Politecnica de Catalunya C / Esteve Terradas、7 08860 Castelldefelsスペイン
Email: sm.darroudi@entel.upc.edu
Teemu Savolainen Unaffiliated
Teemu Savolainenは影響を受けません
Email: tsavo.stds@gmail.com
Michael Spoerk Graz University of Technology Inffeldgasse 16/I 8010 Graz Austria
マイケルスポークグラーツ工科大学インフルドガス16 / I 8010 Grazオーストリア
Email: michael.spoerk@tugraz.at