[要約] RFC 8930は、マルチホップIPv6ネットワーク上で6LoWPANフラグメントを転送する方法に関する文書です。この文書の目的は、効率的なデータ転送を実現するためのプロトコルと手順を定義することにあります。利用場面としては、低電力で広範囲なセンサーネットワークやスマートデバイス間の通信が挙げられます。
Internet Engineering Task Force (IETF) T. Watteyne, Ed.
Request for Comments: 8930 Analog Devices
Category: Standards Track P. Thubert, Ed.
ISSN: 2070-1721 Cisco Systems
C. Bormann
Universität Bremen TZI
November 2020
On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network
マルチホップIPv6ネットワーク上で6lowpanフラグメントを転送する
Abstract
概要
This document provides generic rules to enable the forwarding of an IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) fragment over a route-over network. Forwarding fragments can improve both end-to-end latency and reliability as well as reduce the buffer requirements in intermediate nodes; it may be implemented using RFC 4944 and Virtual Reassembly Buffers (VRBs).
この文書は、経路上のネットワーク上で低電力無線パーソナルエリアネットワーク（6LOWPAN）フラグメントを介したIPv6の転送を可能にするための一般的な規則を提供します。転送フラグメントは、エンドツーエンドの待ち時間と信頼性の両方を改善し、中間ノードのバッファ要件を減らすことができます。RFC 4944と仮想再構成バッファ（VRBS）を使用して実装できます。
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/rfc8930.
この文書の現在のステータス、エラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8930で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 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
2. Terminology
2.1. Requirements Language
2.2. Background
2.3. New Terms
3. Overview of 6LoWPAN Fragmentation
4. Limitations of Per-Hop Fragmentation and Reassembly
4.1. Latency
4.2. Memory Management and Reliability
5. Forwarding Fragments
6. Virtual Reassembly Buffer (VRB) Implementation
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Authors' Addresses
The original 6LoWPAN fragmentation is defined in [RFC4944] for use over a single Layer 3 hop, though multiple Layer 2 hops in a mesh-under network is also possible, and was not modified by the update in [RFC6282]. 6LoWPAN operations including fragmentation depend on a link-layer security that prevents any rogue access to the network.
オリジナルの6LOWPANフラグメンテーションは、単一のレイヤ3ホップを介して使用するために[RFC4944]で定義されていますが、メッシュアンダーネットワーク内の複数のレイヤ2ホップも可能ですが、[RFC6282]の更新によって変更されませんでした。6Lowpanの断片化を含む操作は、ネットワークへの不正アクセスを妨げるリンクレイヤのセキュリティによって異なります。
In a route-over 6LoWPAN network, an IP packet is expected to be reassembled at each intermediate hop, uncompressed, pushed to Layer 3 to be routed, and then compressed and fragmented again. This document introduces an alternate approach called 6LoWPAN Fragment Forwarding (6LFF) whereby an intermediate node forwards a fragment (or the bulk thereof, MTU permitting) without reassembling if the next hop is a similar 6LoWPAN link. The routing decision is made on the first fragment of the datagram, which has the IPv6 routing information. The first fragment is forwarded immediately, and a state is stored to enable forwarding the next fragments along the same path.
経路上6LOWPANネットワークでは、IPパケットが各中間ホップで再組み立てされ、圧縮され、ルーティングされるべきレイヤ3にプッシュされ、次に圧縮されて再び断片化されると予想されます。この文書は、6lowpanフラグメント転送（6LFF）と呼ばれる代替手法を紹介し、それによって中間ノードは次のホップが類似の6LOWPANリンクである場合には、再組み立てされることなくフラグメント（またはそのバルク、MTU許可）を転送する。ルーティング決定は、IPv6ルーティング情報を持つデータグラムの最初のフラグメントで行われます。最初のフラグメントは直ちに転送され、同じパスに沿って次のフラグメントを転送できるようにします。
Done right, 6LoWPAN Fragment Forwarding techniques lead to more streamlined operations, less buffer bloat, and lower latency. But it may be wasteful when fragments are missing, leading to locked resources and low throughput, and it may be misused to the point that the end-to-end latency of one packet falls behind that of per-hop reassembly.
正しい、6LOWPANフラグメント転送技術は、より合理化された操作、より低いバッファ倍、およびより低い待ち時間につながります。しかし、フラグメントが欠けている場合は無駄になり、ロックされたリソースと低スループットをもたらし、1つのパケットのエンドツーエンドの待ち時間がホップごとの再設定の背後にあるという点に誤用されることがあります。
This specification provides a generic overview of 6LFF, discusses advantages and caveats, and introduces a particular 6LFF technique called "Virtual Reassembly Buffer" (VRB) that can be used while retaining the message formats defined in [RFC4944]. Basic recommendations such as the insertion of an inter-frame gap between fragments are provided to avoid the most typical caveats.
この仕様は6LFFの一般的な概要を提供し、利点と警告について説明し、[RFC4944]で定義されたメッセージフォーマットを保持しながら使用できる「仮想再構成バッファー」（VRB）と呼ばれる特定の6LFF技術を導入します。最も典型的な警告を回避するために、フラグメント間のフレーム間ギャップの挿入などの基本的な推奨事項が提供される。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
Past experience with fragmentation, e.g., as described in "IPv4 Reassembly Errors at High Data Rates" [RFC4963] and references therein, has shown that misassociated or lost fragments can lead to poor network behavior and, occasionally, trouble at the application layer. That experience led to the definition of the "Path MTU Discovery for IP version 6" [RFC8201] protocol that limits fragmentation over the Internet.
断片化に関する過去の経験、例えば「高データレートでのIPv4再構成エラー」（RFC4963]およびその参照は、解析された断片または失われたフラグメントが、ネットワークの動作が不十分で、時折アプリケーション層でのトラブルにつながる可能性があることを示しています。その経験は、インターネット上の断片化を制限する「IPバージョン6のPATH MTUディスカバリ」の定義をもたらしました。
"IP Fragmentation Considered Fragile" [RFC8900] discusses security threats that are linked to using IP fragmentation. The 6LoWPAN fragmentation takes place underneath the IP Layer, but some issues described there may still apply to 6LoWPAN fragments (as discussed in further details in Section 7).
「FragiaLと見なされるIPフラグメンテーション」[RFC8900]は、IPフラグメント化を使用してリンクされているセキュリティの脅威について説明します。6LOWPANフラグメンテーションはIPレイヤの下で行われますが、説明されているいくつかの問題は依然として6LOWPANフラグメントに適用される場合があります（セクション7の詳細について説明します）。
Readers are expected to be familiar with all the terms and concepts that are discussed in "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" [RFC4919] and "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944].
読者は、「低電力無線パーソナルエリアネットワーク（6LOWPANS）で「IPv6」で議論されているすべての条項と概念に精通していると予想されます。IEEE 802.15.4ネットワーク[RFC4944]。
"Multiprotocol Label Switching Architecture" [RFC3031] states that with MPLS,
「マルチプロトコルラベルスイッチングアーキテクチャ」[RFC3031]は、MPLSで
| packets are "labeled" before they are forwarded. At subsequent
| hops, there is no further analysis of the packet's network layer
| header. Rather, the label is used as an index into a table which
| specifies the next hop, and a new label.
The MPLS technique is leveraged in the present specification to forward fragments that actually do not have a network-layer header, since the fragmentation occurs below IP.
MPLS技術は、断片化がIPを下回るので、実際にはネットワーク層ヘッダを持たないフラグメントを転送するために、本明細書で活用されています。
This specification uses the following terms:
この仕様は以下の用語を使用します。
6LoWPAN Fragment Forwarding Endpoints: The 6LFF endpoints are the first and last nodes in an unbroken string of 6LFF nodes. They are also the only points where the fragmentation and reassembly operations take place.
6lowpanフラグメント転送エンドポイント：6LFFエンドポイントは、6LFFノードの解除されていない文字列の最初のノードです。それらはまた、断片化と再構成の操作が行われる唯一の点です。
Compressed Form: This specification uses the generic term "compressed form" to refer to the format of a datagram after the action of [RFC6282] and possibly [RFC8138] for Routing Protocol for Low-Power and Lossy Network (RPL) [RFC6550] artifacts.
圧縮形式：この仕様では、この仕様では、[RFC6282]の動作後のデータグラムの形式を参照して、[RFC6282]の動作（RFC6282]の動作（RFC8138]、[RPC6550]アーティファクトを参照しています。。
Datagram_Size: The size of the datagram in its compressed form before it is fragmented.
Datagram_Size：断片化される前の圧縮形式のデータグラムのサイズ。
Datagram_Tag: An identifier of a datagram that is locally unique to the Layer 2 sender. Associated with the link-layer address of the sender, this becomes a globally unique identifier for the datagram within the duration of its transmission.
Datagram_tag：レイヤ2送信者にローカルに固有のデータグラムの識別子。送信者のリンク層アドレスに関連付けられているため、これはその送信期間内のデータグラムに対するグローバルに一意の識別子になります。
Fragment_Offset: The offset of a fragment of a datagram in its compressed form.
fragment_offset：その圧縮形式のデータグラムのフラグメントのオフセット。
Figure 1 illustrates 6LoWPAN fragmentation. We assume node A forwards a packet to node B, possibly as part of a multi-hop route between 6LoWPAN Fragment Forwarding endpoints, which may be neither A nor B, though 6LoWPAN may compress the IP header better when they are both the 6LFF and the 6LoWPAN compression endpoints.
図1は6LOWPANフラグメンテーションを示す。ノードAは、6LOWPANフラグメント転送エンドポイント間のマルチホップルートの一部としてパケットをノードBに転送すると仮定します。6lowpan圧縮エンドポイント。
+---+ +---+
... ---| A |-------------------->| B |--- ...
+---+ +---+
# (frag. 5)
123456789 123456789
+---------+ +---------+
| # ###| |### # |
+---------+ +---------+
outgoing incoming
fragmentation reassembly
buffer buffer
Figure 1: Fragmentation at Node A, and Reassembly at Node B
図1：ノードAの断片化、およびノードBでの再組み立て
Typically, node A starts with an uncompressed packet and compacts the IPv6 packet using the header compression mechanism defined in [RFC6282]. If the resulting 6LoWPAN packet does not fit into a single link-layer frame, node A's 6LoWPAN sub-layer cuts it into multiple 6LoWPAN fragments, which it transmits as separate link-layer frames to node B. Node B's 6LoWPAN sub-layer reassembles these fragments, inflates the compressed header fields back to the original IPv6 header, and hands over the full IPv6 packet to its IPv6 layer.
通常、ノードAは非圧縮パケットで始まり、[RFC6282]で定義されているヘッダー圧縮メカニズムを使用してIPv6パケットをコンパクト化します。結果として得られる6LOWPANパケットが単一のリンク層フレームに収まらない場合、ノードAの6LOWPANサブレイヤはそれを複数の6LOWPANフラグメントに切り取り、それはそれがノードBに別々のリンクレイヤフレームとして送信される。ノードBの6LOWPANサブレイヤはこれらを再構築するフラグメントは、圧縮ヘッダフィールドを元のIPv6ヘッダに戻し、完全なIPv6パケットをIPv6レイヤーに渡します。
In Figure 1, a packet forwarded by node A to node B is cut into nine fragments, numbered 1 to 9 as follows:
図1では、ノードAからノードBによって転送されたパケットを、次のように1から9の番号が付けられた9つのフラグメントに切り離されます。
* Each fragment is represented by the '#' symbol.
* 各フラグメントは '＃'のシンボルによって表されます。
* Node A has sent fragments 1, 2, 3, 5, and 6 to node B.
* ノードAは、フラグメント1,2,3,5、および6をノードBに送信しました。
* Node B has received fragments 1, 2, 3, and 6 from node A.
* ノードBは、ノードAからフラグメント1,2,3、および6を受信している。
* Fragment 5 is still being transmitted at the link layer from node A to node B.
* フラグメント5はまだノードAからノードBへリンク層で送信されている。
The reassembly buffer for 6LoWPAN is indexed in node B by:
6lowpanの再構成バッファはノードBでインデックスされています。
* a unique identifier of node A (e.g., node A's link-layer address).
* ノードAの一意の識別子（例えば、ノードAのリンク層アドレス）。
* the Datagram_Tag chosen by node A for this fragmented datagram.
* この断片化されたデータグラムのノードAによって選択されたデータグラムτ。
Because it may be hard for node B to correlate all possible link-layer addresses that node A may use (e.g., short versus long addresses), node A must use the same link-layer address to send all the fragments of the same datagram to node B.
ノードBが使用可能なすべてのリンク層アドレスを対応付けることが困難である可能性があるため、ノードAが使用できるすべての可能なリンク層アドレス（例えば、長いアドレス）が使用できるようになる可能性があるため、ノードAは同じリンクレイヤアドレスを使用して同じデータグラムのすべてのフラグメントを送信する必要があります。ノードB
Conceptually, the reassembly buffer in node B contains:
概念的には、ノードBの再組み立てバッファには以下が含まれます。
* a Datagram_Tag as received in the incoming fragments, associated with the interface and the link-layer address of node A for which the received Datagram_Tag is unique,
* 受信されたデータグラムτAgが一意であるノードAのインタフェースとリンク層アドレスに関連付けられている着信フラグメントで受信されたデータグラムτAG。
* the actual packet data from the fragments received so far, in a form that makes it possible to detect when the whole packet has been received and can be processed or forwarded,
* これまでに受信されたフラグメントからの実際のパケットデータは、パケット全体が受信されて処理または転送されることができるようにすることができる形で、
* a state indicating the fragments already received,
* すでに受信したフラグメントを示す状態
* a Datagram_Size, and
* Datagram_size、および
* a timer that allows discarding a partially reassembled packet after some timeout.
* タイムアウト後に部分的に再組み立てパケットを破棄することを可能にするタイマー。
A fragmentation header is added to each fragment; it indicates what portion of the packet that fragment corresponds to. Section 5.3 of [RFC4944] defines the format of the header for the first and subsequent fragments. All fragments are tagged with a 16-bit "Datagram_Tag", used to identify which packet each fragment belongs to. Each datagram can be uniquely identified by the sender link-layer addresses of the frame that carries it and the Datagram_Tag that the sender allocated for this datagram. [RFC4944] also mandates that the first fragment is sent first and with a particular format that is different than that of the next fragments. Each fragment except for the first one can be identified within its datagram by the datagram-offset.
各フラグメントにフラグメンテーションヘッダが追加されます。フラグメントが対応するパケットの部分を示します。[RFC4944]のセクション5.3は、最初のフラグメントとそれに続くフラグメントのヘッダーのフォーマットを定義します。すべてのフラグメントは、各フラグメントがどのパケットに属するかを識別するために使用される16ビットの "datagram_tag"でタグ付けされています。各データグラムは、それを搬送するフレームの送信者リンク層アドレスとこのデータグラムに割り当てられたデータグラムτによって一意に識別できます。[RFC4944]最初のフラグメントが最初に送信され、次のフラグメントのそれとは異なる特定のフォーマットで送信されるように義務付けられています。最初のもの以外の各フラグメントは、データグラムオフセットによってそのデータグラム内で識別できます。
Node B's typical behavior, per [RFC4944], is as follows. Upon receiving a fragment from node A with a Datagram_Tag previously unseen from node A, node B allocates a buffer large enough to hold the entire packet. The length of the packet is indicated in each fragment (the Datagram_Size field), so node B can allocate the buffer even if the fragment it receives first is not the first fragment. As fragments come in, node B fills the buffer. When all fragments have been received, node B inflates the compressed header fields into an IPv6 header and hands the resulting IPv6 packet to the IPv6 layer, which performs the route lookup. This behavior typically results in per-hop fragmentation and reassembly. That is, the packet is fully reassembled, then (re-)fragmented, at every hop.
ノードBの標準的な動作（RFC4944]は次のとおりです。ノードAから以前に検出されなかったデータグラムATAGを用いてノードAからフラグメントを受信すると、ノードBはパケット全体を保持するのに十分な大きさのバッファを割り当てる。パケットの長さは各フラグメント（Datagram_Sizeフィールド）に示されているので、最初に受信したフラグメントが最初のフラグメントではなく、ノードBはバッファを割り当てることができます。フラグメントが入ってくると、ノードBはバッファを埋めます。すべてのフラグメントが受信されたとき、ノードBは圧縮されたヘッダフィールドをIPv6ヘッダに膨張させ、結果として生じるIPv6パケットをIPv6レイヤに渡し、それはルートルックアップを実行する。この現象は通常、ホップごとの断片化と再組み立てをもたらします。つまり、パケットは完全に組み立てられ、次に（再）断片化されています。
There are at least two limitations to doing per-hop fragmentation and reassembly. See [ARTICLE] for detailed simulation results on both limitations.
ホップの断片化および再組み立てを行うには少なくとも2つの制限があります。両方の制限に関する詳細なシミュレーション結果については、[記事]を参照してください。
When reassembling, a node needs to wait for all the fragments to be received before being able to re-form the IPv6 packet and possibly forwarding it to the next hop. This repeats at every hop.
再組み立てすると、ノードはIPv6パケットを再形成する前にすべてのフラグメントを受信するのを待つ必要があり、それを次のホップに転送することができます。これはすべてのホップで繰り返されます。
This may result in increased end-to-end latency compared to a case where each fragment is forwarded without per-hop reassembly.
これは、各フラグメントがホップごとの再組み立てなしに転送される場合と比較して、エンドツーエンドの待ち時間が増加する可能性がある。
Constrained nodes have limited memory. Assuming a reassembly buffer for a 6LoWPAN MTU of 1280 bytes as defined in Section 4 of [RFC4944], typical nodes only have enough memory for 1-3 reassembly buffers.
制約されたノードにはメモリが限られています。[RFC4944]のセクション4で定義されている1280バイトの6LOWPAN MTUの再構成バッファを仮定して、典型的なノードは1~3回の再構成バッファに対して十分なメモリを持っています。
To illustrate this, we use the topology from Figure 2, where nodes A, B, C, and D all send packets through node E. We further assume that node E's memory can only hold 3 reassembly buffers.
これを説明するために、ノードA、B、C、およびDはすべてノードEを介してパケットを送信する図2からトポロジを使用します。さらに、ノードEのメモリは3つの再構成バッファのみを保持できると仮定します。
+---+ +---+
... --->| A |------>| B |
+---+ +---+\
\
+---+ +---+
| E |--->| F | ...
+---+ +---+
/
/
+---+ +---+
... --->| C |------>| D |
+---+ +---+
Figure 2: Illustrating the Memory Management Issue
図2：メモリ管理の問題を説明する
When nodes A, B, and C concurrently send fragmented packets, all three reassembly buffers in node E are occupied. If, at that moment, node D also sends a fragmented packet, node E has no option but to drop one of the packets, lowering end-to-end reliability.
ノードA、B、およびCが断片化されたパケットを同時に送信すると、ノードE内の3つの再構成バッファすべてが占有されます。その瞬間に、ノードDも断片化されたパケットを送信する場合、ノードEはオプションを持たないが、パケットの1つを削除し、エンドツーエンドの信頼性を低下させる。
A 6LoWPAN Fragment Forwarding technique makes the routing decision on the first fragment, which is always the one with the IPv6 address of the destination. Upon receiving a first fragment, a forwarding node (e.g., node B in an A->B->C sequence) that does fragment forwarding MUST attempt to create a state and forward the fragment. This is an atomic operation, and if the first fragment cannot be forwarded, then the state MUST be removed.
6LOWPANフラグメント転送技術は、常にIPv6アドレスを持つ1つの最初のフラグメントでのルーティング決定を行います。フラグメント転送を行う転送ノード（例えば、a - > cシーケンス内のノードB）を受信すると、フラグメントを作成し、フラグメントを転送するようにしなければならない。これはアトミック操作であり、最初のフラグメントを転送できない場合は、状態を削除する必要があります。
Since the Datagram_Tag is uniquely associated with the source link-layer address of the fragment, the forwarding node MUST assign a new Datagram_Tag from its own namespace for the next hop and rewrite the fragment header of each fragment with that Datagram_Tag.
Datagram_tagはフラグメントのソースリンク層アドレスに一意的に関連付けられているので、転送ノードはネクストホップに対して独自の名前空間から新しいDatagram_tagを割り当て、各フラグメントのフラグメントヘッダーをそのdatagram_tagと書き換える必要があります。
When a forwarding node receives a fragment other than a first fragment, it MUST look up state based on the source link-layer address and the Datagram_Tag in the received fragment. If no such state is found, the fragment MUST be dropped; otherwise, the fragment MUST be forwarded using the information in the state found.
転送ノードが第1のフラグメント以外のフラグメントを受信すると、受信したフラグメント内のソースリンク層アドレスおよびDatagram_tagに基づいて状態を調べなければならない。そのような状態が見つからない場合は、フラグメントをドロップする必要があります。それ以外の場合は、見つかった状態の情報を使用してフラグメントを転送する必要があります。
Compared to Section 3, the conceptual reassembly buffer in node B now contains the following, assuming that node B is neither the source nor the final destination:
セクション3と比較して、ノードBの概念的な再構成バッファは、ノードBがソースでも最終宛先でもないと仮定して、次のものを含んでいます。
* a Datagram_Tag as received in the incoming fragments, associated with the interface and the link-layer address of node A for which the received Datagram_Tag is unique.
* 受信されたデータグラム_TAGが一意であるノードAのインターフェースとリンク層アドレスに関連付けられている着信フラグメントで受信されたデータグラムτAG。
* the link-layer address that node B uses as the source to forward the fragments.
* ノードBがフラグメントを転送するためにソースとして使用するリンク層アドレス。
* the interface and the link-layer address of the next-hop C that is resolved on the first fragment.
* 最初のフラグメントで解決されるネクストホップCのインターフェイスとリンク層アドレス。
* a Datagram_Tag that node B uniquely allocated for this datagram and that is used when forwarding the fragments of the datagram.
* このデータグラムにユニークに割り当てられ、データグラムのフラグメントを転送するときに使用されるデータグラムτAG。
* a buffer for the remainder of a previous fragment left to be sent.
* 前の断片の残りの部分のためのバッファは送信されました。
* a timer that allows discarding the stale 6LFF state after some timeout. The duration of the timer should be longer than that which covers the reassembly at the receiving endpoint.
* タイムアウト後に古い6LFF状態を破棄することを可能にするタイマー。タイマーの持続時間は、受信エンドポイントで再組み立てをカバーするものよりも長くなければなりません。
A node that has not received the first fragment cannot forward the next fragments. This means that if node B receives a fragment, node A was in possession of the first fragment at some point. To keep the operation simple and consistent with [RFC4944], the first fragment MUST always be sent first. When that is done, if node B receives a fragment that is not the first and for which it has no state, then node B treats it as an error and refrains from creating a state or attempting to forward. This also means that node A should perform all its possible retries on the first fragment before it attempts to send the next fragments, and that it should abort the datagram and release its state if it fails to send the first fragment.
最初のフラグメントを受信していないノードは次のフラグメントを転送できません。これは、ノードBがフラグメントを受信した場合、ノードAはある時点で最初のフラグメントを所有していたことを意味します。操作を簡単かつ整合的にするには[RFC4944]では、最初に最初に送信する必要があります。それが完了した場合、ノードBが最初のものではなく、それが状態がないフラグメントを受信した場合、ノードBはそれをエラーとして扱い、状態を作成することを控えるか、または転送を試みることを控える。これはまた、ノードAが次のフラグメントを送信しようとする前に最初のフラグメント上のすべての可能な再試行をすべて実行し、そのデータグラムを中止し、最初のフラグメントを送信できない場合はその状態を解放する必要があることを意味します。
Fragment forwarding obviates some of the benefits of the 6LoWPAN header compression [RFC6282] in intermediate hops. In return, the memory used to store the packet is distributed along the path, which limits the buffer-bloat effect. Multiple fragments may progress simultaneously along the network as long as they do not interfere. An associated caveat is that on a half-duplex radio, if node A sends the next fragment at the same time as node B forwards the previous fragment to node C down the path, then node B will miss it. If node C forwards the previous fragment to node D at the same time and on the same frequency as node A sends the next fragment to node B, this may result in a hidden terminal problem. In that case, the transmission from node C interferes at node B with that from node A, unbeknownst to node A. Consecutive fragments of a same datagram MUST be separated with an inter-frame gap that allows one fragment to progress beyond the next hop and beyond the interference domain before the next shows up. This can be achieved by interleaving packets or fragments sent via different next-hop routers.
フラグメント転送は、中間ホップの6LOWPANヘッダ圧縮[RFC6282]の利点のいくつかを排除します。戻ると、パケットを格納するために使用されるメモリはパスに沿って分散され、これはバッファぼけ効果を制限します。干渉しない限り、複数のフラグメントがネットワークに沿って同時に進行する可能性があります。関連付けられている警告は、ノードBと同時に次のフラグメントを送信した場合、ノードBがパスの下のノードCに転送された場合、ノードBがそれを欠場することである。ノードCが同時に前のフラグメントをノードDに転送し、ノードAと同じ周波数でノードBに次のフラグメントを送信すると、これは隠れた端末の問題をもたらす可能性がある。その場合、ノードCからの送信はノードAからノードAと干渉し、ノードAからノードAに干渉する。同じデータグラムの連続フラグメントは、1つのフラグメントを超えて次のホップを超えて進行することを可能にするフレーム間ギャップと分離されなければならない。次の干渉ドメインを超えて表示されます。これは、異なるネクストホップルータを介して送信されたパケットまたはフラグメントをインターリーブすることによって達成することができる。
The VRB [LWIG-VRB] is a particular incarnation of a 6LFF that can be implemented without a change to [RFC4944].
VRB [LWIG-VRB]は、[RFC4944]に変更することなく実装できる6LFFの特定の化身です。
VRB overcomes the limitations listed in Section 4. Nodes do not wait for the last fragment before forwarding, reducing end-to-end latency. Similarly, the memory footprint of VRB is just the VRB table, reducing the packet drop probability significantly.
VRBはセクション4にリストされている制限を克服します。ノードは、転送前の最後のフラグメントを待っていないため、エンドツーエンドの待ち時間が短縮されます。同様に、VRBのメモリフットプリントはVRBテーブルだけであり、パケットドロップ確率を大幅に削減します。
However, there are other caveats:
しかし、他の警告があります。
Non-zero Packet Drop Probability: The abstract data in a VRB table entry contains at a minimum the link-layer address of the predecessor and the successor, the Datagram_Tag used by the predecessor, and the local Datagram_Tag that this node will swap with it. The VRB may need to store a few octets from the last fragment that may not have fit within MTU and that will be prepended to the next fragment. This yields a small footprint that is 2 orders of magnitude smaller, compared to needing a 1280-byte reassembly buffer for each packet. Yet, the size of the VRB table necessarily remains finite. In the extreme case where a node is required to concurrently forward more packets than it has entries in its VRB table, packets are dropped.
ゼロ以外のパケットドロップ確率：VRBテーブルエントリの抽象データには、前身と後継者のリンクレイヤアドレス、前身で使用されているデータグラム名、およびこのノードがそれをスワップするローカルDatagram_tagが含まれています。VRBは、MTU内に適合していない可能性がある最後のフラグメントから数オクテットを保存する必要があり、それは次のフラグメントに先行されます。これにより、各パケットごとに1280バイトの再構成バッファを必要とすると比較して、2桁小さい小さな設置面積が得られます。それでも、VRBテーブルのサイズは必ず有限のままである。ノードがそのVRBテーブルにエントリを持つよりも多くのパケットを同時に転送するために必要な極端な場合、パケットはドロップされます。
No Fragment Recovery: There is no mechanism in VRB for the node that reassembles a packet to request a single missing fragment. Dropping a fragment requires the whole packet to be resent. This causes unnecessary traffic, as fragments are forwarded even when the destination node can never construct the original IPv6 packet.
フラグメントリカバリなし：パケットを再構築して単一の不足しているフラグメントをリクエストするノードのためのMecurityはありません。フラグメントを削除するには、パケット全体が再送される必要があります。宛先ノードが元のIPv6パケットを構築できない場合でも、フラグメントが転送されるため、これにより不要なトラフィックが発生します。
No Per-Fragment Routing: All subsequent fragments follow the same sequence of hops from the source to the destination node as the first fragment, because the IP header is required in order to route the fragment and is only present in the first fragment. A side effect is that the first fragment must always be forwarded first.
フラグメントごとのルーティング：その後のすべてのフラグメントは、フラグメントをルーティングするために必要とされ、最初のフラグメントにのみ存在するためにIPヘッダーが必要とされるため、最初のすべてのフラグメントは、最初のフラグメントとして、Source Nodeから宛先ノードへのホップのシーケンスに続いています。副作用は、最初のフラグメントが最初に転送されなければならないことです。
The severity and occurrence of these caveats depend on the link layer used. Whether they are acceptable depends entirely on the requirements the application places on the network.
これらの警告の重大度と発生は、使用されるリンク層によって異なります。それらが許容できるかどうかは、アプリケーションがネットワーク上の適切な要件に完全に依存します。
If the caveats are present and not acceptable for the application, alternative specifications may define new protocols to overcome them. One example is [RFC8931], which specifies a 6LFF technique that allows the end-to-end fragment recovery between the 6LFF endpoints.
警告が存在し、アプリケーションに受け入れられない場合、代替仕様はそれらを克服するための新しいプロトコルを定義することができる。1つの例は[RFC8931]で、6LFFエンドポイント間のエンドツーエンドのフラグメントの回復を可能にする6LFFテクニックを指定します。
An attacker can perform a Denial-of-Service (DoS) attack on a node implementing VRB by generating a large number of bogus "fragment 1" fragments without sending subsequent fragments. This causes the VRB table to fill up. Note that the VRB does not need to remember the full datagram as received so far but only possibly a few octets from the last fragment that could not fit in it. It is expected that an implementation protects itself to keep the number of VRBs within capacity, and that old VRBs are protected by a timer of a reasonable duration for the technology and destroyed upon timeout.
攻撃者は、後続のフラグメントを送信することなく、多数のBogus「フラグメント1」フラグメントを生成することによって、VRBを実装するノードでサービス拒否（DOS）攻撃を実行することができる。これにより、VRBテーブルがいっぱいになります。VRBはこれまでに受信された全データグラムを覚えている必要はありませんが、それに合わない最後のフラグメントから数オクテットしかない。実装は、実装が容量内のVRBの数を保持するために自分自身を保護し、その古いVRBSはテクノロジの合理的な期間のタイマーによって保護され、タイムアウト時に破壊されます。
Secure joining and the link-layer security that it sets up protects against those attacks from network outsiders.
セキュア参加とリンクレイヤセキュリティが、ネットワークの部外者からのそれらの攻撃に対して保護します。
"IP Fragmentation Considered Fragile" [RFC8900] discusses security threats and other caveats that are linked to using IP fragmentation. The 6LoWPAN fragmentation takes place underneath the IP Layer, but some issues described there may still apply to 6LoWPAN fragments.
「IPフラグメンテーションと見なされる」[RFC8900]は、IPフラグメンテーションを使用してリンクされているセキュリティの脅威やその他の注意事項について説明します。6LOWPANフラグメンテーションはIPレイヤの下で行われますが、そこに記載されているいくつかの問題は依然として6LOWPANフラグメントに適用される場合があります。
* Overlapping fragment attacks are possible with 6LoWPAN fragments, but there is no known firewall operation that would work on 6LoWPAN fragments at the time of this writing, so the exposure is limited. An implementation of a firewall SHOULD NOT forward fragments but instead should recompose the IP packet, check it in the uncompressed form, and then forward it again as fragments if necessary. Overlapping fragments are acceptable as long as they contain the same payload. The firewall MUST drop the whole packet if overlapping fragments are encountered that result in different data at the same offset.
* 6LOWPANフラグメントで重複するフラグメント攻撃が可能ですが、この書き込み時に6LOWPANフラグメントで動作する既知のファイアウォール操作はありませんので、露出は制限されています。ファイアウォールの実装はフラグメントを転送してはいけませんが、代わりにIPパケットを再構成し、非圧縮形式で確認してから、必要に応じてフラグメントとして再度転送してください。同じペイロードが含まれている限り、重複フラグメントは許容されます。同じオフセットで異なるデータをもたらす重複フラグメントが発生した場合、ファイアウォールはパケット全体をドロップする必要があります。
* Resource-exhaustion attacks are certainly possible and a sensitive issue in a constrained network. An attacker can perform a DoS attack on a node implementing VRB by generating a large number of bogus first fragments without sending subsequent fragments. This causes the VRB table to fill up. When hop-by-hop reassembly is used, the same attack can be more damaging if the node allocates a full Datagram_Size for each bogus first fragment. With the VRB, the attack can be performed remotely on all nodes along a path, but each node suffers a lesser hit. This is because the VRB does not need to remember the full datagram as received so far but only possibly a few octets from the last fragment that could not fit in it. An implementation MUST protect itself to keep the number of VRBs within capacity and to ensure that old VRBs are protected by a timer of a reasonable duration for the technology and destroyed upon timeout.
* リソース - 枯渇攻撃は確かに可能であり、制約されたネットワークにおける敏感な問題です。攻撃者は、後続のフラグメントを送信せずに多数のBogus第1のフラグメントを生成することによって、VRBを実装するノードを実装することによってDOS攻撃を実行することができる。これにより、VRBテーブルがいっぱいになります。ホップバイホップの再構成が使用されるとき、ノードが各Bogus最初のフラグメントに対してフルデータグラムを割り当てる場合、同じ攻撃が損傷する可能性があります。VRBを使用すると、攻撃はパスに沿ってすべてのノードでリモートで実行できますが、各ノードはより少ないヒットを受ける。これは、VRBがこれまでに受信された完全なデータグラムを覚えている必要がないが、それに合わなかった最後のフラグメントから数オクテットのみがおそらく数オクテットであるためです。実装は、能力内のVRBの数を維持し、古いVRBがテクノロジの合理的な期間のタイマーによって保護され、タイムアウト時に破壊されたことを確実に保護しなければなりません。
* Attacks based on predictable fragment identification values are also possible but can be avoided. The Datagram_Tag SHOULD be assigned pseudorandomly in order to reduce the risk of such attacks. A larger size of the Datagram_Tag makes the guessing more difficult and reduces the chances of an accidental reuse while the original packet is still in flight, at the expense of more space in each frame. Nonetheless, some level of risk remains because an attacker that is able to authenticate to and send traffic on the network can guess a valid Datagram_Tag value, since there are only a limited number of possible values.
* 予測可能なフラグメント識別値に基づく攻撃も可能であるが回避することができる。そのような攻撃の危険性を減らすために、Datagram_tagに疑似乱性を割り当てるべきです。より大きなサイズのDatagram_tagは、推測をより困難にし、元のパケットが依然としてフライト内にある間、各フレーム内のスペースを犠牲にしている間に偶然の再利用の可能性を減らす。それにもかかわらず、ネットワーク上のトラフィックを認証して送信することができる攻撃者が有効なDatagram_tag値を推測できるため、いくつかのリスクが残っています。
* Evasion of Network Intrusion Detection Systems (NIDSs) leverages ambiguity in the reassembly of the fragment. This attack makes little sense in the context of this specification since the fragmentation happens within the Low-Power and Lossy Network (LLN), meaning that the intruder should already be inside to perform the attack. NIDS systems would probably not be installed within the LLN either but rather at a bottleneck at the exterior edge of the network.
* ネットワーク侵入検知システムの回避（NIDS）は、フラグメントの再組み立てにおけるあいまいさを利用しています。この攻撃は、断片化が低電力および非損失のあるネットワーク（LLN）内で発生しているため、この仕様の文脈ではほとんど意味がありません。つまり、侵入者が攻撃を実行するために既に内側にあるべきです。NIDSシステムは、おそらくLLN内にはLLN内にインストールされません。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[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>。
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007, <https://www.rfc-editor.org/info/rfc4919>.
[RFC4919] Kushalnagar、N.、Montenegro、G.、Schumacher、C. Schumacher、「低電力無線パーソナルエリアネットワーク（6lowpans）：概要、仮定、問題ステートメント、および目標、RFC 4919、DOI 10.17487 / RFC49192007年8月、<https：//www.rfc-editor.org/info/rfc4919>。
[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, <https://www.rfc-editor.org/info/rfc4944>.
[RFC4944]モンテネグロ、G.、Kushalnagar、N.、Hui、J.、およびD.Culler、「IEEE 802.15.4ネットワーク上のIPv6パケットの送信」、RFC 4944、DOI 10.17487 / RFC4944、2007年9月、<https：//www.rfc-editor.org/info/rfc4944>。
[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>。
[ARTICLE] Tanaka, Y., Minet, P., and T. Watteyne, "6LoWPAN Fragment Forwarding", IEEE Communications Standards Magazine, Vol. 3, Issue 1, pp. 35-39, DOI 10.1109/MCOMSTD.2019.1800029, March 2019, <https://ieeexplore.ieee.org/abstract/document/8771317>.
[論文]田中、Y.、Minet、P.、およびT.Watteyne、「6lowpan Fragment Forwarding」、IEEE Communications Standards Magazine、Vol。3、問題1、PP。35-39、DOI 10.1109 / MCOMSTD.209.1800029、2019年3月、<https：//ieeexplore.ieee.org/abstract/document/8771317>。
[LWIG-VRB] Bormann, C. and T. Watteyne, "Virtual reassembly buffers in 6LoWPAN", Work in Progress, Internet-Draft, draft-ietf-lwig-6lowpan-virtual-reassembly-02, 9 March 2020, <https://tools.ietf.org/html/draft-ietf-lwig-6lowpan-virtual-reassembly-02>.
[LWIG-VRB] Bormann、C.およびT.Watteyne、「6lowpanでの仮想再構成バッファ」、進行中の作業、インターネットドラフト、ドラフト - LWIG-6LOWPAN-Virtual-Reassembly-02,202月9日、<HTTPS：//tools.ietf.org/html/draft-ietf-lwig-6lowpan-virtual-reassembly-02>。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031]ローゼン、E.、Viswanathan、A.およびR.Callon、 "Multiprotocol Label Switche Architecture"、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<https：//www.rfc-editor.org/info/ RFC3031>。
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963, July 2007, <https://www.rfc-editor.org/info/rfc4963>.
[RFC4963] Heffner、J.、Mathis、M.およびB.Chandler、2007年7月、<https：///www.rfc-編集者。ORG / INFO / RFC4963>。
[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月、2011年9月、2011年9月、<https：//www.rfc-editor.org/info/rfc6282、<https：//www.rfc-editor.org/info/rfc6282>。
[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>。
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, April 2017, <https://www.rfc-editor.org/info/rfc8138>.
[RFC8138] Thubert、P.、ED。、Bormann、C、Toutain、L.、R. Cragie、R.Cragie、「低電力無線パーソナルエリアネットワーク（6LOWPAN）ルーティングヘッダ」、RFC 8138、DOI 10.17487 / RFC8138、2017年4月、<https://www.rfc-editor.org/info/rfc8138>。
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.
[RFC8201] McCann、J.、Theer、S.、Mogul、J.、およびR. Hinden、Ed。、「IPバージョン6のためのパスMTUディスカバリー」、STD 87、RFC 8201、DOI 10.17487 / RFC8201、2017年7月、<https://www.rfc-editor.org/info/rfc8201>。
[RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., and F. Gont, "IP Fragmentation Considered Fragile", BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, <https://www.rfc-editor.org/info/rfc8900>.
[RFC8900]ボニャ、R.、Baker、F.、Huston、G.、Hinden、R.、Troan、O.、F.ゴント、「IPフラグメンテーションと見なす」、BCP 230、RFC 8900、DOI 10.17487 / RFC8900、2020年9月、<https://www.rfc-editor.org/info/rfc8900>。
[RFC8931] Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery", RFC 8931, DOI 10.17487/RFC8931, November 2020, <https://www.rfc-editor.org/info/rfc8931>.
[RFC8931] Thubert、P.、ED。、「低消費電力無線パーソナルエリアネットワーク（6lowpan）選択フラグメントリカバリの「IPv6」、RFC 8931、DOI 10.17487 / RFC8931、2020年11月、<https：///www.rfc-編集者.ORG / INFO / RFC8931>。
Acknowledgments
謝辞
The authors would like to thank Carles Gomez Montenegro, Yasuyuki Tanaka, Ines Robles, and Dave Thaler for their in-depth review of this document and suggestions for improvement. Many thanks to Georgios Papadopoulos and Dominique Barthel for their contributions during the WG activities. And many thanks as well to Roman Danyliw, Barry Leiba, Murray Kucherawy, Derrell Piper, Sarah Banks, Joerg Ott, Francesca Palombini, Mirja Kühlewind, Éric Vyncke, and especially Benjamin Kaduk for their constructive reviews through the IETF last call and IESG process.
著者らは、この文書の詳細なレビューと改善のために、田中康之、田中康之、Ines Robles、そしてDave Thalerに感謝します。WG活動中の貢献のためにGeorgios PapadopoulosとDominique Barthelに感謝します。そして、Roman Danyliw、Barry Leiba、Murray Kucherawy、Derrell Piper、Sarah Banks、Joerg Ott、Francesca Palombini、MirjaKühlewind、エリコのヴィンクケ、特にBenjamin Kaduk、特にIETFの最後の呼び出しとIESGプロセスを介して建設的なレビュー。
Authors' Addresses
著者の住所
Thomas Watteyne (editor) Analog Devices 32990 Alvarado-Niles Road, Suite 910 Union City, CA 94587 United States of America
Thomas Watteyne（編集）Analog Devices 32990 Alvarado-Niles Road、Suite 910 Union City、CA 94587アメリカ
Email: thomas.watteyne@analog.com
Pascal Thubert (editor) Cisco Systems, Inc Building D 45 Allee des Ormes - BP1200 06254 Mougins - Sophia Antipolis France
Pascal Thubert（編集）Cisco Systems、IncビルディングD 45 Allee Des Ormes - BP1200 06254 Mougins - Sophia Antipolis France
Phone: +33 497 23 26 34
Email: pthubert@cisco.com
Carsten Bormann Universität Bremen TZI Postfach 330440 D-28359 Bremen Germany
Bremen Tzi Postfach 330440 D-28359ブレーメンドイツ
Phone: +49-421-218-63921
Email: cabo@tzi.org