找回密码
 注册

扫一扫,访问微社区

QQ登录

只需一步,快速开始

查看: 6692|回复: 2

统一的IPv4/IPv6翻译与封装过渡技术——IVI/MAP-T/MAP-E

[复制链接]
满天星 发表于 2013-4-11 21:33:15 | 显示全部楼层 |阅读模式
基于IPv4 协议的互联网是世界上最重要的信息基础设施,但是只有232 个地址空间的IPv4 地址已经分配完毕。为了解决IPv4 地址耗尽问题,目前有两种技术路线:采用IPv4 地址翻译技术(NAT44)或升级到IPv6。NAT44 是IPv4 公有地址与IPv4私有地址之间的有状态翻译技术,已经非常成熟,但由于其破坏了端到端特性,只能支持单向发起的通信。多年以来,NAT44 在用户接入端被广泛使用,但在核心网络上使用时,需要在NAT44 翻译器上维护大量状态。

为了长远地解决IP 地址的问题,建设下一代IPv6 网络,发展IPv6 信息资源,发展IPv6 用户势在必行。10 多年前,业内已经认识到IPv4 地址枯竭问题,发明了下一代互联网协议IPv6,该协议具有2128 个地址空间,从根本上解决了地址耗尽的问题。因特网工程任务组(IETF)最早推荐从IPv4向IPv6 过渡采用双栈技术和隧道技术,全世界很多运营商在不同规模上进行了IPv6 的试验,若干信息提供商也提供了IPv6 的服务[1]。但截至2012年,全世界IPv6 网的流量平均不到IPv4 的1% 。实践表明,升级到双栈不仅没有给运营上带来直接的收益,反而影响了用户的体验。这就是为什么双栈和隧道技术应用10 多年,却没有推动完成IPv4 互联网向IPv6互联网过渡的原因。从根本上看,网络的价值在于其用户数。对于新建的IPv6 网络,其用户数不可能与IPv4互联网上的用户数可比,如果IPv6 的用户不能与IPv4 的用户互联互通,则IPv6 网络没有任何存在的价值。因此过渡的核心问题是新建IPv6 网络必须与IPv4 互联网互联互通。两种不同协议之间的互联互通,只能通过翻译技术解决,但是由于IETF 在设计IPv6 协议时,没有充分意识到与IPv4 协议兼容的重要性,具有很高的技术难度。随着纯IPv6 网络建设案例的增多和研究的深入,IETF 在IPv4/IPv6 翻译技术,特别是无状态翻译技术取得了突破性进展,形成了系列RFC 标准和工作组草案,为IPv4 到IPv6 过渡提供了新的技术方案。

1 无状态IPv4/IPv6 翻译技术

互联网的基本特性为“ 无连接”的体系结构,路由器不需要维护状态,IPv4/IPv6 翻译器本身也是一个路由器,因此无状态的IPv4/IPv6 翻译器对于运营商来讲更具有价值。同时,无状态IPv4/IPv6 翻译(IVI)技术具有可扩展性、可管理性、安全性好的特点,并支持双向发起的通信。IVI 的名称借用了罗马数字的表示方法。在罗马数字中IV 表示4,VI 表示6,IVI 表示IPv4 和IPv6 的互联互通。

1.1 IPv4/IPv6 翻译技术的应用场景

由于IPv4 的地址空间为232,IPv6的地址空间为2128,极其悬殊,因此不加限制条件的IPv4/IPv6 翻译器在理论上讲是不可行的。在IETF 标准RFC6144 中定义了IPv4/IPv6 翻译的8个应用场景。翻译器的两边一边是IPv4 另一边是IPv6。其变化之一在于哪一边是自己控制的网络,哪一边是互联网。其变化之二在于哪一边发起通信。无状态IPv4/IPv6 翻译技术的应用场景如图1 所示[2]。场景一为IPv6 网络上计算机发起对IPv4 互联网上计算机的访问,场景二为IPv4互联网上计算机发起对IPv6 网络上计算机的访问。



图1无状态IPv4/IPv6翻译技术的应用

场景一和场景二意味着新建纯IPv6 网络,通过翻译器XLAT 为IPv6用户提供对IPv4 互联网的通信。无状态IPv4/IPv6 翻译技术可以适应于场景一和场景二,有状态IPv4/IPv6 翻译技术只能适应于场景一。IPv4/IPv6 翻译技术的核心是需要解决地址映射和协议翻译问题。

1.2 地址映射和域名翻译

由于IPv4 和IPv6 的地址空间差距巨大,用IPv6 表示IPv4 是毫无问题的,可以通过无状态的映射方法,映射后的IPv6 地址称为转换地址。用IPv4 表示IPv6 是难点,可以动态维护映射表,作有状态的地址映射,或在IPv6 地址中选择一个子空间通过无状态的方法与IPv4 地址映射。映射后的IPv6 地址称为可译地址。所有这些地址映射算法均在IETF 标准RFC6052 中定义。嵌入了IPv4 地址的IPv6 地址格式如图2 所示[3]。



图2 嵌入了IPv4 地址的IPv6 地址格式

其中Prefix 是IPv6 网络前缀,根据不同的前缀长度,嵌入IPv4 地址,并且在64 至71 位间保持为全0,以便与IPv6 地址结构中的u-bit 兼容。

Suffix 为后缀,在基本的地址映射中为全0,预留给传输层端口的编码,以便把一个IPv4 地址映射为若干IPv6 地址,达到高效地、无状态地复用稀缺的公有IPv4 地址资源的目的。此外,RFC6052 要求转换地址和可译地址使用同样的前缀(Prefix),从而可以自动获得最优路由。

当纯IPv6 计算机发起对IPv4 互联网的访问时,必须获得相应的转换地址,这个工作由域名翻译器DNS64根据上述映射算法完成,由RFC6147定义[4]。DNS64 是同时接入IPv4 网络和IPv6 网络的域名服务器(DNS),能够把A 记录动态翻译成AAAA 记录。具体步骤为纯IPv6 计算机通过DNS64 查询所需域名的AAAA 记录,如AAAA 记录存在,则DNS64 直接返回AAAA 记录给纯IPv6 计算机;如AAAA 记录不存在,则DNS64 查询域名对应的A 记录,并根据RFC6052 定义的映射算法,生成AAAA 记录返回给纯IPv6 计算机。无状态的翻译器支持IPv4 互联网发起的通信,在这种情况下,需要静态配置的DNS46,当IPv4 互联网上的用户发起对IPv6 计算机的访问时,DNS46 则返回对应IPv6 计算机AAAA 对应的A 记录[5]。

1.3 协议翻译

两种不同协议栈之间的互联互通必须解决的第二个问题是协议翻译,所庆幸的是IPv4 和IPv6 之间协议的差距并不很大,是可译的。具体协议翻译算法由RFC6145 定义,包括版本号映射,IPv4 的服务类型与IPv6 的流量等级映射,IPv4 的总长与IPv6 的载荷长度映射,IPv4 的存活期与IPv6的转发计数映射,IPv4 的传输层协议与IPv6 的下一个头映射,IPv4 地址和IPv6 地址映射等[6]。IPv4 与IPv6 协议翻译的最大难点是分片处理,因为IPv4 可以支持路由器分片或端系统分片,但IPv6 仅支持端系统分片。对于IPv4 已经分片的分组,IPv6 必须增加分片扩展头,以便端系统重组。此外,IPv4 和IPv6 网络所能支持的最大传输单元的大小(MTU)是不同的,同时由于IPv4 的基本头为20 个字节,而IPv6 的基本头为40 个字节,因此在从IPv4 到IPv6 的翻译过程中必然遇到MTU 超出的问题。此外,IPv4 的传输控制协议(ICMP)和IPv6 的传输控制协议(ICMPv6)也有很多不同,需要分别处理。

值得指出的是,当IPv6 网络中的路由器(通常并不使用可译地址)返回ICMPv6 分组时,翻译器无法找到对应的IPv4 地址,造成翻译后的ICMP 分组的源地址不可溯源。IETF最新发布的RFC6791 定义了对这个问题的有效处理方法[7]。

RFC6145 也是有状态IPv4/IPv6 翻译器所依据的协议翻译算法。有状态IPv4/IPv6 翻译器中的状态维护技术由RFC6146 定义,主要规定了IPv6地址和端口到IPv4 地址和端口的动态映射表的生成、维护和销毁算法[8]。

2 无状态双重翻译/封装技术(MAP 系列)

IPv4/IPv6 翻译技术可以使IPv4 和IPv6 互联互通,但仍有3 个问题需要解决。第一个问题是由于IPv4 地址耗尽问题,无状态IPv4/IPv6 翻译必须能够复用公有IPv4 地址以高效使用IPv4 地址资源;第二个问题是目前有的应用程序并没有IPv6 的版本(如Skype),也有的应用程序嵌入了地址的信息(如Ftp);第三个问题是对于终端用户往往需要分配一个64 位的前缀,而不是单个的IPv6 地址。无状态双重翻译/封装系列技术MAP-T/MAP-E 可以解决这些问题。MAP 是Mapping Address and Port 的缩写,意指无状态地对地址和端口进行复用,与双重翻译(MAP-T)或封装(MAP-E)技术组合,可以解决无状态复用公有IPv4 地址的问题和上述的应用程序问题,同时可以支持前缀分配。

MAP-T/MAP-E 目前是IETF 的工作组文档[9-10],其他相关的工作组文档还有DHCPv6 扩展[11]和部署考虑[12]。

2.1 双重翻译模式的应用场景

无状态双重IPv4/IPv6 翻译模式(MAP-T)的应用场景如图3 所示。



图3 无状态双重IPv4/IPv6 翻译模式的应用场景

图3 中,核心翻译器称为BR,对于IPv6 为路由器,对于IPv4 为可以复用IPv4 地址的IPv4/IPv6 翻译器。第二次翻译在家庭网关CE 上进行,CE对于IPv6 为路由器,对于IPv4 为IPv4/IPv6 翻译器,并且根据下述端口映射算法对于传输层的端口进行映射。

IPv6 接入网部署认证和IPv6 前缀分配设备AAA 数据库和DHCPv6 服务器。IPv6 接入网上可以部署使用可译地址的纯IPv6 服务器,通过CE 或BR 的一次翻译能够对于用户的纯IPv4 终端和IPv4 互联网上的用户提供服务。IPv6 接入网的用户设备接到家庭网关上,可以是纯IPv4 终端设备,它通过CE 一次翻译访问网内纯IPv6 服务器的信息资源,同时它通过CE 和BR 双重翻译访问IPv4 互联网上的信息资源,并与其他用户互访。

该用户设备还可以是IPv4/IPv6 双栈终端设备,直接访问网内和IPv6 互联网上的信息资源,并通过CE 和BR 双重翻译访问IPv4 互联网上的信息资源,也能与其他用户互访。该用户设备也可以是纯IPv6 终端设备,直接访问网内和IPv6 互联网上的信息资源,通过BR 一次翻译访问IPv4 互联网上的信息资源,并与其他用户互访。

2.2 封装模式的应用场景

封装模式(MAP-E)的应用场景如图4 所示。



图4MAP-E 的应用场景

图4 中,核心封装/解封装器称为BR,对于IPv6 为IPv6 路由器,对于IPv4 为可以复用IPv4 地址的IPv4over IPv6 封装/解封装器。家庭网关CE 对于IPv6 为路由器,对于IPv4 为IPv4 over IPv6 封装/解封装器,并且根据下述端口映射算法对于传输层的端口进行映射。IPv6 接入网部署认证和IPv6 前缀分配设备AAA 数据库和DHCPv6 服务器。IPv6 接入网的用户设备接到家庭网关上,可以是纯IPv4 终端设备,它通过CE 和BR 封装/解封装访问IPv4 互联网上的信息资源,并与其他用户互访;该用户设备还可以是IPv4/IPv6 双栈终端设备,直接访问网内和IPv6 互联网上的信息资源,并过CE 和BR 封装/解封装访问IPv4 互联网上的信息资源,也能与其他用户互访。值得指出的是,封装模式MAP-E 无法支持在IPv6 接入网内部署纯IPv6 服务器,也不支持可以与IPv4 互联网互联互通的纯IPv6 终端设备。

2.3 端口映射

MAP 的核心技术之一是无状态地址和端口映射算法,其思想是利用16 位的传输层( 传输控制协议(TCP)、数据报协议(UDP))端口对于IPv4 地址进行扩展。不复用IPv4地址时,一个终端设备可用的并发TCP 或UDP 的端口数为65 536;如复用比为16,则一个终端可用的并发TCP 或UDP 的端口数为4 096;如复用比为128,则一个终端可用的并发TCP 或UDP 的端口数为512。根据统计,一个普通终端的并发TCP 或UDP的端口数为有限的,因此可以利用无状态地址和端口映射算法高效率地复用公有IPv4 地址资源。在使用无状态地址和端口映射算法时,需要给每一个终端定义一个端口标识集(PSID),端口标识集和可用端口的映射关系由扩展的模算法来决定。

扩展的模算法的定义为:

(1)给定PSID,该端系统可以使用的传输层端口P 为:P =R ×M ×j +M×K +i ,其中R 为复用比,M 为连续端口数,i 和j 为整数变量。

(2)给定传输层端口P ,该端系统的PSID 为:P = floor(P /M)%R ,其中floor 为只舍不入的取整算法,% 为常规定义的模运算符。

扩展的模算法是一个适应性很广的算法,即可以使持有不同PSID终端所使用的传输层端口在整个端口空间均匀分布,也可以按块分布,还可以制订每一块包含的连续端口数量。此外,扩展的模算法还可以支持类似与无分类地址域间路由(CIDR)类似的地址聚类,即对应于特定的PSID,可以定义PSID 长度,对于可用端口进行聚类使用。

通过扩展的模算法,在给定复用比、连续端口数量和端口聚类长度的条件下,可以通过PSID 的值计算出特定终端可以使用的所有的TCP 或UDP 端口;也可以对于任意给定端口计算出对应的PSID,实现端系统的无状态公有IPv4 地址复用,因而可以极大地减小管理开销,并极大地提高安全性和可溯源性。由于ICMP 和ICMPv6 没有源和目标端口的域,只有标识域(ID),因此要对标识域ID作扩展的模算法映射。

2.4 地址格式

MAP 的地址格式是RFC6052 的扩展,如图5 所示。



图5 MAP 地址格式

与RFC6052 的区别主要有:

(1)MAP 的地址格式是RFC6052当Prefix 长度为64 的一个特例,其Prefix 里包含IPv6 Prefix、EA-bits(由IPv4 子网标识和PSID 组成,用于唯一标识不同的用户)和Subnet-id(用于标识一个用户使用的大于等于/64 的IPv6 子网)。

(2)在MAP 中Suffix 不为0,而是嵌入了PSID。

(3)MAP 对于转换地址和可译地址使用不同的Prefix,以解决为终端用户分配前缀,而不是响应单个地址的要求。

利用EA-bits 可以为每一个家庭网关CE 分配唯一的Prefix,不使用EA-bits,而为每个CE 分配不同的Prefix 也可以达到同样的目的。采用EA-bits 的好处是可以进行地址聚类,可扩展性好;不采用EA-bits 的好处是IPv6 前缀与IPv4 地址独立。这两种方法各有优缺点,可以根据不同需要进行选择。

2.5 统一双重翻译和封装模式的机制

无状态双重IPv4/IPv6 翻译可以支持纯IPv4 应用程序(如Skype),同时对于嵌入IP 地址的应用程序(如Ftp)也不需要IPv4/IPv6 之间的应用层网关(ALG),此外双重翻译不需要DNS64 和DNS46。无状态双重翻译可以看成是具有头压缩功能的、无状态IPv4 over IPv6 的封装技术。无状态双重翻译技术(MAP-T)和无状态封装技术(MAP-E)采用同样扩展的模算法和同样的地址格式(在封装模式下BR 地址可以蜕化为单个地址),因此具有众多的相似性,唯一的不同是数据流处理模式。在双重翻译模式(MAP-T)下数据流的处理依据为翻译,由RFC6145 定义,在封装模式(MAP-E)下数据流的处理为数据封装,由RFC2473 定义[13]。

MAP-T 模式的优点是可以蜕化为一次翻译,有利于过渡到纯IPv6 网络,但仍然保持与IPv4 互联网的互联互通。同时,在IPv6 接入网内的IPv6数据报文没有封装的数据结构,可以使用IPv6 路由器上的所有网络层和传输层的管理和控制功能,而MAP-E必须对于数据报文进行解封装,才能进行管理和控制。MAP-E 模式的优点是可以完全保持IPv4 报文承载的所有信息,同时不需要对传输层的校验和进行修改。由于RFC2473 定义的封装模式与传输层的TCP、UDP 均由IPv6 头结构的下一个头定义,因此,只有从IPv4 到IPv6 的处理需要定义采用翻译模式还是封装模式,从IPv6 到IPv4 的处理可以根据下一个头自动适应性完成翻译或封装模式的选择。因此,MAP-T 和MAP-E 可以根据需求灵活配置,其分析参见MAP 测试文档[14]。

2.6 统一无状态/用户状态/有状态

无状态是指IPv4/IPv6 地址和传输层端口之间的映射关系完全由算法决定,设备不需要维护映射状态表。有状态是指IPv4/IPv6 地址和传输层端口之间的映射关系根据会话的5 元组动态生成,设备需要维护动态生成的映射状态表。用户状态是指IPv4/IPv6 地址和传输层端口之间的映射关系对于各个用户定义,设备只需要维护用户映射状态表。无状态翻译技术不仅可以与无状态封装技术统一起来,也可以与有状态的翻译技术NAT64 和有状态的隧道技术Dual-stack Lite[15] 统一起来。因此MAP-T/MAP-E 家庭网关CE,不经任何修改就可以与有状态翻译器NAT64 或Dual-stack Lite 的AFTR 完成有状态双重翻译或有状态隧道的功能。由于无状态和有状态是两个极端的情况,MAP-T/MAP-E 家庭网关CE 也可以不经任何修改支持任何用户状态的场景。

3 过渡路线图

虽然IPv4 地址已经分配完毕,但全世界IPv6 的普及率仍然非常低。

为了保证全球互联网的健康和可持续发展,必须制订正确的过渡路线图。10 年前IETF 制订的“ 以双栈为主,辅之以隧道,在没有其他选择时用翻译”的策略值得反思,理由为:

(1)这一政策在过去10 余年里并没有完成从IPv4 到IPv6 的过渡。

(2)对于中国这样的国家,已经没有更多的IPv4 公有地址实施双栈,而通过NAT44 利用私有地址实施双栈并不能鼓励IPv6 的过渡。

随着无状态翻译技术(IVI)和无状态双重翻译技术(MAP)的成熟,我们建议应建设纯IPv6 网络,实施“ 以翻译技术为主,辅之以封装,在没有其他选择时用双栈”的策略。具体技术方案为:

(1)新建纯IPv6 网络,当通信的对端也为IPv6 是,采用IPv6 通信。

(2)当通信的对端为IPv4 是,优先采用一次无状态IPv4/IPv6 翻译技术进行通信。

(3)当应用程序不支持IPv6,或应用程序嵌入IPv4 地址时,采用无状态双重IPv4/IPv6 翻译技术进行通信。

(4)当需要保持IPv4 报文所有的信息,或处理传输层加密的报文,采用封装技术进行通信。

(5)在过渡的中后期,双重翻译将无缝地退化成一次翻译,最终关闭一次翻译器,进入纯IPv6 时代。

采用以上建议的过渡线路图,可以使我们自己的网络率先过渡到IPv6,并高效地利用公有IPv4 地址资源与IPv4 互联网互联互通,从而在IPv4 到IPv6 的过渡过程中保持主动。这一技术方案完全符合中国发展下一代互联网的路线图和时间表,即“ 在2011—2015 年的过渡阶段,政府引导全社会向IPv6 过渡,IPv4 与IPv6 共存,新建网络必须为IPv6 并实现与IPv4 的互通”。目前无状态IPv4/IPv6 翻译技术(IVI)已经发布5 个IETF 的RFC 标准,MAP 技术已经形成4 个IETF 工作组草案。IVI 技术已有思科、中兴通讯、华为等设备厂家的产品支持,并在CNGi-CERNET2 上正常运行2 年以上。MAP 技术已有思科等设备厂家的产品正式发布,得到意大利电信、日本软银、德国电信、美国Charter 等多家国际运营商的支持和关注,产业链正在逐步形成。作为唯一能够使IPv4 和IPv6 互联互通的无状态翻译技术和双重翻译技术IVI/MAP,预计在近几年会得到大发展。

参考文献

[1] NORDMARK E, GILLIGAN R. Basic transition mechanisms for IPv6 hosts and routers [S].RFC 4213. 2005.

[2] BAKER F, LI X, BAO C, et al. Framework for IPv4/IPv6 Translation [S]. RF C6144. 2011.

[3] BAO C, HUITEMA C, BAGNULO M, et al.IPv6 addressing of IPv4/IPv6 translators [S]. RFC 6052. 2010.

[4] BAGNULO M, SULLIVAN A, MATTHEWS P,et al. DNS64: DNS extensions for network address translation from IPv6 clients to IPv4 servers [S]. RFC 6147. 2011.

[5] LI X, BAO C, CHEN M, et al. The CERNET IVI translation design and deployment for the IPv4/IPv6 coexistence and transition [S]. RFC 6219. 2011.

[6] LI X, BAO C, BAKER F. IP/ICMP translation algorithm [S]. RFC 6145. 2011

[7] LI X, BAO C, WING D, et al. Stateless source address mapping for ICMPv6 packets [S]. RFC 6791. 2012.

[8] BAGNULO M, MATTHEWS P, VAN BEIJNUM I. Stateful NAT64: Network address and protocol translation from IPv6 clients to IPv4 servers [S]. RFC 6146. 2011.

[9] LI X, BAO C, DEC W, et al. Mapping of address and port using translation (MAP-T) [R]. draft-ietf-softwire-map-t-00. 2012.

[10] TROAN O, DEC W, LI X, et al. Mapping of address and port with encapsulation (MAP) [R]. draft-ietf-softwire-map-02. 2012.

[11] MRUGALSKI T, TROAN O, BAO C, et al. DHCPv6 options for mapping of address and port [R]. draft-ietf-softwire-map-dhcp-01. 2012.

[12] SUN Q, CHEN M, CHEN G, et al. Mapping of address and port (MAP) -- Deployment considerations [R]. draft-ietf-softwire-map-deployment-00. 2012.

[13] CONTA A, DEERING S. Generic packet tunneling in IPv6 specification [S]. RFC 2473. 1998.

[14] LI X, BAO C, HAN G, et al. MAP Testing Results [R]. draft-xli-softwire-map-testing-00. 2012.

[15] DURAND A, DROMS R, WOODYATT J, et al. Dual-stack lite broadband deployments following IPv4 exhaustion [S] .RFC 6333.2011.

作者:包丛笑 李星   来源:中兴通讯技术

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?注册

×
Tanker 发表于 2013-6-14 11:10:57 | 显示全部楼层
这是李教授最新的文章,解决了很多疑问,值得一读。
回复

使用道具 举报

Tanker 发表于 2013-6-17 18:08:18 | 显示全部楼层
图3中的双重翻译不如用隧道,这需要CE设备同时支持翻译和隧道功能。用隧道比双重翻译好得多,问题少。
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

Archiver|手机版|小黑屋|IPv6BBS ( 京ICP备13024693号 | 京公网安备11010802012238 )

GMT+8, 2024-3-29 14:58 , Processed in 0.026051 second(s), 21 queries .

Powered by Discuz! X3.5

© 2001-2023 Discuz! Team.

快速回复 返回顶部 返回列表