下载掌阅APP，畅读海量书库
立即打开
[1]GENI System Overview.GENI-SE-SY-SO-02.0.doc.September 29,2008.
[2]http://www.nets-find.net/.
[3]http://www.openflow.org/.
[4]LixiaZhang,D.Estrin,J.Burke,V.Jacobson,J.D.Thornton,D.K.Smetters,B.Zhang,G.Tsudik,K.claffy,D.Krioukov,D.Massey,C.Papadopoulos,T.Abdelzaher,L.Wang,P.Crowley,E.Yeh.Named Data Networking(ndn)project.NSF Future Internet Architecture Project,2010.
[5]Anja Feldmann.Internet clean-slate design:what and why?ACM SIGCOMM Computer Communication Review,2007,37(3):59-64.
[6]Jennifer Rexford,Constantine Dovrolis.Future Internet Architecture:Clean-Slate Versus Evolutionary Research.Communications of the ACM,2010,53(9):36-40.
[7]Constantine Dovrolis,J.Todd Streelman.Evolvable network architectures:What can we learn from biology?ACM SIGCOMM Computer Communication Review,2010,40(2):72-77.
[8]Constantine Dovrolis.What would Darwin Think about Clean-Slate Architectures?ACM SIGCOMM Computer Communication Review,2008,38(1):29-34.
[9]D Farinacci,V Fuller,D Meyer,D Lewis.Locator/ID separation protocol(LISP).(draft-ietf-lisp-07),April 2010.
[10]Dave Meyer,Vince Fuller,Darrel Lewis,Eliot Lear,Scott Brim,Dave Oran,Noel Chiappa,John Curran,Dino Farinacci.Locator/ID Separation Protocoal(LISP)Tutorial,IETF Vancouver,December 2007,http://www.ietf.org/proceedings/70/slides/RRG-7.pdf.
[11]R.Buyya,A.M.K.Pathan,J.Broberg,Z.Tari.A Case for Peering of Content Delivery Networks,IEEE Distributed Systems Online,Vol.7,No.10,IEEE CS Press,Los Alamitos,CA,USA,October 2006.
[12]Al-Mukaddim Khan Pathan and Rajkumar Buyya.A Taxonomy and Survey of Content Delivery Networks,Technical Report,GRIDS-TR-2007-4,Grid Computing and Distributed Systems Laboratory,The University of Melbourne,Australia,12 February,2007.(Submitted to ACM Computing Surveys)
[13]D.Clark,R.Braden,K.Sollins,J.Wroclawski,D.Katabi,J.Kulik,X.Yang,T.Faber,A.Falk,V.Pingali,M.Handley,N.Chiappa.NEW ARCH:FUTURE GENERATION INTERNET ARCHITECTURE,techinical report,August,2004,http://www.isi.edu/newarch/.
[14]R.Braden,D.Clark,S.Shenker,J.Wroclawski.Developing a Next-Generation Internet Architecture,July 15,2000,http://www.isi.edu/newarch/.
[15]D.Clark,K.Sollins,J.Wroclawski,T.Faber.Addressing Reality:An Architectural Response to Real-World Demands on the Evolving Internet,ACM SIGCOMM 2003 FDNA Workshop,Karlsruhe,August 2003.
[16]K.Sollins.Designing for Scale and Differentiation,ACM SIGCOMM FDNA 2003 Workshop,Karlsruhe,August 2003.
[17]D.Clark,J.Wroclawski,K.Sollins,R.Braden.Tussle in Cyberspace:Defining Tomorrow's Internet,SIGCOMM'02:Proceedings of the 2002 conference on Applications,technologies,architectures,and protocols for computer communications,pages 347-356,New York,NY,USA,2002.ACM.
[18]D.Clark,R.Braden,A.Falk,V.Pingali.FARA:Reorganizing the Addressing Architecture,ACM SIGCOMM 2003 FDNA Workshop,Karlsruhe,August 2003.
[19]R.Braden,T.Faber,M.Handley.From Protocol Stack to Protocol Heap——Role-Based Architecture,HotNets-I,Princeton,NJ,October 2002.
[20]Xiaowai Yang.NIRA:A New Internet Routing Architecture,ACM SIGCOMM FDNA 2003 Workshop,Karlsruhe,August 2003.
[21]http://www.named-data.net/.
[22]http://mobilityfirst.winlab.rutgers.edu/.
[23]http://nebula.cis.upenn.edu/.
[24]http://www.cs.cmu.edu/~xia/.
[25]D.D.Clark.The design philosophy of the darpa internet protocols.SIGCOMM Comput.Commun.Rev.,25:102-111,January 1995.
[26]Anja Feldmann.Internet clean-slate design:what and why?ACM SIGCOMM Computer Communication Review,2007,37(3):59-64.
[27]http://cordis.europa.eu/ist/fet/comms.htm.
[28]Douglas Comer,Lessons Learned From The Internet Project.
[29]Jim Kurose.networking.successes,newchallenges,and an expanding waist,as the field approaches 40,Infocom 2004 keynote talk,March 2004.
[30]吴建平，刘莹，吴茜.新一代互联网体系结构理论研究进展.中国科学E辑：信息科学，2008，38（10）：1540-1564.
[31]吴建平，李星，刘莹.下一代互联网体系结构研究现状和发展趋势.中兴通讯技术，2011.
内容提要
由于IPv4地址分配殆尽，向IPv6过渡已经迫在眉睫。由于IPv4协议和IPv6协议的语法、语义和时序不同，不能兼容，IPv4互联网向IPv6互联网过渡已经成为世界性技术难题。本章分析了过渡的几种主要场景，进一步介绍了目前主要的隧道技术和翻译技术的基本原理和主要协议。
在过去的20多年中，伴随着互联网的快速发展，IPv4协议 [2] 取得了巨大成功。当前全球IPv4用户已经超过20亿，占到人口总数的28%。然而，网络规模的急剧增长也突显出IPv4的一系列严重问题，包括地址空间不足、路由可扩展性问题等。2011年2月，IANA将其最后5个/8的IPv4地址块分配给了RIR，这也标志着全球基于IPv4协议的43亿地址资源已全部分配完毕，而研究表明，RIR在三年之内也会将地址全部分配完毕 [3] 。但是互联的规模仍在快速增加，特别是互联网的移动设备数量在不断增长。这些都需要新的IP地址分配，但是从现有情况来看，IPv4是不能够满足的。另外，由于IPv4地址块分离、多重连接等问题造成不能有效聚合路由，进而导致了路由器中需要维护大量的路由表项，增加了路由查找和存储的开销，这成为互联网进一步发展的瓶颈。而大范围的NAT破坏了端到端的透明性，却并不能从根本上解决IPv4地址紧缺的危机。
IPv6协议 [4] 的提出正是为了解决这些问题，进而取代IPv4。IPv6具有巨大的地址空间，从根本上解决了IPv4地址紧缺的问题。IPv6对报头做了简化，采用40字节的固定报头，不仅减小了报头长度，而且由于报头长度固定，路由器上的处理也更加便捷；另外，IPv6还采用了扩展报头机制，更便于协议自身的功能扩展；IPv6报头中增加了流标签字段，使用流标签功能可以更好地实现服务质量（QoS）支持。无状态地址自动配置可以支持即插即用的特征 [5] ，此外，IPv6具有更好的端到端特性，更好的安全性和移动性支持等特性 [6] 。IPv6是对IPv4的重新设计，解决了IPv4所产生的问题进而提供更好的服务，具有大幅推进互联网发展的潜力，是下一代互联网的支撑协议。
然而IPv6的设计并不兼容IPv4：IPv6不能与IPv4直接通信。本质上讲IPv6是与IPv4平行、独立的网络协议。如果IPv4想要进一步支持IPv6通信，就必须能够执行IPv6路由，而且网络设备也要支持IPv6协议。当前的IPv6应用和IPv6内容服务只占少数 [7] ，大量的网络资源、服务和应用仍位于IPv4网络中，因此IPv4网络仍然会长时间存在。另外，对地址的需求促进了IPv6的发展，可以预见IPv4和IPv6将会长期共存，并且将会逐渐过渡到IPv6。在此期间需要保证IPv4和IPv6的可用性，以及双栈环境下的DNS、QoS和安全等问题。总体来说，需要多种过渡机制来保证IPv4和IPv6的连通性，进而加快IPv6的过渡进程。
IPv6过渡是十多年来IETF争论的一个热点话题。大约在2000年，科研人员提出了一系列的过渡机制，包括6to4 [8] 、6over4 [9] 、NAT-PT [10] 、SIIT [11] 、BIS [12] 等。然而这些机制并没有得到大范围的部署，而且这些机制也没有完全解决过渡问题。原因是这些机制并没有全面考虑可扩展性、寻址、部署模式和IPv4地址紧缺等因素。一些机制甚至因为上述原因而被废弃。但是这些机制确实推动了进一步的研究工作。在2004—2005年，IETF创建两个工作组——Behave和Softwire来进一步解决过渡问题，并且研究更完善的过渡机制。
异构网络中互联的问题是要在IPv4和IPv6的混合网络中建立连接。一个重要的特点是连接的建立需要穿越一个或多个IPv4-IPv6边界，但是IPv4-IPv6边界并不能互操作。由于最终的目的是迁移到IPv6网络，能够互操作有利于克服IPv4存在的影响 [13] 。理论上讲，IPv4与IPv6互联时可能需要穿越多个网络边界，但是最终可将其归结为两个基本问题：异构网络互联（如图4-1所示）和异构网络穿越（如图4-2和图4-3所示）。这也是研究问题的一个有效方法，因为许多更复杂的场景可以分为多个这样的基本问题，解决方案也紧紧围绕着本地寻址和路由，而且IPv4和IPv6 Internet都是有组织的，并非自由分布，这两个基本问题也是现实网络中最常见的实例。
▶ 图4-1 异构网络互联
▶ 图4-2 Mesh网络穿越场景
▶ 图4-3 星形网络穿越场景
当两个直联的网络或主机使用不同的地址族时，就会出现异构网络互联问题。为了实现IPv4网络或主机与IPv6网络或主机的通信，需要引入过渡技术。由于通信报文的源地址与目的地址采用的是不同的地址族，因此，为了实现这样的异构通信，协议转换机制是必不可少的。
IETF Behave工作组 [14] 致力于研究异构互联问题的解决方案，并将这些解决方案推行为行业标准。根据网络规模及通信发起方的不同，Behave工作组提出了异构互联问题中存在的8种不同的场景：IPv6网络向IPv4网络发起通信，IPv6网络向IPv4互联网发起通信，IPv6互联网向IPv4网络发起通信，IPv6互联网向IPv4互联网发起通信，IPv4网络向IPv6网络发起通信，IPv4网络向IPv6互联网发起通信，IPv4互联网向IPv6网络发起通信，IPv4互联网向IPv6互联网发起通信。
需要说明的是上述场景中的“网络”与互联网相比具有更明确、更具体的管理域，如企业级校园网、移动运营商蜂窝网络、住宅区小区网络等。不同的场景对可扩展性的要求不同，这使得在上述场景中实现异构网络互联的难点不尽相同。因此需要对上述场景分别进行考虑。除了网络间的异构互联场景外，异构互联问题还存在两种特殊的场景，即IPv4应用通过主机的IPv6连接与IPv6网络进行通信，以及IPv6应用通过主机的IPv4连接与IPv4网络进行通信。在这种情况下，主机中的TCP/IP协议栈需要提供协议转换机制，使得IPv4/IPv6应用能通过IPv6/IPv4协议进行通信。显然，该问题可以看成应用与异构网络之间的异构互联问题。
当处于IPv6/IPv4网络中的两个或更多IPv4/IPv6本地网络或主机需要进行通信时，就会出现异构穿越问题。为了实现这种穿越异构网络的通信，需要引入过渡技术。如果IPv4本地网络或主机被IPv6网络分隔，则需要使用IPv4-over-IPv6穿越机制；反之，则需要使用IPv6-over-IPv4穿越机制。
IETF Softwire工作组 [15] 致力于研究异构穿越问题的解决方案，并将这些解决方案推行为行业标准。Softwire工作组将异构穿越问题划分为两种典型场景：网状网络（Mesh）通信与星形网络（Hub&Spokes）通信 [16] 。在网状网络通信场景中，采用相同地址族的若干网络孤岛之间的通信被使用另一种地址族的网络所分隔。在星形网络通信场景中，若干使用相同地址族的主机或子网与处于中心的本地接入点的连接被使用不同地址族的网络所分隔。前一种场景通常出现在主干网中，而后一种则通常出现在边缘网中。
由于IPv6和IPv4的不兼容性，实现异构互联和异构穿越并不容易。IPv6与IPv4地址格式长度相差96比特，这使得不可能建立IPv4地址与IPv6地址的一一映射。虽然将IPv4地址空间映射到IPv6中很容易实现，但IPv6地址空间显然不可能被完整地映射到IPv4中。
除了采用过渡技术解决上述异构网络共存问题外，另一种可选方法就是将互联网升级为同时支持IPv4和IPv6的双栈网络。任何两个节点间都能使用IPv4或IPv6进行通信；IPv4-IPv6异构互联或穿越问题将不复存在。在这种情况下，整个互联网将成为两个物理设备上统一而逻辑上分离的网络。然而，双栈互联网既不实用，也不是一种能长期采用的解决方案。由于地址空间耗尽，大规模地扩张IPv4互联网是不切实际的，并且升级全网使其同时支持IPv4和IPv6的巨大开销是不可接受的。
尽管如此，在小规模网络中采用双栈网仍然是可以接受的。实际上，由于不同协议存在不兼容性，双栈节点是实现IPv4与IPv6网络交互不可或缺的组成部分。具体而言，处于IPv4与IPv6网络边界处的双栈节点与IPv4和IPv6网络都能进行通信，进而能为IPv4和IPv6的异构交互提供支持。基于这一点，目前研究领域已经提出了两类过渡技术——翻译技术和隧道技术。