IPV6过渡技术

最新推荐文章于 2024-07-16 22:32:20 发布

jacson8408

最新推荐文章于 2024-07-16 22:32:20 发布

阅读量744

点赞数

分类专栏：网络文章标签：路由器 internet translation 网络 transition 服务器

网络专栏收录该内容

11 篇文章 0 订阅

订阅专栏

该文章摘自http://www.cernet2.edu.cn，文章很好的总结了IPV6的一些过渡技术，虽然不够详细，但比较全面，很多技术我目前也不懂，不知道细节，留待后面补充、更新

1.为什么需要过渡技术

随着Internet的不断发展，原有IPv4的许多不足逐渐暴露了出来，这里面最迫切需要解决的就是IP地址空间耗尽和骨干路由器中路由表过于庞大的问题。这两个问题直接导致了IETF成立IPng工作组来制定新一代的IP协议，并在1995年底为它分配了版本号6，称为IPv6 ( 或 IPng ) 。为了彻底解决目前IPv4遇到的问题并对未来的应用提供更好的支持，IPv6的设计者们最后决定将IPv6设计成一个新的协议，而不仅仅是IPv4的扩展。尽管在设计IPv6的时候已经充分考虑了和IPv4的兼容性，但是它们不是完全兼容的。可以预见，Internet由IPv4向IPv6过渡需要一个相当长的时间才能完成，在这段时间内这种不兼容性的影响将会很突出，IETF已经成立的专门的工作组NGTRANS来研究从IPv4向IPv6的过渡问题。

2.过渡机制概述

我们面临的主要问题不是IPv6本身的问题，而是如何渐进的、无伤害的由基于IPv4的网络过渡到基于IPv6的网络，同时尽可能减少过渡的成本的问题，SIT ( Simple Internet Transition ) 阐述了过渡的要求。
由于过渡是渐进的，在过渡的初期，Internet将由运行IPv4的"海洋"和运行IPv6的"小岛"组成。随着时间的推移，IPv4的海洋将会逐渐变小，而IPv6的小岛将会越来越多，最终完全取代IPv4。在过渡的初期，要解决的主要是IPv6小岛之间的通信问题，随后是IPv6小岛和IPv4海洋之间通信的问题。针对这两类问题已经提出了很多方案，有一些已经相当成熟并形成了RFC，有一些还只是草案。

3.过渡技术分类

解决过渡问题的成熟的基本技术主要有三种：

双协议栈 ( Dual Stack, RFC2893 )：主机同时运行IPv4和IPv6两套协议栈，同时支持两套协议
隧道技术 ( Tunnel, RFC2893 ):这种机制用来在IPv4网络之上连接IPv6的站点，站点可以是一台主机，也可以是多个主机。隧道技术将IPv6的分组封装到IPv4的分组中，封装后的IPv4分组将通过IPv4的路由体系传输，分组报头的"协议" 域设置为41，指示这个分组的负载是一个IPv6的分组，以便在适当的地方恢复出被封装的IPv6分组并传送给目的站点。
- 根据封装/解封装操作发生位置的不同，隧道可以分为四种：
  - 路由器到路由器 ( Router-to-Router )
  - 主机到路由器 ( Host-to-Router )
  - 主机到主机 ( Host-to-Host )
  - 路由器到主机 ( Router-to-Host )
- 根据建立方式的不同，隧道又可以分成两类：
  - (手工)配置的隧道 ( Configured Tunnel )
  - 自动配置的隧道 ( Auto-configured Tunnel )
NAT-PT ( Network Address Translation - Protocol Translation，RFC2766 ):利用转换网关来在IPv4和IPv6网络之间转换IP报头的地址，同时根据协议不同对分组做相应的语义翻译，从而使纯IPv4和纯IPv6站点之间能够透明通信。

4.具体方案

基于这三种基本技术派生出了许多种方案，分别针对特定的情况，解决某些特定问题：

IPv6小岛之间的通信
- 1) 手工配置的隧道 ( Configured Tunnel, RFC2893 )
  - 这种隧道的建立是手工配置的，需要隧道两个端点所在网络的管理员写作完成。隧道的端点地址由配置来决定，不需要为站点分配特殊的IPv6地址，适用于经常通信的IPv6站点之间。这些站点之间必须有可用的IPv4 连接，采用这种机制的站点至少要具有一个全球唯一的IPv4地址，站点中每个主机都至少需要支持IPv6，路由器需要支持双栈。在隧道要经过NAT设施的情况下这种机制可能不可用。
- 2)自动配置的隧道 ( Auto-configured Tunnel, RFC2893 )
  - 这种隧道的建立和拆除是动态的，它的端点根据分组的目的地址确定，适用于单独的主机之间或不经常通信的站点之间。自动配置的隧道需要站点采用IPv4兼容的IPv6地址( IPv4 Compatible IPv6 Address，0::IPv4ADDR/96 )，这些站点之间必须有可用的IPv4连接，每个采用这种机制的主机都需要有一个全球唯一的IPv4地址，采用这种机制不能解决IPv4地址空间耗尽的问题。这种隧道的两个端点都必须支持双栈。在隧道要经过NAT设施的情况下这种机制不可用。
- 3)Tunnel Broker ( RFC3053 )
  - Tunnel Broker不是一种隧道机制，而是一种方便构造隧道的机制，可以简化隧道的配置过程，适用于单个主机获取IPv6连接的情况。Tunnel Broker也可用于站点之间，但这时可能会在IPv6的路由表中引入很多条目，导致IPv6的路由表过于庞大，违背了IPv6设计的初衷。用户可以通过Tunnel Broker从支持IPv6的ISP处获得持久的IPv6地址和域名。 Tunnel Broker要求隧道的双方都支持双栈并有可用的IPv4连接，在隧道要经过NAT设施的情况下这种机制不可用。
- 4)6 to 4 ( RFC3056 )
  - 6to4也是一种自动构造隧道的机制，这种机制要求站点采用特殊的IPv6地址（2002:IPv4ADDR::/48 ），这种地址是自动从站点的IPv4地址派生出来的，每个采用6to4机制的节点必须具有一个全球唯一的IPv4地址。由于这种机制下隧道端点的IPv4地址可以从IPv6地址中提取，所以隧道的建立是自动的。6to4不会在IPv4的路由表中引入新的条目，在IPv6的路由表中只增加一条表项。采用6to4机制的IPv6 ISP只需要做很少的管理工作，这种机制很适用于运行IPv6的站点之间的通信。6to4要求隧道中至少有两台路由器支持双栈和6to4，主机要求至少支持IPv6协议栈。
  - 6to4机制允许在采用6to4的IPv6站点和纯IPv6站点之间通过中继路由器 ( 6to4 Relay Router ) 进行通信，这时不要求通信的两个端点之间具有可用的IPv4连接，中继路由器建议运行BGP4+。
- 5) 6 over 4 ( RFC2529 )
  - 6 over 4 也是一种自动建立隧道的机制，可用于在一个物理链路上的IPv6主机。与1.2不同的是，6 over 4利用IPv4的组播机制来实现虚拟链路（注意不是显式的隧道），这种机制要求站点支持组播，并且站点内采用这种机制的主机和路由器都支持6 over 4。一台6 over 4的路由器在站点内广播它的IPv6网络前缀，这种机制不需要IPv4兼容的地址或手工配置的隧道，适用于一个站点的内部。当采用6 over 4的站点通过一台支持6 over 4的路由器与外界相连时，站点内的主机可以和外部IPv6站点通信。
- 6) BGP Tunnel (Internet Draft )
  - 这种机制适用于IPv6站点之间的通信，可以在IPv4的网络中动态的建立隧道。它只需要为每个采用这种机制的站点分配一个IPv4地址以及由此派生的IPv4兼容地址。与自动隧道不同，这种隧道建立在路由器之间。与6to4不同，采用这种机制的站点不必采用特殊的6to4 IPv6地址。这种机制需要站点的边界路由器运行MP-BGP协议。
IPv6小岛与IPv4海洋之间的通信
- 1）Dual Stack Model ( RFC2893 )
  - 在这种模型下，任意节点都是完全双栈的。这时不存在IPv4与IPv6之间的相互通信问题，但是这种机制要给每一个IPv6的站点分配一个IPv4地址，这个要求随着IPv6站点的增加会很难得到满足。
- 2）Limited Dual Stack Model ( RFC2893 )
  - 在这种模型下，服务器和路由器仍然是双栈的，而非服务器的主机只需要支持IPv6。这种机制可以节省大量的IPv4地址，但是在纯IPv6和纯IPv4节点之间的通信将会出现问题。
- 3）SIIT ( Stateless IP/ ICMP Translation, RFC2765 )
  - SIIT定义了在IPv4和IPv6的分组报头之间进行翻译的方法，这种翻译是无状态的，因此对于每一个分组都要进行翻译。这种机制可以和其它的机制(如NAT-PT)结合用于纯IPv6站点同纯 IPv4站点之间的通信，在采用网络层加密和数据完整性保护的环境下这种技术不可用。
- 4）NAT-PT (Network Address Translation - Protocol Translation, RFC2766 )
  - 这种机制在IPv4分组和IPv6分组之间进行报头和语义的翻译，适用于纯IPv4站点和纯IPv6站点之间的通信。对于一些内嵌地址信息的高层协议（如FTP），NAT-PT需要和应用层的网关协作来完成翻译。这种技术在采用网络层加密和数据完整性保护的环境下将不能工作。
- 5）BIS ( Bump-In-the-Stack, RFC2767 )
  - 这种技术允许不支持IPv6的应用程序能够透明的访问纯IPv6站点。这种机制要求主机必须是双栈的，同时要在协议栈中插入三个特殊的扩展模块：域名解析模块、地址映射模块和报头翻译模块，相当于在主机的协议栈中使用了NAT-PT。
- 6）BIA ( Bump-In-the-API, Internet Draft )
  - 这种技术同BIS类似，只是在API层次而不是在协议栈的层次上进行分组的翻译，实现起来比BIS要简单一些。
- 7）SOCKS64 ( Socks 6 to 4, Internet Draft )
  - SOCKS64（SOCKS Gateway ）是原有SOCKS协议 ( RFC1928 ) 的扩展，相当于IP层的代理。这种机制不需要修改DNS或者做地址映射，可用于多种环境，但是需要采用SOCKS代理服务器，并在客户端安装支持SOCKS代理的软件，对于用户来讲不是透明的。
- 8）TRT ( Transport Relay Translator, Internet Draft )
  - 这种机制和SOCKS64相似，但是它是在传输层进行操作，而不是在网络层。TRT就相当于传输层的代理服务器。
- 9）DSTM ( Dual Stack Transition Mechanism, Internet Draft )
  - 这种机制适用于双协议栈的主机同纯IPv4站点之间通信的情况。采用DSTM的双协议栈主机将会临时得到一个IPv4地址(可采用扩展的DHCPv6)用来同IPv4主机通信。这种机制需要DSTM Server的支持以动态或得IPv4地址，采用DSTM技术的站点内部使用IPv6的路由体系，IPv4的数据报将会被封装到IPv6数据报中在站点内传输。
  - 目前的DSTM不支持纯IPv4站点主动发起的与DSTM主机的通信。
- 10）ALG ( Application Level Gateway ) ( Internet Draft )
  - 这种方法在IPv4中即已广泛应用，比较有代表性的就是HTTP的代理。ALG和TRT、SOCKS64类似，不同点在于ALG是应用层的网关。这种方法需要有专门的代理服务器，针对不同的应用要设置不同的代理，同时还需要客户端应用也在不同程度上支持代理，灵活性很差。

以上是目前存在的一些由IPv4网络过渡到IPv6的机制，无论采取哪一种机制，对DNS的扩展都是必须的(RFC2874)。对于不同的机制，DNS解析时返回地址的顺序、主机使用返回地址的顺序有时很关键，这一点需要特别注意。这些过渡机制都不是普遍适用的，每一种机制都适用于某种或几种特定的网络情况，而且常常需要和其它的技术组合使用。在实际应用时需要综合考虑各种实际情况来制定合适的过渡策略。