IPv6提供了两种自动发现提供解析服务的DNS服务器的方式。

　　(1) 无状态的DNS服务器发现

　　无状态DNS服务器自动发现有以下几种方式:

　　为子网内部的DNS服务器配置站点范围内的任意播地址。要进行自动配置的节点以该任意播地址为目的地址发送服务器发现请求，询问DNS服务器地址、域名和搜索路径等DNS信息。这个请求到达距离最近的DNS服务器，服务器根据请求，回答DNS服务器单播地址、域名和搜索路径等DNS信息。节点根据服务器的应答配置本机DNS信息，以后的DNS请求就直接用单播地址发送给DNS服务器。

　　与第一种方式相同，只是不用站点范围内的任意播地址，而采用站点范围内的组播地址或链路组播地址等。

　　一直用站点范围内的任意播地址作为DNS服务器的地址，所有的DNS解析请求都发送给这个任意播地址。距离最近的DNS服务器负责解析这个请求，得到解析结果后把结果返回请求节点，而不像第一种方式是把DNS服务器单播地址、域名和搜索路径等DNS信息告诉节点。

　　从网络扩展性、安全性、实用性等多方面综合考虑，第一种采用站点范围内的任意播地址作为DNS服务器地址的方式相对较好。

　　(2) 有状态的DNS服务器发现

　　有状态的DNS服务器发现方式是通过类似DHCP的服务器把DNS服务器地址、域名和搜索路径等DNS信息告知节点。当然，这需要额外的服务器。

　　6.IPV6邻居发现

　　IPv6定义了邻居发现协议(Neighbor Discovery protocol，NDP)，它使用一系列IPv6控制信息报文(ICMPv6)来实现相邻节点(同一链路上的节点)的交互管理，并在一个子网中保持网络层地址和链路层地址之间的映射。邻居发现协议中定义了5种类型的信息:路由器宣告、路由器请求、路由重定向、邻居请求和邻居宣告。通过这些信息，实现了对以下功能的支持:

　　路由器发现:即帮助主机来识别本地路由器;

　　前缀发现:节点使用此机制来确定指明链路本地地址的地址前缀以及必须发送给路由器转发的地址前缀;

　　参数发现:帮助节点确定诸如本地链路MTU之类的信息;

　　地址自动配置:用于IPv6节点自动配置;

　　地址解析:替代了ARP和RARP，帮助节点从目的IP地址中确定本地节点(即邻居)的链路层地址;

　　下一跳确定:可用于确定包的下一个目的地，即可确定包的目的地是否在本地链路上。如果在本地链路，下一跳就是目的地;否则，包需要选路，下一跳就是路由器，邻居发现可用于确定应使用的路由器;

　　邻居不可达检测:帮助节点确定邻居(目的节点或路由器)是否可达;

　　重复地址检测:帮助节点确定它想使用的地址在本地链路上是否已被占用;

　　重定向:有时节点选择的转发路由器对于待转发的包而言并非最佳。这种情况下，该转发路由器可以对节点进行重定向，使它将包发送给更佳的路由器。例如，节点将发往Internet的包发送给为节点所在的内部网服务的默认路由器，该内部网路由器可以对节点进行重定向，以使其将包发送给连接在同一本地链路上的Internet路由器。

　　IPv6不再执行地址解析协议(ARP)或反向地址解析协议(RARP)，而以邻居发现协议中的相应功能代替，IPv6邻居发现协议与IPv4地址解析协议主要区别如下:

　　(1)IPv4中地址解析协议ARP是独立的协议，负责IP地址到链路层地址的转换，对不同的链路层协议要定义不同的ARP协议。IPv6中邻居发现协议NDP包含了ARP的功能，且运行于因特网控制报文协议ICMPv6上，更具有一般性，包括更多的内容，而且适用于各种链路层协议;

　　(2)ARP协议以及ICMPv4路由器发现和ICMPv4重定向报文基于广播，而NDP协议的邻居发现报文基于高效的组播和单播;

　　(3) 可达性检测的目的是确认相应IP地址代表的主机或路由器是否还能收发报文，IPv4没有统一的解决方案。NDP中定义了可达性检测过程，保证IP报文不会发送给“黑洞”。

　　7.IPv6超长数据传送问题

　　IPv6要求互联网上的每条链路具有1280或更多个八位组的最大传输单元(MTU)。无法在一段之内传送1280个八位组的链路必须根据链路的情况在IPv6下层的协议中提供分段和重组机制。具有可配置MTU的链路，比如PPP链路必须配置为具有至少1280个八位组的MTU;要发送大于路径MTU的包，节点可以使用IPv6分段报头，在源节点将包分段，并在目的节点将包重组。

　　RFC1981中描述了一种动态发现路径最大传输单元(PMTU)的方法。基本思想是源节点最初假定到目的节点的一条路径的PMTU是这条路径第一跳的已知MTU。如果发往这条路径的任何包由于太大而不能被路径上的一些节点转发，那些节点将丢弃这些包并发回ICMPv6包太大消息。源节点收到这样一个消息后应根据包太大消息中报告的MTU压缩的那一跳的MTU值减小它为这条路径假定的PMTU。当节点对PMTU的估计值小于或等于实际PMTU时路径MTU发现过程结束。要注意在这个过程中“发包-收到包太大消息”的循环可能反复多次，因为路径上总潜在可能存在MTU更小的链路。节点也可以通过停止发送比IPv6最小链路MTU大的包来终止这个发现过程。

　　8. IPV6 路由技术

　　IPv6采用聚类机制，定义了非常灵活的层次寻址及路由结构，同一层次上的多个网络在上层路由器中表示为一个统一的网络前缀，这样可以显著减少路由器必须维护的路由表项。在理想情况下，一个核心主干网路由器只须维护不超过8192个表项。这大大降低了路由器的寻路和存储开销。

　　IPv6协议所带来的另一个特点是提供数据流标签，即流量识别。路由器可以识别属于某个特定流量的数据包，并且这条信息第一次接收时即被记录下来，下一次这个路由器接收到同样的流量数据包后，路由器采用识别的记录情况，而不需查对路径选择表，从而减少了数据处理的时间。

　　多点传送路由是指目的地址是一个多点传送地址的信息包路由。在IPv6中，多点传送路由的问题与IPv4中类似，只是功能有所加强，分别成为了ICMPv6和OSPFv6的一部分，而不是IPv4中的单独协议，从而成为了IPv6整体的一部分。为了路由多点传送信息包，IPv6中创建了一个分布树(多点传送树)到达组里的所有成员。

　　IPv6主要使用三种路由协议:RIPv6(Routing Information Protocol，路由信息协议)、OSPFv6(Open Shortest Path First，开放最短路径优先)和IDRPv2(Inter-Domain Routing Protocol，域间路由协议)以及IS-IS。

　　RIPv6是可以与IPv6共同使用的RIP版本。更新后的RIP允许接收128位地址，没有增加新特性，没有消除以前限制的相关前缀长度。这种选择的原因是为了保持RIPv6的简单性，这样它可以在非常简单的设备上实现。

　　OSPFv6是可以用于IPv6的OSPF版本，它也是IPv6推荐的内部网关路由协议(IGP)，作为所有路由器厂商的标准实现，它适于大型网络。OSPFv6作为OSPF的更新，允许传送新的128位地址和相关的前缀长度，在OSPFv6中，区域定义为128位地址。

　　IDRP是和IPv6共同使用的外部网关路由协议(EGP)，IDRP是一个路径矢量协议，在OSI结构中是设计在无连接网络协议(CLNP，ISO 8473)使用的，在Internet上作为EGP从BGP-4得出，适于和IPv6共同使用的IDRP版本是IDRPv2。

　　8. IPv6组播技术

　　IPv6加强了组播功能，这是一种可将信息传递给所有已登记了欲接收该消息的主机的功能。使用组播功能可以同时传递数据给大量的用户，传递过程只会占有一些公共或专用带宽开销而不会浪费带宽在整个网络里广播。在IPv6的组播功能中增加了“标志”，可以区分永久性与临时性地址，更有利于组播功能的实现。IPv6还包含了一些限制组播消息传递范围的一些特性，这样，组播消息可以被局限在一个特定的位置、区域、公司或其它约定范围，从而减少了带宽的使用并可提供安全性。组播的意义在于只有用户加入相应的组播组才能收到发给该组的信息，这对于视频节目的发送来说意义尤其重大，模拟电视中的频道概念就完全可以用组播组的概念来代替。而且组播组的范围可以包括同一本地网、同一机构网、甚至IPv6全球地址空间中的任何位置的节点，这就为网络多媒体信息服务提供了更大的灵活性。

　　9. IPv6对移动性的支持

　　移动IPv6协议为用户提供可移动的IP数据服务，让用户可以在世界各地都使用同样的IPv6地址，非常适合未来无线上网。

　　现在的互联网协议IPv4，原本不提供任何移动性支持。针对这一情况，IETF于1996年制订了支持移动互联网设备的协议，称为移动IP，其协议有两种版本:基于IPv4的移动IPv4和基于IPv6的移动IPv6。

　　移动IP的主要目标是:不管是连接在本地链路还是移动到外地网络，移动节点总是通过本地地址寻址。移动IP在网络层加入了新的特性，在改变网络连接点时，运行在节点上的应用程序不用修改或配置仍然可用。这些特性使得移动节点总是通过本地地址通信。这种机制对于IP层以上的协议层是完全透明的。移动节点所在的本地链路称为移动节点的家乡链路，移动节点的本地地址称为家乡地址。

　　移动IPv6操作包括家乡代理注册、三角路由、路由优化、绑定管理、移动检测和家乡代理发现。移动IPv6的工作机制如下图所示。图中有3条链路和3个系统。链路A上有一个路由器提供家乡代理服务，这个链路是移动节点的家乡链路。移动节点从链路A移动到链路B。链路C上有一个通信节点，可以是移动的或者静止的。

　　当移动节点连接到外地链路时，除了家乡地址外，它还可以通过一个或多个转交地址进行通信。转交地址是移动节点在外地链路时的IP地址。移动节点的家乡地址和转交地址之间的关联称为“绑定”。移动节点的转交地址可以自动配置。

　　移动IPv6的实现离不开家乡链路上的家乡代理。当移动节点离开本地时，要向家乡链路上的一个路由器注册自己的一个转交地址，要求这个路由器作为自己的家乡代理。家乡代理需要用代理邻居发现来截获家乡链路上发往移动节点家乡地址的数据包，然后通过隧道将截获的数据包发往移动节点的主转交地址。为了通过隧道发送截获的数据包，家乡代理要把数据包进行IPv6封装，外部的IPv6报头地址设为移动节点的主转交地址。

　　当移动节点离开本地时，家乡链路的一些节点可能重新配置，导致执行家乡代理功能的路由器被其他路由器所代替。在这种情况下，移动节点可能不知道自己家乡代理的IP地址。移动IPv6提供了一种动态家乡代理地址发现机制，移动节点可以动态发现家乡链路上家乡代理的IP地址，离开本地时，它在这个家乡代理上注册转交地址。

　　移动IPv6还定义了一个附加的IPv6目的选项——家乡地址选项。作为发送方的移动节点通过在发送的数据包中携带家乡地址选项可以把家乡地址告诉作为接收方的通信节点，而转交地址对于移动IPv6以上层(如传输层)是透明的。

　　在IPv6中，移动节点能把自己的转交地址告诉每个通信节点，使通信节点和移动节点之间进行直接路由，避免了三角路由问题。由于未来互联网上会有大量的无线移动节点，因此，在路由效率上的大规模改善可能对互联网的可扩展性产生本质的影响。

　　移动IPv6具有诱人的应用前景，它为新一代无线用户提供了移动支持，但在移动越区切换、QoS、安全等方面仍不能满足实际应用的需要。目前，许多研究机构(包括移动通信的著名厂商诺基亚、爱立信等)都在研究这些关键技术。

　　移动IPv6与移动IPv4相比优势明显，主要是其设计吸收了移动IPv4的发展经验，并且抓住了设计新版本IP协议(IPv6)的大好时机，结合了IPv6的很多新特性。IPv6的出现是移动计算的一个重要里程碑，IPv6的下列主要特性对于未来的移动无线网络的发展至关重要:足够多的IP地址、安全数据报头的实现、目的选项提高了路由效率、地址自动配置、避免入口过滤、错误恢复没有软状态“瓶颈”。

　　移动IPv6协议的优点在移动终端数量持续上涨的今天尤其突出。IPv6将是实现移动互联网上许多新型而精彩的服务的关键。尽管IPv4中也存在移动协议，但二者之间存在本质的区别:移动IPv4协议不适用于数量庞大的移动终端。目前全世界的移动终端数就超过7亿个，而且移动电话终端的潮流才刚刚开始，包含诸如门、防盗自动警铃等设备的下一轮终端浪潮已经显露出来。移动IP需要为每个设备提供一个全球唯一的IP地址，不久的将来，当每个人都要携带一个或多个移动终端时，IPv4将没有足够的地址空间为在公共互联网上运行的每个移动终端分配一个全球唯一的IP地址，而IPv6却可以实现这一点。除了IPv6的其他优点外，单这一项功能就可以实现个人之间的直接通信。从另一个角度说，移动IPv6能够通过简单的扩展，满足大规模移动用户的需求。这样，它就能在全球范围内解决有关网络和访问技术之间的移动性问题。另外，IPv4协议中对移动性的支持不是强制的，而移动IPv6是IPv6协议中不可或缺的部分，所有IPv6的实现都必须支持移动性。

　　10.IPv6安全特性

　　早期的互联网安全机制只建立于应用程序级，如E-mail加密、SNMPv3网络管理安全、接入安全(HTTP、SSL)等，无法从IP层来保证Internet的安全。为了加强互联网的安全性，从1995年开始，IETF着手研究制定了一套IP安全(IP Security，IPSec)协议用于保护IP通信的安全。IPSec提供既可用于IPv4也可用于IPv6的安全性机制，它是IPv6的一个组成部分，也是IPv4的一个可选扩展协议。通过集成IPSec，IPv6实现了IP级的安全。IPSec提供如下安全性服务:访问控制、无连接的完整性、数据源身份认证、防御包重传攻击、保密、有限的业务流保密性。IPSec的认证报头(Authentication Header，AH，RFC2402中描述)协议定义了认证的应用方法，封装安全负载(Encapsulating Security Payload，ESP，RFC2406中描述)协议定义了加密和可选认证的应用方法。IPSec安全性服务完全通过AH和ESP头相结合的机制来提供，当然还要有正确的相关密钥管理协议。在实际进行IP通信时，可以根据安全需求同时使用这两种协议或选择使用其中的一种。

　　IPv6实质上不会比IPv4更加安全。IPv6标准的起草者、思科总部的两位“杰出网络技术领袖”Fred Baker和 Tony Hain认为IPv6从根本上来说，只是IP地址改变的协议包，并不能解决现在的互联网协议IPv4中的安全问题。但是由于IPSec提供的端到端安全性的两个基本组件——认证和加密——都是IPv6协议的必备组件，而在IPv4中，它们只是可选组件，因此，采用IPv6，安全性会更加简便、一致。更重要的是，IPv6使我们有机会在将网络转换到这种新型协议的同时发展端到端安全性。

　　11. IPv6 服务质量

　　从协议的角度看，IPv6与目前的IPv4提供相同的服务质量(QoS)，但是IPv6的优点体现在能提供不同的服务。这些优点来自于IPv6的报头结构中新增的优先级字段和流标签字段。优先级字段扩大到1个字节，这就可以定义256个级别的优先级，对各种多媒体信息根据紧急性确定数据包的优先级，从而保证每一项服务都能达到用户满意的质量。而有了20位长的流标签字段，在传输过程中，中间的各节点就可以识别和分开处理任何IP地址流。在IPv6中，同一个业务流的所有数据包采用相同的流标签，这样当路由器检测到相同的流标签的时候就采用相同的路径发出去，而不需要为每一个数据包重新选择路由，从而大大提高了数据包转发的效率，降低了端到端的延迟。尽管对流标签的准确应用还没有制定出有关标准，但将来它会用于基于服务级别的新计费系统。此外，在支持“总是在线”连接、防止服务中断以及提高网络性能方面，IPv6也有助于改进服务质量。

　　IPv6实现QoS的协议是IETF的资源保留协议(Resource Reserve Protocol，RSVP)。主机用RSVP代表应用数据流(指可以由路由器或者转发数据的主机辨别的相关数据包的流，在IPv6协议下就是拥有相同的流标签的流)向网络请求特定的服务质量，例如基于平均值的最大带宽、最大接收延迟、优先队列以及其他参数，主机也可以指定一个特定的网络服务级别，这类似于数字视频广播(Digital Video Broadcasting，DVB)中的网络信息表的概念。RSVP带着这个请求通过网络，访问这个数据流经过的网络的每个节点。在每个节点上，RSVP试图为这个流进行资源保留。这使得提供具有服务质量的图像和其它实时业务成为可能。

　　12. IPv4向IPv6的转换

　　IPv6不可能立刻替代IPv4，因此在相当一段时间内IPv4和IPv6会共存在一个环境中。要提供平稳的转换过程，使得对现有的使用者影响最小，就需要有良好的转换机制。国际标准化组织和许多研发机构都开发出了多种IPv4与IPv6的互通转换机制。目前常见的IPv4/IPv6互通转换技术标准:

　　·6to4:RFC 3056

　　·NAT-PT(Network Address Translation-Protocol Translation):RFC 2766

　　·SIIT(Stateless IP/ICMP Translation):RFC 2765

　　·Tunnel broker:RFC 3053

　　·6over4:RFC 2529

　　·BIS(Bump-In-the-Stack):RFC 2767

　　·BIA(Bump-in-the-API):RFC 3338

　　·SOCKS-gateway:RFC 3089

　　·TCP/UDP-relay:RFC 3142

　　·DSTM(Dual Stack Transition Mechanism):draft-ietf-ngtrans-dstm-08.txt

　　·ISATAP(Intra-Site Automatic Tunnel Addressing Protocol):draft-ietf-ngtrans-isatap-08.txt

　　但IETF主要推荐了双协议栈、隧道技术以及NAT等转换机制:

　　(1) IPv6/IPv4双协议栈技术

　　简单地说，双栈机制就是使IPv6网络节点具有一个IPv4栈和一个IPv6栈，同时支持IPv4和IPv6协议。IPv6和IPv4是功能相近的网络层协议，两者都应用于相同的物理平台，并承载相同的传输层协议TCP或UDP，如果一台主机同时支持IPv6和IPv4协议，那么该主机就可以和仅支持IPv4或IPv6协议的主机通信，IPv6/IPv4双协议栈的协议结构如下图所示:

　　对现有路由节点设备进行升级，使其成为IPv4/IPv6路由器，这样IPv6的连接就成为本地链路，相当于IPv4/IPv6存在于相同的物理网络上。双栈方案需要为网络上的每个节点(包括主机和路由器)分配一个IPv4和一个IPv6地址。在IPv6网络建设的初期，由于IPv4地址相对充足，这种方案的实施具有可行性。当IPv6网络发展到一定阶段，为每个节点分配两个全局地址的方案将很难实现。

　　(2) 隧道技术

　　隧道机制就是必要时将IPv6数据包作为数据封装在IPv4数据包里，使IPv6数据包能在已有的IPv4基础设施(主要是指IPv4路由器)上传输的机制。随着IPv6的发展，出现了一些被运行IPv4协议的骨干网络隔离开的局部IPv6网络，为了实现这些IPv6网络之间的通信，必须采用隧道技术。隧道对于源站点和目的站点是透明的，在隧道的入口处，路由器将IPv6的数据分组封装在IPv4中，该IPv4分组的源地址和目的地址分别是隧道入口和出口的IPv4地址，在隧道出口处，再将IPv6分组取出转发给目的站点。隧道技术的优点在于隧道的透明性，IPv6主机之间的通信可以忽略隧道的存在，隧道只起到物理通道的作用。

　　在IPv6全面实施之前，总有一些网络先提供对IPv6的支持，但是这些IPv6网络被运行IPv4协议的骨干网络隔离开来。“IPv6 over IPv4”的隧道就用来连接这些孤立的IPv6网络。隧道技术目前是国际IPv6试验床6Bone所采用的技术。利用隧道技术可以通过现有的运行IPv4协议的Internet骨干网络(即隧道)将局部的IPv6网络连接起来，因而是IPv4向IPv6过渡的初期最易于采用的技术。隧道技术的优点在于隧道的透明性，IPv6主机之间的通信可以忽略隧道的存在，隧道只起到物理通道的作用。它不需要大量的IPv6专用路由器设备和专用链路，可以明显地减少投资。

　　手工配置隧道(Configured Tunnel)

　　这种隧道是手工配置建立的，隧道的端点地址由配置决定，不需要为节点分配特殊的IPv6地址，适用于经常通信的IPv6节点之间使用。每个隧道的封装节点必须保存隧道终点地址，当IPv6包在隧道上传输时，终点地址会作为IPv4包的目的地址进行封装。通常封装节点要根据路由信息决定这个包是否通过隧道转发。采用手工配置隧道方式进行互通的节点间必须有可用的IPv4连接，并且至少要具有一个全球惟一的IPv4地址，每个节点都要支持IPv6，路由器需要支持双协议栈，在隧道要经过NAT设施的情况下该机制失效。

　　其缺点是:在IPv4网络上配置IPv6隧道是一个比较麻烦的过程，而且隧道技术不能实现IPv4主机和IPv6主机之间的通信。

　　自动配置隧道(Auto-configured Tunnel)

　　这种隧道的建立和拆除是动态的，其端点根据分组的目的地址确定，适用于不经常通信的节点间使用。自动配置隧道需要节点采用IPv4兼容的IPv6地址(IPv4ADDR::/96)，这些节点间必须有可用的IPv4连接，采用这种机制的节点需要有一个全球惟一的IPv4地址。采用这种机制不能解决IPv4地址空间耗尽的问题，并且如果把Internet上全部IPv4路由表包括到IPv6网络中，将会加剧路由表的膨胀。这种隧道的两个端点都必须支持双协议栈，在隧道要经过NAT设施的情况下该机制失效。

　　(3) 网络地址转换技术

　　网络地址转换(Network Address Translator，NAT)技术是将IPv4地址和IPv6地址分别看作内部地址和全局地址，或者相反。例如，内部的IPv4主机要和外部的IPv6主机通信时，在NAT服务器中将IPv4地址(相当于内部地址)变换成IPv6地址(相当于全局地址)，服务器维护一个IPv4与IPv6地址的映射表。反之，当内部的IPv6主机和外部的IPv4主机进行通信时，则IPv6主机映射成内部地址，IPv4主机映射成全局地址。NAT技术可以解决IPv4主机和IPv6主机之间的互通问题。

　　许多运营商目前建设的IPv4网络容量很大，那么通过IPv4网络的隧道上承载IPv6流量是当前阶段普遍采用的过渡方法，这种方法能够节省网络建设成本，要求路由器能很好地支持隧道机制，一般需要支持手工隧道、自动隧道等。运营商建设IPv6核心骨干网络时，根据流量大小可能采用一部分专有IPv6链路;随着IPv6核心网络规模扩大，此时主要采用IPv6链路连接，要求路由器具有高性能线速IPv6数据包转发能力。利用路由器IPv6/IPv4双栈机制，双栈IPv6/IPv4主机和纯IPv6或者纯IPv4的主机通信不用采用协议转换，而直接“自动”选择相应的通信协议(IPv4或者IPv6)，国际上一些商用网络和试验网在一定规模范围进行了双栈试验，已经证明是可行的技术方案。

　　企业网络在接入NGI网络时，如果运营商IPv6城域网边缘路由器能支持双栈机制，则可以采用专线方式(纯IPv6+IPv4 NAT)使企业网络接入IPv4和IPv6城域网。若运营商网络不具备双栈接入能力，企业网络可采用隧道方式接入运营商IPv6网络。

　　13. 下一代网络与IPv6的关系

　　IPv6与下一代网络的发展密切相关。随着Internet技术的发展，下一代网络(NGN/NGI)已初具端倪，并将进一步演进和发展。ITU-T的NGN计划(NGN 2004 Project)将下一代网络看作是全球信息基础设施(GII)的具体实现;ETSI将NGN定义为是一种规范和部署网络的概念，通过采用分层、分面和开放接口的方式，给业务提供者和运营者提供一个平台，借助这一平台逐步演进，以生成、部署和管理新的业务;IETF重在发展增强的IP网(可扩展性、安全性和移动性等);3GPP、3GPP2提出了基于IPv6的All-IP核心网络。

　　在Internet成功商业化的同时，下一代互联网的研究与开发工作在各国政府的支持下逐渐展开。1995年美国科学基金会(NSF)资助了下一代因特网(NGI)研究计划，建立了NGI主干网(vBNS);1998年美国大学先进网络联盟(UCAID)成立，设立Internet2研究计划，建立主干网Abilene;1998年亚太地区先进网络组织A-PAN成立，推动亚太地区下一代因特网的研究;2001年欧共体资助下一代因特网研究计划，建立主干网GEANT。通过这些计划的实施，全球已初步建成大规模先进网络试验环境，攻克了一批网络关键技术。

　　而无论是产业界的NGN(Next Generation Network)还是学术界的NGI(Next Generation Internet)，均以IPv6作为其核心技术。

　　以IPv6为核心的下一代网络将实现以下价值:

　　1)下一代网络使网络建设变得更加容易。利用基于IP的网元而不是传统电路交换机，一个新兴的通信公司可把建网费用降低70%;

　　2)下一代网络的运行成本要低很多。下一代网不需另建具有支撑维护功能的重叠网，是一种多业务网，并且在用户管理、业务提供、用户资料修改和自我计费方面更加自动化;>

　　3)下一代网络给新兴的通信公司带来很大的创收机会。他们可以提供应用软件递送或电子商务之类的高收入服务;还可以利用集中的业务控制、应用编程接口和公共编程语言来使业务生成变得更加容易和便宜;

　　4)下一代网络能帮助运营商加强与用户的关系，减少用户流失。运营商可以提供基于Web的接口，让用户通过该接口直接定购新业务、改变服务内容和支付费用，从而与用户建立更广泛更紧密的关系。运营商还可以为用户的特殊需要定制服务，为电子服务开设专门的门户。

　　[参考文献]

　　RFC1809 Using the Flow Label Field in IPv6. June 1995.

　　RFC1881 IPv6 Address Allocation Management. IAB & IESG. December 1995.

　　RFC1887 An Architecture for IPv6 Unicast Address Allocation. December 1995.

　　RFC1924 A Compact Representation of IPv6 Addresses. April 1996.

　　RFC1981 Path MTU Discovery for IP version 6. August 1996.

　　RFC2080 RIPng for IPv6. January 1997.

　　RFC2081 RIPng Protocol Applicability Statement. January 1997.

　　RFC2185 Routing Aspects of IPv6 Transition. September 1997.

　　RFC2374 An IPv6 Aggregatable Global Unicast Address Format. July 1998.

　　RFC2375 IPv6 Multicast Address Assignments. July 1998.

　　RFC2428 FTP Extensions for IPv6 and NATs. September 1998.

　　RFC2450 Proposed TLA and NLA Assignment Rule. December 1998.

　　RFC2452 IP Version 6 Management Information Base for the Transmission Control Protocol. December 1998.RFC2454 IP Version 6 Management Information Base for the User Datagram Protocol. December 1998.

　　RFC2460 Internet Protocol, Version 6 (IPv6) Specification. December 1998.

　　RFC2461 Neighbor Discovery for IP Version 6 (IPv6). December 1998.

　　RFC2462 IPv6 Stateless Address Autoconfiguration. December 1998.

　　RFC2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. December 1998.

　　RFC2464 Transmission of IPv6 Packets over Ethernet Networks. December 1998.

　　RFC2465 Management Information Base for IP Version 6: Textual Conventions and General Group. December 1998.

　　RFC2466 Management Information Base for IP Version 6: ICMPv6 Group. December 1998.

　　RFC2467 Transmission of IPv6 Packets over FDDI Networks. December 1998.

　　RFC2470 Transmission of IPv6 Packets over Token Ring Networks. December 1998.

　　RFC2471 IPv6 Testing Address Allocation. December 1998.

　　RFC2472 IP Version 6 over PPP. December 1998.

　　RFC2473 Generic Packet Tunneling in IPv6 Specification. December 1998.

　　RFC2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. December 1998.

　　RFC2491 IPv6 over Non-Broadcast Multiple Access(NBMA) networks. January 1999.

　　RFC2492 IPv6 over ATM Networks. January 1999.

　　RFC2497 Transmission of IPv6 Packets over ARCnet Networks. January 1999.

　　RFC2526 Reserved IPv6 Subnet Anycast Addresses. March 1999.

　　RFC2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels. March 1999.

　　RFC2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing. March 1999.

　　RFC2590 Transmission of IPv6 Packets over Frame Relay Networks Specification. May 1999.

　　RFC2663 IP Network Address Translator (NAT) Terminology and Considerations. August 1999.

　　RFC2675 IPv6 Jumbograms. August 1999.

　　RFC2710 Multicast Listener Discovery (MLD) for IPv6. October 1999.

　　RFC2711 IPv6 Router Alert Option. October 1999.

　　RFC2732 Format for Literal IPv6 Addresses in URL’s. December 1999.

　　RFC2740 OSPF for IPv6. December 1999.

　　RFC2765 Stateless IP/ICMP Translation Algorithm (SIIT). February 2000.

　　RFC2767 Dual Stack Hosts using the “Bump-In-the-Stack” Technique (BIS). February 2000.

　　RFC2858 Multiprotocol Extensions for BGP-4. June 2000. RFC2893 Transition Mechanisms for IPv6 Hosts and Routers. August 2000.

　　RFC2894 Router Renumbering for IPv6. August 2000.

　　RFC2921 6BONE pTLA and pNLA Formats (pTLA). September 2000.

　　RFC2928 Initial IPv6 Sub-TLA ID Assignments. September 2000.

　　RFC3019 IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol. January 2001.

　　RFC3022 Traditional IP Network Address Translator (Traditional NAT). January 2001.

　　RFC3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6. January 2001.

　　RFC3053 IPv6 Tunnel Broker. January 2001.

　　RFC3056 Connection of IPv6 Domains via IPv4 Clouds. February 2001.

　　RFC3068 An Anycast Prefix for 6to4 Relay Routers. June 2001.

　　RFC3089 A SOCKS-based IPv6/IPv4 Gateway Mechanism. April 2001.

　　RFC3111 Service Location Protocol Modifications for IPv6. May 2001.

　　RFC3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification. June 2001.

　　RFC3142 An IPv6-to-IPv4 Transport Relay Translator. June 2001.

　　RFC3146 Transmission of IPv6 Packets over IEEE 1394 Networks. October 2001.

　　RFC3152 Delegation of IP6.ARPA. August 2001.

　　RFC3162 RADIUS and IPv6. August 2001.

　　RFC3178 IPv6 Multihoming Support at Site Exit Routers. October 2001.

　　RFC3194 The H-Density Ratio for Address Assignment Efficiency: An Update on the H ratio. November 2001.

　　RFC3235 Network Address Translator (NAT)-Friendly Application Design Guidelines. January 2002.

　　RFC3257 Stream Control Transmission Protocol Applicability Statement. April 2002.

　　RFC3266 Support for IPv6 in Session Description Protocol (SDP). June 2002.

　　RFC3306 Unicast-Prefix-based IPv6 Multicast Addresses. August 2002.

　　RFC3307 Allocation Guidelines for IPv6 Multicast Addresses. August 2002.

　　RFC3314 Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards. September 2002.

　　RFC3338 Dual Stack Hosts Using “Bump-in-the-API” (BIA). October 2002.

　　RFC3363 Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS). August 2002.

　　RFC3364 Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6). August 2002.

　　RFC3493 Basic Socket Interface Extensions for IPv6. March 2003.

　　RFC3513 Internet Protocol Version 6 (IPv6) Addressing Architecture. April 2003.RFC3542 Advanced Sockets Application Program Interface (API) for IPv6. May 2003.