Internet Engineering Task Force (IETF) A. Brandt
Request for Comments: 7428 J. Buron
Category: Standards Track Sigma Designs
ISSN: 2070-1721 February 2015
Internet Engineering Task Force (IETF) A. Brandt
Request for Comments: 7428 J. Buron
Category: Standards Track Sigma Designs
ISSN: 2070-1721 February 2015
Transmission of IPv6 Packets over ITU-T G.9959 Networks
通过ITU-T G.9959网络传输IPv6数据包
Abstract
摘要
This document describes the frame format for transmission of IPv6 packets as well as a method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks.
本文档描述了IPv6数据包传输的帧格式，以及在ITU-T G.9959网络上形成IPv6链路本地地址和无状态自动配置IPv6地址的方法。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第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/rfc7428.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7428.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 ....................................................2
1.1. Terms Used .................................................3
1.2. Requirements Language ......................................4
2. G.9959 Parameters to Use for IPv6 Transport .....................5
2.1. Addressing Mode ............................................5
2.2. IPv6 Multicast Support .....................................6
2.3. G.9959 MAC PDU Size and IPv6 MTU ...........................6
2.4. Transmission Status Indications ............................7
2.5. Transmission Security ......................................7
3. 6LoWPAN Adaptation Layer and Frame Format .......................7
3.1. Dispatch Header ............................................8
4. 6LoWPAN Addressing ..............................................9
4.1. Stateless Address Autoconfiguration of Routable IPv6
Addresses ..................................................9
4.2. IPv6 Link-Local Address ...................................10
4.3. Unicast Address Mapping ...................................10
4.4. On the Use of Neighbor Discovery Technologies .............11
4.4.1. Prefix and CID Management (Route-Over) .............11
4.4.2. Prefix and CID Management (Mesh-Under) .............11
5. Header Compression .............................................12
6. Security Considerations ........................................13
7. Privacy Considerations .........................................14
8. References .....................................................14
8.1. Normative References ......................................14
8.2. Informative References ....................................16
Appendix A. G.9959 6LoWPAN Datagram Example .......................17
Acknowledgements ..................................................21
Authors' Addresses ................................................21
1. Introduction ....................................................2
1.1. Terms Used .................................................3
1.2. Requirements Language ......................................4
2. G.9959 Parameters to Use for IPv6 Transport .....................5
2.1. Addressing Mode ............................................5
2.2. IPv6 Multicast Support .....................................6
2.3. G.9959 MAC PDU Size and IPv6 MTU ...........................6
2.4. Transmission Status Indications ............................7
2.5. Transmission Security ......................................7
3. 6LoWPAN Adaptation Layer and Frame Format .......................7
3.1. Dispatch Header ............................................8
4. 6LoWPAN Addressing ..............................................9
4.1. Stateless Address Autoconfiguration of Routable IPv6
Addresses ..................................................9
4.2. IPv6 Link-Local Address ...................................10
4.3. Unicast Address Mapping ...................................10
4.4. On the Use of Neighbor Discovery Technologies .............11
4.4.1. Prefix and CID Management (Route-Over) .............11
4.4.2. Prefix and CID Management (Mesh-Under) .............11
5. Header Compression .............................................12
6. Security Considerations ........................................13
7. Privacy Considerations .........................................14
8. References .....................................................14
8.1. Normative References ......................................14
8.2. Informative References ....................................16
Appendix A. G.9959 6LoWPAN Datagram Example .......................17
Acknowledgements ..................................................21
Authors' Addresses ................................................21
The ITU-T G.9959 recommendation [G.9959] targets low-power Personal Area Networks (PANs). This document defines the frame format for transmission of IPv6 [RFC2460] packets as well as the formation of IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on G.9959 networks.
ITU-T G.9959建议[G.9959]针对低功耗个人区域网络（PAN）。本文件定义了IPv6[RFC2460]数据包传输的帧格式，以及G.9959网络上IPv6链路本地地址和无状态自动配置IPv6地址的形成。
The general approach is to adapt elements of [RFC4944] to G.9959 networks. G.9959 provides a Segmentation and Reassembly (SAR) layer for transmission of datagrams larger than the G.9959 Media Access Control Protocol Data Unit (MAC PDU).
一般方法是将[RFC4944]的元件调整到G.9959网络。G.9959为传输大于G.9959媒体访问控制协议数据单元（MAC PDU）的数据报提供了分段和重组（SAR）层。
[RFC6775] updates [RFC4944] by specifying IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) optimizations for IPv6 Neighbor Discovery (ND) (originally defined by [RFC4861]). This document limits the use of [RFC6775] to prefix and Context ID
[RFC6775]通过为IPv6邻居发现（ND）（最初由[RFC4861]定义）指定低功耗无线个人局域网（6LoWPAN）上的IPv6优化来更新[RFC4944]。本文档将[RFC6775]的使用限制为前缀和上下文ID
assignment. An Interface Identifier (IID) may be constructed from a G.9959 link-layer address, leading to a "link-layer-derived IPv6 address". If using that method, Duplicate Address Detection (DAD) is not needed. Alternatively, IPv6 addresses may be assigned centrally via DHCP, leading to a "non-link-layer-derived IPv6 address". Address registration is only needed in certain cases.
分配接口标识符（IID）可由G.9959链路层地址构成，从而产生“链路层衍生IPv6地址”。如果使用该方法，则不需要重复地址检测（DAD）。或者，可以通过DHCP集中分配IPv6地址，从而产生“非链路层派生的IPv6地址”。只有在某些情况下才需要地址注册。
In addition to IPv6 application communication, the frame format defined in this document may be used by IPv6 routing protocols such as the Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550] or Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks (P2P-RPL) [RFC6997] to implement IPv6 routing over G.9959 networks.
除IPv6应用程序通信外，本文件中定义的帧格式可由IPv6路由协议使用，如低功率和有损网络的路由协议（RPL）[RFC6550]或低功率和有损网络中点对点路由的反应式发现（P2P-RPL）[RFC6997]在G.9959网络上实施IPv6路由。
The encapsulation frame defined by this specification may optionally be transported via mesh routing below the 6LoWPAN layer. Mesh-under and route-over routing protocol specifications are out of scope for this document.
本规范规定的封装框架可选择性地通过6LoWPAN层下方的网格布线进行运输。路由协议规范下的网格和路由协议规范不在本文档的范围内。
6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network
6LoWPAN:IPv6低功耗无线个人局域网
ABR: Authoritative 6LoWPAN Border Router (Authoritative 6LBR) [RFC6775]
ABR：权威6LoWPAN边界路由器（权威6LBR）[RFC6775]
Ack: Acknowledgement
确认：确认
AES: Advanced Encryption Standard
高级加密标准
CID: Context Identifier [RFC6775]
CID:上下文标识符[RFC6775]
DAD: Duplicate Address Detection [RFC6775]
DAD:重复地址检测[RFC6775]
DHCPv6: Dynamic Host Configuration Protocol for IPv6 [RFC3315]
DHCPv6:IPv6的动态主机配置协议[RFC3315]
EUI-64: Extended Unique Identifier [EUI64]
EUI-64：扩展唯一标识符[EUI64]
G.9959: Short range narrow-band digital radiocommunication transceiver [G.9959]
G.9959：短程窄带数字无线电通信收发机[G.9959]
GHC: Generic Header Compression [RFC7400]
GHC：通用头压缩[RFC7400]
HomeID: G.9959 Link-Layer Network Identifier
HomeID:G.9959链路层网络标识符
IID: Interface Identifier
IID：接口标识符
Link-layer-derived address: IPv6 address constructed on the basis of link-layer address information
链路层派生地址：基于链路层地址信息构建的IPv6地址
MAC: Media Access Control
媒体访问控制
Mesh-under: Forwarding via mesh routing below the 6LoWPAN layer
下网格：通过6LoWPAN层下的网格路由进行转发
MTU: Maximum Transmission Unit
最大传输单位
ND: Neighbor Discovery [RFC4861] [RFC6775]
ND:邻居发现[RFC4861][RFC6775]
NodeID: G.9959 Link-Layer Node Identifier
NodeID:G.9959链路层节点标识符
Non-link-layer-derived address: IPv6 address assigned by a managed process, e.g., DHCPv6
非链路层派生地址：由托管进程（如DHCPv6）分配的IPv6地址
P2P-RPL: Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks [RFC6997]
P2P-RPL：低功耗和有损网络中点对点路由的反应式发现[RFC6997]
PAN: Personal Area Network
个人区域网
PDU: Protocol Data Unit
协议数据单元
PHY: Physical Layer
物理层
RA: Router Advertisement [RFC4861] [RFC6775]
RA:路由器广告[RFC4861][RFC6775]
Route-over: Forwarding via IP routing above the 6LoWPAN layer
路由：通过6LoWPAN层上方的IP路由进行转发
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks [RFC6550]
RPL:IPv6低功耗有损网络路由协议[RFC6550]
SAR: G.9959 Segmentation and Reassembly
SAR:G.9959分割和重组
ULA: Unique Local Address [RFC4193]
唯一本地地址[RFC4193]
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]中所述进行解释。
This section outlines properties applying to the PHY and MAC layers of G.9959 and how to use these for IPv6 transport.
本节概述了应用于G.9959物理层和MAC层的属性，以及如何将这些属性用于IPv6传输。
G.9959 defines how a unique 32-bit HomeID network identifier is assigned by a network controller and how an 8-bit NodeID host identifier is allocated to each node. NodeIDs are unique within the network identified by the HomeID. The G.9959 HomeID represents an IPv6 subnet that is identified by one or more IPv6 prefixes.
G.9959定义了网络控制器如何分配唯一的32位HomeID网络标识符，以及如何将8位NodeID主机标识符分配给每个节点。节点ID在由HomeID标识的网络中是唯一的。G.9959 HomeID表示由一个或多个IPv6前缀标识的IPv6子网。
An IPv6 host MUST construct its link-local IPv6 address from the link-layer-derived IID in order to facilitate IP header compression as described in [RFC6282].
IPv6主机必须从链路层派生的IID构造其链路本地IPv6地址，以便按照[RFC6282]中的说明进行IP报头压缩。
A node interface MAY support the M flag of the RA message for the construction of routable IPv6 addresses. A cost-optimized node implementation may save memory by skipping support for the M flag. The M flag MUST be interpreted as defined in Figure 1.
节点接口可支持RA消息的M标志，用于构建可路由IPv6地址。成本优化的节点实现可以通过跳过对M标志的支持来节省内存。M标志必须按照图1中的定义进行解释。
+--------+--------+---------------------------------------------+
| M flag | M flag | Required node behavior |
| support| value | |
+--------+--------+---------------------------------------------+
| No |(ignore)| Node MUST use link-layer-derived addressing |
+--------+--------+---------------------------------------------+
| Yes | 0 | Node MUST use link-layer-derived addressing |
| +--------+---------------------------------------------+
| | 1 | Node MUST use DHCPv6-based addressing, and |
| | | node MUST comply fully with [RFC6775] |
+--------+--------+---------------------------------------------+
+--------+--------+---------------------------------------------+
| M flag | M flag | Required node behavior |
| support| value | |
+--------+--------+---------------------------------------------+
| No |(ignore)| Node MUST use link-layer-derived addressing |
+--------+--------+---------------------------------------------+
| Yes | 0 | Node MUST use link-layer-derived addressing |
| +--------+---------------------------------------------+
| | 1 | Node MUST use DHCPv6-based addressing, and |
| | | node MUST comply fully with [RFC6775] |
+--------+--------+---------------------------------------------+
Figure 1: RA M Flag Support and Interpretation
图1:RA M标志支持和解释
A node that uses DHCPv6-based addressing MUST comply fully with the text of [RFC6775].
使用基于DHCPv6的寻址的节点必须完全符合[RFC6775]的文本。
If DHCPv6-based addressing is used, the DHCPv6 client must use a DHCPv6 Unique Identifier (DUID) of type DUID-UUID, as described in [RFC6355]. The Universally Unique Identifier (UUID) used in the DUID-UUID must be generated as specified in [RFC4122], Section 4.5, starting at the third paragraph in that section (the 47-bit random number-based UUID). The DUID must be stored persistently by the node as specified in Section 3 of [RFC6355].
如果使用基于DHCPv6的寻址，则DHCPv6客户端必须使用DUID-UUID类型的DHCPv6唯一标识符（DUID），如[RFC6355]中所述。DUID-UUID中使用的通用唯一标识符（UUID）必须按照[RFC4122]第4.5节的规定生成，从该节的第三段开始（基于47位随机数的UUID）。按照[RFC6355]第3节的规定，节点必须持久存储DUID。
A word of caution: since HomeIDs and NodeIDs are handed out by a network controller function during inclusion, identifier validity and uniqueness are limited by the lifetime of the network membership. This can be cut short by a mishap occurring at the network controller. Having a single point of failure at the network controller suggests that high-reliability network deployments may benefit from a redundant network controller function.
警告：由于HomeID和NodeID在包含期间由网络控制器函数分发，因此标识符的有效性和唯一性受到网络成员的生存期的限制。网络控制器发生故障时，可以缩短此过程。网络控制器出现单点故障表明，高可靠性网络部署可能受益于冗余网络控制器功能。
This warning applies to link-layer-derived addressing as well as to non-link-layer-derived addressing deployments.
此警告适用于链路层派生寻址以及非链路层派生寻址部署。
[RFC3819] recommends that IP subnetworks support (subnet-wide) multicast. G.9959 supports direct-range IPv6 multicast, while subnet-wide multicast is not supported natively by G.9959. Subnet-wide multicast may be provided by an IP routing protocol or a mesh routing protocol operating below the 6LoWPAN layer. Routing protocol specifications are out of scope for this document.
[RFC3819]建议IP子网支持（子网范围）多播。G.9959支持直接范围的IPv6多播，而G.9959本机不支持子网范围的多播。子网范围的多播可以由在6LoWPAN层下运行的IP路由协议或网状路由协议提供。路由协议规范超出了本文档的范围。
IPv6 multicast packets MUST be carried via G.9959 broadcast.
IPv6多播数据包必须通过G.9959广播进行传输。
As per [G.9959], this is accomplished as follows:
根据[G.9959]，这是通过以下方式实现的：
1. The destination HomeID of the G.9959 MAC PDU MUST be the HomeID of the network.
1. G.9959 MAC PDU的目标HomeID必须是网络的HomeID。
2. The destination NodeID of the G.9959 MAC PDU MUST be the broadcast NodeID (0xff).
2. G.9959 MAC PDU的目标节点ID必须是广播节点ID（0xff）。
G.9959 broadcast MAC PDUs are only intercepted by nodes within the network identified by the HomeID.
G.9959广播MAC PDU仅由HomeID标识的网络内的节点拦截。
IPv6 packets MUST be transmitted using G.9959 transmission profile R3 or higher.
IPv6数据包必须使用G.9959传输配置文件R3或更高版本进行传输。
[RFC2460] specifies that any link that cannot convey a 1280-octet packet in one piece must provide link-specific fragmentation and reassembly at a layer below IPv6.
[RFC2460]规定，任何不能在一块中传输1280个八位组数据包的链路必须在IPv6下的一层提供特定于链路的分段和重组。
G.9959 provides segmentation and reassembly for payloads up to 1350 octets. IPv6 header compression [RFC6282] improves the chances that a short IPv6 packet can fit into a single G.9959 frame. Therefore, Section 3 of this document specifies that [RFC6282] MUST be supported. With the mandatory link-layer security enabled, a G.9959 R3 MAC PDU may accommodate 6LoWPAN datagrams of up to
G.9959为1350个八位字节的有效载荷提供分段和重新组装。IPv6报头压缩[RFC6282]提高了短IPv6数据包装入单个G.9959帧的可能性。因此，本文件第3节规定必须支持[RFC6282]。在启用强制链路层安全性的情况下，G.9959 R3 MAC PDU可容纳多达6个字节的6LoWPAN数据报
130 octets without triggering G.9959 segmentation and reassembly. Longer 6LoWPAN datagrams will lead to the transmission of multiple G.9959 PDUs.
130个八位字节，不触发G.9959分段和重新组装。较长的6LoWPAN数据报将导致多个G.9959 PDU的传输。
The G.9959 MAC layer provides native acknowledgement and retransmission of MAC PDUs. The G.9959 SAR layer does the same for larger datagrams. A mesh routing layer may provide a similar feature for routed communication. An IPv6 routing stack communicating over G.9959 may utilize link-layer status indications such as delivery confirmation and Ack timeout from the MAC layer.
G.9959 MAC层提供MAC PDU的本机确认和重传。对于较大的数据报，G.9959 SAR层也会这样做。网状路由层可以为路由通信提供类似的特征。通过G.9959进行通信的IPv6路由堆栈可以利用链路层状态指示，例如来自MAC层的传递确认和Ack超时。
Implementations claiming conformance with this document MUST enable G.9959 shared network key security.
声称符合本文档的实施必须启用G.9959共享网络密钥安全。
The shared network key is intended to address security requirements in the home at the normal level of security requirements. For applications with high or very high requirements for confidentiality and/or integrity, additional application-layer security measures for end-to-end authentication and encryption may need to be applied. (The availability of the network relies on the security properties of the network key in any case.)
共享网络密钥旨在满足家庭中正常级别的安全需求。对于机密性和/或完整性要求很高或非常高的应用程序，可能需要应用用于端到端身份验证和加密的附加应用程序层安全措施。（在任何情况下，网络的可用性取决于网络密钥的安全属性。）
The 6LoWPAN encapsulation formats defined in this section are carried as payload in the G.9959 MAC PDU. IPv6 header compression [RFC6282] MUST be supported by implementations of this specification. Further, implementations MAY support Generic Header Compression (GHC) [RFC7400]. A node implementing [RFC7400] MUST probe its peers for GHC support before applying GHC.
本节中定义的6LoWPAN封装格式在G.9959 MAC PDU中作为有效载荷携带。本规范的实现必须支持IPv6标头压缩[RFC6282]。此外，实现可支持通用报头压缩（GHC）[RFC7400]。实现[RFC7400]的节点必须在应用GHC之前探测其对等节点是否支持GHC。
All 6LoWPAN datagrams transported over G.9959 are prefixed by a 6LoWPAN encapsulation header stack. The 6LoWPAN payload follows this encapsulation header stack. Each header in the header stack contains a header type followed by zero or more header fields. An IPv6 header stack may contain, in the following order, addressing, hop-by-hop options, routing, fragmentation, destination options, and, finally, payload [RFC2460]. The 6LoWPAN header format is structured the same way. Currently, only one payload option is defined for the G.9959 6LoWPAN header format.
通过G.9959传输的所有6LoWPAN数据报都以6LoWPAN封装头堆栈作为前缀。6LoWPAN有效负载遵循此封装收割台堆栈。标头堆栈中的每个标头都包含一个标头类型，后跟零个或多个标头字段。IPv6报头堆栈可以按以下顺序包含寻址、逐跳选项、路由、分段、目的地选项，最后是有效负载[RFC2460]。6LoWPAN标题格式的结构与此相同。目前，G.9959 6LoWPAN收割台格式仅定义了一个有效负载选项。
The definition of 6LoWPAN headers consists of the dispatch value, the definition of the header fields that follow, and their ordering constraints relative to all other headers. Although the header stack structure provides a mechanism to address future demands on the 6LoWPAN adaptation layer, it is not intended to provide general-purpose extensibility.
6LoWPAN标头的定义包括分派值、随后标头字段的定义以及它们相对于所有其他标头的排序约束。尽管header stack结构提供了一种机制来满足6LoWPAN适配层的未来需求，但它并不打算提供通用扩展性。
An example of a complete G.9959 6LoWPAN datagram can be found in Appendix A.
完整的G.9959 6LoWPAN数据报示例见附录a。
The Dispatch Header is shown below:
调度标题如下所示：
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6LoWPAN CmdCls| Dispatch | Type-specific header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6LoWPAN CmdCls| Dispatch | Type-specific header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Dispatch Type and Header
图2：分派类型和标题
6LoWPAN CmdCls: 6LoWPAN Command Class identifier. This field MUST carry the value 0x4F [G.9959]. The value is assigned by the ITU-T and specifies that the following bits are a 6LoWPAN encapsulated datagram. 6LoWPAN protocols MUST ignore the G.9959 frame if the 6LoWPAN Command Class identifier deviates from 0x4F.
6LoWPAN CmdCls:6LoWPAN命令类标识符。此字段必须带有值0x4F[G.9959]。该值由ITU-T分配，并指定以下位为6LoWPAN封装数据报。如果6LoWPAN命令类标识符偏离0x4F，6LoWPAN协议必须忽略G.9959帧。
Dispatch: Identifies the header type immediately following the Dispatch Header.
分派：标识紧接分派标头之后的标头类型。
Type-specific header: A header determined by the Dispatch Header.
类型特定标头：由分派标头确定的标头。
The dispatch value may be treated as an unstructured namespace. Only a few symbols are required to represent current 6LoWPAN functionality. Although some additional savings could be achieved by encoding additional functionality into the dispatch byte, these measures would tend to constrain the ability to address future alternatives.
分派值可以被视为非结构化命名空间。仅需几个符号即可表示当前的6LoWPAN功能。尽管通过将附加功能编码到调度字节中可以实现一些额外的节省，但这些措施往往会限制解决未来备选方案的能力。
+------------+--------------------+-----------+
| Pattern | Header Type | Reference |
+------------+--------------------+-----------+
| 01 1xxxxx | 6LoWPAN_IPHC | [RFC6282] |
+------------+--------------------+-----------+
+------------+--------------------+-----------+
| Pattern | Header Type | Reference |
+------------+--------------------+-----------+
| 01 1xxxxx | 6LoWPAN_IPHC | [RFC6282] |
+------------+--------------------+-----------+
Other IANA-assigned 6LoWPAN dispatch values do not apply to this document.
IANA分配的其他6LoWPAN分派值不适用于本文档。
Figure 3: Dispatch Values
图3：分派值
6LoWPAN_IPHC: IPv6 Header Compression. Refer to [RFC6282].
6LoWPAN_IPHC:IPv6标头压缩。请参阅[RFC6282]。
IPv6 addresses may be autoconfigured from IIDs that may again be constructed from link-layer address information to save memory in devices and to facilitate efficient IP header compression as per [RFC6282]. Link-layer-derived addresses have a static nature and may involuntarily expose private usage data on public networks. Refer to Section 7.
IPv6地址可根据IID自动配置，IID可再次根据链路层地址信息构建，以节省设备内存，并根据[RFC6282]促进有效的IP报头压缩。链路层派生地址具有静态性质，可能会无意中公开公共网络上的私有使用数据。参见第7节。
A NodeID is mapped into an IEEE EUI-64 identifier as follows:
节点ID映射为IEEE EUI-64标识符，如下所示：
IID = 0000:00ff:fe00:YYXX
IID = 0000:00ff:fe00:YYXX
Figure 4: Constructing a Compressible IID
图4：构建可压缩IID
where XX carries the G.9959 NodeID and YY is a 1-byte value chosen by the individual node. The default YY value MUST be zero. A node MAY use values of YY other than zero to form additional IIDs in order to instantiate multiple IPv6 interfaces. The YY value MUST be ignored when computing the corresponding NodeID (the XX value) from an IID.
其中XX携带G.9959节点ID，YY是由单个节点选择的1字节值。默认YY值必须为零。节点可以使用除零以外的YY值来形成额外的iid，以便实例化多个IPv6接口。从IID计算相应的节点ID（XX值）时，必须忽略YY值。
The method of constructing IIDs from the link-layer address obviously does not support addresses assigned or constructed by other means. A node MUST NOT compute the NodeID from the IID if the first 6 bytes of the IID do not comply with the format defined in Figure 4. In that case, the address resolution mechanisms of [RFC6775] apply.
从链路层地址构造IID的方法显然不支持通过其他方式分配或构造的地址。如果IID的前6个字节不符合图4中定义的格式，则节点不能从IID计算NodeID。在这种情况下，[RFC6775]的地址解析机制适用。
The IID defined above MUST be used whether autoconfiguring a ULA IPv6 address [RFC4193] or a globally routable IPv6 address [RFC3587] in G.9959 subnets.
无论是在G.9959子网中自动配置ULA IPv6地址[RFC4193]还是全局可路由IPv6地址[RFC3587]，都必须使用上面定义的IID。
The IPv6 link-local address [RFC4291] for a G.9959 interface is formed by appending the IID defined above to the IPv6 link-local prefix fe80::/64.
G.9959接口的IPv6链路本地地址[RFC4291]是通过将上面定义的IID附加到IPv6链路本地前缀fe80:：/64形成的。
The "Universal/Local" (U/L) bit MUST be set to zero in keeping with the fact that this is not a globally unique value [EUI64].
“通用/本地”（U/L）位必须设置为零，以保持这不是全局唯一值[EUI64]。
The resulting link-local address is formed as follows:
由此产生的链路本地地址如下所示：
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier (IID) |
+----------+-----------------------+----------------------------+
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier (IID) |
+----------+-----------------------+----------------------------+
Figure 5: IPv6 Link-Local Address
图5:IPv6链路本地地址
The address resolution procedure for mapping IPv6 unicast addresses into G.9959 link-layer addresses follows the general description in Section 7.2 of [RFC4861]. The Source/Target Link-layer Address option MUST have the following form when the link layer is G.9959.
将IPv6单播地址映射到G.9959链路层地址的地址解析过程遵循[RFC4861]第7.2节中的一般说明。当链路层为G.9959时，源/目标链路层地址选项必须具有以下形式。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | NodeID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding |
+- -+
| (All zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | NodeID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding |
+- -+
| (All zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: IPv6 Unicast Address Mapping
图6:IPv6单播地址映射
Option fields:
选项字段：
Type: The value 1 signifies the Source Link-layer address. The value 2 signifies the Destination Link-layer address.
类型：值1表示源链接层地址。值2表示目标链路层地址。
Length: This is the length of this option (including the Type and Length fields) in units of 8 octets. The value of this field is always 1 for G.9959 NodeIDs.
长度：此选项的长度（包括类型和长度字段），以8个八位字节为单位。对于G.9959节点ID，此字段的值始终为1。
NodeID: This is the G.9959 NodeID to which the actual interface currently responds. The link-layer address may change if the interface joins another network at a later time.
NodeID：这是实际接口当前响应的G.9959 NodeID。如果接口稍后加入另一个网络，链路层地址可能会改变。
[RFC4861] specifies how IPv6 nodes may resolve link-layer addresses
from IPv6 addresses via the use of link-local IPv6 multicast.
[RFC6775] is an optimization of [RFC4861], specifically targeting
6LoWPAN networks. [RFC6775] defines how a 6LoWPAN node may register
IPv6 addresses with an authoritative border router (ABR). Mesh-under
networks MUST NOT use [RFC6775] address registration. However,
[RFC6775] address registration MUST be used if the first 6 bytes of
the IID do not comply with the format defined in Figure 4.
[RFC4861] specifies how IPv6 nodes may resolve link-layer addresses
from IPv6 addresses via the use of link-local IPv6 multicast.
[RFC6775] is an optimization of [RFC4861], specifically targeting
6LoWPAN networks. [RFC6775] defines how a 6LoWPAN node may register
IPv6 addresses with an authoritative border router (ABR). Mesh-under
networks MUST NOT use [RFC6775] address registration. However,
[RFC6775] address registration MUST be used if the first 6 bytes of
the IID do not comply with the format defined in Figure 4.
In route-over environments, IPv6 hosts MUST use [RFC6775] address registration. A node implementation for route-over operation MAY use [RFC6775] mechanisms for obtaining IPv6 prefixes and corresponding header compression context information [RFC6282]. [RFC6775] route-over requirements apply with no modifications.
在路由环境中，IPv6主机必须使用[RFC6775]地址注册。路由覆盖操作的节点实现可以使用[RFC6775]机制来获取IPv6前缀和相应的报头压缩上下文信息[RFC6282]。[RFC6775]不作任何修改，适用路线越过要求。
An implementation for mesh-under operation MUST use [RFC6775] mechanisms for managing IPv6 prefixes and corresponding header compression context information [RFC6282]. [RFC6775] Duplicate Address Detection (DAD) MUST NOT be used, since the link-layer inclusion process of G.9959 ensures that a NodeID is unique for a given HomeID.
正在运行的mesh实现必须使用[RFC6775]机制来管理IPv6前缀和相应的头压缩上下文信息[RFC6282]。[RFC6775]不得使用重复地址检测（DAD），因为G.9959的链路层包含过程确保节点ID对于给定的HomeID是唯一的。
With this exception and the specific redefinition of the RA Router Lifetime value 0xFFFF (refer to Section 4.4.2.3), the text of the following subsections is in compliance with [RFC6775].
除此例外和RA路由器寿命值0xFFFF的具体重新定义外（参考第4.4.2.3节），以下小节的内容符合[RFC6775]。
As stated by [RFC6775], an ABR is responsible for managing prefix(es). Global routable prefixes may change over time. It is RECOMMENDED that a ULA prefix is assigned to the 6LoWPAN subnet to facilitate stable site-local application associations based on IPv6 addresses. A node MAY support the M flag of the RA message. This influences the way IPv6 addresses are assigned. Refer to Section 2.1 for details.
如[RFC6775]所述，ABR负责管理前缀。全局可路由前缀可能会随时间变化。建议将ULA前缀分配给6LoWPAN子网，以促进基于IPv6地址的稳定站点本地应用程序关联。节点可以支持RA消息的M标志。这会影响IPv6地址的分配方式。有关详细信息，请参阅第2.1节。
The 6LoWPAN Context Option (6CO) is used according to [RFC6775] in an RA to disseminate Context IDs (CIDs) to use for compressing prefixes. One or more prefixes and corresponding Context IDs MUST be assigned during initial node inclusion.
根据RA中的[RFC6775]，使用6LoWPAN上下文选项（6CO）来传播上下文ID（CID）以用于压缩前缀。在初始节点包含期间，必须分配一个或多个前缀和相应的上下文ID。
When updating context information, a CID may have its lifetime set to zero to obsolete it. The CID MUST NOT be reused immediately; rather, the next vacant CID should be assigned. Header compression based on CIDs MUST NOT be used for RA messages carrying context information. An expired CID and the associated prefix MUST NOT be reset but rather must be retained in receive-only mode if there is no other current need for the CID value. This will allow an ABR to detect if a sleeping node without a clock uses an expired CID, and in response, the ABR MUST return an RA with fresh context information to the originator.
更新上下文信息时，CID可能会将其生存期设置为零以使其过时。不得立即重复使用CID；相反，应该分配下一个空CID。基于CID的报头压缩不得用于承载上下文信息的RA消息。如果当前不需要CID值，则不得重置过期的CID和相关前缀，而是必须在仅接收模式下保留。这将允许ABR检测没有时钟的休眠节点是否使用过期的CID，并且作为响应，ABR必须向发起者返回带有新上下文信息的RA。
Nodes MUST renew the prefix and CID according to the lifetime signaled by the ABR. [RFC6775] specifies that the maximum value of the RA Router Lifetime field MAY be up to 0xFFFF. This document further specifies that the value 0xFFFF MUST be interpreted as infinite lifetime. This value MUST NOT be used by ABRs. Its use is only intended for a sleeping network controller -- for instance, a battery-powered remote control being master for a small island-mode network of light modules.
节点必须根据ABR发出的生存期信号更新前缀和CID。[RFC6775]指定RA路由器生存期字段的最大值可能高达0xFFFF。本文档进一步规定值0xFFFF必须解释为无限生存期。ABR不得使用此值。其用途仅适用于睡眠网络控制器——例如，电池供电的遥控器是灯模块小岛模式网络的主控器。
IPv6 header compression [RFC6282] MUST be implemented, and GHC [RFC7400] compression for higher layers MAY be implemented. This section will simply identify substitutions that should be made when interpreting the text of [RFC6282] and [RFC7400].
必须实现IPv6报头压缩[RFC6282]，并且可以实现更高层的GHC[RFC7400]压缩。本节将简单确定在解释[RFC6282]和[RFC7400]文本时应进行的替换。
In general, the following substitutions should be made:
一般而言，应进行以下替换：
o Replace "802.15.4" with "G.9959".
o 将“802.15.4”替换为“G.9959”。
o Replace "802.15.4 short address" with "<Interface><G.9959 NodeID>".
o 将“802.15.4短地址”替换为“<Interface><G.9959 NodeID>”。
o Replace "802.15.4 PAN ID" with "G.9959 HomeID".
o 将“802.15.4 PAN ID”替换为“G.9959 HomeID”。
When a 16-bit address is called for (i.e., an IEEE 802.15.4 "short address"), it MUST be formed by prepending an Interface label byte to the G.9959 NodeID:
当调用16位地址（即IEEE 802.15.4“短地址”）时，必须通过在G.9959节点ID前加一个接口标签字节来形成：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface | NodeID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface | NodeID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A transmitting node may be sending to an IPv6 destination address that can be reconstructed from the link-layer destination address. If the Interface number is zero (the default value), all IPv6 address bytes may be elided. Likewise, the Interface number of a fully elided IPv6 address (i.e., SAM/DAM=11) may be reconstructed to the value zero by a receiving node.
发送节点可以发送到可以从链路层目的地地址重构的IPv6目的地地址。如果接口号为零（默认值），则可以省略所有IPv6地址字节。类似地，完全省略的IPv6地址（即SAM/DAM＝11）的接口号可由接收节点重构为值零。
64-bit 802.15.4 address details do not apply.
64位802.15.4地址详细信息不适用。
The method of derivation of Interface Identifiers from 8-bit NodeIDs preserves uniqueness within the network. However, there is no protection from duplication through forgery. Neighbor Discovery in G.9959 links may be susceptible to threats as detailed in [RFC3756]. G.9959 networks may feature mesh routing. This implies additional threats due to ad hoc routing as per [KW03]. G.9959 provides capability for link-layer security. G.9959 nodes MUST use link-layer security with a shared key. Doing so will alleviate the majority of threats stated above. A sizable portion of G.9959 devices is expected to always communicate within their PAN (i.e., within their subnet, in IPv6 terms). In response to cost and power consumption considerations, these devices will typically implement the minimum set of features necessary. Accordingly, security for such devices may rely on the mechanisms defined at the link layer by G.9959. G.9959 relies on the Advanced Encryption Standard (AES) for authentication and encryption of G.9959 frames and further employs challenge-response handshaking to prevent replay attacks.
从8位节点ID派生接口标识符的方法保持了网络中的唯一性。但是，没有防止伪造复制的保护措施。如[RFC3756]所述，G.9959链路中的邻居发现可能容易受到威胁。G.9959网络可能采用网状路由。根据[KW03]，这意味着由于临时路由而产生的额外威胁。G.9959提供了链路层安全功能。G.9959节点必须使用具有共享密钥的链路层安全性。这样做将减轻上述大多数威胁。很大一部分G.9959设备预计总是在其PAN内通信（即，在IPv6术语中，在其子网内）。为了响应成本和功耗方面的考虑，这些设备通常会实现所需的最小功能集。因此，此类设备的安全性可依赖于G.9959在链路层定义的机制。G.9959依靠高级加密标准（AES）对G.9959帧进行身份验证和加密，并进一步采用质询-响应握手来防止重播攻击。
It is also expected that some G.9959 devices (e.g., billing and/or safety-critical products) will implement coordination or integration functions. These may communicate regularly with IPv6 peers outside the subnet. Such IPv6 devices are expected to secure their end-to-end communications with standard security mechanisms (e.g., IPsec, Transport Layer Security (TLS), etc.).
预计一些G.9959设备（如计费和/或安全关键产品）将实现协调或集成功能。它们可以定期与子网外的IPv6对等方通信。这类IPv6设备有望通过标准安全机制（例如IPsec、传输层安全（TLS）等）保护其端到端通信。
IP addresses may be used to track devices on the Internet; such devices can in turn be linked to individuals and their activities. Depending on the application and the actual use pattern, this may be undesirable. To impede tracking, globally unique and non-changing characteristics of IP addresses should be avoided, e.g., by frequently changing the global prefix and avoiding unique link-layer-derived IIDs in addresses.
IP地址可用于跟踪互联网上的设备；这样的装置可以反过来与个人及其活动相联系。根据应用程序和实际使用模式，这可能是不需要的。为了阻止跟踪，应避免IP地址的全局唯一性和不变特性，例如，通过频繁更改全局前缀和避免地址中的唯一链路层派生IID。
Some link layers use a 48-bit or 64-bit link-layer address that uniquely identifies the node on a global scale, regardless of global prefix changes. The risk of exposing a G.9959 device from its link-layer-derived IID is limited because of the short 8-bit link-layer address.
某些链路层使用48位或64位链路层地址，在全局范围内唯一标识节点，而不考虑全局前缀的更改。由于短的8位链路层地址，从其链路层派生的IID暴露G.9959设备的风险是有限的。
While intended for central address management, DHCPv6 address assignment also decouples the IPv6 address from the link-layer address. Addresses may be made dynamic by the use of a short DHCP lease period and an assignment policy that makes the DHCP server hand out a fresh IP address every time. For enhanced privacy, the DHCP-assigned addresses should be logged only for the duration of the lease, provided the implementation also allows logging for longer durations as per the operational policies.
DHCPv6地址分配用于中央地址管理，同时还将IPv6地址与链路层地址解耦。地址可以通过使用较短的DHCP租赁期和使DHCP服务器每次都分发新IP地址的分配策略而变得动态。为了增强隐私，DHCP分配的地址应仅在租赁期间记录，前提是实施还允许根据操作策略记录更长的持续时间。
It should be noted that privacy and frequently changing address assignments come at a cost. Non-link-layer-derived IIDs require the use of address registration. Further, non-link-layer-derived IIDs cannot be compressed; this leads to longer datagrams and increased link-layer segmentation. Finally, frequent prefix changes necessitate more Context Identifier updates; this not only leads to increased traffic but also may affect the battery lifetime of sleeping nodes.
应该注意的是，隐私和频繁更改地址分配是有代价的。非链路层派生的IID需要使用地址注册。此外，非链路层派生的iid不能被压缩；这将导致更长的数据报和更多的链路层分段。最后，频繁的前缀更改需要更多的上下文标识符更新；这不仅会导致通信量增加，还可能影响休眠节点的电池寿命。
[G.9959] International Telecommunication Union, "Short range narrow-band digital radiocommunication transceivers - PHY and MAC layer specifications", ITU-T Recommendation G.9959, January 2015, <http://www.itu.int/rec/T-REC-G.9959>.
[G.9959]国际电信联盟，“短程窄带数字无线电通信收发器-物理层和MAC层规范”，ITU-T建议G.9959，2015年1月<http://www.itu.int/rec/T-REC-G.9959>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>.
[RFC4122]Leach，P.，Mealling，M.和R.Salz，“通用唯一标识符（UUID）URN名称空间”，RFC 4122，2005年7月<http://www.rfc-editor.org/info/rfc4122>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月<http://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月<http://www.rfc-editor.org/info/rfc4291>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月<http://www.rfc-editor.org/info/rfc4861>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.
[RFC4944]黑山，G.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过IEEE 802.15.4网络传输IPv6数据包”，RFC 49442007年9月<http://www.rfc-editor.org/info/rfc4944>.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, September 2011, <http://www.rfc-editor.org/info/rfc6282>.
[RFC6282]Hui，J.和P.Thubert，“基于IEEE 802.15.4的网络上IPv6数据报的压缩格式”，RFC 62822011年9月<http://www.rfc-editor.org/info/rfc6282>.
[RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August 2011, <http://www.rfc-editor.org/info/rfc6355>.
[RFC6355]Narten，T.和J.Johnson，“基于UUID的DHCPv6唯一标识符（DUID-UUID）的定义”，RFC 63552011年8月<http://www.rfc-editor.org/info/rfc6355>.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, November 2012, <http://www.rfc-editor.org/info/rfc6775>.
[RFC6775]Shelby，Z.，Chakrabarti，S.，Nordmark，E.，和C.Bormann，“低功耗无线个人区域网络（6LoWPANs）上IPv6邻居发现优化”，RFC 67752012年11月<http://www.rfc-editor.org/info/rfc6775>.
[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 7400, November 2014, <http://www.rfc-editor.org/info/rfc7400>.
[RFC7400]Bormann，C.，“6LoWPAN GHC：低功率无线个人区域网络（6LoWPANs）上IPv6的通用报头压缩”，RFC 7400，2014年11月<http://www.rfc-editor.org/info/rfc7400>.
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64TM)", November 2012, <http://standards.ieee.org/ regauth/oui/tutorials/EUI64.html>.
[EUI64]IEEE，“64位全局标识符（EUI-64TM）指南”，2012年11月<http://standards.ieee.org/ regauth/oui/tutorials/EUI64.html>。
[KW03] Karlof, C. and D. Wagner, "Secure Routing in Sensor Networks: Attacks and Countermeasures", Elsevier Ad Hoc Networks Journal, Special Issue on Sensor Network Applications and Protocols, vol. 1, issues 2-3, September 2003.
[KW03]Karlof，C.和D.Wagner，“传感器网络中的安全路由：攻击和对策”，《爱思唯尔adhoc网络杂志》，传感器网络应用和协议专刊，第1卷，第2-3期，2003年9月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 33151003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, August 2003, <http://www.rfc-editor.org/info/rfc3587>.
[RFC3587]Hinden，R.，Deering，S.，和E.Nordmark，“IPv6全球单播地址格式”，RFC 3587，2003年8月<http://www.rfc-editor.org/info/rfc3587>.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004, <http://www.rfc-editor.org/info/rfc3756>.
[RFC3756]Nikander，P.，Kempf，J.和E.Nordmark，“IPv6邻居发现（ND）信任模型和威胁”，RFC 37562004年5月<http://www.rfc-editor.org/info/rfc3756>.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004, <http://www.rfc-editor.org/info/rfc3819>.
[RFC3819]Karn，P.，Bormann，C.，Fairhurst，G.，Grossman，D.，路德维希，R.，Mahdavi，J.，黑山，G.，Touch，J.，和L.Wood，“互联网子网络设计师的建议”，BCP 89，RFC 3819，2004年7月<http://www.rfc-editor.org/info/rfc3819>.
[RFC6550] Winter, T., Thubert, P., 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, March 2012, <http://www.rfc-editor.org/info/rfc6550>.
[RFC6550]温特，T.，图伯特，P.，布兰特，A.，许，J.，凯尔西，R.，列维斯，P.，皮斯特，K.，斯特鲁克，R.，瓦塞尔，JP.，和R.亚历山大，“RPL：低功耗和有损网络的IPv6路由协议”，RFC 65502012年3月<http://www.rfc-editor.org/info/rfc6550>.
[RFC6997] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. Martocci, "Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks", RFC 6997, August 2013, <http://www.rfc-editor.org/info/rfc6997>.
[RFC6997]Goyal，M.，Baccelli，E.，Philipp，M.，Brandt，A.，和J.Martocci，“低功率和有损网络中点对点路由的反应性发现”，RFC 69972013年8月<http://www.rfc-editor.org/info/rfc6997>.
This example outlines each individual bit of a sample IPv6 UDP packet arriving to a G.9959 node from a host in the Internet via a PAN border router.
此示例概述了通过泛边界路由器从Internet主机到达G.9959节点的示例IPv6 UDP数据包的每个位。
In the G.9959 PAN, the complete frame has the following fields.
在G.9959 PAN中，整个框架具有以下字段。
G.9959:
G.9959：
+------+---------+----------+---+-----+----------...
|HomeID|SrcNodeID|FrmControl|Len|SeqNo|DestNodeID|
+------+---------+----------+---+-----+----------+-...
+------+---------+----------+---+-----+----------...
|HomeID|SrcNodeID|FrmControl|Len|SeqNo|DestNodeID|
+------+---------+----------+---+-----+----------+-...
6LoWPAN:
6LoWPAN：
...+--------------+----------------+-----------------------...
|6LoWPAN CmdCls|6LoWPAN_IPHC Hdr|Compressed IPv6 headers|
...-------------+----------------+-----------------------+-...
...+--------------+----------------+-----------------------...
|6LoWPAN CmdCls|6LoWPAN_IPHC Hdr|Compressed IPv6 headers|
...-------------+----------------+-----------------------+-...
IPv6, TCP/UDP, App payload:
IPv6、TCP/UDP、应用程序负载：
...+-------------------------+------------+-----------+
|Uncompressed IPv6 headers|TCP/UDP/ICMP|App payload|
...------------------------+------------+-----------+
...+-------------------------+------------+-----------+
|Uncompressed IPv6 headers|TCP/UDP/ICMP|App payload|
...------------------------+------------+-----------+
The frame comes from the source IPv6 address 2001:0db8:ac10:ef01::ff:fe00:1206. The source prefix 2001:0db8:ac10:ef01/64 is identified by the IPHC CID = 3.
该帧来自源IPv6地址2001:0db8:ac10:ef01:：ff:fe00:1206。源前缀2001:0db8:ac10:ef01/64由IPHC CID=3标识。
The frame is delivered in direct range from the gateway that has source NodeID = 1. The Interface Identifier (IID) ff:fe00:1206 is recognized as a link-layer-derived address and is compressed to the 16-bit value 0x1206.
该帧从源节点ID=1的网关直接发送。接口标识符（IID）ff:fe00:1206被识别为链路层派生地址，并被压缩为16位值0x1206。
The frame is sent to the destination IPv6 address 2001:0db8:27ef:42ca::ff:fe00:0004. The destination prefix 2001:0db8:27ef:42ca/64 is identified by the IPHC CID = 2.
帧被发送到目标IPv6地址2001:0db8:27ef:42ca:：ff:fe00:0004。目标前缀2001:0db8:27ef:42ca/64由IPHC CID=2标识。
The IID ff:fe00:0004 is recognized as a link-layer-derived address.
IID ff:fe00:0004被识别为链路层派生地址。
Thanks to the link-layer-derived addressing rules, the sender knows that this is to be sent to G.9959 NodeID = 4, targeting the IPv6 interface instance number 0 (the default).
由于链路层派生的寻址规则，发送方知道这将发送到G.9959 NodeID=4，目标是IPv6接口实例号0（默认值）。
To reach the 6LoWPAN stack of the G.9959 node (skipping the G.9959 header fields), the first octet must be the 6LoWPAN Command Class (0x4F).
要访问G.9959节点的6LoWPAN堆栈（跳过G.9959头字段），第一个八位组必须是6LoWPAN命令类（0x4F）。
0
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-...
| 0x4F |
+-+-+-+-+-+-+-+-+-...
0
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-...
| 0x4F |
+-+-+-+-+-+-+-+-+-...
The Dispatch Header bits '011' advertise a compressed IPv6 header.
调度标头位“011”播发压缩的IPv6标头。
0 1
0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-...
| 0x4F |0 1 1
+-+-+-+-+-+-+-+-+-+-+-+-...
0 1
0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-...
| 0x4F |0 1 1
+-+-+-+-+-+-+-+-+-+-+-+-...
The following bits encode the first IPv6 header fields:
以下位对第一个IPv6标头字段进行编码：
TF = '11' : Traffic Class and Flow Label are elided
NH = '1' : Next Header is elided
HLIM = '10' : Hop limit is 64
TF = '11' : Traffic Class and Flow Label are elided
NH = '1' : Next Header is elided
HLIM = '10' : Hop limit is 64
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x4F |0 1 1 1 1 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x4F |0 1 1 1 1 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
CID = '1' : CI data follows the DAM field
SAC = '1' : Src addr uses stateful, context-based compression
SAM = '10' : Use src CID and 16 bits for link-layer-derived addr
M = '0' : Dest addr is not a multicast addr
DAC = '1' : Dest addr uses stateful, context-based compression
DAM = '11' : Use dest CID and dest NodeID to link-layer-derived addr
CID = '1' : CI data follows the DAM field
SAC = '1' : Src addr uses stateful, context-based compression
SAM = '10' : Use src CID and 16 bits for link-layer-derived addr
M = '0' : Dest addr is not a multicast addr
DAC = '1' : Dest addr uses stateful, context-based compression
DAM = '11' : Use dest CID and dest NodeID to link-layer-derived addr
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x4F |0 1 1 1 1 1 1 0|1 1 1 0 0 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x4F |0 1 1 1 1 1 1 0|1 1 1 0 0 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Address compression context identifiers:
地址压缩上下文标识符：
SCI = 0x3 DCI = 0x2
SCI=0x3 DCI=0x2
2 3
4 5 6 7 8 9 0 1
...+-+-+-+-+-+-+-+-...
| 0x3 | 0x2 |
...+-+-+-+-+-+-+-+-...
2 3
4 5 6 7 8 9 0 1
...+-+-+-+-+-+-+-+-...
| 0x3 | 0x2 |
...+-+-+-+-+-+-+-+-...
IPv6 header fields: (skipping "version" field) (skipping "Traffic Class") (skipping "flow label") (skipping "payload length")
IPv6头字段：（跳过“版本”字段）（跳过“流量类别”）（跳过“流量标签”）（跳过“有效负载长度”）
IPv6 header address fields:
IPv6标头地址字段：
SrcIP = 0x1206 : Use SCI and 16 least significant bits of link-layer-derived address
SrcIP=0x1206：使用SCI和链路层派生地址的16个最低有效位
(skipping DestIP ) - completely reconstructed from dest NodeID and DCI
（跳过destp）-完全从dest NodeID和DCI重建
2 3 4
4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x3 | 0x2 | 0x12 | 0x06 |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
2 3 4
4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x3 | 0x2 | 0x12 | 0x06 |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Next Header encoding for the UDP header:
UDP标头的下一个标头编码：
Dispatch = '11110': Next Header dispatch code for UDP header
C = '0' : 16-bit checksum carried inline
P = '00' : Both src port and dest port are carried in-line
Dispatch = '11110': Next Header dispatch code for UDP header
C = '0' : 16-bit checksum carried inline
P = '00' : Both src port and dest port are carried in-line
4 5
8 9 0 1 2 3 4 5
...+-+-+-+-+-+-+-+-...
|1 1 1 1 0|0|0 0|
...+-+-+-+-+-+-+-+-...
4 5
8 9 0 1 2 3 4 5
...+-+-+-+-+-+-+-+-...
|1 1 1 1 0|0|0 0|
...+-+-+-+-+-+-+-+-...
UDP header fields:
UDP标头字段：
src port = 0x1234 dest port = 0x5678
src端口=0x1234目标端口=0x5678
5 6 7 8
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 3 4 5 6 7
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x12 | 0x34 | 0x56 | 0x78 |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-..
5 6 7 8
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 3 4 5 6 7
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x12 | 0x34 | 0x56 | 0x78 |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-..
(skipping "length")
checksum = .... (actual checksum value depends on
the actual UDP payload)
(skipping "length")
checksum = .... (actual checksum value depends on
the actual UDP payload)
1
8 9 0
8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| (UDP checksum) |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
1
8 9 0
8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| (UDP checksum) |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Add your own UDP payload here...
在此处添加您自己的UDP负载。。。
Acknowledgements
致谢
Thanks to the authors of RFC 4944 and RFC 6282, and members of the IETF 6LoWPAN working group; this document borrows extensively from their work. Thanks to Erez Ben-Tovim, Erik Nordmark, Kerry Lynn, Michael Richardson, and Tommas Jess Christensen for useful comments. Thanks to Carsten Bormann for extensive feedback that improved this document significantly. Thanks to Brian Haberman for pointing out unclear details.
感谢RFC 4944和RFC 6282的作者以及IETF 6LoWPAN工作组的成员；这份文件广泛借鉴了他们的工作。感谢埃雷斯·本·托维姆、埃里克·诺德马克、克里·林恩、迈克尔·理查森和托马斯·杰西·克里斯滕森的有用评论。感谢Carsten Bormann的广泛反馈，大大改进了本文档。感谢Brian Haberman指出了不清楚的细节。
Authors' Addresses
作者地址
Anders Brandt Sigma Designs Emdrupvej 26A, 1. Copenhagen O 2100 Denmark
Anders Brandt Sigma设计Emdrupvej 26A，1。哥本哈根2100丹麦
EMail: anders_brandt@sigmadesigns.com
EMail: anders_brandt@sigmadesigns.com
Jakob Buron Sigma Designs Emdrupvej 26A, 1. Copenhagen O 2100 Denmark
雅各布·伯伦·西格玛设计Emdrupvej 26A，1。哥本哈根2100丹麦
EMail: jakob_buron@sigmadesigns.com
EMail: jakob_buron@sigmadesigns.com