[要約] RFC 9032は、6TiSCHネットワークにおけるデバイスの参加と登録情報をカプセル化する方法について記述しています。この文書の目的は、安全なデバイスの接続とネットワークへのスムーズな統合を促進することです。主に、IoTデバイスがエネルギー効率の良い方法で通信し、管理されるシナリオで利用されます。
Internet Engineering Task Force (IETF) D. Dujovne, Ed.
Request for Comments: 9032 Universidad Diego Portales
Category: Standards Track M. Richardson
ISSN: 2070-1721 Sandelman Software Works
May 2021
Encapsulation of 6TiSCH Join and Enrollment Information Elements
6Tisch結合と登録情報要素のカプセル化
Abstract
概要
In the Time-Slotted Channel Hopping (TSCH) mode of IEEE Std 802.15.4, opportunities for broadcasts are limited to specific times and specific channels. Routers in a TSCH network transmit Enhanced Beacon (EB) frames to announce the presence of the network. This document provides a mechanism by which additional information critical for new nodes (pledges) and long-sleeping nodes may be carried within the EB in order to conserve use of broadcast opportunities.
IEEE STD 802.15.4のタイムスロットチャネルホッピング（TSCH）モードでは、放送の機会は特定の時間と特定のチャネルに制限されています。TSCHネットワーク内のルータは、ネットワークの存在を発表するための強化されたビーコン（EB）フレームを送信します。この文書は、放送機会の使用を節約するために、新たなノード（PLEDGES）および長寿命ノードにとって重要な情報がEB内で実行され得るメカニズムを提供する。
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/rfc9032.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https：//www.rfc-editor.org/info/rfc9032で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（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 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トラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Terminology
1.2. Layer 2 Synchronization
1.3. Layer 3 Synchronization: IPv6 Router Solicitations and
Advertisements
1.4. Layer 2 Selection
2. Protocol Definition
3. Security Considerations
4. Privacy Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgments
Authors' Addresses
[RFC7554] describes the use of the Time-Slotted Channel Hopping (TSCH) mode of [IEEE.802.15.4].
[RFC7554] [IEEE.802.15.4]のタイムスロットチャネルホッピング（TSCH）モードの使用方法について説明します。
In TSCH mode of IEEE Std 802.15.4, opportunities for broadcasts are limited to specific times and specific channels. Routers in a TSCH network transmit Enhanced Beacon (EB) frames during broadcast slots in order to announce the time and channel schedule.
IEEE STD 802.15.4のTSCHモードでは、放送の機会は特定の時間と特定のチャネルに制限されています。TSCHネットワーク内のルータは、時間とチャネルスケジュールをアナウンスするために、ブロードキャストスロット中に強化されたビーコン（EB）フレームを送信します。
This document defines a new IETF Information Element (IE) subtype to place into the EB to provide join and enrollment information to prospective pledges in a more efficient way.
このドキュメントは、EBに入れるための新しいIETF情報要素（IE）サブタイプを定義して、より効率的な方法で将来のPLEDGESへの参加と登録情報を提供します。
The following subsections explain the problem being solved, which justifies carrying the join and enrollment information in the EB.
以下のサブセクションでは、解決されている問題について説明し、それはEBの結合情報および登録情報を運ぶ正当化する。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
Other terminology can be found in Section 2.1 of [RFC9030].
他の用語は[RFC9030]のセクション2.1にあります。
As explained in Section 4.5.2 of [RFC8180], the EB has a number of purposes: it carries synchronization information such as the Absolute Slot Number (ASN) and Join Metric and identifiers for the timeslot template and the channel hopping sequence, and it indicates the TSCH slotframe.
[RFC8180]のセクション4.5.2で説明されているように、EBは多くの目的を持っています。絶対スロット数（ASN）などの同期情報とタイムスロットテンプレートとチャネルホッピングシーケンスのメトリックと識別子などの同期情報を搭載しています。TSCHスロットフレームを示します。
An EB announces the existence of a TSCH network and the nodes already joined to that network. Receiving an EB allows a Joining Node (pledge) to learn about the network and to synchronize with it.
EBは、TSCHネットワークの存在と既にそのネットワークに結合されているノードを発表します。EBを受信すると、結合ノード（Predge）がネットワークについて学び、それと同期することができます。
The EB may also be used as a means for a node already part of the network to resynchronize [RFC7554].
EBは、既にネットワークの一部を再同期させているノードの手段として使用することもできます[RFC7554]。
There are a limited number of timeslots designated as broadcast slots by each router in the network. Considering 10 ms slots and a slotframe length of 100, these slots are rare and could result in only 1 slot per second for broadcasts, which needs to be used for the beacon. Additional broadcasts for Router Advertisements (RA) or Neighbor Discovery (ND) could be even more scarce.
ネットワーク内の各ルータによってブロードキャストスロットとして指定されたタイムスロットの数が限られています。10msのスロットとスロットフレームの長さ100を考えると、これらのスロットはまれであり、ブロードキャストに1秒あたり1スロットのみを生じる可能性があり、ビーコンに使用する必要がある。ルーター広告（RA）または近隣探索（ND）の追加のブロードキャストはさらに乏しい可能性があります。
1.3. Layer 3 Synchronization: IPv6 Router Solicitations and Advertisements
1.3. レイヤ3の同期：IPv6ルータの勧誘と広告
At Layer 3, [RFC4861] defines a mechanism by which nodes learn about routers by receiving multicast RAs. If no RA is received within a set time, then a Router Solicitation (RS) may be transmitted as a multicast, to which an RA will be received, usually unicast.
レイヤ3では、[RFC4861]は、マルチキャストRASを受信することによってノードがルータについて学習するメカニズムを定義します。設定時間内にRAが受信されない場合、ルータ勧誘（RS）は、RAが受信されるマルチキャストとして送信され、通常はユニキャストすることができる。
Although [RFC6775] reduces the amount of multicast necessary for address resolution via Neighbor Solicitation (NS) messages, it still requires multicast of either RAs or RSes. This is an expensive operation for two reasons: there are few multicast timeslots for unsolicited RAs; and if a pledge node does not receive an RA, and decides to transmit an RS, a broadcast Aloha slot (see Appendix A.5 of [RFC7554]) is consumed with unencrypted traffic. [RFC6775] already allows for a unicast reply to such an RS.
[RFC6775]隣接勧誘（NS）メッセージを介してアドレス解決に必要なマルチキャストの量を減らすが、RASまたはRSEのいずれかのマルチキャストが必要です。これは2つの理由で高価な操作です。迷惑なRASのためのマルチキャストタイムスロットはほとんどありません。また、PREDGEノードがRAを受信しない場合、RSの送信を決定し、ブロードキャストALOHAスロット（[RFC7554]の付録A.5を参照）が暗号化されていないトラフィックで消費されます。[RFC6775]そのようなRSへのユニキャスト応答をすでに許可します。
This is a particularly acute issue for the join process for the following reasons:
これは、以下の理由から、参加プロセスの特に急激な問題です。
1. Use of a multicast slot by even a non-malicious unauthenticated node for a Router Solicitation (RS) may overwhelm that timeslot.
1. ルータ勧誘（RS）のための悪意のある未認証ノードでさえマルチキャストスロットを使用すると、そのタイムスロットが圧倒されます。
2. It may require many seconds of on-time before a new pledge receives a Router Advertisement (RA) that it can use.
2. 新しい誓約が使用できるルーター広告（RA）を受信する前に、数秒のオン時間が必要になる場合があります。
3. A new pledge may have to receive many EBs before it can pick an appropriate network and/or closest Join Proxy to attach to. If it must remain in the receive state for an RA as well as find the EB, then the process may take dozens of seconds, even minutes for each enrollment attempt that it needs to make.
3. 新しい誓約は、適切なネットワークを選ぶ前に多くのEBSを受け取る必要があります。それがRAの受信状態に留まる必要があるならば、EBを見つけるだけでなく、プロセスはそれが行う必要がある各登録の試みについて数十秒かかることがあります。
In a complex Low-power and Lossy Network (LLN), multiple LLNs may be connected together by Backbone Routers (technology such as [RFC8929]), resulting in an area that is serviced by multiple, distinct Layer 2 instances. These are called Personal Area Networks (PANs). Each instance will have a separate Layer 2 security profile and will be distinguished by a different PANID. The PANID is part of the Layer 2 header as defined in [IEEE.802.15.4]: it is a 16-bit value that is chosen to be unique, and it contributes context to the Layer 2 security mechanisms. The PANID provides a context similar to the Extended Service Set ID (ESSID) in 802.11 networking and can be considered similar to the 802.3 Ethernet VLAN tag in that it provides context for all Layer 2 addresses.
複雑な低消費電力および非損失ネットワーク（LLN）では、バックボーンルータ（[RFC8929]などのテクノロジ）によって複数のLLNを接続することができ、複数の異なるレイヤ2インスタンスによって処理される領域が得られます。これらは個人エリアネットワーク（PAN）と呼ばれます。各インスタンスは別のレイヤ2セキュリティプロファイルを持ち、別のパニッドによって区別されます。PANIDは[IEEE.802.15.4]で定義されているレイヤ2ヘッダーの一部です。これは、一意になるように選択されている16ビット値であり、レイヤ2セキュリティメカニズムにコンテキストを寄与します。PANIDは、802.11ネットワーキングの拡張サービスセットID（ESSID）と同様のコンテキストを提供し、それがすべてのレイヤ2アドレスのコンテキストを提供するという点で802.3イーサネットVLANタグと同様に考慮することができます。
A device that is already enrolled in a network may find after a long sleep that it needs to resynchronize with the Layer 2 network. The device's enrollment keys will be specific to a PANID, but the device may have more than one set of keys. Such a device may wish to connect to a PAN that is experiencing less congestion or that has a shallower Routing Protocol for LLNs (RPL) tree [RFC6550]. It may even observe PANs for which it does not have keys, but for which it believes it may have credentials that would allow it to join.
ネットワークに既に登録されているデバイスは、レイヤ2ネットワークと再同期する必要があるという長いスリープ後に見つけることができます。デバイスの登録キーはPANIDに固有のものになりますが、デバイスは複数のキーを持つことがあります。そのような装置は、輻輳が少ない、またはLLN（RPL）ツリー[RFC6550]のための浅いルーティングプロトコルを有するパンに接続することを望むことがある。それはそれが鍵を持っていないがそれが参加することを可能にする信用証明書を持っているかもしれないと信じるかもしれないPANを観察するかもしれません。
In order to identify which PANs are part of the same backbone network, the network ID is introduced in this extension. PANs that are part of the same backbone will be configured to use the same network ID. For RPL networks [RFC6550], configuration of the network ID can be done with a configuration option, which is the subject of future work.
どのPANが同じバックボーンネットワークの一部であるかを識別するために、ネットワークIDがこの拡張機能で導入される。同じバックボーンの一部であるPANは、同じネットワークIDを使用するように設定されます。RPLネットワークの場合[RFC6550]は、ネットワークIDの構成を設定オプションで実行できます。これは将来の作業の対象です。
In order to provide some input to the choice of which PAN to use, the PAN priority field has been added. This lists the relative priority for the PAN among different PANs. Every EB from a given PAN will likely have the same PAN priority. Determination of the PAN priority is the subject of future work; but it is expected that it will be calculated by an algorithm in the 6LoWPAN Border Router (6LBR), possibly involving communication between 6LBRs over the backbone network.
使用するPANの選択にいくつかの入力を提供するために、PAN Priorityフィールドが追加されました。これは、さまざまなPANの間のパンの相対優先順位を示しています。特定のパンからのEBはすべて同じPAN優先順位を持つ可能性があります。パンの優先順位の決定は将来の仕事の主題です。しかし、それは、6lowpan国境ルータ（6LBR）のアルゴリズムによって計算されることが予想され、おそらくバックボーンネットワーク上の6LBR間の通信を含む。
The parent selection process [RFC6550] can only operate within a single PAN because it depends upon receiving RPL DIO messages from all available parents. As part of the PAN selection process, the device may wish to know how deep in the LLN mesh it will be if it joins a particular PAN, and the rank priority field provides an estimation of each announcer's rank. Once the device synchronizes with a particular PAN's TSCH schedule, it may receive DIOs that are richer in their diversity than this value. The use of this value in practice is the subject of future research, and the interpretation of this value of the structure is considered experimental.
親選択プロセス[RFC6550]は、使用可能なすべての親からRPL DIOメッセージを受信したことに依存するため、単一のパン内でのみ動作できます。PAN選択プロセスの一部として、デバイスは、LLNメッシュの深さが特定のPANに参加するかどうかを知りたいと思うかもしれません。ランク優先順位フィールドは各アナウンサーのランクの推定を提供します。デバイスが特定のPANのTSCHスケジュールと同期されると、この値よりも多様性に豊富なDIOSが表示されることがあります。この価値の実際の使用は将来の研究の対象であり、この構造のこの値の解釈は実験的と考えられています。
[RFC8137] creates a registry for new IETF IE subtypes. This document allocates a new subtype.
[RFC8137]新しいIETF IEサブタイプのレジストリを作成します。この文書は新しいサブタイプを割り当てます。
The new IE subtype structure is as follows. As explained in [RFC8137], the length of the subtype content can be calculated from the container, so no length information is necessary.
新しい副種の構造は次のとおりです。[RFC8137]で説明したように、サブタイプコンテンツの長さはコンテナから計算できますので、長さ情報は必要ありません。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |R|P| res | proxy prio | rank priority |
+-+-+-+-+-+-+-+-+-+-------------+-------------+-----------------+
| PAN priority | |
+---------------+ +
| Join Proxy Interface ID |
+ (present if P=1) +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ +
| network ID |
+ variable length, up to 16 bytes +
~ ~
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
Figure 1: IE Subtype Structure
図1：IEサブタイプ構造
res: Reserved bits MUST be ignored upon receipt and SHOULD be set to 0 when sending.
res：受信時に予約ビットは無視されなければならず、送信時に0に設定する必要があります。
R: The RA R-flag is set if the sending node will act as a router for host-only nodes relying on stateless address auto-configuration (SLAAC) to get their global IPv6 address. Those hosts MUST send a unicast RS message in order to receive an RA with the Prefix Information Option.
R：送信ノードがステートレスアドレス自動設定（SLAAC）に依存するホストノード（SLAAC）に頼っているホストノードのルータとして機能する場合は、RA R-Flagが設定されます。グローバルIPv6アドレスを取得します。これらのホストは、プレフィックス情報オプションを使用してRAを受信するためにユニキャストRSメッセージを送信する必要があります。
In most cases, every node sending a beacon will set this flag, and in a typical mesh, this will be every single node. When this bit is not set, it might indicate that this node may be under provisioned or that it may have no additional slots for additional nodes. This could make this node more interesting to an attacker.
ほとんどの場合、ビーコンを送信するすべてのノードはこのフラグを設定し、一般的なメッシュでは、これはすべてのノードになります。このビットが設定されていない場合、このノードがプロビジョニングされているか、追加ノードに追加のスロットを持たない可能性があることを示すことがあります。これはこのノードを攻撃者にとってより面白くする可能性があります。
P: If the Proxy Address P-flag is set, then the Join Proxy Interface ID bit field is present. Otherwise, it is not provided.
P：プロキシアドレスPフラグが設定されている場合は、結合プロキシインタフェースIDビットフィールドが存在する。そうでなければ、それは提供されていません。
This bit only indicates if another part of the structure is present, and it has little security or privacy impact.
このビットは、構造体の別の部分が存在するかどうかを示し、セキュリティやプライバシーの影響がほとんどありません。
proxy prio (proxy priority): This field indicates the willingness of the sender to act as a Join Proxy. Lower value indicates greater willingness to act as a Join Proxy as described in [RFC9031]. Values range from 0x00 (most willing) to 0x7e (least willing). A priority of 0x7f indicates that the announcer should never be considered as a viable Join Proxy. Only unenrolled pledges look at this value.
プロキシPRIO（Proxy Priority）：このフィールドは、送信者の結合プロキシとして機能する意思を示します。低い値[RFC9031]に記載されているように、結合プロキシとして機能する意思が大きいことを示します。値は0x00（ほとんどの意思）から0x7e（最小喜び）の範囲です。0x7fの優先順位は、アナウンサーが実行可能な参加プロキシと考えるべきではないことを示します。この値を調べるだけでなく、アンエンロールされていないPLEDGESのみが表示されます。
Lower values in this field indicate that the transmitter may have more capacity to handle unencrypted traffic. A higher value may indicate that the transmitter is low on neighbor cache entries or other resources. Ongoing work such as [NETWORK-ENROLLMENT] documents one way to set this field.
このフィールドの下位値は、送信機が暗号化されていないトラフィックを処理するための容量が多くなる可能性があることを示しています。値が大きいほど、送信機が隣接キャッシュエントリまたは他のリソースが低いことを示している可能性があります。[ネットワーク登録]のような進行中の作業このフィールドを設定する1つの方法。
rank priority: The rank priority is set by the IPv6 LLN Router (6LR) that sent the beacon and is an indication of how willing this 6LR is to serve as a RPL parent [RFC6550] within a particular network ID. Lower values indicate more willingness, and higher values indicate less willingness. This value is calculated by each 6LR according to algorithms specific to the routing metrics used by the RPL [RFC6550]. The exact process is a subject of significant research work. It will typically be calculated from the RPL rank, and it may include some modifications based upon current number of children or the number of neighbor cache entries available. Pledges MUST ignore this value. It helps enrolled devices only to compare connection points.
ランクの優先順位：ランクの優先順位は、ビーコンを送信したIPv6 LLNルータ（6LR）によって設定され、この6LRが特定のネットワークID内のRPL親[RFC6550]として機能する方法を示しています。より低い値はより意欲的さを示し、そしてより高い値は意欲が低いことを示しています。この値は、RPL [RFC6550]によって使用されるルーティングメトリックに固有のアルゴリズムに従って、各6LRによって計算されます。正確なプロセスは、有意な研究作業の対象です。それは通常RPLランクから計算され、現在の子数または利用可能な隣接キャッシュエントリの数に基づくいくつかの修正を含めることができる。PLEDGESはこの値を無視する必要があります。それは、接続ポイントを比較するためだけに登録されたデバイスを登録するのを助けます。
An attacker can use this value to determine which nodes are potentially more interesting. Nodes that are less willing to be parents likely have more traffic, and an attacker could use this information to determine which nodes would be more interesting to attack or disrupt.
攻撃者はこの値を使用して、どのノードが潜在的に興味深いかを判断できます。両親になることを望んでいないノードは、より多くのトラフィックを持っている可能性があり、攻撃者はこの情報を使用してどのノードが攻撃または混乱を興味深くするのかを判断できます。
PAN priority: The PAN priority is a value set by the Destination-Oriented Directed Acyclic Graph (DODAG) root (see [RFC6550], typically the 6LBR) to indicate the relative priority of this LLN compared to those with different PANIDs that the operator might control. This value may be used as part of the enrollment priority, but typically it is used by devices that have already enrolled and need to determine which PAN to pick when resuming from a long sleep. Unenrolled pledges MAY consider this value when selecting a PAN to join. Enrolled devices MAY consider this value when looking for an eligible parent device. Lower values indicate more willingness to accept new nodes.
PAN優先順位：PAN優先順位は、宛先指向の有向・非晶系グラフ（DODAG）rootによって設定された値（[RFC6550]、通常は6LBR）を参照して、オペレーターが異なるパニッドを持つものと比較して、このLLNの相対優先順位を示します。コントロール。この値は登録優先順位の一部として使用できますが、通常はすでに登録されているデバイスで使用され、長いスリープから再開するときにどのパンを選択する必要があります。登録されていないPledgesは、結合するPANを選択するときにこの値を考慮することができます。登録されたデバイスは、適格な親デバイスを探すときにこの値を考慮することができます。低い値は、新しいノードを受け入れる意欲が高いことを示しています。
An attacker can use this value, along with the observed PANID in the EB to determine which PANIDs have more network resources, and may have more interesting traffic.
攻撃者は、EBの観察されたPANIDとともにこの値を使用して、どのパニッドがより多くのネットワークリソースを持っているかを決定することができ、より面白いトラフィックを持つ可能性があります。
Join Proxy Interface ID: If the P bit is set, then 64 bits (8 bytes) of address are present. This field provides the Interface ID (IID) of the link-local address of the Join Proxy. The associated prefix is well-known as fe80::/64. If this field is not present, then IID is derived from the Layer 2 address of the sender per SLAAC [RFC4862].
プロキシインターフェイスIDを結合する：Pビットが設定されている場合は、64ビット（8バイト）のアドレスが存在します。このフィールドには、結合プロキシのリンクローカルアドレスのインタフェースID（IID）があります。関連する接頭辞はFE80 :: / 64としてよく知られています。このフィールドが存在しない場合、IIDはSLAACごとの送信者のレイヤ2アドレスから派生します[RFC4862]。
This field communicates the IID bits that should be used for this node's Layer 3 address, if it should not be derived from the Layer 2 address. Communication with the Join Proxy occurs in the clear. This field avoids the need for an additional service-discovery process for the case where the Layer 3 address is not derived from the Layer 2 address. An attacker will see both Layer 2 and Layer 3 addresses, so this field provides no new information.
このフィールドは、レイヤ2アドレスから派生していない場合、このノードのレイヤ3アドレスに使用するIIDビットを通信します。結合プロキシとの通信は明確に発生します。このフィールドは、レイヤ3アドレスがレイヤ2アドレスから導出されない場合の追加のサービス発見プロセスの必要性を回避します。攻撃者にはレイヤ2とレイヤ3の両方のアドレスが表示されるため、このフィールドは新しい情報を提供しません。
network ID: This is a variable length field, up to 16-bytes in size that uniquely identifies this network, potentially among many networks that are operating in the same frequencies in overlapping physical space. The length of this field can be calculated as being whatever is left in the IE.
ネットワークID：これは、このネットワークを一意に識別する最大16バイトのサイズで、重複する物理空間で同じ周波数で動作している多くのネットワークの中にある潜在的に、サイズが16バイトです。このフィールドの長さは、IEに残されているものとして計算できます。
In a 6TiSCH network, where RPL [RFC6550] is used as the mesh routing protocol, the network ID can be constructed from a truncated SHA-256 hash of the prefix (/64) of the network. This will be done by the RPL DODAG root and communicated by the RPL Configuration Option payloads, so it is not calculated more than once. This is just a suggestion for a default algorithm: it may be set in any convenient way that results in a non-identifying value. In some LLNs where multiple PANIDs may lead to the same management device (the Join Registrar/Coordinator (JRC)), then a common value that is the same across all the PANs MUST be configured. Pledges that see the same network ID will not waste time attempting to enroll multiple times with the same network when the network has multiple attachment points.
RPL [RFC6550]がメッシュルーティングプロトコルとして使用されている6Tischネットワークでは、ネットワークIDはネットワークのプレフィックス（/ 64）の切り捨てられたSHA-256ハッシュから構成することができます。これはRPL DODAGルートによって行われ、RPL構成オプションペイロードによって伝達されるため、複数回計算されません。これはデフォルトのアルゴリズムのための単なる提案です。識別されない値をもたらす任意の便利な方法で設定できます。複数のパニッドが同じ管理デバイス（参加レジストラ/コーディネータ（JRC））につながる可能性がある一部のLLNでは、すべてのPANにわたって同じ値を構成する必要があります。同じネットワークIDを見ているPLEDGESは、ネットワークに複数の添付ポイントがあるときに同じネットワークで複数回登録しようとする時間を無駄にしません。
If the network ID is derived as suggested, then it will be an opaque, seemingly random value and will not directly reveal any information about the network. An attacker can match this value across many transmissions to map the extent of a network beyond what the PANID might already provide.
ネットワークIDが示唆されていると導き出された場合、それは不透明であり、一見ランダムな値になり、ネットワークに関する情報を直接表示させません。攻撃者は、パニッドがすでに提供されているものを超えてネットワークの範囲をマッピングするために、多くの送信にわたるこの値を一致させることができます。
All of the contents of this IE are transmitted in the clear. The content of the EB is not encrypted. This is a restriction in the cryptographic architecture of the 802.15.4 mechanism. In order to decrypt or do integrity checking of Layer 2 frames in TSCH, the TSCH ASN is needed. The EB provides the ASN to new (and long-sleeping) nodes.
このIEの内容はすべて明確に送信されます。EBの内容は暗号化されていません。これは802.15.4メカニズムの暗号化アーキテクチャにおける制限です。TSCHのレイヤ2フレームの整合性検査を復号化または実行するためには、TSCH ASNが必要です。EBは、ASNを新しい（および長い睡眠中の）ノードに提供します。
The sensitivity of each field is described within the description of each field.
各フィールドの感度は各フィールドの説明内に記載されている。
The EB is authenticated at the Layer 2 level using 802.15.4 mechanisms using the network-wide keying material. Nodes that are enrolled will have the network-wide keying material and can validate the beacon.
ネットワーク全体のキーイング材料を使用して、802.15.4メカニズムを使用して、EBがレイヤ2レベルで認証されます。登録されているノードはネットワーク全体のキーイングマテリアルを持ち、ビーコンを検証できます。
Pledges that have not yet enrolled are unable to authenticate the beacons and will be forced to temporarily take the contents on faith. After enrollment, a newly enrolled node will be able to return to the beacon and validate it.
まだ登録されていない誓約はビーコンを認証することができず、信仰の中身を一時的に取り入れることを余儀なくされます。登録後、新しく登録されたノードはビーコンに戻って検証することができます。
In addition to the enrollment and join information described in this document, the EB contains a description of the TSCH schedule to be used by the transmitter of this packet. The schedule can provide an attacker with a list of channels and frequencies on which communication will occur. Knowledge of this can help an attacker to more efficiently jam communications, although there is future work being considered to make some of the schedule less visible. Encrypting the schedule does not prevent an attacker from jamming, but rather increases the energy cost of doing that jamming.
この文書に記載されている登録および結合情報に加えて、EBは、このパケットの送信機によって使用されるTSCHスケジュールの説明を含む。スケジュールは、通信が発生するチャネルと周波数のリストを攻撃者に提供することができます。これに関する知識は、スケジュールのいくつかを見やすくするために考慮されている将来の作業が検討されていますが、攻撃者がより効率的にJAMコミュニケーションを支援するのに役立ちます。スケジュールを暗号化すると、攻撃者が妨害されるのを妨げませんが、その妨害を行うエネルギーコストを増やします。
The use of a network ID may reveal information about the network. The use of a SHA-256 hash of the DODAGID (see [RFC6550]), rather than using the DODAGID itself directly provides some privacy for the addresses used within the network, as the DODAGID is usually the IPv6 address of the root of the RPL mesh.
ネットワークIDを使用すると、ネットワークに関する情報が表示されることがあります。DoDagID自体を使用するのではなく、DoDagIDのSHA-256ハッシュ（[RFC6550]参照）を使用すると、DoDagIDは通常RPLのルートのIPv6アドレスであるため、ネットワーク内で使用されているアドレスのプライバシーをいくつか提供します。メッシュ。
An interloper with a radio sniffer would be able to use the network ID to map out the extent of the mesh network.
無線スニファを備えたインターロープは、ネットワークIDを使用してメッシュネットワークの範囲をマッピングすることができるでしょう。
IANA has assigned the following value in the "IEEE Std 802.15.4 IETF IE Subtype IDs" registry, as defined by [RFC8137].
[RFC8137]で定義されているように、「IEEE STD 802.15.4 IETF IEサブタイプID」レジストリに次の値を割り当てました。
+=======+==================+===========+
| Value | Subtype ID | Reference |
+=======+==================+===========+
| 2 | 6tisch-Join-Info | RFC 9032 |
+-------+------------------+-----------+
Table 1
表1
[IEEE.802.15.4] IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE Standard 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875, April 2016, <https://ieeexplore.ieee.org/document/7460875>.
[IEEE.802.15.4] IEEE、「低速ワイヤレスネットワークのためのIEEE規格」、IEEEスタンダード802.15.4-2015、DOI 10.1109 / IEEESTD.2016.7460875、<https：//ieeexplore.ieee.org/document/ 7460875>。
[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[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）の隣接発見（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<https：//www.rfc-editor.org/info/rfc4861>。
[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>。
[RFC8137] Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information Element for the IETF", RFC 8137, DOI 10.17487/RFC8137, May 2017, <https://www.rfc-editor.org/info/rfc8137>.
[RFC8137] Kivinen、T.およびP. Kinney、「IEEE 802.15.4 IETFのIEEE 802.15.4情報要素」、RFC 8137、DOI 10.17487 / RFC8137、2017年5月、<https：//www.rfc-editor.org/info/RFC8137>。
[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>。
[RFC9031] Vučinić, M., Ed., Simon, J., Pister, K., and M. Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH", RFC 9031, DOI 10.17487/RFC9031, May 2021, <https://www.rfc-editor.org/info/rfc9031>.
[RFC9031]Vužinić、M.、Ed。、Simon、J.、Pister、K.、およびM.リチャードソン、「6Tischの拘束結合プロトコル（COJP）」、RFC 9031、DOI 10.17487 / RFC9031、2021年5月、<HTTPS//www.rfc-editor.org/info/rfc9031>。
[NETWORK-ENROLLMENT] Richardson, M., Jadhav, R. A., Thubert, P., and H. She, "Controlling Secure Network Enrollment in RPL networks", Work in Progress, Internet-Draft, draft-ietf-roll-enrollment-priority-04, 7 February 2021, <https://tools.ietf.org/html/draft-ietf-roll-enrollment-priority-04>.
[ネットワーク登録] Richardson、M.、Jadhav、RA、Thubert、P.、およびH。彼女は、「RPLネットワークにおける安全なネットワーク登録の制御」、進行中の作業、インターネットドラフト、ドラフト - IETFロール登録 - 優先順位 - 04,2021、<https://tools.ietf.org/html/draft-ietf-roll-enrollment-priority-04>。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T.、T. Jinmei、「IPv6ステートレスアドレス自動設定」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<https：//www.rfc-editor.org/info/ RFC4862>。
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, <https://www.rfc-editor.org/info/rfc6550>.
[RFC6550]冬、T.、ED。、Thubert、P.、Ed。、Brandt、A.、Hui、J.、Kelsey、R.、Levis、P.、Pister、K.、Struik、R.、Vasseur、JP。、およびR.RPL：低消費電力ネットワークの「RPL：IPv6ルーティングプロトコル」、RFC 6550、DOI 10.17487 / RFC6550、2012年3月、<https：//www.rfc-editor.org/info/RFC6550>。
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015, <https://www.rfc-editor.org/info/rfc7554>.
[RFC7554] Watteyne、T.、ED。、Palattella、M.、およびL.Grieco、「IEEE 802.15.4Eタイムスロットチャンネルホッピング（TSCH）（IoT）：問題声明 "、RFC 7554、DOI 10.17487 / RFC7554、2015年5月、<https://www.rfc-editor.org/info/rfc7554>。
[RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, May 2017, <https://www.rfc-editor.org/info/rfc8180>.
[RFC8180] Vilajosana、X.、ED。、Pister、K.、およびT.Watteyne、「IEEE 802.15.4EのTSCHモードでの最小IPv6（6tisch）構成」、BCP 210、RFC 8180、DOI 10.17487 / RFC8180、2017年5月、<https：//www.rfc-editor.org/info/rfc8180>。
[RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli, "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929, November 2020, <https://www.rfc-editor.org/info/rfc8929>.
[RFC8929] Thubert、P.、Ed。、Perkins、CE、E. Levy-Abngingoli、「IPv6 Backbone Router」、RFC 8929、DOI 10.17487 / RFC8929、2020年11月、<https：//www.rfc-編集者。ORG / INFO / RFC8929>。
[RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", RFC 9030, DOI 10.17487/RFC9030, May 2021, <https://www.rfc-editor.org/info/rfc9030>.
[RFC9030]「IEEE 802.15.4（6tisch）のタイムスロットチャネルホッピングモード（6Tisch）」、RFC 9030、DOI 10.17487 / RFC9030、<https：//のタイムスロットチャネルホッピングモードでのIPv6のアーキテクチャー。www.rfc-editor.org/info/rfc9030>。
Acknowledgments
謝辞
Thomas Watteyne provided extensive editorial comments on the document. Carles Gomez Montenegro generated a detailed review of the document at Working Group Last Call. Tim Evens provided a number of useful editorial suggestions.
Thomas Watteyneは文書上で広範な編集コメントを提供しました。Carles Gomez Montenegroは、ワーキンググループの最後の呼び出しで文書の詳細なレビューを生み出しました。Tim Evensは、いくつかの便利な編集上の提案を提供しました。
Authors' Addresses
著者の住所
Diego Dujovne (editor) Universidad Diego Portales Escuela de Informática y Telecomunicaciones Av. Ejército 441 Santiago Región Metropolitana Chile
Diego Dujovne（編集者）Universidad Diego Portales Escuela deInformáticay Telecomunicaciones AV。Ejército441 SantiagoRepiónMetropolitanaチリ
Phone: +56 (2) 676-8121
Email: diego.dujovne@mail.udp.cl
Michael Richardson Sandelman Software Works
Michael Richardson Sandelman Software Works.
Email: mcr+ietf@sandelman.ca