Network Working Group N. Kushalnagar
Request for Comments: 4919 Intel Corp
Category: Informational G. Montenegro
Microsoft Corporation
C. Schumacher
Danfoss A/S
August 2007
Network Working Group N. Kushalnagar
Request for Comments: 4919 Intel Corp
Category: Informational G. Montenegro
Microsoft Corporation
C. Schumacher
Danfoss A/S
August 2007
IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals
低功耗无线个人区域网络（6LoWPANs）上的IPv6：概述、假设、问题陈述和目标
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes the assumptions, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only.
本文档描述了通过IEEE 802.15.4网络传输IP的假设、问题陈述和目标。本文件中列举的目标集仅构成初始目标集。
Table of Contents
目录
1. Introduction ....................................................2
2. Overview ........................................................2
3. Assumptions .....................................................3
4. Problems ........................................................4
4.1. IP Connectivity ............................................4
4.2. Topologies .................................................5
4.3. Limited Packet Size ........................................6
4.4. Limited Configuration and Management .......................6
4.5. Service Discovery ..........................................6
4.6. Security ...................................................6
5. Goals ...........................................................7
6. Security Considerations .........................................9
7. Acknowledgements ...............................................10
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
1. Introduction ....................................................2
2. Overview ........................................................2
3. Assumptions .....................................................3
4. Problems ........................................................4
4.1. IP Connectivity ............................................4
4.2. Topologies .................................................5
4.3. Limited Packet Size ........................................6
4.4. Limited Configuration and Management .......................6
4.5. Service Discovery ..........................................6
4.6. Security ...................................................6
5. Goals ...........................................................7
6. Security Considerations .........................................9
7. Acknowledgements ...............................................10
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
Low-power wireless personal area networks (LoWPANs) comprise devices that conform to the IEEE 802.15.4-2003 standard by the IEEE [IEEE802.15.4]. IEEE 802.15.4 devices are characterized by short range, low bit rate, low power, and low cost. Many of the devices employing IEEE 802.15.4 radios will be limited in their computational power, memory, and/or energy availability.
低功率无线个人区域网络（LoWPANs）包括符合IEEE[IEEE802.15.4]的IEEE 802.15.4-2003标准的设备。IEEE 802.15.4设备具有短距离、低比特率、低功耗和低成本的特点。许多采用IEEE 802.15.4无线电的设备在计算能力、内存和/或能量可用性方面受到限制。
This document gives an overview of LoWPANs and describes how they benefit from IP and, in particular, IPv6 networking. It describes LoWPAN requirements with regards to the IP layer and the above, and spells out the underlying assumptions of IP for LoWPANs. Finally, it describes problems associated with enabling IP communication with devices in a LoWPAN, and defines goals to address these in a prioritized manner. Admittedly, not all items on this list may be necessarily appropriate tasks for the IETF. Nevertheless, they are documented here to give a general overview of the larger problem. This is useful both to structure work within the IETF as well as to better understand how to coordinate with external organizations.
本文档概述了LoWPANs，并描述了它们如何受益于IP，尤其是IPv6网络。它描述了与IP层及以上相关的低PAN要求，并阐明了低PAN IP的基本假设。最后，它描述了与以低范围实现与设备的IP通信相关的问题，并定义了以优先方式解决这些问题的目标。诚然，并非该列表中的所有项目都适用于IETF。尽管如此，这里记录了它们是为了对更大的问题进行总体概述。这对IETF内的工作结构以及更好地理解如何与外部组织协调都很有用。
A LoWPAN is a simple low cost communication network that allows wireless connectivity in applications with limited power and relaxed throughput requirements. A LoWPAN typically includes devices that work together to connect the physical environment to real-world applications, e.g., wireless sensors. LoWPANs conform to the IEEE 802.15.4-2003 standard [IEEE802.15.4].
LoWPAN是一种简单的低成本通信网络，允许在功率有限且吞吐量要求较低的应用中进行无线连接。LoWPAN通常包括协同工作以将物理环境连接到现实世界应用程序（例如，无线传感器）的设备。低端符合IEEE 802.15.4-2003标准[IEEE802.15.4]。
Some of the characteristics of LoWPANs are as follows:
LoWPANs的一些特征如下：
1. Small packet size. Given that the maximum physical layer packet is 127 bytes, the resulting maximum frame size at the media access control layer is 102 octets. Link-layer security imposes further overhead, which in the maximum case (21 octets of overhead in the AES-CCM-128 case, versus 9 and 13 for AES-CCM-32 and AES-CCM-64, respectively), leaves 81 octets for data packets.
1. 小包大小。假设最大物理层分组为127字节，则在媒体访问控制层产生的最大帧大小为102个八位字节。链路层安全带来了进一步的开销，在最大情况下（AES-CCM-128的开销为21个八位字节，而AES-CCM-32和AES-CCM-64的开销分别为9和13个八位字节），为数据包留下81个八位字节。
2. Support for both 16-bit short or IEEE 64-bit extended media access control addresses.
2. 支持16位短地址或IEEE 64位扩展媒体访问控制地址。
3. Low bandwidth. Data rates of 250 kbps, 40 kbps, and 20 kbps for each of the currently defined physical layers (2.4 GHz, 915 MHz, and 868 MHz, respectively).
3. 低带宽。当前定义的每个物理层（分别为2.4 GHz、915 MHz和868 MHz）的数据速率分别为250 kbps、40 kbps和20 kbps。
4. Topologies include star and mesh operation.
4. 拓扑包括星形和网状操作。
5. Low power. Typically, some or all devices are battery operated.
5. 低功耗。通常，部分或所有设备由电池供电。
6. Low cost. These devices are typically associated with sensors, switches, etc. This drives some of the other characteristics such as low processing, low memory, etc. Numerical values for "low" elided on purpose since costs tend to change over time.
6. 低成本。这些设备通常与传感器、开关等相关。这会驱动一些其他特性，如低处理、低内存等。由于成本往往会随时间变化，因此故意省略“低”的数值。
7. Large number of devices expected to be deployed during the lifetime of the technology. This number is expected to dwarf the number of deployed personal computers, for example.
7. 在技术生命周期内，预计将部署大量设备。例如，预计这一数字将使部署的个人电脑数量相形见绌。
8. Location of the devices is typically not predefined, as they tend to be deployed in an ad-hoc fashion. Furthermore, sometimes the location of these devices may not be easily accessible. Additionally, these devices may move to new locations.
8. 设备的位置通常不是预定义的，因为它们往往是以特别的方式部署的。此外，有时这些设备的位置可能不容易接近。此外，这些设备可能会移动到新的位置。
9. Devices within LoWPANs tend to be unreliable due to variety of reasons: uncertain radio connectivity, battery drain, device lockups, physical tampering, etc.
9. 由于各种原因，低端设备往往不可靠：无线电连接不确定、电池耗尽、设备锁定、物理篡改等。
10. In many environments, devices connected to a LoWPAN may sleep for long periods of time in order to conserve energy, and are unable to communicate during these sleep periods.
10. 在许多环境中，连接到LoWPAN的设备可能会长时间睡眠以节省能源，并且在这些睡眠期间无法通信。
The following sections take into account these characteristics in describing the assumptions, problems statement, and goals for LoWPANs, and, in particular, for 6LoWPANs (IPv6-based LoWPAN networks).
以下章节在描述LoWPANs的假设、问题陈述和目标时考虑了这些特征，特别是6LoWPANs（基于IPv6的LoWPAN网络）。
Given the small packet size of LoWPANs, this document presumes applications typically send small amounts of data. However, the protocols themselves do not restrict bulk data transfers.
鉴于LoWPANs的数据包大小较小，本文假定应用程序通常发送少量数据。但是，协议本身并不限制批量数据传输。
LoWPANs, as described in this document, are based on IEEE 802.15.4-2003. It is possible that the specification may undergo changes in the future and may change some of the requirements mentioned above.
如本文件所述，LoWPANs基于IEEE 802.15.4-2003。规范将来可能会发生变化，并且可能会改变上述部分要求。
Some of these assumptions are based on the limited capabilities of devices within LoWPANs. As devices become more powerful, and consume less power, some of the requirements mentioned above may be somewhat relaxed.
其中一些假设是基于低端设备的有限能力。随着设备功能的增强和功耗的降低，上面提到的一些要求可能会有所放宽。
While some LoWPAN devices are expected to be extremely limited (the so-called "Reduced Function Devices" or RFDs), more capable "Full Function Devices" (FFDs) will also be present, albeit in much smaller numbers. FFDs will typically have more resources and may be mains powered. Accordingly, FFDs will aid RFDs by providing functions such as network coordination, packet forwarding, interfacing with other types of networks, etc.
虽然一些低潘设备预计将非常有限（所谓的“缩减功能设备”或RFD），但也将出现功能更强大的“全功能设备”（FFD），尽管数量要少得多。FFD通常会有更多的资源，并且可能由主电源供电。因此，FFD将通过提供网络协调、数据包转发、与其他类型网络的接口等功能来帮助RFD。
The application of IP technology is assumed to provide the following benefits:
假定IP技术的应用可提供以下好处：
1. The pervasive nature of IP networks allows use of existing infrastructure.
1. IP网络的普及性允许使用现有的基础设施。
2. IP-based technologies already exist, are well-known, and proven to be working.
2. 基于IP的技术已经存在，是众所周知的，并且被证明是有效的。
3. An admittedly non-technical but important consideration is that IP networking technology is specified in open and freely available specifications, which is favorable or at least able to be better understood by a wider audience than proprietary solutions.
3. 一个公认的非技术性但重要的考虑因素是，IP网络技术是在开放和免费提供的规范中指定的，这比专有解决方案更有利或至少能够被更广泛的受众更好地理解。
4. Tools for diagnostics, management, and commissioning of IP networks already exist.
4. IP网络的诊断、管理和调试工具已经存在。
5. IP-based devices can be connected readily to other IP-based networks, without the need for intermediate entities like translation gateways or proxies.
5. 基于IP的设备可以方便地连接到其他基于IP的网络，而不需要翻译网关或代理等中间实体。
Based on the characteristics defined in the overview section, the following sections elaborate on the main problems with IP for LoWPANs.
根据概述一节中定义的特征，以下各节详细阐述了低面板IP的主要问题。
The requirement for IP connectivity within a LoWPAN is driven by the following:
低范围内的IP连接要求由以下因素驱动：
1. The many devices in a LoWPAN make network auto configuration and statelessness highly desirable. And for this, IPv6 has ready solutions.
1. 低范围内的许多设备使得网络自动配置和无状态成为人们非常需要的。为此，IPv6提供了现成的解决方案。
2. The large number of devices poses the need for a large address space, well met by IPv6.
2. 大量的设备需要大量的地址空间，IPv6很好地满足了这一需求。
3. Given the limited packet size of LoWPANs, the IPv6 address format allows subsuming of IEEE 802.15.4 addresses if so desired.
3. 鉴于LoWPANs的数据包大小有限，如果需要，IPv6地址格式允许包含IEEE 802.15.4地址。
4. Simple interconnectivity to other IP networks including the Internet.
4. 与其他IP网络（包括Internet）的简单互连。
However, given the limited packet size, headers for IPv6 and layers above must be compressed whenever possible.
然而，考虑到有限的数据包大小，必须尽可能压缩IPv6和以上层的报头。
LoWPANs must support various topologies including mesh and star.
LoWPANs必须支持各种拓扑，包括网格和星形。
Mesh topologies imply multi-hop routing, to a desired destination. In this case, intermediate devices act as packet forwarders at the link layer (akin to routers at the network layer). Typically these are "full function devices" that have more capabilities in terms of power, computation, etc. The requirements on the routing protocol are:
网状拓扑意味着到所需目的地的多跳路由。在这种情况下，中间设备充当链路层的数据包转发器（类似于网络层的路由器）。通常，这些是在功率、计算等方面具有更多能力的“全功能设备”。对路由协议的要求如下：
1. Given the minimal packet size of LoWPANs, the routing protocol must impose low (or no) overhead on data packets, hopefully independently of the number of hops.
1. 给定LoWPANs的最小数据包大小，路由协议必须对数据包施加低（或无）开销，希望与跳数无关。
2. The routing protocols should have low routing overhead (low chattiness) balanced with topology changes and power conservation.
2. 路由协议应具有低路由开销（低聊天次数），并与拓扑变化和节能相平衡。
3. The computation and memory requirements in the routing protocol should be minimal to satisfy the low cost and low power objectives. Thus, storage and maintenance of large routing tables is detrimental.
3. 路由协议中的计算和内存需求应该最小，以满足低成本和低功耗的目标。因此，存储和维护大型路由表是有害的。
4. Support for network topologies in which either FFDs or RFDs may be battery or mains-powered. This implies the appropriate considerations for routing in the presence of sleeping nodes.
4. 支持网络拓扑，其中FFD或RFD可以由电池或电源供电。这意味着在存在休眠节点的情况下进行路由时需要考虑适当的因素。
As with mesh topologies, star topologies include provisioning a subset of devices with packet forwarding functionality. If, in addition to IEEE 802.15.4, these devices use other kinds of network interfaces such as ethernet or IEEE 802.11, the goal is to seamlessly integrate the networks built over those different technologies. This, of course, is a primary motivation to use IP to begin with.
与网状拓扑一样，星形拓扑包括提供具有数据包转发功能的设备子集。如果除IEEE 802.15.4外，这些设备还使用其他类型的网络接口，如以太网或IEEE 802.11，则目标是无缝集成基于这些不同技术构建的网络。当然，这是开始使用IP的主要动机。
Applications within LoWPANs are expected to originate small packets. Adding all layers for IP connectivity should still allow transmission in one frame, without incurring excessive fragmentation and reassembly. Furthermore, protocols must be designed or chosen so that the individual "control/protocol packets" fit within a single 802.15.4 frame. Along these lines, IPv6's requirement of sub-IP reassembly (see Section 5) may pose challenges for low-end LoWPAN devices that do not have enough RAM or storage for a 1280-octet packet.
LoWPANs中的应用程序预计会产生小数据包。为IP连接添加所有层仍应允许在一个帧中传输，而不会导致过度碎片化和重新组装。此外，协议的设计或选择必须确保单个“控制/协议包”适合单个802.15.4帧。沿着这些思路，IPv6对子IP重组的要求（见第5节）可能会对低端低潘设备提出挑战，因为这些设备没有足够的RAM或存储空间来容纳1280个八位组的数据包。
As alluded to above, devices within LoWPANs are expected to be deployed in exceedingly large numbers. Additionally, they are expected to have limited display and input capabilities. Furthermore, the location of some of these devices may be hard to reach. Accordingly, protocols used in LoWPANs should have minimal configuration, preferably work "out of the box", be easy to bootstrap, and enable the network to self heal given the inherent unreliable characteristic of these devices. The size constraints of the link layer protocol should also be considered. Network management should have little overhead, yet be powerful enough to control dense deployment of devices.
如上所述，预计LoWPANs内的设备将大量部署。此外，预计它们的显示和输入能力有限。此外，其中一些设备的位置可能很难到达。因此，LoWPANs中使用的协议应具有最小的配置，最好是“开箱即用”，易于引导，并且鉴于这些设备固有的不可靠特性，使网络能够自我修复。还应考虑链路层协议的大小限制。网络管理的开销应该很小，但功能强大到足以控制设备的密集部署。
LoWPANs require simple service discovery network protocols to discover, control and maintain services provided by devices. In some cases, especially in dense deployments, abstraction of several nodes to provide a service may be beneficial. In order to enable such features, new protocols may have to be designed.
LoWPANs需要简单的服务发现网络协议来发现、控制和维护设备提供的服务。在某些情况下，特别是在密集部署中，抽象多个节点以提供服务可能是有益的。为了实现这些功能，可能必须设计新的协议。
IEEE 802.15.4 mandates link-layer security based on AES, but it omits any details about topics like bootstrapping, key management, and security at higher layers. Of course, a complete security solution for LoWPAN devices must consider application needs very carefully. Please refer to the security consideration section below for a more detailed discussion and in-depth security requirements.
IEEE 802.15.4规定了基于AES的链路层安全性，但它忽略了有关引导、密钥管理和更高层安全性等主题的任何细节。当然，对于LoWPAN设备来说，一个完整的安全解决方案必须非常仔细地考虑应用需求。有关更详细的讨论和深入的安全要求，请参阅下面的安全考虑部分。
The goals mentioned below are general and not limited to IETF activities. As such, they may not only refer to work that can be done within the IETF (e.g., specification required to transmit IP, profile of best practices for transmitting IP packets, and associated upper level protocols, etc). They also point at work more relevant to other standards bodies (e.g., desirable changes to or profiles relevant to IEEE 802.15.4, W3C, etc). When the goals fall under the IETF's purview, they serve to point out what those efforts should strive to accomplish, regardless of whether they are pursued within one (or more) new (or existing) working groups. When the goals do not fall under the purview of the IETF, documenting them here serves as input to other organizations [LIAISON].
以下提到的目标是一般性的，不限于IETF活动。因此，它们可能不仅指可以在IETF内完成的工作（例如，传输IP所需的规范、传输IP数据包的最佳实践概要以及相关的上层协议等）。它们还指出了与其他标准机构更相关的工作（例如，IEEE 802.15.4、W3C等相关的理想变更或概要文件）。当这些目标属于IETF的权限时，它们可以用来指出这些努力应该努力实现什么，而不管这些努力是在一个（或多个）新的（或现有的）工作组内实现的。当目标不在IETF的权限范围内时，将其记录在此处作为其他组织的输入[联络]。
Note that a common underlying goal is to reduce packet overhead, bandwidth consumption, processing requirements, and power consumption.
请注意，一个共同的基本目标是减少数据包开销、带宽消耗、处理要求和功耗。
The following are the goals according to priority for LoWPANs:
以下是根据LoWPANs优先级确定的目标：
1. Fragmentation and Reassembly layer: As mentioned in the overview, the protocol data units may be as small as 81 bytes. This is obviously far below the minimum IPv6 packet size of 1280 octets, and in keeping with Section 5 of the IPv6 specification [RFC2460], a fragmentation and reassembly adaptation layer must be provided at the layer below IP.
1. 碎片和重组层：如概述中所述，协议数据单元可能小到81字节。这显然远低于1280个八位字节的最小IPv6数据包大小，并且根据IPv6规范[RFC2460]第5节的规定，必须在IP下的层提供碎片和重组适配层。
2. Header Compression: Given that in the worst case the maximum size available for transmitting IP packets over an IEEE 802.15.4 frame is 81 octets, and that the IPv6 header is 40 octets long, (without optional headers), this leaves only 41 octets for upper-layer protocols, like UDP and TCP. UDP uses 8 octets in the header and TCP uses 20 octets. This leaves 33 octets for data over UDP and 21 octets for data over TCP. Additionally, as pointed above, there is also a need for a fragmentation and reassembly layer, which will use even more octets leaving very few octets for data. Thus, if one were to use the protocols as is, it would lead to excessive fragmentation and reassembly, even when data packets are just 10s of octets long. This points to the need for header compression. As there is much published and in-progress standardization work on header compression, the 6LoWPAN community needs to investigate using existing header compression techniques, and, if necessary, specify new ones.
2. 报头压缩：在最坏的情况下，通过IEEE 802.15.4帧传输IP数据包的最大可用大小为81个八位字节，而IPv6报头的长度为40个八位字节（没有可选的报头），因此上层协议（如UDP和TCP）只剩下41个八位字节。UDP在报头中使用8个八位字节，TCP使用20个八位字节。这使得UDP上的数据保留了33个八位字节，TCP上的数据保留了21个八位字节。此外，如上所述，还需要一个碎片和重组层，它将使用更多的八位字节，只留下很少的八位字节用于数据。因此，如果按原样使用协议，将导致过度的碎片化和重组，即使数据包只有10秒的八位字节长。这表明需要对报头进行压缩。由于有许多已发布和正在进行的关于头部压缩的标准化工作，6LoWPAN社区需要使用现有的头部压缩技术进行调查，如有必要，还需要指定新的头部压缩技术。
3. Address Autoconfiguration: [6LoWPAN] specifies methods for creating IPv6 stateless address auto configuration. Stateless auto configuration (as compared to stateful) is attractive for 6LoWPANs, because it reduces the configuration overhead on the hosts. There is a need for a method to generate an "interface identifier" from the EUI-64 [EUI64] assigned to the IEEE 802.15.4 device.
3. 地址自动配置：[6LoWPAN]指定用于创建IPv6无状态地址自动配置的方法。无状态自动配置（与有状态相比）对于6LoWPANs很有吸引力，因为它减少了主机上的配置开销。需要一种从分配给IEEE 802.15.4设备的EUI-64[EUI64]生成“接口标识符”的方法。
4. Mesh Routing Protocol: A routing protocol to support a multi-hop mesh network is necessary. There is much published work on ad-hoc multi hop routing for devices. Some examples include [RFC3561], [RFC3626], [RFC3684], all experimental. Also, these protocols are designed to use IP-based addresses that have large overheads. For example, the Ad hoc On-Demand Distance Vector (AODV) [RFC3561] routing protocol uses 48 octets for a route request based on IPv6 addressing. Given the packet-size constraints, transmitting this packet without fragmentation and reassembly may be difficult. Thus, care should be taken when using existing routing protocols (or designing new ones) so that the routing packets fit within a single IEEE 802.15.4 frame.
4. Mesh路由协议：需要一个支持多跳Mesh网络的路由协议。关于设备的ad-hoc多跳路由有很多已发表的工作。一些例子包括[RFC3561]、[RFC3626]、[RFC3684]，都是实验性的。此外，这些协议设计为使用基于IP的地址，这些地址的开销很大。例如，adhoc按需距离向量（AODV）[RFC3561]路由协议使用48个八位字节作为基于IPv6寻址的路由请求。考虑到数据包大小的限制，在没有碎片和重组的情况下传输该数据包可能会很困难。因此，在使用现有路由协议（或设计新的路由协议）时应小心，以便路由数据包适合单个IEEE 802.15.4帧。
5. Network Management: One of the points of transmitting IPv6 packets is to reuse existing protocols as much as possible. Network management functionality is critical for LoWPANs. However, management solutions need to meet the resource constraints as well as the minimal configuration and self-healing functionality described in Section 4.4. The Simple Network Management Protocol (SNMP) [RFC3410] is widely used for monitoring data sources and sensors in conventional networks. SNMP functionality may be translated "as is" to LoWPANs with the benefit to utilize existing tools. However, due to the memory, processing, and message size constraints, further investigation is required to determine if the use of SNMPv3 is suitable, or if an appropriate adaptation of SNMPv3 or use of different protocols is in order.
5. 网络管理：传输IPv6数据包的要点之一是尽可能重用现有协议。网络管理功能对于LoWPANs至关重要。但是，管理解决方案需要满足资源限制以及第4.4节中描述的最低配置和自愈功能。简单网络管理协议（SNMP）[RFC3410]广泛用于监控传统网络中的数据源和传感器。SNMP功能可以“按原样”转换为低水平，这有利于利用现有工具。然而，由于内存、处理和消息大小的限制，需要进一步调查以确定SNMPv3的使用是否合适，或者SNMPv3的适当适配或不同协议的使用是否有序。
6. Implementation Considerations: It may be the case that transmitting IP over IEEE 802.15.4 would become more beneficial if implemented in a "certain" way. Accordingly, implementation considerations are to be documented.
6. 实施注意事项：如果以“特定”方式实施，则通过IEEE 802.15.4传输IP可能会变得更加有益。因此，应记录实施注意事项。
7. Application and higher layer Considerations: As header compression becomes more prevalent, overall performance will depend even more on efficiency of application protocols. Heavyweight protocols based on XML such as SOAP [SOAP], may not be suitable for LoWPANs. As such, more compact encodings (and perhaps protocols) may become necessary. The goal here is to specify or suggest modifications to existing protocols so that
7. 应用程序和更高层的注意事项：随着报头压缩变得越来越普遍，总体性能将更加依赖于应用程序协议的效率。基于XML的重量级协议（如SOAP[SOAP]）可能不适用于LoWPANs。因此，可能需要更紧凑的编码（可能还有协议）。这里的目标是指定或建议对现有协议的修改，以便
they are suitable for LoWPANs. Furthermore, application level interoperability specifications may also become necessary in the future and may thus be specified.
它们适用于低档。此外，应用程序级互操作性规范在将来也可能成为必要的，因此可能会被指定。
8. Security Considerations: Security threats at different layers must be clearly understood and documented. Bootstrapping of devices into a secure network could also be considered given the location, limited display, high density, and ad-hoc deployment of devices.
8. 安全注意事项：必须清楚地理解和记录不同层次的安全威胁。考虑到设备的位置、有限的显示、高密度和特殊部署，也可以考虑将设备引导到安全网络中。
IPv6 over LoWPAN (6LoWPAN) applications often require confidentiality and integrity protection. This can be provided at the application, transport, network, and/or at the link layer (i.e., within the 6LoWPAN set of specifications). In all these cases, prevailing constraints will influence the choice of a particular protocol. Some of the more relevant constraints are small code size, low power operation, low complexity, and small bandwidth requirements.
IPv6 over LoWPAN（6LoWPAN）应用程序通常需要保密性和完整性保护。这可以在应用程序、传输、网络和/或链路层（即在6LoWPAN规范集内）提供。在所有这些情况下，普遍存在的限制将影响特定协议的选择。一些更相关的约束是小代码大小、低功耗操作、低复杂性和小带宽要求。
Given these constraints, first, a threat model for 6LoWPAN devices needs to be developed in order to weigh any risks against the cost of their mitigations while making meaningful assumptions and simplifications. Some examples for threats that should be considered are man-in-the-middle attacks and denial of service attacks.
考虑到这些限制，首先，需要开发6LoWPAN设备的威胁模型，以便在做出有意义的假设和简化的同时，将任何风险与其缓解措施的成本进行权衡。应考虑的威胁示例包括中间人攻击和拒绝服务攻击。
A separate set of security considerations apply to bootstrapping a 6LoWPAN device into the network (e.g., for initial key establishment). This generally involves application level exchanges or out-of-band techniques for the initial key establishment, and may rely on application-specific trust models; thus, it is considered extraneous to 6LoWPAN and is not addressed in these specifications. In order to be able to select (or design) this next set of protocols, there needs to be a common model of the keying material created by the initial key establishment.
一组单独的安全注意事项适用于将6LoWPAN设备引导到网络中（例如，初始密钥建立）。这通常涉及用于初始密钥建立的应用程序级交换或带外技术，并且可能依赖于特定于应用程序的信任模型；因此，它被认为与6LoWPAN无关，在这些规范中没有涉及。为了能够选择（或设计）下一组协议，需要一个由初始密钥建立创建的密钥材料的通用模型。
Beyond initial key establishment, protocols for subsequent key management as well as to secure the data traffic do fall under the purview of 6LoWPAN. Here, the different alternatives (TLS, IKE/ IPsec, etc.) must be evaluated in light of the 6LoWPAN constraints.
除了初始密钥建立之外，用于后续密钥管理以及保护数据通信的协议也属于6LoWPAN的权限范围。在这里，必须根据6LoWPAN约束来评估不同的备选方案（TLS、IKE/IPsec等）。
One argument for using link layer security is that most IEEE 802.15.4 devices already have support for AES link-layer security. AES is a block cipher operating on blocks of fixed length, i.e., 128 bits. To encrypt longer messages, several modes of operation may be used. The earliest modes described, such as ECB, CBC, OFB and CFB provide only confidentiality, and this does not ensure message integrity. Other modes have been designed which ensure both confidentiality and
使用链路层安全性的一个理由是，大多数IEEE 802.15.4设备已经支持AES链路层安全性。AES是一种在固定长度块（即128位）上运行的分组密码。要加密较长的消息，可以使用几种操作模式。描述的最早的模式，如ECB、CBC、OFB和CFB，只提供机密性，这不能确保消息的完整性。还设计了其他模式，以确保机密性和安全性
message integrity, such as CCM* mode. 6LoWPAN networks can operate in any of the previous modes, but it is desirable to utilize the most secure modes available for link-layer security (e.g., CCM*), and build upon it.
消息完整性，如CCM*模式。6LoWPAN网络可以在以前的任何模式下运行，但最好利用链路层安全可用的最安全模式（如CCM*），并在此基础上进行构建。
For network layer security, two models are applicable: end-to-end security, e.g., using IPsec transport mode, or security that is limited to the wireless portion of the network, e.g., using a security gateway and IPsec tunnel mode. The disadvantage of the latter is the larger header size, which is significant at the 6LoWPAN frame MTUs. To simplify 6LoWPAN implementations, it is beneficial to identify the relevant security model, and to identify a preferred set of cipher suites that are appropriate given the constraints.
对于网络层安全性，有两种模型适用：端到端安全性，例如使用IPsec传输模式；或仅限于网络无线部分的安全性，例如使用安全网关和IPsec隧道模式。后者的缺点是收割台尺寸较大，这在6 Lowpan机架MTU上非常明显。为了简化6LoWPAN实现，确定相关的安全模型，并确定一组在给定约束条件下合适的首选密码套件是有益的。
Thanks to Geoff Mulligan, Soohong Daniel Park, Samita Chakrabarti, Brijesh Kumar, and Miguel Garcia for their comments and help in shaping this document.
感谢Geoff Mulligan、Soohong Daniel Park、Samita Chakrabarti、Brijesh Kumar和Miguel Garcia在形成本文件方面的评论和帮助。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[IEEE802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2003", October 2003.
[IEEE802.15.4]IEEE计算机协会，“IEEE标准802.15.4-2003”，2003年10月。
[EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY", IEEE, http://standards.ieee.org/ regauth/oui/tutorials/EUI64.html.
[EUI64]“64位全局标识符（EUI-64）注册机构指南”，IEEE，http://standards.ieee.org/ regauth/oui/tutorials/EUI64.html。
[6LoWPAN] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", Work in Progress, May 2005.
[6LoWPAN]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，正在进行的工作，2005年5月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]Harrington，D.，Presohn，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, July 2003.
[RFC3561]Perkins，C.，Belding Royer，E.，和S.Das，“临时按需距离向量（AODV）路由”，RFC 3561，2003年7月。
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.
[RFC3626]Clausen，T.和P.Jacquet，“优化链路状态路由协议（OLSR）”，RFC 3626，2003年10月。
[RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)", RFC 3684, February 2004.
[RFC3684]Ogier，R.，Templin，F.，和M.Lewis，“基于反向路径转发（TBRPF）的拓扑传播”，RFC 3684，2004年2月。
[SOAP] "XML Protocol Working Group", W3C, http://www.w3c.org/2000/xp/Group/.
[SOAP]“XML协议工作组”，W3C，http://www.w3c.org/2000/xp/Group/.
[LIAISON] "IETF Liaison Activities", IETF, http://www.ietf.org/liaisonActivities.html.
[联络]“IETF联络活动”，IETF，http://www.ietf.org/liaisonActivities.html.
Authors' Addresses
作者地址
Nandakishore Kushalnagar Intel Corp
南达基肖尔库沙尔纳加尔英特尔公司
EMail: nandakishore.kushalnagar@intel.com
EMail: nandakishore.kushalnagar@intel.com
Gabriel Montenegro Microsoft Corporation
加布里埃尔黑山微软公司
EMail: gabriel.montenegro@microsoft.com
EMail: gabriel.montenegro@microsoft.com
Christian Peter Pii Schumacher Danfoss A/S
克里斯蒂安·彼得·皮伊·舒马赫·丹佛斯A/S
EMail: schumacher@danfoss.com
EMail: schumacher@danfoss.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。