RFC 8066 - IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8066
タイトル : RFC 8066 - IPv6 over Low-Power Wireless Personal Area Network（6LoWPAN）ESCディスパッチコードポイントとガイドライン
翻訳編集 : 自動生成

[要約] RFC 8066は、6LoWPANにおけるIPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelinesに関するガイドラインです。このRFCの目的は、6LoWPANネットワークでのIPv6通信におけるESCディスパッチコードポイントの使用とガイドラインを提供することです。

Internet Engineering Task Force (IETF)                    S. Chakrabarti
Request for Comments: 8066
Updates: 4944, 6282                                        G. Montenegro
Category: Standards Track                                      Microsoft
ISSN: 2070-1721                                                 R. Droms

J. Woodyatt Google February 2017

J. Woodyatt Google 2017年2月

IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines

IPv6 over Low-Power Wireless Personal Area Network（6LoWPAN）ESCディスパッチコードポイントとガイドライン

Abstract

概要

RFC 4944 defines the ESC dispatch type to allow additional dispatch octets in the 6LoWPAN header. The value of the ESC dispatch type was updated by RFC 6282; however, its usage was not defined in either RFC 6282 or RFC 4944. This document updates RFC 4944 and RFC 6282 by defining the ESC extension octet code points and listing registration entries for known use cases at the time of writing of this document.

RFC 4944は、ESCディスパッチタイプを定義して、6LoWPANヘッダーで追加のディスパッチオクテットを許可しています。 ESCディスパッチタイプの値はRFC 6282によって更新されました。ただし、その使用法はRFC 6282またはRFC 4944のいずれにも定義されていません。このドキュメントは、このドキュメントの執筆時点でESC拡張オクテットコードポイントを定義し、既知のユースケースの登録エントリをリストすることにより、RFC 4944およびRFC 6282を更新します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8066.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8066で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Usage of ESC Dispatch Octets  . . . . . . . . . . . . . . . .   3
     3.1.  Interaction with Other RFC 4944 Implementations . . . . .   4
     3.2.  ESC Extension Octets Typical Sequence . . . . . . . . . .   5
     3.3.  ITU-T G.9903 ESC Type Usage . . . . . . . . . . . . . . .   6
     3.4.  NALP and ESC Dispatch Types . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1. Introduction

1. はじめに

Section 5.1 of [RFC4944] defines the dispatch header and types. The ESC type is defined to use additional dispatch octets in the 6LoWPAN header. RFC 6282 modifies the value of the ESC dispatch type and that value is recorded in IANA registry [IANA-6LoWPAN]. However, the octets and usage following the ESC dispatch type are not defined in either [RFC4944] or [RFC6282]. In recent years with 6LoWPAN deployments, implementations and standards organizations have started using the ESC extension octets. This highlights the need for an updated IANA registration policy.

[RFC4944]のセクション5.1は、ディスパッチヘッダーとタイプを定義しています。 ESCタイプは、6LoWPANヘッダーで追加のディスパッチオクテットを使用するように定義されています。 RFC 6282はESCディスパッチタイプの値を変更し、その値はIANAレジストリ[IANA-6LoWPAN]に記録されます。ただし、ESCディスパッチタイプに続くオクテットと使用法は、[RFC4944]でも[RFC6282]でも定義されていません。近年6LoWPANの導入により、実装および標準化組織はESC拡張オクテットの使用を開始しました。これは、更新されたIANA登録ポリシーの必要性を強調しています。

This document defines the new "ESC Extension Types" registry and the ESC extension octets for future applications. In addition, this document records the ITU-T specification for ESC dispatch octet code points as an existing known usage.

このドキュメントは、新しい「ESC拡張タイプ」レジストリと将来のアプリケーションのためのESC拡張オクテットを定義します。さらに、このドキュメントでは、ESCディスパッチオクテットコードポイントのITU-T仕様を既存の既知の使用法として記録しています。

2. Terminology

2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

3. Usage of ESC Dispatch Octets

3. ESCディスパッチオクテットの使用

RFC 4944 [RFC4944] first introduces this "ESC" dispatch header type for extension of dispatch octets. RFC 6282 [RFC6282] subsequently modified its value to [01 000000].

RFC 4944 [RFC4944]では、ディスパッチオクテットの拡張のために、この「ESC」ディスパッチヘッダータイプを最初に導入しています。 RFC 6282 [RFC6282]はその後、その値を[01 000000]に変更しました。

This document specifies that the first octet following the ESC dispatch type be used for extension type (extended dispatch values). Subsequent octets are left unstructured for the specific use of the extension type:

このドキュメントでは、ESCディスパッチタイプに続く最初のオクテットを拡張タイプ（拡張ディスパッチ値）に使用することを指定しています。後続のオクテットは、拡張タイプの特定の使用のために構造化されません。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     ESC       | ESC EXT Type  | Extended Dispatch Payload
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Frame Format with ESC Dispatch Type

図1：ESCディスパッチタイプのフレームフォーマット

ESC: The left-most octet is the ESC dispatch type containing '01000000'.

ESC：左端のオクテットは、「01000000」を含むESCディスパッチタイプです。

ESC Extension Type (EET): It is the first octet following the ESC dispatch type. Extension type defines the payload for the additional dispatch octets. The values are from 0 to 255. Values 0 and 255 are reserved for future use. The remaining values from 1 to 254 are assigned by IANA. The EET values are similar to dispatch values in the 6LoWPAN header except they are preceded by the ESC dispatch type. Thus, ESC extension types and dispatch values are using orthogonal code spaces. Though not desirable, multiple ESC dispatch types MAY appear in a 6LoWPAN header. Section 3.1 describes how to handle an unknown ESC dispatch type.

ESC拡張タイプ（EET）：ESCディスパッチタイプに続く最初のオクテットです。拡張タイプは、追加のディスパッチオクテットのペイロードを定義します。値は0〜255です。値0および255は将来の使用のために予約されています。 1から254までの残りの値はIANAによって割り当てられます。 EET値は、ESCディスパッチタイプが前にあることを除いて、6LoWPANヘッダーのディスパッチ値に似ています。したがって、ESC拡張タイプとディスパッチ値は直交コード空間を使用しています。望ましくありませんが、複数のESCディスパッチタイプが6LoWPANヘッダーに表示される場合があります。セクション3.1では、不明なESCディスパッチタイプの処理方法について説明します。

Extended Dispatch Payload (EDP): This part of the frame format must be defined by the corresponding extension type. A specification is required to define the usage of each extension type and its corresponding Extension Payload. For the sake of interoperability, specifications of extension octets MUST NOT redefine the existing ESC Extension Type codes.

拡張ディスパッチペイロード（EDP）：フレームフォーマットのこの部分は、対応する拡張タイプによって定義する必要があります。各拡張タイプとそれに対応する拡張ペイロードの使用法を定義するには、仕様が必要です。相互運用性のために、拡張オクテットの仕様は、既存のESC拡張タイプコードを再定義してはなりません。

Section 5.1 of RFC 4944 indicates that the Extension Type field may contain additional dispatch values larger than 63, as corrected by [Err4359]. For the sake of interoperability, the new dispatch type (EET) MUST NOT modify the behavior of existing dispatch types [RFC4944].

RFC 4944のセクション5.1は、[Err4359]によって修正されたように、拡張タイプフィールドに63より大きい追加のディスパッチ値が含まれる可能性があることを示しています。相互運用性のために、新しいディスパッチタイプ（EET）は既存のディスパッチタイプの動作を変更してはなりません[RFC4944]。

3.1. Interaction with Other RFC 4944 Implementations

3.1. 他のRFC 4944実装との相互作用

It is expected that existing implementations of RFC 4944 are not capable of processing ESC extension data octets as defined in this document. However, implementers have to assume that an existing implementation that attempts to process an EET that is unknown to them will simply drop the packet or ignore the ESC dispatch octets.

RFC 4944の既存の実装では、このドキュメントで定義されているESC拡張データオクテットを処理できないことが予想されます。ただし、実装者は、不明なEETを処理しようとする既存の実装がパケットを単にドロップするか、ESCディスパッチオクテットを無視すると想定する必要があります。

If an implementation following this document, during processing of the received packet, reaches an ESC dispatch type for which it does not understand the ESC Extension Type (EET) octets, it MUST drop that packet. However, it is important to clarify that a router node SHOULD forward a 6LoWPAN packet with the EET octets as long as it does not attempt to process any unknown ESC extension octets.

このドキュメントに従う実装が、受信したパケットの処理中に、ESC拡張タイプ（EET）オクテットを理解できないESCディスパッチタイプに到達した場合、そのパケットをドロップする必要があります。ただし、不明なESC拡張オクテットの処理を試みない限り、ルーターノードはEETオクテットを含む6LoWPANパケットを転送する必要があることを明確にすることが重要です。

Multiple ESC extension octets may appear in a packet. The ESC dispatch types can appear as the first, last, or middle dispatch octets. However, a packet will get dropped by any node that does not understand the EET at the beginning of the packet. Placing an EET toward the front of the packet has a greater probability of causing the packet to be dropped than placing the same EET later in the packet. Placement of an EET later in the packet increases the chance that a legacy device will recognize and successfully process some dispatch type [RFC4944] before the EET. In this case, the legacy device will ignore the EET instead of dropping the entire packet.

複数のESC拡張オクテットがパケットに現れる場合があります。 ESCディスパッチタイプは、最初、最後、または中間のディスパッチオクテットとして表示できます。ただし、パケットは、パケットの先頭にあるEETを理解していないノードによってドロップされます。 EETをパケットの前に配置すると、同じEETをパケットの後ろに配置するよりも、パケットがドロップされる可能性が高くなります。パケットの後の方にEETを配置すると、レガシーデバイスがEETの前に特定のディスパッチタイプ[RFC4944]を認識して正常に処理する可能性が高くなります。この場合、レガシーデバイスはパケット全体をドロップする代わりにEETを無視します。

3.2. ESC Extension Octets Typical Sequence

3.2. ESC拡張オクテットの典型的なシーケンス

The sequence and order of ESC extension octets with respect to the 6LoWPAN Mesh header and LOWPAN_IPHC header are described below. When the LOWPAN_IPHC dispatch type is present, ESC dispatch types MUST appear before the LOWPAN_IPHC dispatch type in order to maintain backward compatibility with Section 3.2 of RFC 6282. The following diagrams provide examples of ESC extension octet usages:

6LoWPAN MeshヘッダーとLOWPAN_IPHCヘッダーに関するESC拡張オクテットのシーケンスと順序を以下に説明します。 LOWPAN_IPHCディスパッチタイプが存在する場合、RFC 6282のセクション3.2との下位互換性を維持するために、ESCディスパッチタイプはLOWPAN_IPHCディスパッチタイプの前に出現する必要があります。次の図は、ESC拡張オクテットの使用例を示しています。

A LoWPAN encapsulated IPv6 Header compressed packet:

LoWPANカプセル化IPv6ヘッダー圧縮パケット：

   +-------+------+--------+--------+-----------------+--------+
   |   ESC | EET  | EDP    |Dispatch| LOWPAN_IPHC hdr | Payld  |
   +-------+------+--------+--------+-----------------+--------+

A LoWPAN_IPHC Header, Mesh header and an ESC extension octet:

LoWPAN_IPHCヘッダー、メッシュヘッダー、ESC拡張オクテット：

   +-----+-----+-----+----+------+-------+---------------+------+
   |M typ| Mhdr| ESC | EET|EDP   |Disptch|LOWPAN_IPHC hdr| Payld|
   +-----+-----+-----+----+------+-------+---------------+------+

A Mesh header with ESC dispatch types:

ESCディスパッチタイプのメッシュヘッダー：

   +-------+-------+-----+-----+-------+
   | M Typ | M Hdr | ESC | EET |EDP    |
   +-------+-------+-----+-----+-------+

With Fragment header:

フラグメントヘッダー：

   +-------+-------+--------+------+-----+-----+-------+
   | M Typ | M Hdr | F Typ  | F hdr|ESC  | EET |  EDP  |
   +-------+-------+--------+------+-----+-----+-------+

ESC dispatch type as a LowPAN encapsulation:

LowPANカプセル化としてのESCディスパッチタイプ：

   +--------+--------+--------+
   | ESC    | EET    | EDP    |
   +--------+--------+--------+

Figure 2: A 6LoWPAN Packet with ESC Dispatch Types

図2：ESCディスパッチタイプを含む6LoWPANパケット

3.3. ITU-T G.9903 ESC Type Usage

3.3. ITU-T G.9903 ESCタイプの使用

The ESC dispatch type is used in [G3-PLC] to provide native mesh routing and bootstrapping functionalities. The ITU-T recommendation [G3-PLC] (see Section 9.4.2.3) defines commands that are formatted like ESC Extension Type fields. The command ID values are 0x01 to 0x1F.

ESCディスパッチタイプは[G3-PLC]で使用され、ネイティブメッシュルーティングとブートストラップ機能を提供します。 ITU-T勧告[G3-PLC]（セクション9.4.2.3を参照）は、ESC拡張タイプフィールドのような形式のコマンドを定義しています。コマンドIDの値は0x01〜0x1Fです。

The frame format is defined as follows:

フレーム形式は次のように定義されています。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 1| ESC       |  Command ID   | Command Payload
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: G.9903 Frame Format with ESC Dispatch Type

図3：G.9903フレームフォーマットとESCディスパッチタイプ

3.4. NALP and ESC Dispatch Types

3.4. NALPおよびESCディスパッチタイプ

According to Section 5.1 of RFC 4944 [RFC4944], NALP dispatch octets are reserved for use as a kind of escape code for identification of non-6LoWPAN payloads. Since ESC dispatch types are part of 6LoWPAN dispatch types (extended), they are orthogonal to NALP octets.

RFC 4944 [RFC4944]のセクション5.1によると、NALPディスパッチオクテットは、非6LoWPANペイロードを識別するための一種のエスケープコードとして使用するために予約されています。 ESCディスパッチタイプは6LoWPANディスパッチタイプ（拡張）の一部であるため、NALPオクテットと直交しています。

This document clarifies that NALP dispatch codes only provide an escape method for non-6LoWPAN payloads when they appear as the initial octet of a LoWPAN encapsulation, and that the potential meaning of their appearance in any other location is reserved for future use.

このドキュメントでは、NALPディスパッチコードがLoWPANカプセル化の最初のオクテットとして表示される場合、非6LoWPANペイロードのエスケープメソッドのみを提供し、他の場所での表示の潜在的な意味は将来の使用のために予約されていることを明確にします。

4. IANA Considerations

4. IANAに関する考慮事項

IANA has registered the 'ESC Extension Types' values per the policy 'Specification Required' [RFC5226], following the same policy as in the IANA Considerations section of [RFC4944]. For each Extension Type (except the Reserved values), the specification MUST define corresponding Extended Dispatch Payload frame octets for the receiver implementation to read the ESC dispatch types in an interoperable fashion.

IANAは、[RFC4944]のIANAに関する考慮事項セクションと同じポリシーに従って、ポリシー「Specification Required」[RFC5226]に従って「ESC拡張タイプ」の値を登録しました。それぞれの拡張タイプ（予約済みの値を除く）について、仕様は、レシーバー実装が相互運用可能な方法でESCディスパッチタイプを読み取るために、対応する拡張ディスパッチペイロードフレームオクテットを定義する必要があります。

Section 4.1 of [RFC5226] indicates that "Specification Required" calls for a Designated Expert review of the public specification requesting registration of the ESC Extension Type values.

[RFC5226]のセクション4.1は、「仕様が必要です」は、ESC拡張タイプ値の登録を要求する公開仕様の指定専門家レビューを要求することを示しています。

The allocation of code points should follow the guidelines on "Usage of ESC Dispatch Octets" (Section 3) and the typical example (Section 3.2) sections. ESC Extension Type code points MUST be used in conjunction with 6lo protocols following [RFC4944] or its derivatives. The requesting document MUST specify how the ESC dispatch octets will be used along with 6LoWPAN headers in their use cases.

コードポイントの割り当ては、「ESCディスパッチオクテットの使用法」（セクション3）および典型的な例（セクション3.2）セクションのガイドラインに従う必要があります。 ESC拡張タイプコードポイントは、[RFC4944]またはその派生物に従う6loプロトコルと組み合わせて使用する必要があります。要求するドキュメントは、ESCディスパッチオクテットがその使用例で6LoWPANヘッダーと共にどのように使用されるかを指定しなければなりません（MUST）。

The initial values for the 'ESC Extension Type' fields are as follows:

「ESC拡張タイプ」フィールドの初期値は次のとおりです。

   +-------+---------------------------------+---------------+
   | Value | Description                     | Reference     |
   +-------+---------------------------------+---------------+
   |  0    | Reserved                        | This document |
   |       |                                 |               |
   | 1-31  | Used by ITU-T G.9903 and G.9905 | ITU-T G.9903 &|
   |       |     Command IDs                 | ITU-T G.9905  |
   |       |                                 |               |
   | 32-254| Unassigned                      |               |
   |       |                                 |               |
   | 255   | Reserved                        | This document |
   +-------+---------------------------------+---------------+

Figure 4: Initial Values for the ESC Extension Types Registry

図4：ESC拡張タイプレジストリの初期値

5. Security Considerations

5. セキュリティに関する考慮事項

There are no additional security threats due to the assignments of ESC dispatch type usage described in this document. Furthermore, this document forbids defining any extended dispatch values or extension types that modify the behavior of existing dispatch types.

このドキュメントで説明されているESCディスパッチタイプの使用法の割り当てによる追加のセキュリティ上の脅威はありません。さらに、このドキュメントでは、既存のディスパッチタイプの動作を変更する拡張ディスパッチ値または拡張タイプの定義を禁止しています。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[Err4359] RFC Errata, Erratum ID 4359, RFC 4944, <https://www.rfc-editor.org/errata_search.php?eid=4359>.

[Err4359] RFC Errata、Erratum ID 4359、RFC 4944、<https://www.rfc-editor.org/errata_search.php?eid=4359>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.

[RFC4944]モンテネグロ、G。、クシャルナガル、N。、ホイ、J。、およびD.キュラー、「IEEE 802.15.4ネットワークを介したIPv6パケットの送信」、RFC 4944、DOI 10.17487 / RFC4944、2007年9月、<http： //www.rfc-editor.org/info/rfc4944>。

[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <http://www.rfc-editor.org/info/rfc6282>.

[RFC6282]ホイ、J。、エド。およびP. Thubert、「IEEE 802.15.4ベースのネットワーク上のIPv6データグラムの圧縮形式」、RFC 6282、DOI 10.17487 / RFC6282、2011年9月、<http://www.rfc-editor.org/info/rfc6282>。

6.2. Informative References

6.2. 参考引用

[G3-PLC] International Telecommunications Union, "G.9903 : Narrowband orthogonal frequency division multiplexing power line communication transceivers for G3-PLC networks", February 2014, <http://www.itu.int/rec/T-REC-G.9903-201402-I>.

[G3-PLC]国際電気通信連合、「G.9903：G3-PLCネットワーク用の狭帯域直交周波数分割多重電力線通信トランシーバー」、2014年2月、<http://www.itu.int/rec/T-REC- G.9903-201402-I>。

[IANA-6LoWPAN] IANA, "IPv6 Low Power Personal Area Network Parameters", <https://www.iana.org/assignments/_6lowpan-parameters>.

[IANA-6LoWPAN] IANA、「IPv6 Low Power Personal Area Network Parameters」、<https://www.iana.org/assignments/_6lowpan-parameters>。

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.

[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。

Acknowledgements

謝辞

The authors would like to thank the members of the 6lo WG for their comments. Many thanks to Carsten Bormann, Ralph Droms, Thierry Lys, Cedric Lavenu, and Pascal Thubert for discussions regarding the bits allocation issues, which led to this document. Jonathan Hui and Robert Cragie provided extensive reviews and guidance for interoperability. The authors acknowledge the comments from the following people that helped shape this document: Paul Duffy, Don Sturek, Michael Richardson, Xavier Vilajosana, Scott Mansfield, Dale Worley, and Russ Housley. Thanks to Brian Haberman, our document shepherd, for guidance in the IANA Considerations section.

著者は、コメントのために6lo WGのメンバーに感謝したいと思います。このドキュメントにつながったビット割り当ての問題について議論してくれたCarsten Bormann、Ralph Droms、Thierry Lys、Cedric Lavenu、Pascal Thubertに感謝します。 Jonathan HuiとRobert Cragieは、相互運用性に関する広範なレビューとガイダンスを提供しました。著者は、このドキュメントの作成に貢献した次の人々からのコメントを認めます。PaulDuffy、Don Sturek、Michael Richardson、Xavier Vilajosana、Scott Mansfield、Dale Worley、およびRuss Housley。 IANAの考慮事項セクションのガイダンスを提供してくれたドキュメントシェパードのBrian Habermanに感謝します。

Authors' Addresses

著者のアドレス

Samita Chakrabarti San Jose, CA United States of America

さみたちゃｋらばｒちさんじょせ、かうにてｄＳたてｓおｆあめりか

   Email: samitac.ietf@gmail.com

Gabriel Montenegro Microsoft United States of America

ガブリエルモンテネグロマイクロソフトアメリカ合衆国

   Email: gabriel.montenegro@microsoft.com

Ralph Droms United States of America

ラルフ・ドロムスアメリカ合衆国

   Email: rdroms.ietf@gmail.com

James Woodyatt Google Mountain View, CA United States of America

James Woodyatt Google Mountain View、CAアメリカ合衆国

   Email: jhw@google.com