我们都知道大家面临IPv4地址压力，以及我们网络是不是要升级到或者说有可能升级到IPv6，面临这些压力我们一个重要问题如果我们把网络升级到IPv6，现在我们的CP，SP，内容提供商，应用程序对IPv6他们支持程度如何，他们是不是全面支持了我们IPv6特别是P2P应用，无论是BT还是QQ，还是MSN，是否支持IPv6，我们现在知道结果不是太理想，也许后期会支持。
从网络方面看，大家一直探讨重要问题，如果我们把边缘网升级到IPv6，因为我们地址不够用，升级到IPv6以后，我们如何能够满足我们用户大量用户，我现在没有IPv6应用，没有IPv6SAP供我们访问，我们还得访问IPv4，我们升级IPv6用户如何接着访问我们现有大量IPv4服务器，或者是IPv4内容。
既然提出这样一个问题，大家自然想到我是不是采用一个翻译技术，就是说我们在边缘网用户上已经有了IPv6或者说只有IPv6情况下，我们要访问原有IPv4资源，这时候要用翻译，大家自然而然想要用翻译，我们是不是只能用翻译，不能用其他技术，翻译是一个很重要解决方案，但是我们要探讨是不是翻译是唯一的解决方案。
翻译当中终端使用IPv6协议站，自然一个问题就是我们上层应用是不是要基于IPv6，如果不基于IPv6，没有IPv6的话，像我说的MSN应用软件，客户端不支持IPv6的时候，这时候是不是翻译究竟翻谁，会存在这个问题，在翻译技术当中，我们这个图，作片是一个V6，中间有一个两种协议类型转换网关，这个转换网关我们要做的事情，把4和6的东西进行互相翻译，面临一些问题，比如说翻译开销很多，其次就是我们在翻译的时候，可能是需要对不仅是传统的FTP应用层翻译，而且我们对像很重要的大量P2P协议等等。
凡是我们一个协议应用层写入一个IPv4地址程序翻译需要针对它进行开发，将来有多少种这样的应用，这件事我们谁也不知道，我们在真正互联网关一个网络层设备商做一些上层应用应该要做的事情，改P2P协议的传输，这件事而言不仅是开销大，也破坏网络传输端到端透明性这一点是非常重要的问题，再进一步是我刚才说的如果我们现在无论是MSN，QQ，甚至是网站没有提供IPv6服务，现在究竟我这个翻译东西放到中间以后，我究竟是要翻什么东西，没有东西可让我翻，换句话说一个主机也好还是一个手机也好，如果仅仅有IPv6协议站，上面无数应用运行不起来，仅仅翻译在我们现在网络过渡里面还是不够的。
所以再次基础上我们考虑是不是有可能另外一种问题，就是我们不是要基于6和4之间翻译，是不是有可能基于隧道实现我们所谓的6和4互访，这里面我们再补充一句，我们即便使用翻译的时候，我们两个网络4和6网络至今AFBR做了一个什么事情，实际上就是我究竟如何管理我的IPv4地址，我究竟针对每一个应用我如何维护一个所谓的五原组或者IPv4和IPv6我们不管是如何做IPv4和IPv6之间翻译，我们最终要解决在AFBR设备上面必须实现我凡是从IPv6出来一个流，一个主机上数据，一定要分配一个IPv4地址，这样才能进入IPv4世界，同样IPv4地址端口号给他的时候，我仍然要使用IPv4地址端口号。
所以这时候我们资源分配，IPv4地址和IPv4端口号资源分配在我们AFBR仍然要进行，我们在AFBR上进行，面临刚才说的诸多问题，还有一种方式就是我们是不是有可能把这样的资源分配分配以后我们是不是有可能让我们通信对端左边IPv6的主机或者IPv6CP设备感知到你这样的分配，一旦感知以后，是不是有可能采用隧道的形式进行。
所以这样我们就提出了我们的4over6，在AFBR分配针对每一个用户，分配IPv4地址端口号，我把分配结果直接想办法让我们端系统感知，可能是CPE，也可能是我们主机，感知到IPv4技术分配以后，我们在主机可以直接使用我们IPv4协议站，那么在传输的时候，我们就使用IPv4OVERIPv6两边进行分装，IPv6网络设备跟IPv4网络上互联网进行实施通信，避免在我们中间盒子上翻译，避免开销太大问题等等。
网络实际应用场景可以换一个角度再想一想，实际网络当中不存在IPv6单站设备，这一点大家理解如何，有没有见过一个主机，这样主机是不是仅支持IPv6协议站，不支持IPv4协议站有没有这样的设备，据我所知是不存在这样的设备，可能存在仅支持IPv4不支持IPv6，随着IPv6推广绝大多数设备都会支持IPv6，支持IPv6是不是不支持IPv4协议站呢，是不会，这样我的端系统尽量利用已有广泛支持IPv4协议站，支持IPv4协议站我采用翻译方式也要分配资源，只是在AFBR上分配资源，干脆把这样一个资源分配让你的终端设备能够感知，一旦终端设备感知，终端上层应用可以直接使用IPv4协议站向这边发送使用一个4over6，能够实现上层应用友好性。
这里面有一些技术难点，比如说我们在AFBR确保流量是不是使用共有地址和端口我们才能实现双向互访，这一点是非常重要，我们知道现在家庭用户迁移到IPv6，为什么大家不愿意，就是说迁移到IPv6没有SAP给我资源访问，SAP为什么不愿意迁移到IPv6上，我没有提供新效益，如果说运营商给我提供是一个IPv6网络传输我会不会把IPv4用户丢掉这一点SAP是绝对不敢，我们使用一个共有IPv4地址，我们在建我们新服务器，SAP服务器，把我们服务器建到一个IPv6网络里面，我们可以通过4OVER6隧道将来新兴IPv6用户访问同时，保障我们不丢失原有大量IPv4用户，如果我们使用公有IPv4可以实现面向服务器的用户迁移。
对于我们运营商，已经拥有大量IPv4地址，我们如果直接全部使用私有地址，还有一个问题是什么问题，我们IPv4地址资源是不是一下子变成没有用的东西，这一点也不是我们运营商想看到的，所以还有一种办法就是对于一些比如说高端的用户，高端用户无论企业还是个人用户给他们可以分配一些公有地址，他们可以使用各式各样P2P软件，使得他们能够进行一些增值业务体验。
我们强调一种方式是使用公有IPv4地址，如果不够用的时候，我们可以把公有价值加上IPv4端口号，从AFBR双栈接入点下发到用户端，用户端作为一般的用户端他们可以采用加上端口号实现这种地址的复用。这里面还有一些技术问题，是有状态影射还是无状态影射，甚至是无状态加上地址端口，一系列关系维护在AFBR里面，使得我们AFBR变成一个沉重的负担。
这个完全不会，我们跟所有翻译方式相比，翻译方式不仅在这里面维护这样的影射还要进行翻译，网络层翻译还有应用层翻译，对一些特殊应用还不能支持，获得IPv4地址上面IPv4服务就可以使用了。这里面还有一些具体技术，必须细节问题这里面就不一一讲了，简单说一句我们通过DHCP，IPv4OVERIPv6使得我们边缘主机或者网络获得远端给我们分配IPv4地址，IPv4地址分配不是在IPv4网络是跨越了IPv6网络，我们需要是一个DHCP，OVERM2M的机制，发出去，从我们小网向户发数据，一个数据过来以后在我们IPv4应用只看到IPv4协议站，在IPv4报文前面加上IPv4头，由集中点把IPv4头去掉，获得原始的IPv4头，加一个封装，对于应用跟我们IPv4还是完全一样的。
除了一个前面说的是一个每一个主机或者是CP获得是一个完整的公有IPv4地址以外，还有可能进行相应地址复用，这里面必然存在一个问题，我一定要把端口当做一个重要资源，当做一个区分地址，主机一个资源，这里面我们使用就是现在有一个专门PCP工作组，如何分配端口号，当做地址资源一部分进行分配，把端口号地址一块分配到我们客户端，客户端拿着这样地址一块使用，上层应用我们仍然是在IPv4上面的应用。并且实现了地址的复用，大家说这种不太好，我们只能做stateless一个基本想法把我们的地址直接嵌入到一个IPv6地址里面去，把IPv4地址嵌入到IPv6地址，通过地址嵌入实现状态迁移，原来是我们在两个双栈路由器维护4和6地址影射，我们直接把4地址嵌入到6里面去，这里具体嵌入模式，我们除了一个特定网络前缀，加上一个IPv4地址以外，如果我们要实现地址复用，我们在后面进一步加上一个端口号信息，可以实现这种基于无状态地址复用，这一点是跟我们翻译机制都是非常一样。现在除了前面说的这些4over6还有是做prieate4over6我拿一个IPv4地址，你给我分配什么内容，我发送到你的远端爱做什么做什么，维护相应的状态信息，这一点是跟前面非常类似，我们地址分配相应信息，是不是要传送到这一端。
把前面4over6技术总结一下，跟我们6、4翻译技术做一个简单对比，大家一直认为，6、4之间互访只能用翻译进行，不仅可以通过6、4之间翻译实现互访而且可以通过4over6支持我们之间的互访，之所以能够通过4over6技术支持我们的互访，最重要原因就是我们现在任何一个设备一定是拥有IPv4协议站，为什么一定要把它放弃了，不用它呢，哪怕是用一个假协议站，虚拟协议这样一个协议站放到这儿应该用它，我们有很多好处，比如说一个是地址复用，仅仅是一个网络中间一个设备进行翻译的时候，我可以支持有状态地址复用，但是难以支持无状态，如果只有一个盒子做翻译点难以支持无状态复用，对于我们在中间集中控制点公有地址维护，边界上需要进行统一维护。
从开销上面讲翻译技术自然设计到4、6协议之间翻译，开销是一个重要问题，我们使用翻译要好很多但是仍然有很多开销，可扩展性会好很多，性能可扩展方面，翻译技术，44、46性能可扩展都是存在问题，应用友好型是特别重要，应用持续首先支持6，我们才可以谈上如何做4、6翻译，如果你不支持IPv6你究竟翻什么东西，没有东西让你去翻，但是我们4over6可以很好支持IPv4应用，对IPv4应用是具有透明性。
简单回顾一下我们清华大学在4over6取得成果，边缘网络如何实现IPv4和IPv6的互通。我们从03、04年一直参与IETF，当初最初是解决骨干网上IPv4OVERIPv6传输问题，包括中国教育科研网下一代网络也建立了纯IPv6全国性主干网。我们建立这个全国性主干网我们提供IPv6接入同时也需要IPv4，我们去IETF完全相应的RFC也是吴建平老师牵头完成的。当时都是我们通过4over6使得4连接到对端的网络，CNGI支持下要全面部署的4over6系统。
在IETF获得一些成果在我们国内CCSA也获得一些标准，特别是我们跟现在运营商合作也是非常密切。中国电信业有一个联合实验室，把我们如何做过渡技术作为其中一个重点，我特别提出合作，这个合作可能不仅是包括跟我们厂商合作，跟运营商合作，更多我也是希望我们能够开展跟上层应用合作，昨天我们有的专家也说过，如果我们一些运营商，或者国家政府提供一些IPv6接入，甚至是一些价格方面比较优惠的IPv6接入，这时候我们内容服务提供商可能更好的推动。
我会遇到另外一个问题，我们内容提供商应用程序提供商，应用程序客户端全部要支持IPv6，如果能够支持更好，如果不能支持的情况下，我们如何尽量大力度使用我们现在提供的价格比较优惠的，IPv6传输，这时候我想我们4over6技术应该是一个先驱，所以4over6技术我希望是能够在我们IPv6过渡的时间至少在先期起到一个促进作用，我能够积极接入到IPv6网络上，无论是SAP，服务器，积极接入到IPv6网络上，以后即便在上层应用没有大量修改情况下，我能够保持我们IPv4原有信息能够访问了，不会丢失用户资源，部署到IPv6网络上，IPv6用户访问你自然拿IPv6访问，有IPv4用户能够不丢失这是我们希望看到的事情。
