[译]RFC4919（中文版）IPv6应用于低功耗无线个人局域网(6LoWPANs)： 概述，设想，问题陈述，目标

IPv6应用于低功耗无线个人局域网(6LoWPANs)：

概述，设想，问题陈述，目标

 

文档声明

这份文档为因特网社区提供信息。它不指定为一种因特网标准。这份文档的分发不受限制。

版权

IETF组织版权所有（2007）。

摘要

这份文档描述了在IEEE802.15.4网络上传输IP数据的假设，问题和目标。本文所列举的目标仅仅形成了一个初始的目标集合。 

1、 简介

低功耗无线个人局域网（LoWPANs）包含符合IEEE 802.15.4－2003标准[IEEE802.15.4]的设备。IEEE 802.15.4设备的特点是近距离、低速率、低功耗和低成本。多数使用IEEE 802.15.4射频的设备都在计算能力、存储、和/或电源上有所限制。 

这份文档概述了LoWPANs并描述了它如何在IP网络特别是IPv6网络中使用。本文描述了LoWPAN在关于IP层和上层的要求，并给出了一些在LoWPANs上使用IP的假想。最后，本文描述了在LoWPANs设备上使用IP通信的相关问题，并为优先方式解决这些问题定义目标。当然，本文所列的项目未必全都适合于IETF工作。然而，本文是为了给一个更大的问题做一个简要的概述。这对于IETF组织工作和更好的和其他组织合作都是有好处的。 

2、 概述 

LoWPAN是一个简单的低成本通信网络，它可以在有限电源和低网络速率要求的应用中使用无线通信。一个典型的LoWPAN包含互联的设备用于连接物理环境和现实应用，如无线传感器。LoWPANs服从IEEE 802.15.4－2003标准[IEEE802.15.4]。 

       以下是一些LoWPANs的特点：

1） 报文很小。因为物理层的最大数据包是127字节，所以介质访问控制层的最大帧长是102字节。链路层安全协议也占用了一定的空间（AES－CCM－128点用21字节，AES－CCM－32占用9字节，AES－CCM－64占用13字节），所以剩下给用户数据的空间可能只有81字节。

2） 支持16位短地址和IEEE扩展MAC地址。

3） 低带宽。数据速率是250kbps，40kbps，20kbps分别对应于已定义的物理层（2.4GHz,915MHz,868MHz）。

4） 拓扑结构包括星形和mesh网络。

5） 低功耗。典型地，一些或全部设备使用电池供电。

6） 低成本。这些设备用作是传感器、开关等。这些设备还有其他一些特点如处理能力低、存储少等。“低”的具体数值就不指定了因为成本会随时间而改变。

7） 在这项技术的生命周期内会有大量的设备被部署。例如，这些设备的数量将会使个人电脑的数量显得非常渺小。

8） 设备的地点通常不是事先设定的，因为设备会以点对点的方式进行部署。另外，有些设备的位置是不容易进入的。而且，设备可能会移动到新的位置。

9） LoWPANs设备多是不可靠的，原因有几点：不确定的射频连接、电池耗尽、设备锁定、物理干扰等。

10）             在很多环境下，连接到LoWPAN的设备为了节约电量可能长时间处于休眠状态，而在休眠时期不能进行通信。 

接下来的章节会对LoWPANs特别地是6LoWPANs（基于IPv6的LoWPANs网络）的假设、问题陈述、目标进行具体的描述。

3、 假设 

基于LoWPANs的报文是很小的，本文假定应用通常只发送很少量的数据。然而，协议本身并没有限制发送大量数据。 

在本文所描述的LoWPANs是基于IEEE802.15.4-2003的。具体的规格可能会在未来发生改变，上述提到的一些要求也可能会变化。 

部分假设是基于LoWPANs网络的设备处理能力是有限的。当设备的处理能力变强、消耗的电能减少，上述所提到的一些条件可以适当放松。

一些LoWPAN设备是需要非常受限的（叫作“少功能设备”或RFDs），更强的设备“全功能设备”（FFDs）也会讲到，虽然数量很少。FFDs通常有更多的资源并可能有线供电。因此，FFDs会辅助RFDs来提供一些功能如网络协调、报文转发、连接其他类型的网络等。

使用IP技术主要有以下好处：

1） IP网络的普遍性使得设备可以利用现有的网络结构。

2） 基于IP的技术是已经存在的、广为人知的、并证明是可行的。

3） 一个不可否认的非技术性但重要的因素是IP网络技术是公开的并可免费获得的，这是有好处的或至少相对于专有的技术方案来说IP技术上大众更容易理解。

4） IP网络的诊断、管理、运维等工具是已经存在的。

5） 基于IP的设备能够很容易的与其他IP网络连接，不需要中转设备如翻译网关或代理。

4、问题

基于在概述一节所定义的特点，以下部分详细描述LoWPANs应用IP的主要问题。

4.1、IP连接

LoWPAN的IP连接所必要的一些条件如下所述：

1） LoWPAN网络中的大量设备需要网络进行自动配置并高度无状态描述。因此IPv6是很好的选择。

2） 大量的设备需要大量的地址空间，IPv6是不二之选。

3） 基于LoWPANs报文大小限制，在需要的情况下IPv6地址格式允许包含IEEE802.15.4地址。

4） 简单互联于其他IP网络包括因特网。 

然而，因受报文大小限制，只要有可能IPv6和上层报头必需压缩。 

4.2、拓扑结构 

LoWPANs必须支持多种拓扑结构，包括mesh和星形。 

Mesh拓扑意味着要到达目标要经过多跳路由。在这里，中间设备在链路层上进行报文转发（类似于网络层的路由器）。通常这些是“全功能设备”，有更好的电源和计算能力。路由协议的要求有： 

1）  由于LoWPANSs的报文很小，路由协议必须只增加少量（或没有）报文数据，最好跟跳数无关。

2）  路由协议应该只有少量的路由报文数据（少交换数据），平衡拓扑的变化和电量消耗。

3）  为了满足低成本和低功耗的目标，路由协议对于计算能力和存储的要求尽量降低。因此，存储和维护大路由表是不可能的。

4）  支持电池供电或有线供电的FFDs或RFDs所组成的网络拓扑。这意味着要考虑到对睡眠节点的路由。 

正如mesh拓扑一样，星形拓扑包含一个具有报文转发功能的设备子集。除了IEEE802.15.4，这些设备可能使用其他的网络接口如以太网或IEEE 802.11，目标是为了与那些建立在不同拓扑的网络进行无缝集成。当然，这是一开始使用IP的最主要原因。 

4.3、受限的报文大小 

LoWPANs应用要发送小报文。所有层数据加在一起使用IP连接应该只用一帧进行传输，不必产生过多的碎片和组装。更进一步，协议必须设计或选择来满足单个“控制/协议报文”只包含在一个802.15.4帧内。按照这些原则，IPv6要求子IP重组（见节5），这对低档的LoWPAN设备来说是一个挑战，因为可能没有足够的RAM或存储来处理1280字节的报文。

4.4、受限的配置和管理

如前面所提到的，LoWPANs设备是需要部署很大数量的。另外，这些设备是很少有显示和输入功能的。而且，有些设备布置的地方是很难进入的。因此，LoWPANs所用的协议应尽可能少配置，最好是“开箱即用”的，容易启动，网络具有自动修复功能，因为设备固有的不可靠性。链路层协议也要考虑限制大小。网络管理开销尽量减小，但要足够控制大量密集部署的设备。

4.5、服务发现 

LoWPANs需要一个简单的服务发现网络协议来发现、控制和维护设备所提供的服务。在某些情况下，特别是密集部署的设备，整合几个节点来提供一个服务是有好处的。为了实现这样的功能，需要设计新的协议。

4.6、安全 

IEEE 802.15.4使用AES在链路层是安全的，但它在程序启动、密钥管理和上层协议的安全性方面没有作任何具体的规定。当然，LoWPANs设备必须根据应用的需要仔细考虑一个完整的安全性方案。请参考后面安全相关的章节做更具体的讨论和深入的安全需求分析。

5、目标 

下面所提到的目标具有一般性，并不限定在IETF任务里。同样的，这不仅仅涉及到只有IETF才能完成的工作（例如传输IP的具体需求、现实中传输IP报文最好的配置、相关的上层协议等）。它同样指向了跟其他标准更相关的工作（例如与IEEE 802.15.4相关的变化描述或配置文件、W3C等）。当目标是在IETF的范围内时，它用来指出什么样的工作是需要完成的，不管是否在一个（或多个）新的（或已存在的）工作组里完成的。当目标不在IETF的范围内时，在这里提到是为了交给其他的组织[LIAISON]。 

请注意，一个共同的目标是减小报文开销、带宽开销、处理器需求、和电量消耗。 

下面是按优先级列出的一些LoWPANs目标： 

1）  分片和重组层：正如概述里提到的一样，协议数据单元可能只有81字节大小。这明显比IPv6的最小报文1280字节还要小得多，为了符合第5节的IPv6要求，在IP层下面必须提供一个分片和重组的适配层。

2）  报头压缩：考虑到在最坏情况下，一个IEEE 802.15.4帧可用于传输IP报文的大小只有81字节，并且IPv6报头长度为40字节（在没有报头选项的情况下），这就只剩下41字节给上层协议了，如UDP和TCP。UDP使用8字节的报头而TCP使用20字节。别外，如上面所提到的，还需要一个分片和重组层，这将会占用更多的字节，留给数据的字节就更少了。这样，如果要使用这样的协议，这将会导致大量的分片和重组，即使数据包长度只有10个字节。这表明需要进行报头压缩。因为有大量的已发行的和正在制定中的关于报头压缩的标准化文件，6LoWPAN必须考虑使用现有的报头压缩技术，并且，如果有需要的话，制定新的标准。

3）  地址自动配置：[6LoWPAN]指定了自动配置无状态IPv6地址的方法。无状态自动配置（相对于有状态的）更适合于6LoWPANs，因为它在主机上减少了配置信息的流量。这就需要一种方法来从IEEE802.15.4设备上分配的EUI－64[EUI64]来生成“接口标识符”。

4）  Mesh路由协议：一种支持多跳mesh网络的路由协议是必需的。现已有很多发布的点对点多跳路由协议。一些例子包括[RFC3561]、[RFC3626]、[RFC3684]这些都是实验性的。同样，这些协议是为使用有比较在的报头的基于IP地址而设计的。例如，特别按需距离矢量（AODV）[RFC3561]路由协议使用48字节报头进行基于IPv6地址的路由请求。考虑到报文大小的限制，传输这个报文而不用分片和重组是比较困难的。因此，为了使路由报文只限在一个IEEE 802.15.4帧内，在选择现有的路由协议（或设计新的协议）时应该要认真考虑。

5）  网络管理：使用IPv6进行报文传输的一个重要原因是为了尽可能的使用现有的协议。网络管理功能对于LoWPANs来说是很重要的。然而，管理方式必须符合受限资源和在4.4节提到的最小配置和自动修复功能。在传统的网络中，简单网络管理协议（SNMP）[RFC3410]被广泛的使用在数据资源和传感器的监控上。SNMP功能对于LoWPANs来说可认为“同样的”，为了利用现有的工具。然而，由于受到存储容量、处理能力和报文大小的限制，使用SNMPv3是否合适还是需要进一步的研究，或者在SNMPv3上加一个适配层，或者使用另一个不同的协议。

6）  实施注意事项：在IEEE 802.15.4上传输IP报文或许是更有好处的，如果通过“某种”方式来实施。因此，实施注意事项是必要考虑的。

7）  应用层和更高层的注意事项：正因报头压缩变得越来越普遍，总体性能会更依赖于应用协议的高效性。基于XML的重量级协议如SOAP[SOAP]可能不太适合LoWPANs。同样，更简洁的编码（或许协议）是有必要的。本文的目标是指定或建议如何修改现有协议以使它们适合用于LoWPANs。此外，应用层的互操作性在未来可能是必需的，因此需要考虑到。

8）  安全事项：不同层的安全威胁必须仔细理解和研究。考虑到设备的安装位置、有限的显示、高度密集和点对点部署，加入安全网络是需要全面考虑的。

6、安全事项 

基于IPv6的LoWPAN（6LoWPAN）应用经常需要机密性和完整性保护。安全保护可由应用层、传输层、网络层和/或链路层来提供（也就是说，在6LoWPAN的协议集里）。在所有这些情况下，诸多的限制会影响到一个特定协议的选择。一些更相关的限制是代码量小、低电量、低复杂度和小带宽。

考虑到这些限制，首先，为了测试当做出有意义的假设和简单化时对于减轻成本的任何风险，必需要为6LoWPAN设备开发一个威胁模型。一些需要考虑的威胁例子是中间人攻击和拒绝服务攻击。

一个单独的安全事项集应用于6LoWPAN设备加入网络的过程（即，初始密钥建立）。这通常包含应用层交换或初始密钥建立的带外技术，并可能依赖于特定应用的信任模型；因此，这不在6LoWPAN的范围内，所以本文不做更多描述。为了能够选择（或设计）下一项协议，这就需要由初始密钥建立的键控材料成为一个通用模型。

在初始密钥建立之外，后面的密钥管理和数据传输安全协议是在6LoWPAN范围内的。这里，不同的选择（TLS，IKE/IPsec等）必须依据6LoWPAN的限制来评估。 

在链路层上使用安全协议的一个争论是多数IEEE 802.15.4设备已经支持AES链路层安全。AES是一个在固定块长度（128位）操作的一个块密码。为了加密更长的消息，可使用几种不同的操作方式。最早的模式是，如ECB、CBC、OFB和CFB只提供保密性，这并不能保证消息的完整性。其他已经设计出的模式可同时保证机密性和完整性，如CCM*模式。6LoWPAN可以使用先前的任一种模式，但使用最安全的链路层安全模式（即CCM*）是很有必要的，并建立在这之上。 

对于网络层安全，有两种可用的模型：端到端安全，即使用IPsec传输模式，或限制于网络无线部分的安全，即是使用安全网关和IPsec隧道模式。后一种模式的不利之处是报头太大，这对6LoWPAN帧的MTUs是很重要的。为了简化6LoWPAN的实施，指定相关的安全模型是有好处的，并要指定一组适合于受限环境的优先密码集。

7、致谢 

感谢GeoffMulligan、 SoohongDaniel Park、 SamitaChakrabarti、Brijesh Kumar和Miguel Garcia提出的意见并帮助完成了这份文档。 

8、参考文献

（请参见英文原文http://www.rfc-editor.org/rfc/rfc4919.txt）

 

 

本文由zucheng10翻译，

Email:zucheng10@qq.com

http://blog.csdn.net/zucheng10