BEHAVE工作组相关工作综述

 摘要：由于IP资源的紧缺，NAT作为一种重要的解决方案在全球有着广泛的应用，但同时带来的一些问题也亟需解决。为了规范NAT设备并设计穿越NAT设备的解决方案，IETF成立了BEHAVE工作组并对其做了大量的工作。目前，工作组已制定了一些NAT问题的解决方案和设备标准并对于将NAT应用于IPv6和IPv4共存问题做了大量工作。根据当前IPv6的应用现状，工作组对于IPv6网络连接到IPv4网络或互联网已经提出了相关的解决方案。本文在分析目前NAT的使用背景和BEHAVE的工作目标的基础上，重点介绍了BEHAVE工作组的工作内容、基本技术思路和现有成果。
关键字：BEHAVE工作组，NAT，网络地址转换，IPv4/IPv6共存
1     引言
BEHAVE（Behavior Engineering for Hindrance Avoidance）工作组隶属于IETF组织（Internet工程任务组，Internet Engineering Task Force）。IETF成立于1985年底，是全球互联网最具权威的技术标准化组织，主要任务是以发布RFC的形式负责互联网相关技术规范的研发和制定，当前绝大多数国际互联网技术标准出自IETF。
IETF体系结构分为三类，一个是互联网架构委员会（IAB），第二个是互联网工程指导委员会（IESG），第三个是在八个领域里面的工作组（Working Group）。标准制定工作具体由工作组承担，工作组分成八个领域，分别是Internet路由、传输、应用领域等等。BEHAVE工作组是 传输研究领域下面的一个工作组，主要负责解决包含NAT网络的通信问题。
由于网络地址的不足，NAT技术作为解决网络地址不足的一种重要的解决方案在全球都有广泛的应用。网络地址转换(NAT, Network Address Translation)属接入广域网技术，是一种将私有地址转化为合法公有的IP地址的转换技术，它被广泛应用于各种类型Internet接入方式和各种类型的网络中。
BEHAVE工作组主要工作是解决NAT相关问题，提出解决方案使包含NAT的网络可以支持相关协议正常工作，同时是网络外的节点可以发现并使用该网络。近年来，BEHAVE的工作热点是使用协议转换技术解决IPV4和IPv6的共存问题，以使IPv4平稳过渡到IPv6。
随着网络用户的突飞猛进，由于IPV4设计者在设计初期对网络用户数量的低估，现在IPV4几乎已经耗尽，为了解决这个问题，研究人员提出使用IPV6代替IPV4而彻底解决地址不足的问题。然而，目前民用互联网大部分都是基于IPV4协议，因此，如何在IPV4过度到IPV6期间内能让IPV4和IPV6共存同时又可以相互访问，成为IPV6领域一个重要课题。目前，解决IPV4和IPV6共存问题主要有两种方法，转换和隧道。转换技术主要解决IPv6和IPV4之间的通信，而隧道技术主要解决不同协议网络之间的穿越。
BEHAVE工作组在[RFC6144]提出IPv4/IPv6之间的协议转换框架，并指出IPv4和IPv6之间进行通信主要分为八种情形：
     IPv6网络到IPv4因特网
     IPv4因特网到IPv6网络
     IPv6因特网到IPv4网络
     IPv4网络到IPv6因特网
     IPv6网络到IPv4网络
     IPv4网络到IPv6网络
     IPv4因特网到IPv6因特网
     IPv6因特网到IPv4因特网
同时，工作组也在讨论多播的地址转换，包括传输控制、单源多播和多源多播。
2     包含NAT网络的解决方案
当网络中存在NAT时，网络内的节点无法与网络外的节点直接通信，需要在NAT服务器上通过特定的解决机制以使网络内节点可以和网络外的节点进行通信。BEHAVE工作组分析并提出了一系列解决方案和最佳实践建议以使两个中间存在NAT的网络节点之间可以正常通信。
2.1 NAT设备的行为要求
为了解决NAT存在网络的正常通信，BEHAVE分别提出了UDP、TCP和ICMP等协议对NAT设备的要求，并建议NAT设备开发商满足这些要求以保证应用程序的正常运行。
2.1.1 UDP对NAT设备的行为要求
[RFC4787]定义了NAT在处理UDP时不同的NAT行为，提出了一系列要求，并对这些要求在安全性和网络结构上进行了分析。如果NAT满足这些了要求，使用UDP的网络应用就可以正常运行。
BEHAVE提出以下要求及建议：
     要求NAT必须支持 “节点不依赖映射”行为。
     建议NAT在IP地址池中可以为每一个内部地址映射一个外部地址。
     要求NAT在分配端口时不可以出现端口超载。
     建议NAT分配端口时，奇数端口对应奇数端口，偶数端口对应偶数端口。
     要求NAT的UDP映射计时器的重置时间不能小于两分钟。知名端口除外。
     当内部节点发送报文给外部节点时，要求NAT重置映射计时器。
     NAT网络设备的外部IP接口可以被自动配置只能出现在两种情况下：自动配置可以保证它的内部网络IP地址和外部网络的不冲突，或者在所有的内部节点及外部存在IP冲突的节点之间可以转换并转发报文。
     如果网络对应用的透明很重要，建议NAT存在节点不依赖过滤行为。如果过滤行为的严格性更重要，建议使用地址依赖过滤。
     要求NAT必须支持节点访问相同NAT后面的另一节点的外部地址的行为。
     要求关掉基于UDP协议的NAT ALGS。
     要求NAT不能在任何时间任何情况下改变转换和过滤行为策略。
     要求接收到任何类型的ICMP信息NAT都不能丢弃或改变NAT映射。
     如果一个接收到的数据包中内部DF设置为1，NAT必须送回给主机一个ICMP信息，告诉主机需要分片。
     要求NAT必须支持接收有序和无序的分片。
2.1.2 TCP对NAT设备的行为要求
近年来，研究人员设计了很多解决方案以支持TCP点对点应用可以穿越NAT并正常工作，但是这些方法都依赖于NAT的特定的行为操作，而这些行为并不一定被所有的NAT设备支持。因此，[RFC5382]提出了一系列NAT设备要求的标准以保证TCP可以直接穿越NAT。
BEHAVE提出了以下要求及建议：
     要求NAT必须支持“节点不依赖映射”行为。
     如果NAT允许了一个TCP链接，就要求NAT必须同时支持TCP从内部和外部初始化这个链接。
     如果网络对应用的透明很重要，建议NAT支持节点不依赖过滤行为。如果过滤行为的严格性更重要，建议支持地址依赖过滤。
     当一个NAT接收到一个主动进入的SYN数据包时，NAT必须在至少等待6秒钟后再对其进行响应。如果这期间NAT接受并转换了一个该连接的另一个SNY数据包并将其发送出去，NAT则丢弃该SYN数据包。否则，NAT必须发送一个ICMP端口不可达错误。
     当NAT不能确定TCP链接是否运行时，判断这个链接是否已经闲置了一段时间，如果是NAT可以丢弃此链接。
     如果NAT中含有影响TCP的ALGs，建议将这些ALG默认关闭。
     要求NAT在分配端口时不可以出现端口超载。
     要求NAT必须支持节点TCP链接相同NAT后面的另一节点的外部地址的行为。
     如果NAT转换TCP报文，它也必须转换ICMP目标不可达报文。
     接收到任何类型的ICMP报文都不能终止NAT映射，也不能终止ICMP报文对应的TCP链接。
2.1.3 ICMP对NAT设备的行为要求
[RFC5508]提出了ICMP协议对NAT的行为要求，明确的提出了ICMP查询报文和ICMP差错报文在NAT上的穿越行为。此文档作为UDP和TCP对NAT设备要求的补充。
BEHAVE提出了以下要求及建议：
     除非和本地策略冲突，一个NAT设备必须允许从内部主机发出ICMP查询报文以及相应的响应报文。
     ICMP的会话时间刷新间隔必须不能低于60秒
     当收到一个ICMP差错报文，如果ICMP校验和错误，NAT自动丢弃此差错报文。如果校验和正确，进一步处理。
     当NAT收到从内部或者外部发来的ICMP差错报文，如果不存在活动地址映射对应此报文，NAT自动丢弃此报文。如果存在，进一步处理。
     当NAT正在处理与一个ICMP查询或响应报文对应的差错报文，NAT设备不能刷新或者删除相应的NAT会话。
     NAT-TRAD设备必须支持节点向相同NAT后面的另一节点的外部地址发送ICMP查询报文。所有的NAT设备（NAT-TRAD和NAPT）必须支持这种情况下发送ICMP差错报文。
     当一个NAT设备因为资源限制和管理限制不能为传输流建立NAT会话时，NAT设备应该发送一个ICMP目标不可达差错报文给发送者并丢弃原始报文。
     NAT设备可以实施一个策略控制以阻止发送ICMP给某一端口。
     NAT对每种ICMP报文都有不同的要求。
     NAT可以丢弃或者适当的处理非查询差错报文。
2.1.4 总结
BEHAVE工作组除了提出了TCP、UDP和ICMP协议对NAT的行为要求外，还提出了IP组播及DCCP等协议对NAT的行为要求。
BEHAVE通过测试观察NAT行为，提出了各种协议的行为要求，NAT设备提供商可以通过满足这些行为要求，使NAT获得更好的功能性性能。
2.2 使用中继穿越NAT
虽然BEHAVE提出了TCP、UDP等协议对NAT的行为要求并要求NAT设备满足这些要求，同时也提出了一些机制来解决一些特定的网络背景，但是仍不能保证所有NAT设备满足所有要求。同时，网络中存在一些特殊应用背景，也无法对所有应用背景都进行规范。因此，当一个主机运行在在NAT后面时，总有些情况使它不能与其他主机直接通信。
比如，一个NAT后面的主机希望与另一个NAT后面的主机通信，为解决这种问题，可以使用[RFC5218]提出的打孔技术来发现一个直接的链接路径。但是，如果一方NAT不能满足打孔技术的相关要求，就无法找到直接的链接路径。
为了解决这些情况，可以使用一个中继作为两点之间通信的中间节点来互相转发他们的数据包。基于这种思想BEHAVE提出TURN（Traversal Using Relays around NAT）协议。此协议作为STUN(Session Traversal Utilities for NAT)的一个扩展和用例，它在公共的互联网上设置一个第三方中介节点作为中继转播收到的报文。
2.2.1 Session Traversal Utilities for NAT
STUN（Session Traversal Utilities for NAT）[RFC5389]是一个作为其他协议处理NAT穿越的工具。主机使用此协议可以确定NAT给它分配的IP地址和端口，也可以用它来检查两节点之间的连通性，也可以用来作为keep-alive协议来保持NAT绑定。STUN允许和许多存在的NAT一起工作，但对NAT没有特别的行为要求。
STUN本身不是NAT穿越解决方案，它只是一个可以在NAT穿越解决方案使用到的工具。
STUN被设计为应用在一个或多个NAT穿越的解决方案中，这些解决方案被称为STUN用例。每一个STUN用例描述了如何使用STUN来解决NAT穿越问题。一般来说，一个解决方案需要提出STUN消息何时发送，包含哪些可选属性，使用什么服务器以及使用什么验证机制。


 
图1 一种STUN配置

一种STUN配置如图1所示。在这个配置下，两个节点（STUN Server & Client）布置了STUN协议。STUN客户端连接到私有网络1上，私有网络1通过NAT1和私有网络2链接。私有网络2通过NAT2和公共因特网链接，STUN服务器连接在公共因特网上。
STUN是一种客户端-服务器协议。它支持两种类型的事务。一种是请求/响应，客户端发送一个请求给服务器，服务器返回一个响应。一种是指示性事务，客户端或者服务器向对方发送一个指示性信息而不产生响应。
所有的STUN消息都以一个固定格式的报头开始。报头包括方法、类型和事务ID。方法表示这个消息是哪种消息。类型表示这个消息是一个请求、成功响应、错误响应还是一个指示性消息。事务ID在请求/响应事务中使客户端知道响应对应的是那个请求。对于指示性消息，事务ID可以用作测试信息。
[RFC5389]只定义了一个方法——绑定。其他方法可以在其他协议中声明使用。绑定方法可以用在请求/响应事务或者指示性事务中，当使用在求情/响应事务中时，绑定方法可以被客户端使用以确定特定的绑定——NAT分配给它的地址。在指示性事务中，绑定方法可以用来保持绑定存在。
在请求/响应事务的绑定方法中，客户端发送一个绑定请求，当STUN服务器接收到绑定请求后，它将源地址拷贝到XOR-MAPPED_ADDRESS属性中返回给客户端，这样客户端通过读取这个属性就可以知道最外城的NAT绑定给他的IP地址。在发送请求过程中，请求消息可能经过多个NAT，如在图1中经过了两个NAT，而服务器获得的是NAT2给客户端分配的地址，因此客户端最后获知的也是NAT2给他分配的地址。
除此之外，STUN还定义了一系列可选处理程序供用例选择使用。
总之，STUN提供了一系列基本的功能供其他NAT穿越解决方案使用，在此基础上其他解决方案可以选择、扩展STUN提供的功能以完成最终的成功穿越。
2.2.2 中继NAT穿越协议TURN
为了解决NAT穿越问题，BEHAVE工作组基于STUN协议在[RFC5766]提出了TURN（Traversal Using Relays around NAT）协议的概念。它允许在某些NAT后主机无法链接的环境下，通过一个中继节点作为媒介节点，主机可以通过控制这个中继节点以与对方节点通信。TURN与其它中继控制协议不同的一点是它允许主机通过使用一个中继节点与多个对等节点进行通信。
TURN协议允许位于NAT后面的主机（TURN客户端）请求另一个主机（TURN服务器）作为一个中继，客户端可以通过服务器与另一个主机（对等节点）之间转发它的数据包达到与对等节点间接通信的效果，同时客户端也可以控制如何实现转发。客户端通过获得一个客户端分配给他的中继传输地址，当对等节点发送一个数据包到这个中继传输地址（relayed transport address），TURN将数据报转发给TURN客户端。当客户端发送一个数据包到服务器时，服务器将这个数据包转发给对等节点同时将数据报的源地址改为它跟配给客户端的中继传输地址。
图2表示一种TURN工作的网络拓扑。TURN客户端在一个NAT后面，而这个NAT是一个行为不满足要求的NAT，比如使用地址端口依赖映射，从而导致TURN客户端无法和它的对等节点直接通信。这种情况下，客户端通过TURN服务器的支持与对等节点进行间接通信。


图2 TURN网络拓扑

虽然TURN客户端通过使用TURN服务器作为中继来与对等节点进行通信一般都会正常工作，但是它对资源要求更高。协议需要一个TURN服务器支持，而且服务器对互联网接入要求较高的带宽。因此，最好的方法是只有两节点无法进行直接通信时在使用TURN服务器。
2.2.3 其它相关工作
在TURN协议的基础上，BEHAVE工作组还做了其他的相关工作。[RFC5769] 提供了一些合适格式的SURN报文作为测试用例，可以测试STUN协议的实现和安装效果。[RFC5780]定义了一种STUN用例，可以用来发现STUN客户端和服务器之间的NAT和防火墙存在和行为。[RFC6062]扩展了TURN，使它可以支持TURN客户端请求TCP链接。[RFC6156]扩展了TURN使它可以支持IPV6以及IPV6和IPV4之间的通信。
3     NAT解决IPV4和IPv6共存问题
随着IPv6网络的发展，IPv4网络和IPv6网络共存问题成为了一个急需解决的问题。目前存在两种方法解决这个问题，隧道技术和地址转换技术。隧道技术可以在不干扰以前的协议的基础上提供链接功能，但是它有一些缺点，首先使用隧道技术不能使用以前协议所提供的其他服务，而只能简单使用带宽。其次，使用新的协议的主机无法和使用以前协议的主机进行通信。BEHAVE工作组近期主要工作就是通过转换技术来解决IPv4和IPv6的共存问题。
3.1 IPV4/IPV6转换框架
[RFC6144]分析了IPv4和IPv6之间的应用背景，定义了IPv4和IPv6之间的转换框架。文章提出网络应用主要分为两种：客户端/服务器应用和P2P应用，这两种应用的主要区别是哪一方发起第一次链接请求。在这个基础上，根据可能的网络背景文章提出了八种IPV4和IPV6之间连接情况：
1)     IPv6网络到IPv4因特网
一个网络由于IPV4地址的不足或者其他技术或者经济限制只能支持IPV6，但是这个请求与IPV4互联网通信。

图3 IPv6网络到IPv4因特网

无状态或者有状态的解决方案都可以支持这种情况。
2)     IPv4因特网到IPv6网络
当情况1)的IPv6网络不仅希望访问IPV4互联网，还希望作为服务器被IPV4互联网访问。

图 4 IPv4因特网到IPv6网络

这种通信情况对于转换技术来说是一个比较难以解决的情形。有状态的NAT-PT可以和ALG合作而支持这种情况，但是这种技术已经被废弃。
无状态的转换解决方案可以支持这种情况。
3)     IPv6因特网到IPv4网络
当IPV6互联网成为主流，IPV4网络希望提供服务给IPV6节点。

图5 IPv6因特网到IPv4网络

4)     IPv4网络到IPv6因特网
IPV4网络希望访问IPV6互联网。

图6 IPv4网络到IPv6因特网

5)     IPv6网络到IPv4网络
一个IPV4网络和一个IPV6网络都属于同一个机构。IPV4地址可以使用公共地址或者私有地址。IPV6地址也可以使用公共地址或者唯一本地地址。

图7 IPv6网络到IPv4网络

6)     IPv4网络到IPv6网络
这是情况5)网络的另一个情况。

图8 IPv4网络到IPv6网络

7)     IPv4因特网到IPv6因特网
这种情况像是一个理想状态下的转换技术。IPV6互联网上的纯IPV6主机作为起点向处于IPV4互联网的IPv4主机发起链接。

图9 IPv4因特网到IPv6因特网

由于在地址数量空间上的巨大差异，目前没有可行的转换技术来处理这种情况。
8)     IPv6因特网到IPv4因特网
这种情况很像情况7)。

图10 IPv6因特网到IPv4因特网

同时，文章还提出了IPv6/IPv4间的转换框架。转换框架主要包含以下模块：
1)     地址转换
当IPV4-IPv6进行协议转换时，首先要确定地址之间是如何转换的。地址转换技术可以分为无状态转换技术(stateless translation)和有状态转换技术(stateful translation)两种。有状态转换是指需要在转换设备中动态产生并维护IPV4地址和IPV6地址之间的映射关系，而无状态转换是通过预先设定的算法维护IPV4地址和IPV6地址之间的映射关系。
BEHAVE在[RFC6052]中提出了一种IPV6和IPv4地址之间的转换方法。此文档提出可以使用IPV6知名前缀或网络前缀加IPV4地址作为IPV6地址，即将IPv4嵌入到IPv6地址内，这样就可以进行直接的地址转换。
2)     IP&ICMP转换
在协议转换过程中，还需要考虑IP和ICMP报文的转换。BEHAVE工作组在[RFC6145]中提出了一个IP/ICMP转换算法，它支持IPv4和IPv6报头之间的互相转换。
3)     转换状态维护
在有状态转换机制中，IP和ICMP转换都需要维护转换状态。[RFC6164]提出了一种维护状态的机制。
4)     DNS64和DNS46
DNS64和DNS46用来进行A记录和AAAA记录之间的转换。[RFC6147]提出了DNS64的解决方案。
5)     其他应用层协议的ALG
除了上述模块，一些应用层协议还要求特殊的支持。比如FTP，BEHAVE工作组为了支持FTP在IPV6-to-IPv4情况下提出了[RFC6384]。
3.2 IPV6-to-IPV4转换解决方案
近年来由于IPV4地址的耗尽，IPV6网络开始发展。但是，目前互联网还是以IPv4为基础的，也就是说，大部分的服务和资源还是分配在IPv4互联网上的，而IPv6网络以孤岛的形式分布在IPV4网络海洋里。所以，当前急需解决的问题是IPV6网络连接到IPv4互联网或者IPV4网络情况下的网络地址转换。
为了解决IPV6-to-IPV4问题，BEHAVE工作组提出了有状态的NAT64[RFC6164]和DNS64[RFC6147]，两个模块共同协作构成了一个较完美的解决方案。有状态的NAT64是一个解决IPV6与IPV4数据包之间的相互转换的机制。DNS64根据A类型的资源记录合成AAAA类型的资源记录。在此基础上，BEHAVE工作组在最新的草案中也对这种解决方案进行了一些补充和分析。为了应用层协议的正常工作，BEHAVE工作组在[RFC6384]提出了能使FTP在这种情况下正常工作的应用层网关ALG。
带状态的NAT64和DNS64可以很容易的部署，而且他们对IPV6客户端和IPV4服务器也不需要改变。
图11是IPV6网络通过NAT64和DNS64连接到IPV4网络或者互联网的拓扑图。

 
图11 NAT64&DNS64实现IPv6-to-IPv4
在这个网络中，H1和H2通信的流程如下：
1)     H1发出一个DNS请求，本地的域名服务器支持DNS64协议，它合成了一个AAAA资源记录并返回给H1。这个AAAA资源记录里面包含了一个由知名前缀和IPV4地址构成的IPV6地址。
2)     H1发送一个SYN报文给H2。这个报文的目的地址是H2的本地IPV6地址。
3)     数据包路由发送到NAT64。
4)     NAT64收到数据包并对其进行以下处理：
a)     NAT64在它的IPV4地址上选择一个未使用过的端口并且创建一个映射条目。将数据包的源地址、端口映射到NAT64上的地址和端口。
b)     NAT64使用IP/ICMP转换算法将IPV6的报头转换为IPV4的报头。
c)     NA64T将刚才选择的端口和它的地址左右报文的源地址，将它的目的地址查询映射表，转换为IPV4地址。
5)     NAT64通过它的IPV4端口将转换后的报文发送给H2。
6)     H2节点接收到报文，发送一个SYN+ACK报文给H1。报文的源地址是H2的IPv4地址，目的地址是NAT64的地址。
7)     NAT64收到报文后根据报文的目标地址查找映射表，找到IPv6地址，并作以下处理：
a)     NAT64将IPV4报头转化为IPv6报头。
b)     将在映射表中查找到的IPv6地址作为目的地址，将源地址转化为知名前缀加IPv4地址的IPv6地址。
8)     NAT64将转换后的报文从IPV6接口发送给H1。
通过以上步骤H1和H2通过NAT64和DNS64的支持实现了通信。
4     总结
综上所述，BEHAVE工作组的工作目标是通过设计相关标准及解决方案解决包含NAT网络的各种问题。目前，工作组提出了一些NAT产生的问题的解决方案和设备标准并对于将NAT应用于IPv6和IPv4共存问题做了大量工作。近年来，随着IPV6的发展，如何解决IPv4和IPV6的共存问题成为BEHAVE工作组急需解决的问题。目前，工作组对于IPv6网络连接到IPv4网络或互联网已经提出了相关的解决方案，并已经提出了相关互联网草案对其进行分析及扩展。