CN101707605A - 基于IPv4/IPv6协议翻译的IPSec穿越互连方法 - Google Patents
基于IPv4/IPv6协议翻译的IPSec穿越互连方法 Download PDFInfo
- Publication number
- CN101707605A CN101707605A CN200910223988A CN200910223988A CN101707605A CN 101707605 A CN101707605 A CN 101707605A CN 200910223988 A CN200910223988 A CN 200910223988A CN 200910223988 A CN200910223988 A CN 200910223988A CN 101707605 A CN101707605 A CN 101707605A
- Authority
- CN
- China
- Prior art keywords
- ipsec
- ike
- gateway
- load
- nat
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明提出基于IPv4/IPv6协议翻译的IPSec穿越互连的方法，包括IKE SA协商和IPSec SA协商操作，具体为：将以普通的UDP-IKE形式发送IKE消息；在IKE SA协商过程中，IPSec双方交换VID载荷来检测彼此的NAT-PT穿越能力；在IKE SA协商过程中，IPSec双方交换TD载荷来检测传输沿途NAT-PT设备的存在性，当沿途存在NAT或NAT-PT设备时，后继协商信令采用UDP-non-ESP-IKE封装格式；在IPSec SA协商过程中，交换IRA载荷以确认发端所使用的IP协议和确切地址，收端依照IRA载荷对其传输层CRC进行纠正。本发明实现IPv4/IPv6过渡网络中跨协议边界的主机、或子网安全互连。
Description
技术领域
本发明涉及IPv4/IPv6协议翻译互连技术NAT-PT与IPSec协议，特别是涉及到解决IPSec协议与NAT-PT机制之间兼容互连问题的改进技术。
背景技术
IPv4地址的急剧耗竭使得互联网规模的可扩展性受到了严重影响，同时其基础协议机制对IP移动网络、自组网络等新兴业务的支持也相对匮乏，全面采用IPv6势在必行。
然而长久以来，人们在IPv4网络基础上积累了大量的资源、投资与应用，鉴于IPv4设施及应用过渡至IPv6的规模与成本，其面向IPv6的过渡过程绝不可能一蹴而就，二者之间势必存在着相当长一段并存过渡时期。而在这一过渡时期中，如何保障异构IP协议节点及网络之间协议转换互连的安全性，成为IPv6应用推广过程中所需面临的一个关键问题。
这一问题继而在IPv4/IPv6迁徙过程中引发了一系列显著的需求，其大致可分为两个方面：一方面，人们期望纯IPv4与纯IPv6主机间端对端协议翻译互连的安全性能够得到保障；而另一方面，在IPv4/IPv6并存的过渡网络环境中，人们希望在IPv4、IPv6私有网络之间实现可跨协议域边界的透明转发，以尽可能重用已有的IPv4 VPN服务，削减部署、改造及管理成本。
考虑到统一IP承载的网络整体演进趋势，IPSec协议为满足上述安全应用需求提供了一种适当的技术手段，它既可用于实现端对端的可信传输通信，同时也被广泛地应用于三层VPN隧道互连与远程接入场合。但遗憾的是，作为一种网络层安全扩展机制，IPSec并不完全独立于底层IP协议，即，在IPv4/IPv6过渡网络中，即便在网络层上实施了IP协议翻译操作(NAT-PT)，也无法实现跨IP协议域的IPSec实体之间的互连，这一关键局限则为上述需求的实现制造了极大障碍。
NAT-PT是当前唯一一种支持异构IP网络直接互连的IPv4/IPv6过渡机制，然而它却无法与IPSec实现互操作。这一机制兼容性问题主要源于二者功能性的本质矛盾：一方面，地址-协议翻译将导致IPSecAH/ESP封装的完整性验证失败，而另一方面，IPSec分组封装与加密也将使得NAT-PT无法获取必要的信息，从而妨碍其转换操作的实施。上述问题极大限制了IPSec在跨IP协议域过渡互连场合中的安全服务能力。
目前主要存在着两种基本思路，一种是双栈部署方式，即在所有设备上均配备双栈，这一IPSec互连实施方式最为直观，但其缺陷在于它将显著地增加部署和改造成本，并且令网络及安全管理的复杂度翻倍，而这在IPv4/IPv6过渡过程中往往是难以接受、应当尽量避免的。
此外，还存在着一类以IP HTI为代表的技术改进思路；让NAT-PT设备被动介入IPSec协商过程，进而由发端根据NAT-PT所提供的信息来调整发送数据，从而向收端隐藏地址-协议翻译细节并实现IPSec协议的有效穿越，是其基本思路；此类技术多以NAT-PT机制改进为根本出发点，其不仅需要升级已部署的NAT-PT设备，同时还必须辅以部分的IPSec协议栈修改，同时，它只能实现AH传输模式穿越而无法实现不同协议子网的隧道互连，且不能穿越端口转换设备，除此之外，作为“中间人”的NAT-PT设备由于无法获悉IKE会话密钥而只能以明文形式向发端发送转换信息，因而还引入了额外的安全隐患；综合其各方面缺陷可见，以NAT-PT改造方式来实现IPSec跨协议域互连在实际应用中并不具备足够的可行性.
发明内容
本发明提出通过IPSec协议及互连方式改进途径来解决其与NAT-PT的机制兼容性问题，从而实现IPv4/IPv6过渡网络中跨协议边界的主机、或子网安全互连。
本发明提出基于IPv4/IPv6协议翻译的IPSec穿越互连的方法，包括IKE SA协商和IPSec SA协商操作，具体包括以下步骤：将以普通的UDP-IKE形式发送IKE消息；在IKE SA协商过程中，IPSec双方交换VID载荷来检测彼此的NAT-PT穿越能力；在IKE SA协商过程中，IPSec双方交换TD载荷来检测传输沿途NAT-PT设备的存在性，当沿途存在NAT或NAT-PT设备时，后继协商信令采用UDP-non-ESP-IKE封装格式；在IPSec SA协商过程中，交换IRA载荷以确认发端所使用的IP协议和确切地址，收端依照IRA载荷对其传输层CRC进行纠正。
进一步，IKE SA协商和IPSec SA协商操作之后，还包括网关与网关之间的协作地址映射的步骤，在6to4应用场合中，具体为：客户端向网关ga发送DNSv6请求，以解析服务器的域名；网关ga将DNSv6请求转换成IKE负载形式后发送给网关gb；网关gb将DNSv6请求翻译成DNSv4请求，并中继给DNSv4服务器；网关gb收到DNSv4服务器的应答，将DNS应答以IKE载荷形式返回给网关ga；网关ga收到IKE载荷，从中获悉客户端和服务器的本地地址；网关ga在客户端所处的IPv6域中为服务器分配替代地址AAb，将替代地址AAb以IKE载荷形式告知网关gb；网关gb在IPv4域中为客户端分配替代地址AAa，将替代地址以IKE负载形式通告给网关ga。
进一步，网关与网关之间的协作地址映射之后的操作，还包括隧道报文协议翻译的步骤，具体为：处于IPv6域中的客户端向处于IPv4域中的服务器发起连接请求；客户端发送的报文将在网关ga处被封装成UDP-ESP传输格式，并转发给网关gb；网关gb抛弃外层IPv4与UDP首部，并对ESP进行解封从而获得IPv6隧道报文；网关gb依据协作地址映射关系，将IPv6隧道报文翻译成为IPv4形式，并转发至网关gb背后的IPv4域中。
进一步，将DNS应答以IKE载荷形式返回给网关ga、以及将替代地址以IKE负载形式通告给网关ga的操作，还包括以下步骤：将DNS应答与替代地址合并成为一条IKE消息。
进一步，IKE SA协商和IPSec SA协商操作之后，还包括主机与网关之间的协作地址映射的步骤，具体为：主机将DNSv6请求转换成IKE负载形式后发送给网关gb；网关gb将DNSv6请求翻译成DNSv4请求，并中继给DNSv4服务器；网关gb收到DNSv4服务器的应答，将DNS应答以IKE载荷形式返回给主机；主机收到IKE载荷，从中获悉客户端和服务器的本地地址；主机在所处的IPv6域中为服务器分配替代地址AAb，将替代地址AAb以IKE载荷的形式告知网关gb；网关gb在IPv4域中为主机分配替代地址AAa，将替代地址以IKE负载形式通告给主机。
进一步，将DNS应答以IKE载荷形式返回给主机、以及将替代地址以IKE负载形式通告给主机的操作，还包括以下步骤：将DNS应答与替代地址合并成为一条IKE消息.
进一步，IPSec双方交换TD载荷来检测传输沿途NAT-PT设备的存在性的操作，包括以下步骤：当TD中的Proto字段不匹配时，则至少有奇数个NAT-PT设备位于IPSec双方的传输路径之上。
进一步，IPSec双方交换TD载荷来检测传输沿途NAT-PT设备的存在性的操作，还包括以下步骤：当双方所发送的TD载荷是完全相同的，则通信途中没有NAT-PT或NAT转换设备存在，直接建立IPSec互连。
进一步，IPSec双方交换TD载荷来检测传输沿途NAT-PT设备的存在性的操作，还包括以下步骤：当TD中的Proto字段匹配，且HAS_HLa不等于HASH_Ab或HASH_Lb不等于HASH_Aa时，则通信途中存在着NAT或者存在偶数个NAT-PT，将采用标准的NAT-T机制建立IPSec互连。
在4to6应用场合中，其协议步骤与上述6to4应用场合类似。
与现有技术相比，本发明旨在结合IPv4/IPv6协议翻译机制(即NAT-PT机制)，对IPSec进行相应的协议及互连方式增强，以实现采用不同IP协议栈的主机与主机之间、主机与IPSec三层VPN网络之间、及IPSec VPN网络与网络之间的可信传输、接入与互连。
该发明顺应IPv4/IPv6过渡需要，提供了一种有效的互连技术途径，其具备良好的向下兼容性和适应性，能够实现对NAT(NAPT)、NAT-PT(NAPT-PT)混合的复杂网络环境的IPSec穿越，以充分利用已部署的IPv4安全业务及服务资源，极大减少已有IPv4网络及安全服务改造成本，从而有利于实现IPv4网络和应用面向IPv6的平滑过渡。
附图说明
图1为本发明中基于IPv4/IPv6协议翻译的IPSec端对端传输穿越互连的方法流程图。
图2为本发明改进后的IKE SA协商过程。
图3为本发明改进后的IPSec SA协商过程。
图4为本发明采用不同IP协议的网关-网关IPSec隧道互连场合(G2G互连场景，6to4应用场合)。
图5为本发明采用不同IP协议的主机-网关IPSec接入互连场合(H2G互连场景，6to4应用场合)。
具体实施方式
图1为本发明中基于IPv4/IPv6协议翻译的IPSec端对端传输穿越互连的方法，包括IKE SA协商和IPSec SA协商操作，具体包括以下步骤：
在步骤101，将以普通的UDP-IKE形式发送IKE消息。
在握手阶段，在确认NAT或NAT-PT存在之前，其IKE消息采用普通的UDP-IKE格式；只有在沿途NAT或NAT-PT确认之后，后继信令才会使用UDP-non-ESP-IKE格式，以实现无二义性的传输复用。
在步骤102，在IKE SA协商过程中，IPSec双方交换VID载荷来检测彼此的NAT-PT穿越能力。
在步骤103，在IKE SA协商过程中，IPSec双方交换TD载荷来检测传输沿途NAT-PT设备的存在性，当沿途存在NAT或NAT-PT设备时，后继协商信令采用UDP-non-ESP-IKE封装格式，用NAT-PT穿越机制进行IPSec互连。
在步骤104，在IPSec SA协商过程中，交换IRA载荷以确认发端所使用的IP协议和确切地址，收端依照IRA载荷对其传输层CRC进行纠正。
本发明给出了一种可跨IP协议边界、实现NAT-PT穿越的IPSec互连改进技术，提出采用UDP-ESP封装机制与两种互连模式，即TP-Mode(Transport-Mode)传输模式和TN-Mode(Tunnel-Mode)隧道模式，以分别支持不同IP协议设备之间的IPSec端对端互连和不同IP协议域IPSec VPN之间的隧道互通。
其中，TP-Mode用于建立IPv6域中的单协议栈主机与IPv4域中单栈主机之间的IPSec端对端互连。其对标准的IKE SA协商过程进行了相应改进，通过交换若干额外的IKE载荷来检测对端NAT-PT穿越能力，并发现沿途的NAT-PT设备。此外，由于传输沿途的NAT-PT设备需对外层IP首部进行转换，这将可能导致UDP-ESP封装的传输层负载校验失败，于是，在TP-Mode中，IPSec双方还将在IPSec SA协商过程中交换彼此发送报文时所使用的原始端对端信息，从而为收端校验和纠正提供便利，实现正常的传输层校验。
TN-Mode则主要用于在异构IP网络域间建立安全的隧道互连，并为其隧道网关背后的私有网络提供透明的分组转发服务，即便它们使用的是完全不同的IP协议；它同时还容许单协议栈主机实现对异种IP协议三层VPN的远程接入。TN-Mode与TP-Mode的IKE SA与IPSecSA协商过程基本类似，然而在互连方式上则存在着巨大差异：由于UDP-ESP封装的隧道报文并不能在穿越传输过程中得到正确的翻译，因此其无法被直接转发至收端网关背后的异构IP协议域中，对此，我们在TN-Mode中提出了一种网关与网关之间的协作互连机制，并以此来实现内部分组的协同翻译转换；为使得这一过程足够可行，我们还引入了相应的若干IKE载荷来实现其间的辅助信息交换目的。
下面将结合附图和实施方式具体说明上述改进过程。
UDP-ESP封装
本发明采用了UDP-ESP封装来支持IPSec对NAT-PT的穿越。这主要基于如下考虑：首先，UDP-ESP传输格式同时提供了对IPSec传输模式及隧道模式的支持，并为实现对普通NAT-T协议的后向兼容性提供了便利；其次，鉴于其外层UDP首部无状态且足够简洁，这种穿越封装方式所引入的额外协议转换代价最小；再次，UDP-ESP封装还有助于帮助ICMP等不具备传输端口的协议实现对NAPT-PT等端口转换机制的穿越；最后，在采用UDP-ESP封装的隧道场合下，传输沿途所有的端口转换均只作用于外层UDP首部，而这一首部在收端解封装时将被完全丢弃，因此，UDP-ESP封装格式的引入，可以完全屏蔽沿途所有端口转换操作的影响，以简化机制分析与设计。
IKE SA改进协商过程
IKE SA协商过程主要包括两方面的改进，即协议支持性检测与NAT-PT存在性检测。其改进后的协商过程如图2所示。其中的HDR为IKE首部，HDR＊则表示IKE载荷加密，SA和KE载荷分别代表着建议载荷与Diffie-Hellman密钥交换载荷，而N则为现时负载。
IPSec双方通过交换一个众所周知的VID(Vendor ID)载荷来实现彼此的NAT-PT穿越能力检测.在IKE SA协商之前，每一提供NAT-PT穿越支持的IPSee对端均必须发送正确的VID载荷，以便对端确认其协议能力。
另一方面，传输沿途NAT-PT设备的存在性检测则主要通过IPSec双方交换TD(Translation Discovery)载荷来实现。TD载荷的内容主要包括发端所使用的IP协议、及从发端角度所看到的端对端信息的哈希值。仍以图2为例，其中的TDa载荷可定义为：
TDa：＝Protoa|HASH_La|HASH_Aa
HASH_La：＝Hash(LAa|LPa)
HASH_Aa：＝Hash(AAb|APb)
其中，HASH_L与HASH_A的计算将使用IPSec双方所议定的散列算法；LA与LP代表发端的本地地址与传输端口号，而AA与AP则代表着收端的分配地址及端口。值得指出的是，AA与AP一般由NAT-PT设备在发端所处的协议域中为收端分配所得，其不一定等同于收端发送报文时所使用的真实地址与端口号。
如果双方所发送的TD载荷是完全相同的，这表明此时其二者的通信途中并没有任何NAT-PT或NAT转换设备存在，它们可直接建立IPSec互连。如果TD中的Proto字段不匹配，则说明此时至少有奇数个NAT-PT设备位于IPSec双方的传输路径之上，这意味着它们必须使用NAT-PT穿越机制进行IPSec互连。除此之外，还有可能存在着Proto字段相同、然而双方各自计算所得的哈希值却并不相同的情况。这意味着在IPSec双方的传输途中，要么只有若干NAT设备，要么仅存在着偶数个NAT-PT设备；尽管后者情况较前者要相对复杂，但值得指出的是，在这两种情况中所采用的穿越互连方法却并不存在本质差异：由于IPSec是一种完全基于端对端关系的安全协议，因此采用通常的NAT-T机制便足以有效地实现上述两种场合中的穿越互连。
TP-Mode传输模式
在TP-Mode中，由于封装在UDP-ESP内部的传输层校验和无法被穿越路径沿途的NAT-PT设备更新，因此为避免传输层校验失败，IPSec收端必须对其进行相应的校验。
值得庆幸的是，在IPv6中，除地址长度之外，TCP/UPD伪头装配及CRC计算过程与IPv4中是基本一致的。为了在收端实现对CRC的相应更新，收端必须知道发端所使用的IP协议和确切地址。上述信息可通过在IPSec SA协商过程中交换IRA载荷(IPSec RelationAnnouncement)的方式来获得，如图3所示。其中的IRAa与IRAb载荷定义如下：
IRAa：＝Protoa|Protobehind_a|LAa|AAb
IRAb：＝Protob|Protobehind_b|LAb|AAa
当UDP-ESP报文抵达收端时，外层UDP首部将被剥除。收端在ESP解封之后，将依照IRA载荷对其传输层CRC进行纠正，进而将更新后的传输层负载递交给上层协议栈。考虑到某些上层协议指定(如ICMP等)与底层IP协议是紧耦合的，因此在转交其负载之前，收端有可能需要对其进行相应的协议翻译；除此之外，某些特殊的应用层负载同样也可能需要进行相应转换。然而值得指出的是，上述情况在端对端的传输模式中并不多见，在多数情况下，接收端的协议翻译操作并不是必须的。
TN-Mode隧道模式
TN-Mode的IKE/IPSec协商过程与TP-Mode类似，它也同样采用了UDP-ESP封装形式.然而与TP-Mode不同的是，在TN-Mode中，我们必须对每一个隧道内部报文进行再次的协议翻译；这主要是由于其IP隧道报文被完全封装在UDP-ESP中而无法被沿途的NAT-PT设备所转换的缘故，因此，在这些内部报文被转发至不同的IP协议域之前，IPSec隧道网关必须对其进行相应转换.
一般而言，存在着两种典型的TN-Mode应用场景，其分别为网关对网关(G2G)隧道场景与主机对网关(H2G)接入场景，如图4和图5所示。
首先考虑G2G隧道场景，不妨以某位于网关ga之后的IPv6主机a试图访问某位于网关gb之后的服务器b(6to4应用场合)为例，如图4所示。为简洁起见，图4对所有链路及其对应传输格式进行了标注，方括号和圆括号分别代表UDP-ESP及UDP-non-ESP-IKE载荷。例如在图4中，存在类似如下标注IPv6 UDP(DNS-REQUEST)和IPv6 UDP[IPv6 TCP Payload]，此处的圆括号和方括号即指其中的“()”和“[]”。
隧道穿越过程共可分为协作地址映射及隧道报文协议翻译等2个阶段，其中前者包括图4中的步骤1至步骤12，后者则包括图4中的步骤A至步骤H。
在访问服务器b之前，客户端a将向网关ga发送一个DNSv6请求，以解析b的域名。该请求进而被网关ga转换成一个特殊的IKE负载形式，即DNS-REQUEST，并发送给网关gb。当其到达gb后，它将继而被翻译成为一个DNSv4请求并被中继给DNSv4服务器。而在gb收到相应的DNS应答之后，gb将把DNS应答进一步转换成一个等价的特殊IKE载荷DNS-REPLY，并将其返回给ga。最终，ga将收到这一载荷，并从中获悉LAa和LAb，即客户端a和服务器b的本地地址。
ga紧接着将在a所处的IPv6域中为b分配一个替代地址AAb，从而为即将到来的a的后继会话连接做好准备。同时，ga还将把AAb以TRANS-INFO载荷的形式告知gb，在获悉AAb之后，gb也将在IPv4域中为a分配一个替代地址AAa，继而将替代地址以对应的特殊IKE负载TRANS-ACK通告给ga。至此，ga和gb均已获知(LAa，AAb)和(AAa，LAb)这两对地址映射关系。最终，gb将AAb以DNSv6应答的形式告知a，a的连接发起准备就绪，协作地址映射过程结束。
在上述过程中，4个特殊的IKE载荷传递均将受到IKE SA的保护，它们的定义如下。另外值得一提的是，我们可将这些DNS应答及替代地址合并成为一条IKE消息，从而将整个交互过程简化为一个一次性的IKE消息交换过程，减少消息交互次数，提高映射建立效率。
DNS-REQUEST：＝LAa|Domain_Nameb
DNS-REPLY：＝LAb|Domain_Nameb
TRANS-INFO：＝(LAa|AAa)|LAb|Link_MTUa
TRANS-ACK：＝(LAa|AAa)|(AAb|LAb)|Link_MTUb
当上述过程完成之后，a开始向b发起新的连接请求。a发送的报文将在ga处被封装成UDP-ESP传输格式，并进一步转发给gb。gb将抛弃其外层IPv4与UDP首部，并对ESP进行解封从而获得隧道内部报文，进而依据前期建立的地址映射关系，将此IPv6隧道报文翻译成为IPv4形式，并最终转发至gb网关背后的IPv4域中。至此，一次隧道报文转发完毕，返回报文的转发过程与上述过程是类似的。
接下来再考虑当某远程主机尝试通过一呼叫网关接入内部VPN的情况，即H2G接入场景，如图4所示.值得指出的是，至今为止，并不是所有的远程终端均具备双栈功能，况且，即使其终端具备双栈能力，这也并不意味着它能够自由地选择其接入网络环境，因此，为远程接入用户提供有效的异构IP协议VPN接入手段是非常有必要的.
对于H2G场景而言，其与G2G场景的唯一不同在于，由于此时的远程主机ra将直接访问gb，因此，ra必须依靠自身来实现部分在G2G场景中由ga网关所承担的DNS代理及地址分配功能。仍以图5中的6to4应用场合为例，当ra的上层应用发送一个DNSv6请求时，其将始终被ra的IPSec协议栈所截获(步骤1)，继而触发DNS代理过程(图5中的步骤1至步骤6)和一次ra与gb之间的地址映射协商过程(图5中的步骤7至步骤10)。当上述操作均完成之后，ra的上层应用将获得一个与图5步骤6中的DNS-REPLY载荷语义对等的DNSv6应答，并依据该应答来完成与gb的后继映射地址分配工作。
与G2G场景类似的，我们可将ra与gb之间的DNS代理及地址分配过程合并成一次性的IKE消息交换，从而减少往返交互次数；同时还可注意到，在两种典型场景中，仅有gb需具备隧道报文协议翻译功能，而客户端则无需双栈；此外值得一提的还有ra所分配的AAb地址，与G2G场景中ga所分配的IPv6端地址相比，ra所分配的地址仅具有字面替换含义，而并不代表任何具体的路由承诺，因为ra仅需关注于本机的地址映射即可。上述诸方面特点均使得远程主机的实现得以极大简化。
作为对详细描述的结论，应该注意本领域的技术人员将会很清楚可对优选实施例做出许多变化和修改，而实质上不脱离本发明的原理。这种变化和修改包含在所附权利要求书所述的本发明的范围之内。
Claims (9)
1.基于IPv4/IPv6协议翻译的IPSec穿越互连的方法，包括IKESA协商和IPSec SA协商操作，具体包括以下步骤：
将以普通的UDP-IKE形式发送IKE消息；
在IKE SA协商过程中，IPSec双方交换VID载荷来检测彼此的NAT-PT穿越能力；
在IKE SA协商过程中，IPSec双方交换TD载荷来检测传输沿途NAT-PT设备的存在性，当沿途存在NAT或NAT-PT设备时，后继协商信令采用UDP-non-ESP-IKE封装格式；
在IPSec SA协商过程中，交换IRA载荷以确认发端所使用的IP协议和确切地址，收端依照IRA载荷对其传输层CRC进行纠正。
2.根据权利要求1所述的IPSec穿越互连的方法，其中，IKESA协商和IPSec SA协商操作之后，还包括网关与网关之间的协作地址映射的步骤，具体为：
客户端向网关ga发送DNSv6请求，以解析服务器的域名；
网关ga将DNSv6请求转换成IKE负载形式后发送给网关gb；
网关gb将DNSv6请求翻译成DNSv4请求，并中继给DNSv4服务器；
网关gb收到DNSv4服务器的应答，将DNS应答以IKE载荷形式返回给网关ga；
网关ga收到IKE载荷，从中获悉客户端和服务器的本地地址；
网关ga在客户端所处的IPv6域中为服务器分配替代地址AAb，将替代地址AAb以IKE载荷形式告知网关gb；
网关gb在IPv4域中为客户端分配替代地址AAa，将替代地址以IKE负载形式通告给网关ga。
3.根据权利要求2所述的IPSec穿越互连的方法，其中，网关与网关之间的协作地址映射之后的操作，还包括隧道报文协议翻译的步骤，具体为：
处于IPv6域中的客户端向处于IPv4域中的服务器发起连接请求；
客户端发送的报文将在网关ga处被封装成UDP-ESP传输格式，并转发给网关gb；
网关gb抛弃外层IPv4与UDP首部，并对ESP进行解封从而获得IPv6隧道报文；
网关gb依据协作地址映射关系，将IPv6隧道报文翻译成为IPv4形式，并转发至网关gb背后的IPv4域中。
4.根据权利要求2或3所述的IPSec穿越互连的方法，其中，将DNS应答以IKE载荷形式返回给网关ga、以及将替代地址以IKE负载形式通告给网关ga的操作，还包括以下步骤：将DNS应答与替代地址合并成为一条IKE消息。
5.根据权利要求1所述的IPSec穿越互连的方法，其中，IKESA协商和IPSec SA协商操作之后，还包括主机与网关之间的协作地址映射的步骤，具体为：
主机将DNSv6请求转换成IKE负载形式后发送给网关gb；
网关gb将DNSv6请求翻译成DNSv4请求，并中继给DNSv4服务器；
网关gb收到DNSv4服务器的应答，将DNS应答以IKE载荷形式返回给主机；
主机收到IKE载荷，从中获悉客户端和服务器的本地地址；
主机在所处的IPv6域中为服务器分配替代地址AAb，将替代地址AAb以IKE载荷的形式告知网关gb；
网关gb在IPv4域中为主机分配替代地址AAa，将替代地址以IKE负载形式通告给主机。
6.根据权利要求5所述的IPSec穿越互连的方法，其中，将DNS应答以IKE载荷形式返回给主机、以及将替代地址以IKE负载形式通告给主机的操作，还包括以下步骤：将DNS应答与替代地址合并成为一条IKE消息。
7.根据权利要求1所述的IPSec穿越互连的方法，其中，IPSec双方交换TD载荷来检测传输沿途NAT-PT设备的存在性的操作，包括以下步骤：当TD中的Proto字段不匹配时，则至少有奇数个NAT-PT设备位于IPSec双方的传输路径之上。
8.根据权利要求1所述的IPSec穿越互连的方法，其中，IPSec双方交换TD载荷来检测传输沿途NAT-PT设备的存在性的操作，还包括以下步骤：当双方所发送的TD载荷是完全相同的，则通信途中没有NAT-PT或NAT转换设备存在，直接建立IPSec互连。
9.根据权利要求1所述的IPSec穿越互连的方法，其中，IPSec双方交换TD载荷来检测传输沿途NAT-PT设备的存在性的操作，还包括以下步骤：当TD中的Proto字段匹配，且HASH_La不等于HASH_Ab或HASH_Lb不等于HASH_Aa时，则通信途中存在着NAT或者存在偶数个NAT-PT，将采用标准的NAT-T机制建立IPSec互连。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200910223988A CN101707605A (zh) | 2009-11-20 | 2009-11-20 | 基于IPv4/IPv6协议翻译的IPSec穿越互连方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200910223988A CN101707605A (zh) | 2009-11-20 | 2009-11-20 | 基于IPv4/IPv6协议翻译的IPSec穿越互连方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101707605A true CN101707605A (zh) | 2010-05-12 |
Family
ID=42377796
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN200910223988A Pending CN101707605A (zh) | 2009-11-20 | 2009-11-20 | 基于IPv4/IPv6协议翻译的IPSec穿越互连方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101707605A (zh) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104283977A (zh) * | 2013-07-08 | 2015-01-14 | 北京思普崚技术有限公司 | 一种vpn网络中的vpn自动穿越方法 |
| CN104954222A (zh) * | 2015-05-22 | 2015-09-30 | 东南大学 | 基于ipsec协议的隧道模式esp硬件封装装置 |
| WO2015154346A1 (zh) * | 2014-04-10 | 2015-10-15 | 中兴通讯股份有限公司 | 一种对经过nat穿越的ipsec报文进行ah认证的方法及装置 |
| CN106506457A (zh) * | 2016-10-12 | 2017-03-15 | 中国联合网络通信集团有限公司 | 一种终端接入网络的方法及系统 |
| CN107105026A (zh) * | 2017-04-14 | 2017-08-29 | 中国联合网络通信有限公司沈阳市分公司 | 一种ipv4/ipv6交换应用平台 |
| CN109005026A (zh) * | 2018-08-13 | 2018-12-14 | 常熟理工学院 | 一种支持隐私保护的网络通信实现方法 |
| CN111954223A (zh) * | 2020-07-23 | 2020-11-17 | 哈尔滨工业大学 | 一种基于WiFi和BLE复合芯片的异构协议协作方法 |
-
2009
- 2009-11-20 CN CN200910223988A patent/CN101707605A/zh active Pending
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104283977A (zh) * | 2013-07-08 | 2015-01-14 | 北京思普崚技术有限公司 | 一种vpn网络中的vpn自动穿越方法 |
| CN104283977B (zh) * | 2013-07-08 | 2017-12-19 | 北京思普崚技术有限公司 | 一种vpn网络中的vpn自动穿越方法 |
| WO2015154346A1 (zh) * | 2014-04-10 | 2015-10-15 | 中兴通讯股份有限公司 | 一种对经过nat穿越的ipsec报文进行ah认证的方法及装置 |
| CN104954222A (zh) * | 2015-05-22 | 2015-09-30 | 东南大学 | 基于ipsec协议的隧道模式esp硬件封装装置 |
| CN106506457A (zh) * | 2016-10-12 | 2017-03-15 | 中国联合网络通信集团有限公司 | 一种终端接入网络的方法及系统 |
| CN107105026A (zh) * | 2017-04-14 | 2017-08-29 | 中国联合网络通信有限公司沈阳市分公司 | 一种ipv4/ipv6交换应用平台 |
| CN107105026B (zh) * | 2017-04-14 | 2020-02-11 | 中国联合网络通信有限公司沈阳市分公司 | 一种ipv4/ipv6交换应用平台 |
| CN109005026A (zh) * | 2018-08-13 | 2018-12-14 | 常熟理工学院 | 一种支持隐私保护的网络通信实现方法 |
| CN109005026B (zh) * | 2018-08-13 | 2021-04-20 | 常熟理工学院 | 一种网络通信实现方法 |
| CN111954223A (zh) * | 2020-07-23 | 2020-11-17 | 哈尔滨工业大学 | 一种基于WiFi和BLE复合芯片的异构协议协作方法 |
| CN111954223B (zh) * | 2020-07-23 | 2022-05-20 | 哈尔滨工业大学 | 一种基于WiFi和BLE复合芯片的异构协议协作方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10462054B2 (en) | Overloading address space for improved routing, diagnostics, and content-relay network | |
| EP2230822B1 (en) | Establishing a connection traversing a network address translation gateway | |
| CN101707605A (zh) | 基于IPv4/IPv6协议翻译的IPSec穿越互连方法 | |
| JP5607617B2 (ja) | ＩＰｖ６ドメインでデータパケットを受信する方法、ならびに関連するデバイスおよび住居用ゲートウェイ | |
| US20120207168A1 (en) | METHODS AND DEVICES FOR ROUTING DATA PACKETS BETWEEN IPv4 AND IPv6 NETWORKS | |
| US20050138166A1 (en) | IP network node and middleware for establishing connectivity to both the IPv4 and IPv6 networks | |
| US20120317252A1 (en) | Method and system for address conflict resolution | |
| CN101030935B (zh) | 一种IPSec穿越NAT-PT的方法 | |
| CN101499965B (zh) | 一种基于IPSec安全关联的网络报文路由转发和地址转换方法 | |
| JPH11112577A (ja) | Ｌａｎシステム間相互接続方式及びネットワークサービスシステム | |
| JP5506933B2 (ja) | ネットワーク相互通信の実現方法及びシステム | |
| CN101325580B (zh) | 基于nat-pt的ftp应用层网关的实现方法 | |
| EP2479935A1 (en) | Method, system and communication terminal for implementing inter-communication between new network and internet | |
| CN100471163C (zh) | 在IPv6中用主机间隧道支持IPv4应用程序的方法 | |
| CN101222412B (zh) | 网络地址转换穿越方法和系统 | |
| JP6386166B2 (ja) | ＩＰｖ４とＩＰｖ６との間の翻訳方法及び装置 | |
| CN103888554B (zh) | IPv4与IPv6互通的域名解析方法和系统 | |
| WO2009005212A1 (en) | Ipv6 over ipv4 transition method and apparatus for improving performance of control server | |
| Cui et al. | State management in IPv4 to IPv6 transition | |
| WO2012075688A1 (zh) | 一种可以取代ipv6的网络层协议 | |
| CN101783775B (zh) | 一种向量网和ip网的网关方式互连方法 | |
| US20230388397A1 (en) | Resolving Overlapping IP Addresses in Multiple Locations | |
| CN114726824B (zh) | 无线宽带路由器、报文处理和域名解析方法及装置 | |
| JP2001136198A (ja) | ネットワーク間通信方法およびサーバ装置並びにネットワーク間通信システム | |
| JP2008092607A (ja) | トランスレータ |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20100512 |