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
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谷歌2017年2月
IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines
低功率无线个人区域网（6LoWPAN）上的IPv6 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标题中添加调度八位字节。电子稳定控制系统调度类型的值由RFC 6282更新；然而，其用途在RFC 6282或RFC 4944中均未定义。本文档更新了RFC 4944和RFC 6282，定义了ESC扩展八位代码点，并列出了编写本文档时已知用例的注册条目。
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 http://www.rfc-editor.org/info/rfc8066.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8066.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 . . . . . . . . . . . . . . . . . . . . . . . . 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
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]中。但是，[RFC4944]或[RFC6282]中均未定义ESC调度类型之后的八位字节和用法。近年来，随着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规范记录为现有已知用法。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
ESC扩展类型（EET）：它是ESC调度类型之后的第一个八位组。扩展类型定义附加调度八位字节的有效负载。这些值从0到255。值0和255保留供将来使用。1到254之间的其余值为
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.
由IANA指派。EET值与6LoWPAN标题中的调度值类似，只是前面有ESC调度类型。因此，ESC扩展类型和分派值使用正交代码空间。尽管不可取，但6LoWPAN标题中可能会出现多种ESC调度类型。第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节指出，扩展类型字段可能包含大于63的附加分派值，如[Err4359]所更正。为了互操作性，新调度类型（EET）不得修改现有调度类型的行为[RFC4944]。
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调度类型，但它不理解ESC扩展类型（EET）八位字节，则必须丢弃该数据包。然而，必须澄清的是，路由器节点应转发带有EET八位字节的6LoWPAN数据包，只要它不尝试处理任何未知的ESC扩展八位字节。
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，而不是丢弃整个数据包。
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网状收割台和LOWPAN_IPHC收割台，ESC扩展八位字节的顺序和顺序如下所述。当LOWPAN_IPHC调度类型存在时，ESC调度类型必须出现在LOWPAN_IPHC调度类型之前，以保持与RFC 6282第3.2节的向后兼容性。下图提供了ESC扩展八位字节用法的示例：
A LoWPAN encapsulated IPv6 Header compressed packet:
低泛封装IPv6头压缩数据包：
+-------+------+--------+--------+-----------------+--------+
| ESC | EET | EDP |Dispatch| LOWPAN_IPHC hdr | Payld |
+-------+------+--------+--------+-----------------+--------+
+-------+------+--------+--------+-----------------+--------+
| 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|
+-----+-----+-----+----+------+-------+---------------+------+
+-----+-----+-----+----+------+-------+---------------+------+
|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 |
+-------+-------+-----+-----+-------+
+-------+-------+-----+-----+-------+
| M Typ | M Hdr | ESC | EET |EDP |
+-------+-------+-----+-----+-------+
With Fragment header:
使用片段标题：
+-------+-------+--------+------+-----+-----+-------+
| M Typ | M Hdr | F Typ | F hdr|ESC | EET | EDP |
+-------+-------+--------+------+-----+-----+-------+
+-------+-------+--------+------+-----+-----+-------+
| M Typ | M Hdr | F Typ | F hdr|ESC | EET | EDP |
+-------+-------+--------+------+-----+-----+-------+
ESC dispatch type as a LowPAN encapsulation:
ESC调度类型为低量程封装：
+--------+--------+--------+
| ESC | EET | EDP |
+--------+--------+--------+
+--------+--------+--------+
| ESC | EET | EDP |
+--------+--------+--------+
Figure 2: A 6LoWPAN Packet with ESC Dispatch Types
图2：具有ESC调度类型的6LoWPAN数据包
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.
[G3-PLC]中使用ESC调度类型，以提供本机网格路由和引导功能。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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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调度类型的帧格式
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调度代码仅在非6 LoWPAN有效载荷作为LoWPAN封装的初始八位字节出现时提供转义方法，且其在任何其他位置出现的潜在含义保留供将来使用。
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注意事项部分中的相同策略，按照策略“所需规范”[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
代码点的分配应遵循“ESC调度八位字节的使用”指南（第3节）和典型示例（第3.2节）章节。ESC扩展类型代码点必须与[RFC4944]或其后的6lo协议结合使用
derivatives. The requesting document MUST specify how the ESC dispatch octets will be used along with 6LoWPAN headers in their use cases.
衍生品。请求文件必须指定ESC调度八位字节在其用例中如何与6LoWPAN头一起使用。
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 |
+-------+---------------------------------+---------------+
+-------+---------------------------------+---------------+
| 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扩展类型注册表的初始值
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调度类型使用的分配，不存在其他安全威胁。此外，本文档禁止定义任何修改现有分派类型行为的扩展分派值或扩展类型。
[Err4359] RFC Errata, Erratum ID 4359, RFC 4944, <https://www.rfc-editor.org/errata_search.php?eid=4359>.
[Err4359]RFC勘误表，勘误表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.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过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]Hui，J.，Ed.和P.Thubert，“基于IEEE 802.15.4的网络上IPv6数据报的压缩格式”，RFC 6282，DOI 10.17487/RFC6282，2011年9月<http://www.rfc-editor.org/info/rfc6282>.
[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低功耗个人局域网参数”<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，“在RFCs中编写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工作组成员的评论。非常感谢Carsten Bormann、Ralph Droms、Thierry Lys、Cedric Lavenu和Pascal Thubert就bits分配问题进行的讨论，最终形成了本文档。Jonathan Hui和Robert Cragie为互操作性提供了广泛的审查和指导。作者感谢以下人士的评论，这些人帮助形成了本文件：保罗·达菲、唐·斯特雷克、迈克尔·理查森、泽维尔·维拉戈萨纳、斯科特·曼斯菲尔德、戴尔·沃利和罗斯·霍斯利。感谢我们的文档管理员Brian Haberman在IANA注意事项部分提供指导。
Authors' Addresses
作者地址
Samita Chakrabarti San Jose, CA United States of America
美利坚合众国加利福尼亚州圣何塞Samita Chakrabarti
Email: samitac.ietf@gmail.com
Email: samitac.ietf@gmail.com
Gabriel Montenegro Microsoft United States of America
美利坚合众国加布里埃尔
Email: gabriel.montenegro@microsoft.com
Email: gabriel.montenegro@microsoft.com
Ralph Droms United States of America
拉尔夫·德罗姆斯美利坚合众国
Email: rdroms.ietf@gmail.com
Email: rdroms.ietf@gmail.com
James Woodyatt Google Mountain View, CA United States of America
James Woodyatt Google Mountain View，加利福尼亚州，美利坚合众国
Email: jhw@google.com
Email: jhw@google.com