1995年，IPv6第一个官方版本正式发布。1998年12月，IPv6在被IETF通过公布互联网标准规范（RFC 2460）的方式定义出台。这是个用于分组交换互联网络的网络层协议。驱使IETF重新设计互联网协议的主要原因是，IPv4地址在可预见的未来中即将被耗尽。

IETF（The Internet Engineering Task Force）

“IETF的标准工作分为8个重要的研究领域，分别是应用领域、通用领域、互联网领域、操作与管理领域、实时应用和基础设施领域、路由领域、安全领域和传送领域，每个研究领域均有1~3名领域主管（Area Directors），负责本领域的日常运转。每个领域又由多个工作组（Work Group）组成，每个工作组有1~2名工作组主席主持本组的日常工作。目前，针对IPv6协议、规范、过渡和演进比较活跃的工作组主要有互联网领域的PPPext，SAVI，Softwire工作组；操作与管理领域的v6ops工作组；传送领域的Behave工作组等。”

“截止到目前，共有123个涉及IPv6的RFC成为Proposed Standard，其中26个已经被废止，需要说明的是，废止它们的新的RFC未必是Proposed Standard，有可能是RFC的任何状态。现在仍然有效的97个Proposed Standard RFC涵盖的领域非常广泛，主要涉及移动IPv6，IPv6路由，6PE（RFC4798），IPv6组播，DHCPv6，IPv6编址及架构，IPv6 MIB，IPv6Sec，Teredo（RFC4380），6 to 4（RFC3056），ICMPv6以及IPv6在L2协议上的封装等方面。”

“IPv6过渡技术主要指针对协议转换、地址翻译、隧道封装等技术方案的RFC，相关标准包括：

    （1）IPv4向IPv6过渡框架、场景定义。

    （2）IPv4/v6协议翻译技术。

    （3）IPv4/v6隧道相关技术。

    （4）IPv6过渡地址格式定义。

    （5）IPv6 DHCP相关标准定义。

    （6）IPv6 DNS及DNS-ALG相关标准定义。”

——《IPv6标准及演进方式》作者: 胡捷王茜陈运清赵慧玲

BEHAVE(Behavior Engineering for Hindrance Avoidance) 工作组翻译

Description of Working Group

工作组的描述

The working group creates documents to enable NATs to function in as deterministic a fashion as possible.

工作组为了使NATs能够尽可能的成为决定性的时尚产品而编写文档（-_-!翻译的好shi……）

To support deployments where communicating hosts require using different address families (IPv4 or IPv6), address family translation is
needed to establish communication. In BEHAVE's specification work on this topic it will coordinate with the V6ops WG on requirements and operational considerations.

为了支持需要使用不同地址簇（IPv4或者IPv6）的通信主机的部署，地址簇的转换是必不可缺的。BEHAVE工作组的关于这个主题的专职工作是与V6ops( iPv6 Operations)工作组在需求和运营决策上进行协作。

"An IPv4 network" or "an IPv6 network" in the descriptions below refer to a network with a clearly identifiable administrative domain (e.g., an enterprise campus network, a mobile operator's cellular network, a residential subscriber network, etc.). It will also be that network that deploys the necessary equipment for translation.

在以下描述中出现的“一个IPv4网络”或者“一个IPv6网络”表示拥有明确的可标识的管理域的网络（比如企业校园网，运行商的移动电话网，住户订阅网络等等），也表示部署了必要的转换设备的网络。

BEHAVE will adopt additional work items to finish four scenarios:
An IPv6 network to IPv4 Internet, IPv6 Internet to an IPv4 network,An IPv6 network to an IPv4 network, and An IPv4 network to an
IPv6 network. These additional work items include suggestions to application developers to improve application interactions with those translation scenarios.

BEHAVE 将实施额外的工作项目来完成四个情景转换：
一个IPv6网络到IPv4的互联网；IPv6互联网到IPv4网络，IPv6网络到IPv4网络，IPv4网络到IPv6网络。这些额外的工作项目包括了给应用程序开发者的建议，建议他们提高应用程序对这些转换情景的集成。

The following scenario remains in scope for discussion, and new milestones can be created to address this scenario:

* An IPv4 application running on an IPv6-only connected host to the IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for
packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is embedded
in the IPv4 host.

下属情景依然在讨论的范围之中，可以为该情景创立新的里程碑：

*一个IPv4应用程序在一个只允许IPv6连接的主机运行连接到IPv6互联网。也就是说，对在由IPv4主机发向IPv6主机的单向流或者双向流内的数据包执行IPv4和IPv6之间的转换。转换功能嵌入在IPv4的主机中。

The following scenarios remain in scope for discussion, but creating new milestones will require re-chartering:

* An IPv4 network to IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv4 network using either public or private IPv4 address space.

* IPv4 Internet to an IPv6 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv6 network where selected IPv6 hosts and services are to be reachable.

* multicast translation, including control traffic (IGMP and MLD), Single Source Multicast (SSM) and Any Source Multicast (ASM).

下列情景依然在讨论的范围之内，但是需要重新备案（re-charting大概就是备案，重新立牌坊的意思吧）：

*一个IPv4网络到IPv6互联网，也就是说，对在由IPv4主机发向IPv6主机的单向流或者双向流内的数据包执行IPv4和IPv6之间的转换。这个转换功能倾向使用公共或者私有的IPv4地址空间来服务一个指定的IPv4网络。

*IPv4互联网到一个IPv6网络，也就是说，对在游IPv4主机发向IPv6主机的单向流或者双向流中的数据包执行IPv4和IPv6之间的转换。这个转换功能服务于一个指定的IPv6网络，这个网络里的IPv6主机和服务需要是可获得的。

*多播转换，包括流量控制（IGMP和MLD），单源多播(SSM)和任一来源的多播（ASM）

All translation solutions shall be capable of handling flows using TCP, UDP, DCCP, and SCTP, unless they prevent a timely completion of the work item. The parts of ICMP that can be translated are also required to work across a translation solution. Additional protocols directly on top of IP may be supported. Translation mechanisms must handle IP fragmentation.

任何的转换方案需要都需要具备使用TCP,UDP,DCCP和SCTP处理流的能力，除非他们能够防止工作项的按时完成（没看懂）。ICMP可以被转换的部分同样也需要一个转换方案。直接加在IP之上的额外的协议可能也支持。转换机制必须能够处理IP分片。

Translation mechanisms cannot transparently support protocols that embed network addresses within their protocol messages without application level gateways (ALGs). Because ALGs have security issues (like blocking usage of TLS), are error prone and brittle, and hinder application development, the usage of ALGs in the defined translators should be avoided. Instead application developers will need to be aware and use mechanisms that handle the address family translation. ALGs may be considered only for the most crucial of legacy applications.

转换机制不能直接支持那些将网络地址内嵌到协议信息中而不使用应用程序级别网关（ALGs）的协议。因为ALGs存在安全问题（比如粗赛TLS的使用），是易出错并且脆弱的，阻碍应用程序的发展，在定义好的转换器上不应该使用ALGs。作为替代应用程序的开发者们需要意识到并且使用一些处理地址簇转换的机制。ALGs可能仅仅在面对非常重要的遗产程序的情况下需要被考虑。

Solutions may solve more than one of the cases, however timely delivery is more important than a unified solution.

解决方案也许能够处理不止一个的上述问题，但是及时的交付比一个统一的解决方案要重要的多。

附：网络体系结构课程论文

BEHAVE工作组及其主要工作

Abstract

随着IPv4地址逐步耗尽，IPv6协议从2008年开始又重新得到业界的关注。在向IPv6的过渡中，IPv4与IPv6将在很长一段时间内处于共存状态，如何实现IPv4与IPv6共存期的应用互访和平滑演进是实现IPv4向IPv6成功过渡的基础。在这样的大背景下，过渡技术的研究就显得极其重要。本文介绍了IETF BEHAVE工作组在此领域的工作，简单说明了其工作目标，阐述了其基本技术思路和现有成果。

关键词： BEHAVE， Translation， NAT

1. 背景简介

1998年12月IPv6被IETF公布（RFC2460），至今已有10余年，IPv6仍没有得到广泛的部署，而IPv4地址即将用尽，互联网用户及运营商还来不及推广被IETF所推荐的双栈结构的操作（Dual-stack operation）的方法来从IPv4迁移到IPv6。因此需要在过渡期采取更好的策略和技术规范。

除了双栈（Dual-Stack）技术之外，已有的IPv4/IPv6过渡期技术可以分为两类^[2]：翻译（Translation）和隧道（Tunneling）技术。其中IETF Behave工作组主要研究翻译类技术。

2. 工作目标：

BEHAVE工作组的工作是设计和标准化文档，主要围绕IPv6 NAT展开，根本目标是鼓励用户向IPv6迁移，通过推动NAT（Network Address Translation）技术成为过渡期主流技术的方式^[3]。为以下六种翻译情景提供解决方案：IPv6网络到IPv4互联网；IPv4互联网到IPv6网络；IPv6互联网到IPv4网络；IPv4网络到IPv6互联网；IPv6网络到IPv4网络；IPv4网络到IPv6网络^[1]。

3. 翻译技术的基本思路：

过渡期的地址翻译技术是由IPv4的NAT技术发展而来。在IPv4的NAT技术中，为了减少IPv4全局地址的消耗，在网络边界处使用NAT实现私有地址与全局地址（公网地址）的转换盒IP报头重写，结合端口复用技术，建立私有地址与全局地址的映射关系，实现一个全局地址被多个私有地址共享。

同样的，过渡期的地址翻译技术的基本思想就是将IPv6数据包中报文头字段与IPv4数据包中对应的字段建立一一映射关系，从而达到在两个使用不同地址族的网络之间实现报文的转发。典型应用是NAT-PT（Nework Address Translation – Protocol Translation RFC 2766），结合使用应用层网管DNS-ALG在网络层进行IP地址的映射和转换。如图1

图1. NAT-PT 应用情境^[4]

其优点在于只需要配置NAT-PT服务器即可实现纯IPv6节点和纯IPv4节点的相互通信，而缺点则是资源消耗较大、服务器负载过重，使得NAT-PT设备称为性能瓶颈。NAT-PT后来被IETF在RFC 4966中被废弃。所以之后BEHAVE工作组的工作就要求设计能够避免或者克服NAT-PT问题的新的IPv6/IPv4翻译标准。

根据IPv6地址空间与IPv4地址空间映射的不同方法，可以把翻译类型分为有状态（Stateful）协议翻译和无状态（Stateless）协议翻译。其中，有状态协议翻译（如Stateful NAT64，PNAT等）主要通过建立映射表的方案，在任意IPv6地址与任意IPv4地址之间建立映射关系，而无状态协议翻译则是通过将IPv4地址内嵌到IPv6地址中，实现无状态地址翻译。因此，无状态协议翻译（如IVI，DIVI等）仅能访问具有特定格式IPv6地址的主机，而有状态协议翻译则能够访问任意地址格式的IPv6主机^[3]。

IP/ICMP翻译算法（RFC6145）中定义了无状态的翻译技术，其关键点在于IPv4地址被内嵌进了IPv6地址的当中。指定的IPv6地址范围被用来在IPv6的世界中代表IPv4系统（IPv4-converted 地址），需要在翻译器上手工配置。而在IPv4的世界中所有的IPv6系统都拥有可以用算法直接映射为对应的服务提供商的IPv4地址的子集的地址（IPv4-translatable addresses）。因为采用算法映射所以无需再翻译器上记录IPv4/IPv6状态。这种算法映射要求IPv6主机采用手工配置或者DHCPv6的方式分配指定的IPv6地址。

Stateful NAT64（RFC 6146）有状态的翻译技术与无状态的最大不同在于不需要IPv6和IPv4地址之间进行算法绑定，但是需要在NAT64转换设备上记录状态或地址绑定，^[6]多个纯IPv6的用户可以只对应一个IPv4地址，类似于NAT44中的端口复用技术。一般只支持通过IPv6网络侧用户发起连接访问IPv4侧网络资源。但NAT64也支持通过手工配置静态映射关系，实现IPv4网络主动发起连接访问IPv6网络。

通常IPv4/IPv6的地址翻译都会配合使用DNS64（RFC 6147），一种将A资源记录合称为AAAA资源记录的机制。比如Stateful NAT64在结合使用DNS64时（如图2），不需要在IPv6客户端或IPv4服务器端做任何修改就可以允许一个纯IPv6的客户机通过域名发起对一个纯IPv4服务器的通信。DNS64与NAT-PT中的DNS-ALG功能类似，但并不像DNS-ALG那样是一个应用层网关，而是从NAT中剥离出来，直接使用自身的地址发送/接收数据报文。

图2. NAT64结合DNS64的拓扑结构

4. BEHAVE工作组的现有成果

由于BEHAVE工作组的首要目标是推进NAT在网络中变得更主流，所以需要围绕NAT设计各种标准和机制，用来应付各种各样的协议和应用程序，除了基本的IPv4/IPv6地址翻译机制，TCP、UDP、ICMP等协议的报文头转换，为降低应用程序对ALG的依赖程度而设计的NAT穿越技术TURN、STUN机制等都在BAHAVE的设计范围之内。

工作组目前发布了19个RFC，如表1所示，其中有Standards Track 10篇，Best Current Practice 5篇，Informational 3篇，Experimental 1篇。

RFC 6052	Standards Track	IPv6 Addressing of IPv4/IPv6 Translators
本文档讨论了将一个IPv6地址和其对应的IPv4地址的相互翻译的算法，只需要使用静态的配置信息。该算法定义了一个公共的地址前缀（Well-Known Prefix），特定组织和机构也可以在合适的时候使用指定网络的前缀。算法式的地址翻译在 IPv4/IPv6翻译器上使用，正如其他类型的代理和网关（比如DNS）在IPv4/IPv6情境中使用一样。
RFC 5597	Best Current Practice	Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol
本文档为NAT对数据报拥塞控制协议处理定义了一组需求。这些需求DCCP应用程序，比如流应用，能够一致的执行，并且与已经被IETF发布的NATs的TCP需求非常相似、确保NATs满足这组需求将会极大的增加使用DCCP的应用正确运行的可能性。
RFC 6147	Standards Track	DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers
DNS64是一个将A记录合成为AAAA记录的机制。针对那一类使用NATs的应用，将DNS64与IPv6/IPv4翻译器一起使用，使得纯IPv6的客户端和纯IPv4的服务器之间可以建立客户端-服务器模式的通信，而不需要在IPv6或者IPv4节点上作出任何改变，本文档详细说明了DNS64，并且提供了关于如何将它与IPv6/IPv4翻译器结合部署的建议。
RFC 6384	Standards Track	An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation
文件传输协议（FTP）有非常长的历史，尽管如今有很多其他的文件传输的协议来选择，FTP仍然使用的十分广泛。正因为如此，会有这样的情况：有些客户机只支持IPv6连接而很多服务器仍然是纯IPv4的，使用IPv6-to-IPv4翻译器来进行交接，在这样的情况下，FTP能够最大程度的通过这些翻译器来工作就显得很重要了。 FTP有主动和被动模式，两者都有IPv4专用的原始命令和可扩展的不指定IP版本的命令。只有扩展的被动FTP模式不需要在通过IPv6-to-IPv4翻译器时做任何改变。但是，许多现存的FTP服务器不支持这种模式。本文档详细说明了一个可能解决这种不匹配问题的中间体。
RFC 5135	Best Current Practice	IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT)
该文档详细说明了一个网络地址转换器(NAT)和一个支持任意源的组播或者指定源的IP组播的网络地址端口转换器（NAPT）的需求。一个严格遵守本文所描述的需求的可IP组播的NAT 设备可以对IP组播应用程序的操作进行优化，这些优化总体上是不被IP组播NAT设备察觉的
RFC5780	Experimental	NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)
本文档定义了一个实验性的使用Session Traversal Utilities for NAT（STUN）协议在STUN客户端和STUN服务器之间发现NATs和防火墙的存在和当前行为的用法
RFC 5508	Best Current Practice	NAT Behavioral Requirements for ICMP
本文档详细说明了NAT设备结合使用互联网消息控制协议(ICMP)时所需要的行为性质。目的是为了使NAT设备在面对多样化的应用程序协议的穿越时更具有可预测性和兼容性。相关的其他文档提供了专门的TCP,UDP和其他协议的行为建议
RFC 4787	Best Current Practice	Network Address Translation (NAT) Behavioral Requirements for Unicast UDP
本文档定义了描述当处理单播UDP时不同类型的网络地址转换（NAT）的行为的基本术语，还定义了一组需求，这些欲求允许多个应用程序，比如多媒体通信或者在线游戏，能够一致的工作。开发符合这组需求的NATs将会极大的增加该应用程序正常工作的可能性。
RFC5128	Informational	State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)
本文档记录了各种各样目前已知的在NAT环境下应用程序建立直接通信的方法。尽管本文是用来进行描述性的记录，安全考虑章节依然给出了一些纯粹的建议关于如何处理。使用这些方法时由应用程序不经意间造成的安全漏洞。本文覆盖了供TCP和UDP应用程序的NAT 穿越方法。并不是说认可这些方法，仅仅是用来记录在案。
RFC 5389	Standards Track	Session Traversal Utilities for NAT (STUN)
NAT的会话穿越公爵（STUN）是一种为其他协议在处理NAT穿越时服务的工具协议。它可以被端节点用来决定由NAT分配给自己的IP地址和端口。它也可以被用来检查两个端点之间的可连通性，像保留协议一样维持NAT的绑定。STUN同很多现存的NATs一起工作，不需要特殊的行为需求。 STUN本身并不是NAT穿越的解决方案。它更像是一个在NAT穿越方案中使用的工具。这是一个对之前版本的STUN说明（RFC3489）的重要变化，在前一个版本中STUN被定义为一个完全的解决方案。本文档废弃了RFC 3489
RFC 5769	Informational	Test Vectors for Session Traversal Utilities for NAT (STUN)
NAT的会话穿越工具（STUN）协议定义几个STUN属性。这些内容——指纹技术，信息完整性和与或地址映射机制——都涉及了二进制逻辑运算（Hashing，xor）。本文档提供了这些属性的测试向量。
RFC 5382	Best Current Practice	NAT Behavioral Requirements for TCP
本文档为NATs处理允许许多诸如点对点应用和在线游戏能够一致地工作的TCP定义了一组需求。开发迎合这组需求的NATs能够极大的增加这些应用的正常工作的可能性。
RFC 6156	Standards Track	Traversal Using Relays around NAT (TURN) Extension for IPv6
本文档增加了对TURN的IPv6支持。TURN的IPv6支持包括IPv4到IPv6，IPv6到IPv6和IPv6到IPv4的中继转发。本文档定义了TURN的请求地址族属性。请求地址族属性云溪一个客户机明确的请求TURNserver分配的地址类型（比如一个纯IPv节点可以请求TURN服务器分配一个IPv6地址）。
RFC 6062	Standards Track	Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations
本规范定义了一个TURN的扩展，一个供网络地址翻译器穿越用NAT的中继协议。这个扩展允许一个TURN客户机请求TCP的分配，并且定义了新的请求和标记，用来为TURN服务器来开通并且接受来自客户机端的TCP连接。TURN和这个扩展都是有目的严格规范了中继地址的使用方式。特别是它用来防止用户使用从TURN服务器获得的端口运行通用目的的服务器。
RFC 5928	Standards Track	Traversal Using Relays around NAT (TURN) Resolution Mechanism
本文档定义了一个决议机制来解决一系列服务器传输地址，这些地址可以被尝试着用来创建一个TURN分配。
RFC 5766	Standards Track	Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
如果一台主机在NAT之后，那么在特定情况下它将不能直接同其他主机通信（peers）。在这些情况下，该主机使用一个类似通信中继的中间节点提供的服务就显得很有必要了。这种规范定义了一个协议，叫做他的控制中继的活动，并且使用该中继来与它的peer交换包。
RFC 6144	Informational	Framework for IPv4/IPv6 translation
本文档描述了IPv4/iPv6翻译的框架。这是处在替换NAT-PT的情景之中进行的讨论，NAT-PT已在RFC 4966中被废弃，该框架旨在在向IPv6迁移的过程中使得网络中IPv和IPv6以某种合理的方式共存。
RFC 6146	Standards Track	Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
本文档描述了有状态的NAT64转换，使得纯IPV6的客户机能够使用单播的UDP、TCP或者ICMP与IPV4服务器联系。分配给NAT64转换器的一个或者多个公开的IPV4地址被多个纯IPV6的客户机共享使用。当有状态的NAT64与DNS64关联时，通常不在需要在IPV6客户机和IPV4服务器上再做任何改变。
RFC 6145	Standards Track	IP/ICMP Translation Algorithm
描述了无状态的IP/ICMP转换算法（SIIT: Stateless IP/ICMP Translation），该算法在IPv4和IPv6报文之间进行报文头的翻译（包括ICMP报文头）。

表1. BEHAVE目前发布的RFC及其简介^[3]

从BEHAVE工作组目前发布的RFC来看，已经完成的工作主要覆盖了如图3所示的几种翻译情景：1. IPv6网络到IPv互联网的有状态和无状态的翻译；2. IPv4互联网到IPv6网络的无状态翻译；3. IPv6互联网到IPv网络的有状态翻译；4. IPv6网络到IPv4网络的有状态和无状态翻译；5. IPv4网络到IPv6网络的无状态翻译。