跳转到内容

IPv6过渡机制

本页使用了标题或全文手工转换
维基百科，自由的百科全书
IPv6过渡机制
标准
实验性
信息性
草稿
已弃用

IPv6过渡机制是指那些用来促进互联网从原有网际协议IPv4向下一代网际协议IPv6过渡的技术。具体来说，由于IPv4和IPv6网络是互不兼容的，这些技术的主要目的在于使得这两个网络中的主机能够访问对方网络。

为了实现IPv6的技术指标，各方必须寻找简单有效的过渡方案，将现有的网络从IPv4过渡到IPv6。互联网工程任务组（IETF）通过使用互联网草案（I-D）和RFC这些方法来指导相关工作组，并为工作组提供讨论与开发这些过渡机制的平台。RFC 4213 定义了一些基础的IPv6过渡机制。

无状态IP/ICMP转换

无状态IP/ICMP转换（SIIT）是在IPv6和IPv4报文头格式之间进行转换。SIIT方法定义一类被称为IPv4转换（IPv4-translated）地址的IPv6地址。这类地址的前缀为::ffff:0:0/96，也可被写作::ffff:a.b.c.d，其中IPv4格式的地址a.b.c.d表示一个使能IPv6（IPv6-enabled）的节点。选择这个前缀是为了生成一个为0的校验值，以此来避免改变传输协议头中的校验值。[1]

此算法可以使IPv6主机无需拥有一个永久的IPv4地址就能与仅有IPv4的主机通信。地址分配和路由的细节并没有在此规范中被提及。

这个规范由NGTRANS IETF工作组制订，草案由Sun Microsystems的E. Nordmark于2000年2月作为RFC 2765发布。2011年，RFC 2765被RFC 6145代替[2]。RFC 2765的地址格式化部分被定义在RFC 6052中[3]。

RFC 6144定义IPv4/IPv6转换的框架[4]。

隧道中间人

隧道中间人将IPv6流量封装在IPv4互联网的传输链接中（通常使用6in4），在IPv4互联网上建立起IPv6隧道以打通两个互联网之间的连接。这些隧道可以通过隧道设置协议（TSP）或AYIYA来管理。[5]

6rd

主条目：IPv6快速部署

6rd是一种在ISP的IPv4架构上实现快速部署IPv6服务的机制。它在IPv4与IPv6之间进行无状态地址映射，并且在用户节点之间自动建立相关隧道，以允许用户根据IPv4数据包的形式传输IPv6数据部。

此方案在2007年末首次被大规模部署（RFC 5569 [6]）。RFC 5969[7]详述了此协议。

传输中继翻译

RFC 3142 定义了 传输中继翻译（TRT）方法，是最常见的NAT-PT以及NAPT-PT形式。

假设IPv6主机将会发起链接，并且目的主机存在于IPv4网络之中。发起主机上的静态地址映射表、特殊 DNS 服务器实现或经修改的 DNS 解析器实现，会提供某个特殊形式的IPv6地址作为目的地址。TRT中的中继（Relay）会将该特殊IPv6地址翻译成IPv4地址，随后发起IPv4链接至目的主机。这个过程中，路由器会将数据包路由至中继上，而中继会持续地将IPv4数据包翻译成IPv6数据包并发送至IPv6主机（反之亦然），直到两个主机的会话结束。[8]

NAT64

主条目：NAT64
NAT64 和 DNS64

NAT64是一种可以让IPv6主机与IPv4服务器通信的机制。NAT64服务器需要至少一个IPv4地址和一个32位的IPv6网段（例如：64:ff9b::/96，见 RFC 6052 和 RFC 6146 ）。IPv6客户端将希望与之通信的IPv4地址嵌入在这32位之中，并将数据包发往生成的地址。NAT64服务器则创建IPv6与IPv4地址间的NAT映射，使得它们可以彼此通信。[9]

DNS64

DNS64是指一种专门的DNS服务器，在其处理某个域名的AAAA记录查询时，如果该域名仅有A记录，那么DNS64会使用该A记录生成出来一项AAAA记录。生成出来的IPv6地址前缀指向一个IPv6/IPv4的转换器，而剩余32位嵌入了A记录中的IPv4地址。指向的转换器通常是一个NAT64服务器。RFC 6147对DNS64标准进行了定义。[10]

这种过渡机制存在两个值得注意的问题：

  • 它只适合使用DNS查找远程主机地址的场景，无法参与客户端直接使用IPv4地址的场景。
  • DNS64服务器需要返回并非域所有者所指定的记录，因此如果执行转换的DNS服务器不是域名所有者的服务器，DNS根的DNSSEC校验将会失败。

ISATAP

主条目：ISATAP

ISATAP是一种IPv6过渡机制，在双栈节点之间通过IPv4网络传输IPv6数据包。

不同于6over4（较早的基于IPv4多播的类似协议），ISATAP将IPv4用作虚拟的非广播多路访问网络（NBMA）的数据链路层，因此底层的IPv4网络架构无需支持多播。

464XLAT

464XLAT（RFC 6877）可以使仅有IPv6网络上的客户端访问仅有IPv4的互联网服务（例如 Skype）。[11][12]

客户端通过SIIT转换器将IPv4数据包转换成IPv6，然后通过仅有IPv6的网络将其发送到运营商的NAT64转换器。NAT64转换器将IPv6数据包重新转换回IPv4，最后通过支持IPv4的网络将其发送到仅有IPv4的服务器。SIIT转换器（客户端转换器，CLAT：Customer-side translator）可以由客户端自己实现，也可以在支持IPv4的中间设备上实现；NAT64转换器（服务端转换器，PLAT：Provider-side translator）必须可以同时联系到IPv4网络上的服务器，以及通过CLAT联系到客户端。

双栈精简版

DS-Lite

双栈精简版（Dual-Stack Lite，简称DS-Lite） 是一种使用 IPv4-over-IPv6 隧道将 IPv4 数据包发送到运营商来实现 IPv4 私网地址用户穿越 IPv6 网络访问 IPv4 公网的解决方案。

支持此技术的客户端设备（CPE）会将 IPv4 数据包封装到 IPv6 数据包中，并且将数据包发送至运营商的电信级NAT（CGNAT）。CGNAT 收到数据包后，将其还原为 IPv4 数据包，在进行 NAT 处理后发送到 IPv4 互联网。 CGNAT 通过记录 IPv6 源地址、私有 IPv4 地址，以及 TCP 或 UDP 端口号来标识流量。

轻量 4over6 方案 （Lightweight 4over6，简称lw4o6） 是 DS-Lite 的一种改进方案，它将 NAT 功能从运营商端转移到客户端设备上，通过降低运营商需要管理的 NAT 状态来减少运营商的开销。[13]

v4 经 v6 路由

IETF 在 RFC 5549 和 RFC 9229 中定义了一个只将 IPv4 地址分配给终端，而中间路由器只需分配 IPv6 地址的方法，以此降低核心网络所需的管理量。通过这个方法，IPv4 数据包即使没有经过封装或者转换的过程，也可以正常通过仅有 IPv6 地址的路由器跳转至下一个站点。[14][15]

MAP

MAP（Mapping of Address and Port，地址兼端口映射）是一系列由思科提出的无状态 IPv4-IPv6-IPv4 双重转换技术，存在翻译（MAP-T）和封装（MAP-E）两种版本。[16] 这系列技术根据A+P（Address + Port）的思路，利用了现代网络下IPv4已然枯竭，但仍存在许多闲置 TCP/UDP 端口的这个特点，将同一个公网 IPv4 地址根据端口范围继续细分，并且只为任一用户下发其中一个范围（如端口1024-2048或8192-9216）。考虑到IPv6存在一定数量的多余比特，MAP可以将这些比特空间用来储存用户被下发的端口范围等信息，以达到ISP端无需维持NAT状态的效果。一些运营商如意大利Sky已经开始将其推广至大众用户。[17]

草案

IETF 仍在讨论或已放弃以下机制：

4rd

IPv4 居家部署（IPv4 Residual Deployment，简称4rd）是一项实验性提案，目的在用于促进跨 IPv6 网络的 IPv4 服务居家部署。与 6rd 相似，该技术以无状态的方式进行 IPv6 和 IPv4 地址之间的映射。它支持基于传输层端口对 IPv4 网络进行扩展，是 A+P 模型的无状态变体。虽然后来衍生出了 MAP-E 和 MAP-T 两项基于同一理念的技术，但 4rd 至今仍属于实验性技术。

弃用机制

IETF 已弃用这些机制：

NAT-PT

RFC 2766 定义了 Network Address Translation/Protocol Translation (NAT-PT) 这项机制。由于存在许多问题，它已被 RFC 4966 淘汰并且被降级为历史状态。这项机制一般与某一 DNS 应用程序级网关（DNS-ALG）实现结合使用。

NAPT-PT

尽管与 NAT-PT 非常相近，同样是在 RFC 2766 中被定义的 Network Address Port Translation + Protocol Translation，在网络地址转换的基础上添加了端口的转换，以避免多个内网用户同时使用同一个被暴露在外网的端口，导致出现安全性和程序稳定性的问题。这项机制已在 RFC 4966 中被定性为弃用机制。

参考文献

  1. ^ RFC 2765 - 无状态IP/ICMP转换算法(SIIT), E. Normark (February 2000)
  2. ^ RFC 6145 IP/ICMP Translation Algorithm
  3. ^ RFC 6052 - IPv6 Addressing of IPv4/IPv6 Translators
  4. ^ RFC 6144 - Framework for IPv4/IPv6 Translation
  5. ^ RFC:3053
  6. ^ RFC 5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
  7. ^ RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification
  8. ^ Yamamoto, Kazu; Itoh, Jun-ichiro. An IPv6-to-IPv4 Transport Relay Translator. Internet Engineering Task Force. 2001-06 [2023-06-08]. （原始内容存档于2023-01-28）. 
  9. ^ RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
  10. ^ RFC 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers
  11. ^ Video: 464XLAT Live Demo at World IPv6 Congress in Paris. Internet Society. 3 April 2013 [2020-10-10]. （原始内容存档于2017-09-13）. 
  12. ^ 464XLAT -- A Solution for Providing IPv4 Services Over and IPv6-only Network. T-Mobile USA. [5 August 2013]. （原始内容存档于2020-11-12）. 
  13. ^ Cui, Y.; Sun, Q.; Boucadair, M.; Tsou, T.; Lee, Y.; Farrer, I. Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture. 2015-07 [2023-02-13]. doi:10.17487/RFC7596. （原始内容存档于2023-05-12） （英语）. 
  14. ^ Le Faucheur, François; Rosen, Eric. Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop. May 2009. RFC 5549. 
  15. ^ Chroboczek, Juliusz. Pv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol. May 2022. RFC 9229. 
  16. ^ Mark Townsley. Mapping Address + Port (PDF). Cisco. September 24, 2012 [2012-09-25]. （原始内容存档 (PDF)于2022-12-29）. 
  17. ^ Richard Patterson. IPv6-Only with MAP-T. Richard Patterson - Sky Italia and MAP-T. RIPE Open House. [2023-06-07]. （原始内容存档于2023-02-21）. 
  • IPv6 in Practice, Benedikt Stockebrand (2006), ISBN 3-540-24524-3
  • RFC 2767, Bump-in-the-Stack
  • RFC 3338, Bump-in-the-API
  • RFC 3089, Socks-based Gateway
  • RFC 6219, The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition
检索自“https://zh.wikipedia.org/w/index.php?title=IPv6过渡机制&oldid=84331289”