IPv6BBS

 找回密码
 注册

扫一扫,访问微社区

QQ登录

只需一步,快速开始

查看: 6121|回复: 4

IPv4/IPv6过渡的核心技术标准RFC6052

[复制链接]
满天星 发表于 2010-12-9 22:16:45 | 显示全部楼层 |阅读模式
近年来,随着互联网用户数的飞速增长,IPv4地址资源也急剧消耗。根据亚太地区网络中心(APNIC)测算,2011年3月IANA可分配IPv4地址将全部耗尽;到2012年各个地区互联网地址分配机构RIR可分配IPv4地址将全部耗尽。拥有足够地址空间的IPv6协议作为下一代互联网协议,早在1998年就有了相应的RFC(RFC 2460),却没有在11年的发展中得到大规模的应用。目前作为解决IPv4协议地址空间不足的惟一替代协议,人们越来越认识到必须向IPv6过渡,IPv6网络的大规模部署势在必行。

  过渡问题需要突破技术

  总结IETF长期形成的有关技术文档,可以看到,作为IETF最早推荐的双栈过渡技术和隧道过渡技术,却没有推动实现IPv4互联网向IPv6互联网过渡。双栈技术能够使得双栈主机分别与IPv4主机和IPv6主机通信,但是双栈方案并没有解决IPv4和IPv6互访的问题,同时该方案需要的IPv4地址量并没有减少,IPv4地址耗尽的问题并没有解决。隧道技术采用报文的封装机制,能够利用IPv4网络传递IPv6报文或者利用IPv6网络传递IPv4报文,但是同样的,它仅支持跨越IPv6网络的IPv4-IPv4通信或跨越IPv4网络的IPv6-IPv6通信,无法支持IPv4和IPv6的互访。另一方面,在隧道的自动配置时需要单独的机制,而这种机制在大规模部署时存在着可扩展性和可管理性的问题。

  从1998年开始我们开始建设CERNET的IPv6试验床,采用IPv6 over IPv4技术;在2000年建设NSFCNET,采用IPv4/IPv6双栈技术;在2004年建设CNGI-CERNET2,采用纯IPv6和IPv4 over IPv6技术。这些实践证明无论采用双栈技术还是采用隧道技术,从IPv4到IPv6的过渡进展速度仍然赶不上IPv4地址耗尽的速度。我们认识到整个Internet不可能在短时间内进行IPv4到IPv6的切换。因此在长期的过渡过程中,大量的IPv4的应用业务仍将在较长一段时期内存在并会以缓慢的速度逐步过渡到IPv6。在这个过渡期间,IPv4和IPv6的不兼容性使得IPv6的用户无法直接访问IPv4网络上的资源,同时,IPv4用户也无法直接访问IPv6网络上的资源。这就给IPv6网络的进一步部署和应用带来了巨大的困难,因此,IPv4网络和IPv6网络之间互访问题成为了IPv4向IPv6过渡方案中要解决的关键问题。

  IPv4/IPv6翻译技术能够成功实现IPv4网络与IPv6网络之间的互访问题,但是由于IETF在设计IPv6协议时,没有充分意识到与IPv4协议兼容的重要性。翻译技术可以分为无状态翻译技术(stateless translation)和有状态翻译技术(stateful translation)两种。有状态翻译是指需要在翻译设备中动态产生并维护IPv4地址和IPv6地址之间的映射关系,反之,通过预先设定的算法维护IPv4地址和IPv6地址之间的映射关系,则称为无状态翻译。IETF历史上早期的IPv4/IPv6的翻译技术标准为RFC2765和RFC2766。其中RFC2765是无状态的翻译(SIIT),只适用于子网范畴,无法实用;RFC2766为有状态的翻译(NAT-PT),具有可扩展性等重大问题,已被RFC4966归类为历史性技术标准。


  IVI解决过渡难题

  通过建设IPv6网络的大量的实践,我们提出了基于运营商路由前缀的无状态IPv4/IPv6翻译技术IVI(在罗马数字的表示中 VI代表4,VI代表6,所以IVI代表IPv4和IPv6的互联互通)。这一发明正好解决了全球面临的严峻的IPv4/IPv6的过渡难题。因此从2008年以来,我们积极参与了IETF的Transport领域中的BEHAVE工作组IPv4/IPv6翻译过渡技术相关RFC的制定。

  在以IVI为代表的无状态翻译技术和以NAT64为代表的有状态的翻译技术的基础上,IETF的BEHAVE工作组形成了最新IPv4/IPv6翻译技术标准的新框架文件,针对8个IPv4/IPv6通过翻译技术实现互通的场景,制定新的协议集标准,包括IPv4/IPv6地址翻译、IPv4/IPv6协议翻译、有状态翻译时的状态维护方法、域名翻译等等。

  IETF已于2010年10月发布IVI翻译技术的第一个标准RFC6052。

  RFC6052是BEHAVE工作组新框架中最重要的部分之一,定义IPv4/IPv6地址的翻译机制,这个机制既可以用于无状态的IPv4/IPv6翻译技术,也可以用于有状态的IPv4/IPv6翻译技术。RFC6052属于标准类RFC,也是IPv6技术核心标准RFC4291(IP Version 6 Addressing Architecture)的重要更新和补充,成为IPv6体系结构中新的核心技术标准。RFC6052对于IPv6协议地址结构的演进和IPv4/IPv6过渡技术具有重要的影响。

  RFC6052的创新

  作为RFC6052的主要作者,我们在此简要介绍RFC6052的主要内容。

  RFC6052的要点为:

  1. 讨论了嵌入IPv4地址的IPv6地址的结构,包括IPv4-converted IPv6 address和IPv4-translatable IPv6 address的概念。指出这类地址既可以用于IPv4/IPv6的翻译,又可以用于IPv4/IPv6的隧道。
  2. 定义了嵌入IPv4地址的IPv6地址的结构格式包括前缀(prefix),IPv4地址(v4),u字节(u)和后缀(suffix)。在此基础上,定义了IPv4地址到IPv6地址和IPv6地址到IPv4地址的翻译算法,给出了相应的实例。

  3. 对于无状态的IPv4/IPv6翻译(IVI),内部IPv6主机的地址必须使用IPv4-translatable IPv6 address,互联网上的IPv4主机必须使用IPv4-converted IPv6 address;这两类地址的前缀必须使用运营商的路由前缀。可使用的前缀长度包含/32、/40、/48、/56、/64。无状态的IPv4/IPv6翻译可以用于的场景为“an IPv6 network to the IPv4 Internet”,“the IPv4 Internet to an IPv6 network”,“an IPv6 network to an IPv4 network”,和“an IPv4 network to an IPv6 network”。目前的IPv4和IPv6的路由配置策略均可用于无状态的IPv4/IPv6翻译,具有很好的可扩展性、安全性和可运营性。

  4. 对于有状态的IPv4/IPv6翻译(NAT64),互联网上的IPv4主机必须使用IPv4-converted IPv6 address;在应用场景“the IPv6 Internet to an IPv4 network”中必须使用运营商的路由前缀,在应用场景“an IPv6 network to the IPv4 Internet”和“an IPv6 network to an IPv4 network”中,除使用运营商的路由前缀外,还可以使用well-known前缀64:ff9b::/96。

  5. 讨论了RFC6052所定义的新的地址结构对于路由、网络管理和网络安全的影响。

  目前我们正在实施 “2008年下一代互联网业务试商用及设备产业化专项-教育科研基础设施IPv6技术升级和应用示范项目:IPv4/IPv6过渡系统”。该项目以RFC6052和相关系列标准为依据。国内外运营商和信息提供商也正在对基于RFC6052及其他系列标准的方案进行测试和现网部署。

(作者单位为清华大学网络中心)

(文章来源:《中国教育网络》杂志2010年12月刊)

附:
RFC6052:IPv6 Addressing of IPv4/IPv6 Translators  http://www.rfc-editor.org/rfc/rfc6052.txt
yuyong 发表于 2010-12-12 15:05:54 | 显示全部楼层
期待IVI可以商用部署。
 楼主| 满天星 发表于 2010-12-12 16:03:47 | 显示全部楼层
IVI在教育网显然是有部署了,包括相关的Linux设备源代码(IVI Itranslation implementation与 IVI A/AAAA DNS proxy implementation)。
NAT64也有相关的部署了!
二者都有相关组织、机构免费提供的Linux源代码,本站内都有相关协议原理的RFC\Draft\Linux Source Code介绍链接!
xiaobao4955 发表于 2012-11-16 10:54:18 | 显示全部楼层
IVI是不是和中国电信合作的?
 楼主| 满天星 发表于 2012-11-16 19:37:20 | 显示全部楼层
xiaobao4955 发表于 2012-11-16 10:54
IVI是不是和中国电信合作的?

不清楚,偶也是不明真相的围观群众!
据说Cernet上应该有吧!
您需要登录后才可以回帖 登录 | 注册

本版积分规则

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

GMT+8, 2020-11-25 01:34 , Processed in 0.027960 second(s), 17 queries .

Powered by Discuz! X3.4

Copyright © 2001-2020, Tencent Cloud.

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