CN101557349A

CN101557349A - 处理互联网数据报的方法和系统

Info

Publication number: CN101557349A
Application number: CNA2009101437611A
Authority: CN
Inventors: 孙斌
Original assignee: Individual
Current assignee: Individual
Priority date: 2009-05-26
Filing date: 2009-05-26
Publication date: 2009-10-14
Anticipated expiration: 2029-05-26
Also published as: CN101557349B

Abstract

一种处理互联网数据报的方法和系统，通过检查位于IPv4数据报头部之中的一个特定的标志字段来确定是否存在地址扩展信息。如果该地址扩展标志字段存在，则把IPv4数据报头部中的32位源地址字段和/或目的地址字段与数据报头部之中的另一个字段的数据位结合，组成比32位更长的源地址或目的地址。所述标志字段为一个专用的地址扩展选项，其选项类型码为一个在IPv4中保留未用的选项类型码值，其总长度可达40个字节。此技术方案可实现一个与IPv4保持完全兼容、使用变长地址、具有20级地址扩展层次的IP地址方案和数据报处理技术。根据本发明，现有的IPv4地址作为“0级扩展地址”是永久有效的，已经分配和正在使用的IPv4网络和系统可以长久地使用下去，而地址升级只是引入新的更长的扩展地址。本发明的这种逐级扩展、多级地址并存使用的方式能够更好地应对全球IPv4地址耗尽和IP技术升级所必须面对的各种挑战。

Description

处理互联网数据报的方法和系统

技术领域

本发明涉及互联网技术领域中的互联网数据报(internet datagram)处理技术，特别是涉及在数据报的头部设置地址信息并根据此信息在网络节点之间传递数据报的方法和系统。

背景技术

以互联网(Internet)为代表的网络互联(internetworking)技术令位于不同网络的节点(计算机或各类数字设备)之间相互传递数据成为可能。分布于全球的大量局域网之中的计算机通过使用标准化的网间互联协议，可以实现快速高效的双向数据通信，无论这些局域网实际上使用了何种不同的物理特性或电子通信技术。众所周知，互联网所使用的网间互联协议统称为TCP/IP，它是一组专为实现跨越多个网络的数据报存储与转发而设计开发的网络互联协议。TCP/IP自上个世纪70年代后期提出以来，经过了30多年的发展和完善，已成为支撑全球互联网运行和日常应用的坚实技术基础。TCP/IP所包括的各种协议按其功能可分为三大层次：(1)位于底层的一组协议为网络层协议，以IP(Internet Protocol)为核心，实现了与物理网络无关的节点到节点的数据报转发，主要包括网络层地址分配、路由(routing，路径自动选择)、自动分片与重组等基本功能；(2)在IP之上是一组传输层协议，包括TCP和UDP，它们在IP层的基本功能之上进一步提供端点地址之间的端口复用、连接与状态维护、差错控制、接收确认和重发等功能；(3)在TCP和UDP之上即为各种应用层协议，包括各种路由信息交换协议(例如RIP、BGP等)、DNS、DHCP、SNMP，以及HTTP、FTP、SMTP、POP3、NFS等等，正是这些第三层上的应用协议实现了日益丰富多彩的互联网应用软件和服务。

TCP/IP所拥有的网间互联功能是由IP实现的。作为一个多种网络之间的互联技术，IP的重要性体现在如下两个方面：一是为上层协议和应用程序提供一个隐藏了下层网络硬件特性和通信细节的抽象层，即提供网络硬件的透明性；另一个方面是为上层协议和应用程序隐藏数据报路由和分片与重组的细节，即提供数据报传递过程的透明性。IP是通过其独特的数据报寻址方法来实现这两个方面的功能。IP为每个网络节点设置一个逻辑地址(即IP地址)，同一个(子)网络中的节点的IP地址必须具有相同的网络标识号(NetID，即IP地址的某个前缀)，并设置路由器(或称为IP网关)节点来实现相邻网络之间的数据报转发。通过这种寻址方法，基于IP的上层协议和应用程序可以完全不用处理数据报在跨越不同网络过程中的路由和分片细节，包含无数个不同类型网络的整个互联网在IP层之上就像是一个全联通的数十亿个节点到节点的单一网络，而数据报的路由细节被完全隐藏在IP路由器的配置管理模块之中。用户和应用程序只需要给出目标节点的IP地址，就可以在源地址和目标地址之间进行数据报的传递，完全不用关心和理解网络硬件地址如何映射、网络之间如何连接、如何选取数据报传递路径等底层细节。因此，IP数据报寻址方法实现了IP网络的硬件无关性、网际互联与路由的透明性，这有效地保证了基于IP的上层协议的独立性和可移植性，并最大限度地简化了跨网络计算机通信应用程序的开发和普及。

因此，对于TCP/IP所最终实现的诸多数据报传递服务而言，由网络层协议定义的IP地址是这一整套机制的前提条件。为了使数据报跨越不同的物理(子)网络，网络层协议需要给连接在网络上的每个节点设置抽象的、与底层硬件技术无关的逻辑地址，或称为网络层地址。IP地址就是这样一种硬件无关的逻辑地址。对于上层协议和应用程序而言，网络层协议最重要的功能是数据报寻址(addressing)，即为数据报的传递确定通信两端的地址，并由此完成数据报的路由，也就是在源地址和目的地址之间选择一条合适的传递路径。因此，IP地址是实现互联网数据报寻址的核心机制，可以说IP网络是一种以逻辑地址为核心的网络(区别于以交换为中心的传统电信网络)。

具体而言，IP是通过在网络层的IP数据报头部(IP datagram header)中嵌入源地址和目的地址来实现数据报的寻址。参与数据报传递的网络节点完全根据数据报头部的地址信息来完成路由，而无需了解、维护数据报的历史或状态信息。每个被选为转发IP数据报的网络节点会接收该数据报，然后根据其头部中的目的地址所包含的信息选择传递路径，该信息即“子网标识符”(Subnet ID)或者是一组Subnet ID的共同的高位二进制数据位(称为地址“前缀”prefix)，用此信息可从该节点的路由表中选取出最合适的下一跳节点的IP地址，再利用地址解析协议(ARP)即可获得下一跳的物理地址(例如以太网接口卡的48比特MAC地址)。IP数据报由此得以在连接不同网络的网关型节点主机(即路由器)之间逐跳转发，实现跨局域网络的数据报传递。TCP/IP的网络层以IP为核心协议(还包括ICMP、IGMP等辅助协议)，其现有的标准化版本包括IPv4(Internet Protocol Version4)和IPv6(Internet Protocol Version 6)两种，二者都是利用在网络层数据报头部嵌入源地址和目的地址并按照上述方式实现寻址的。不过，IPv6使用了比IPv4更长的地址字段和不同的、不兼容的数据报头部格式。

众所周知，IPv4使用32位二进制数的地址来对互联网上各个(子)网络上的节点进行统一编号和寻址。有关IPv4地址、数据报头部格式定义和寻址方面的信息可参见文献RFC 791(见网址http://www.ietf.org/rfc/rfc0791.txt).因此，IPv4所能连接的节点数目不能超过2的32次方(近43亿个)。在互联网的早前，这个地址空间被认为是足够大的。但随着互联网应用的极为快速的发展，数以十亿计的服务器、个人计算机和其它数字化终端设备已经被连接到互联网上，并且网络节点数目的增加还有继续加速的趋势。目前，IPv4的32位地址空间中的绝大多数地址已经被申请和分配。根据不同来源的预测，可供分配的IPv4地址将在未来2至4年左右的期限内耗尽。在本说明书写作之时，尚未被分配的IPv4地址还剩下大约484,720,000个。如果按目前的平均分配速度，可估计出这些空余的IPv4地址号将在大约750天的时间内被申请完毕(参见网址http://inetcore.com/project/ipv4ec/)。这意味着在可预见的很短时间内，一些新建的子网将因为无法申请到全球唯一的IP地址而不能直接地接入互联网，可能被迫大量采用私有子网地址与网络地址和端口翻译(NAPT)的非对称接入方式。

IPv6是为了应对IPv4地址空间不足的一次较为早期的尝试，其技术标准在上个世纪90年代中期即已完成，并经历了若干调整。IPv6的基本规范参见RFC 2460(网址http://www.ietf.org/rfc/rfc2460.txt).IPv6使用了128位的定长地址，是IPv4地址长度的4倍，可以从根本上解决IPv4地址空间过小的问题。然而，IPv6却为此使用了一种全新的数据报头部格式，从而成为一个与IPv4完全不兼容的、相互独立无关的网络层协议。其关键的一个后果是：IPv4数据报不能直接在IPv6网络中传递，因而现有的所有IPv4设备和软件都必须进行升级才能连接IPv6网络；所有基于IPv4的协议、应用程序都必须重新编写和安装才能在IPv6系统上运行，而如果某些IPv4软硬件无法作升级或重写，则必须被废止。这显然是一个极为高昂的代价，在IPv6的早期设计过程中这个技术转化代价并未被充分估计和重视。自IPv6技术标准提出已经过去15年，无法向后兼容IPv4的问题一直是IPv6难以得到普遍应用的显著障碍。多年的事实表明，IPv6促进者们无法让整个互联网产业界迅速地放弃和废止在IPv4上发展起来的大量设备和应用软件。虽然诸如IPv6-IPv4双协议栈(dual-stack)系统结构、6-4地址转换(NAT 6-4，即在私网内部使用IPv6、在外部网络使用IPv4)以及其它隧道技术(IP6 over IP4)等各种复杂的过渡性技术已被提出或者仍在不断试验，但IPv6与IPv4的不兼容性是根本性的(因为二者的数据报格式不同)，短期内难以获得妥善的解决方案。因此，可预计IPv4到IPv6的升级仍然是一个长久的过程。

显然，在当前可供分配的IPv4地址日渐耗尽的时候，设计和开发一个能够与IPv4保持完全兼容、同时又具有比32位IPv4地址空间更大的网络层地址范围的互联网数据报寻址技术，将具有其现实的紧迫性和显著的实用价值。IT产业界可尽快将此技术应用到软硬件产品之中，最为优先地解决可用IPv4地址即将耗尽这个本世纪初最大的技术难题之一，同时又保持已分配的现有IPv4地址继续有效地使用、不会对现有的IPv4系统和用户造成任何影响，并极大地延长IPv4软硬件的使用时间。不过，目前这样的技术方案尚未出现。

发明内容

本发明的一个目的是提出一种改进的互联网数据报处理方法和系统，在不改动IPv4数据报头部格式的前提条件下，对IPv4数据报头部中的地址字段进行扩展，组成比32位地址更长的地址，从而在向后兼容IPv4系统的基础上能够对更大范围的逻辑地址空间进行寻址，同时还能保持正在使用的IPv4地址持久有效。

本发明的另一个目的是提出一种具有比IPv4更大地址范围的互联网数据报处理方法，它不仅兼容IPv4，而且还能直接支持包括UDP和TCP在内的基于IPv4的传输层协议，无需对它们的协议规范和实现进行改动。

本发明的再一个目的是提出一种具有比IPv4更大地址范围的互联网数据报处理方法，它支持基于IPv4 Socket API(套接字应用程序编程接口)的应用程序，使得这些已有的应用程序能够以源代码兼容和二进制代码兼容的方式在改进后的互联网数据报处理系统上正常运行。

为达到上述目的，本发明采用如下的技术方案：

一种处理互联网数据报的方法，通过使用IPv4格式的数据报头部(100)之中的地址信息在网络节点之间传递数据报文，其特征在于包括如下步骤：

检查位于IPv4数据报头部之中的一个特定的标志字段(210)，并按照如下方式处理数据报：

■如果该标志字段(210)不存在，则使用IPv4数据报头部中的32位源地址字段(120)和32位目的地址字段(130)分别作为源地址和目的地址；

■如果该标志字段(210)存在，则把IPv4数据报头部中的32位源地址字段(120)或32位目的地址字段(130)之中的至少一个与数据报头部所包含的另一个字段(230)之中的数据位结合，组成比32位更长的源地址或目的地址。

其中，所述标志字段(210)包含在数据报头部的一个特定字段(200)中，作为该字段(200)的一个组成部分(210)，并且所述用于扩展数据报头部中的源地址字段(120)或目的地址字段(130)的另一个字段为该字段(200)的另一个组成部分(230)；所述特定字段为一个专用的数据报头部选项(200)，用于扩展源地址字段(120)或目的地址字段(130)的数据位包含在所述选项数据字段(230)之中；所述选项类型字段(210)的一部分数据位(213)指示在所述选项数据字段(230)之中所包含的用于扩展源地址字段(120)或目的地址字段(130)的数据位的长度；所述选项类型字段(210)所包含一个选项类型码(212)，其数值为在IPv4中保留未用的选项类型码，即二进制数01或者11；所述选项(200)的最小长度为2字节，而最大长度为IPv4数据报选项字段(140)的最大长度，即40个字节。另外，所述源地址扩展字段(231)和目标地址扩展字段(232)分别是扩展后的位源地址和目的地址的高位数；在计算IP上层协议的校验和时，忽略所述的扩展地址字段(200)，仅使用未扩展的IPv4数据报头部的32位源地址字段(120)和目的地址字段(130)。同时，实现本方法的系统包括了执行上述步骤的指令序列的操作装置或设备，该指令序列被包含在计算机操作系统内核的处理互联网数据报的模块之中。

与现有技术对比，本发明的技术方案具备如下优点：

一个显著的优点是保持了与IPv4的完全兼容性，这表现为3个方面：(1)本发明的方法和系统可以继续处理IPv4数据报，效果与现有IPv4系统完全一样；(2)基于IPv4的上层协议(传输层协议TCP、UDP和应用层各种协议)无需修改或者只需很少修改，就可以在新的系统上使用；(3)现有的基于Socket API的应用程序无需修改，其二进制代码可以照旧使用，同时IPv4 Socket API本身只需少量地址结构的修改就可以支持新的数据报寻址方法，因而现有的大量基于IPv4 Socket API的应用程序能够以源代码兼容和二进制代码兼容的方式在本发明的系统上正常运行。

本发明的另一个积极效果是提供了逐级的、可变长度的地址扩展，具备多达19级(19个字节地址长度)的扩展能力，即从最少1+4＝5个字节的IP地址，到最长19+4＝23个字节的IP地址，共有19个扩展地址集合。而现有的IPv4地址可作为扩展级别为0的IP地址，与这19个级别的扩展地址一起，组成一个共20级的非常巨大的地址空间。这20个级别的地址集合的并集比IPv6的地址空间大得多，是一种具有更大地址扩展能力的IP地址结构。

本发明的再一个突出特性是：具有不同级别的扩展地址的网络节点之间可以直接通信，即数据报的源地址和目的地址可以是不同的扩展级别。数据报可以在0级(无扩展)地址、1至19级扩展地址的任何地址之间相互传递，因此在引入更高级别的扩展地址时，原有已分配的较低级地址仍然可用、无需变更。特别是，IPv4地址可保持永久有效，现有的IPv4地址分配和系统配置无需被废止或者进行任何变动。这是一个与IPv6相比的突出优势：现有的IPv4地址作为0级扩展地址可以同其它19级扩展地址之中的任何一级地址相互双向传送数据报，因此是完全有效的地址，故作为0级扩展地址的IPv4地址在本发明的技术方案中是永久有效的。已经分配和正在使用的IPv4地址可以永久地使用下去。而IPv6这类定长地址扩展方案要求所有节点主机永久地废弃已配置的IPv4地址。因此，本发明的这种逐级扩展、多级地址并存共用的方式能够更好地应对全球IP地址升级所必须面对的各种挑战。

本发明的再一个优点是其实现和安装部署比较简单，可以直接添加在现有操作系统内核或者设备驱动程序的代码中，其复杂性远小于实现和配置类似IPv6那样一个全新的数据报寻址处理系统。

因此，本发明的技术方案在保持了与IPv4完全兼容的同时，能够快速、有效地解决IPv4地址即将耗尽的技术难题。在实际应用中，本技术方案可望取得比包括IPv6在内的现有IPv4改进技术更佳的技术效果。

附图说明

本说明书包含12个附图。

图1是常规的IPv4数据报的头部格式示意图。

图2是本发明实施例所使用的作为IPv4数据报头部选项的地址扩展标志字段以及地址扩展部分的一种具体格式。

图3是带有本发明实施例所使用的地址扩展信息的IPv4数据报格式。

图4是实现一种在IPv4数据报头部中检查是否存在如图2和图3所示的地址扩展信息的方法的流程图。

图5是本发明实施例所使用的源地址和目的地址的扩展级别均为1的数据报。

图6是本发明实施例所使用的源地址的扩展级别为2、目的地址的扩展级别为4的数据报。

图7是本发明实施例的一种带有地址扩展标志选项的数据报，其中源地址是作为0级扩展地址的IPv4地址，而目的地址的扩展级别为1。这种类型的数据报表示源节点具有扩展地址处理能力，但目前正使用0级地址配置。

图8是另一种带有本发明实施例的地址扩展信息的数据报，其中源地址和目的地址的扩展级均别为0(即无扩展的IPv4地址)。

图9是本发明实施例的互联网数据报寻址方法的流程图。

图10是IPv4Socket API所使用的标准的套接字地址数据结构sockaddr_in{}的内存格局。

图11表示本发明对IPv4Socket API的套接字地址数据结构sockaddr_in{}的改进情况，其中增加了地址扩展信息。

图12是使用本发明所改进的Socket API套接字地址数据结构sockaddr_in{}的一个TCP客户端应用程序的C语言代码样例。

具体实施方式

下面结合附图和实施例对上述技术方案作进一步的说明。

本发明的实施例通过修改一个支持IPv4数据报处理的计算机操作系统内核而实现。经过这种改进的操作系统除了继续支持基于32位地址的IPv4数据报的收发之外，还能支持基于本发明提出的使用扩展地址的数据报处理，即本方法向后兼容IPv4。为叙述方便，本说明书以下部分在适当的语境下将本发明提出的这种使用了比32位地址更长的扩展地址、同时保持与IPv4兼容的数据报处理技术方案简称为IPv4++技术。如无需区分，术语“IP”在本说明书用中被用于指称或修饰IPv4和IPv4++的公共特征。

为实现完全的兼容性，本发明所提出的基于IPv4++扩展地址的数据报处理方法以IPv4数据报寻址方法为基础，将后者所有涉及IP地址处理的部分进行改进以支持更长的IP地址，而其它与网络地址处理无关的部分则保持不变或者维持原有的处理结果。

■IPv4数据报寻址方法

众所周知，互联网数据报的寻址完全是由IP协议确定的。IPv4给出了在32位网络地址上的数据报寻址方法。本发明的核心内容是改进IPv4的寻址方法，使之能够进一步支持在比32位地址更大的网络地址上的数据报寻址。

IPv4的寻址方法包括如下几方面的内容：网络(逻辑)地址的格式和配置方案，数据报的格式，以及对数据报进行路由的方法。本发明所提出的互联网数据报处理技术方案就是对IPv4寻址方法的这几个方面进行扩充，使其能够处理更大的逻辑网络地址，同时其它所有与IP地址无关的部分则尽量不做任何改动，使其在网络地址为32位时又能得到与IPv4的处理方法完全一致的结果。

IPv4地址格式：

如背景技术所述，IP网络是一种以硬件无关的逻辑地址为核心的网络。以逻辑地址作为抽象，互联网上层应用协议和应用程序可独立于底层的物理连接特性和通信细节，且不用操心任何两个地址之间的子网是如何互联和选路的。即使网络结构发生变化，应用程序依然可以工作。作为网络层逻辑地址的IP地址是实现TCP/IP全部机制的首要前提条件。

IPv4地址为32位整数，通常用点分十进制(dotted decimal)形式表示为a.b.c.d，即用0～255之间的十进制数分别表示一个IPv4地址的4个字节(字节顺序为big-endian方式)。IPv4地址具有一种独特的格式，以便实现子网划分的功能。IP地址的最有特色之处在于它是一个二元组结构，而不是一个简单的32位整数序号，即每个IP地址实际上是由两个字段即网络号与主机号所组成的二元组{NetID，HostID}。在同一个网段(子网)内的所有主机节点必须具有相同的NetID和不同的HostID，只有在这样配置好的网络上，主机之间才能进行IP数据报的寻址和收发：具有相同NetID地址的主机之间对数据报做直接传递(direct delivery)，而目标NetID不在本网段内的数据报则交由路由器进行间接传递，即逐跳选路(hop-by-hop routing)。一个IP地址的32位整数如何划分为两个字段{NetID，HostID}，需要使用子网掩码(Subnet Mask)来确定，因而在同一个网段内的所有主机都被配置成具有相同的子网掩码。例如，如果某个网段的子网掩码被设置为二进制111111111111 1111 1111 0000 0000 0000(通常简写成/20)，则这指明该网段内的所有IP地址的前20位为NetID，后12位为HostID.如果一个地址162.105.63.90被分配在该网段内，则可确定其NetID＝162.105.48.0，HostID＝0.0.15.90。利用NetID和子网掩码，可把该网段内的全部地址范围记为162.105.48.0/20(即CIDR记号，表示前20比特固定，用作NetID)，它对应于一个共包含2048个地址的地址块(其中HostID为全0和全1的地址保留为特殊用途)。

如何为某个网段设置子网掩码，这是由网络管理的具体配置所决定的。利用IP地址这种机制可以灵活地配置网络和主机，并提高地址范围的利用率。注意，IP数据报头部只需包括IP地址即可，无需包含源地址或者目标地址的子网掩码。这样，无论目的地址所在的网段如何划分和配置拓扑结构，其本地路由器可以随时更新对应网段的子网掩码，从而保证正确地将任意来源的数据报传递到目标IP地址所对应的主机网卡。另外，根据IPv4的地址分配模式，IPv4地址是由申请者所拥有的。如果某个机构拥有了一个IPv4地址前缀a.b.c.d/n(即一个地址块)，则该机构必须配置至少一个路由器，与其它机构的路由器连接，并通过运行某种路由协议，将其路由表的配置信息自动地传播给相邻的路由器，最终汇聚到互联网骨干路由器的路由表之中。

IPv4数据报格式：

文献RFC 791(http://www.ietf.org/rfc/rfc0791.txt)定义了IPv4数据报头部的格式，如附图1所示。该数据报头部100共包含了13个字段。前10个字段保存的信息分别为：版本、头部长度、所需服务的类型、数据报总长度、与数据报分片(fragmentation)相关的3个字段、最远可传递的节点数、负载数据中所使用的上层协议、以及整个头部的校验和110；随后的两个字段分别是发送数据报的源节点的IP地址120、数据报的目的节点的IP地址130；最后还有一个可选的选项字段(Options field)140。如所周知，IPv4数据报头部的这两个IP地址字段120、130的长度都是4个字节(即32位)。

在IPv4数据报头部的13个字段中，前12个字段的长度固定为20个字节，而最后的选项字段的长度是可变长度的，为0至40字节。正是因为选项字段的存在，IPv4数据报头部的长度在20至60字节之间可变长。源节点在发送数据报时可以在选项字段内设置一个或者多个选项，每个选项具有固定的数据格式和含义。选项字段主要用在网络测试或调试。早期引入选项字段的目的主要是为了让目的节点了解网络路径上的路况信息，即数据报所经历的路由器的有关信息。不过IP数据报头部的这些选项已很少被使用，主要问题之一是选项字段长度(40字节)太小，不足以记录当前互联网典型路径上的大量路由器的信息。更最重要的原因是很多路由器出于安全方面的配置一般不处理选项字段，或者忽略整个选项字段，或者不执行源节点在选项字段给出的大部分指令。

如下下文所述，本发明实施例将IPv4选项字段140的一部分或者全部字节用于源地址字段或者目的地址字段的扩展用途。

IPv4数据报的路由方法：

众所周知，IPv4通过在数据报头部(datagram header)中嵌入源地址和目的地址来实现数据报传递路径的逐跳选路。参与数据报传递的网络节点完全根据数据报头部的地址信息来完成路由过程，而无需了解、维护数据报的任何历史或状态信息。每个被选为转发IP数据报的网络节点(通常称为路由器)会接收该数据报，然后根据其头部中的目的地址所包含的信息选择传递路径，该信息即“子网标识符”(Subnet ID)或者是一组SubnetID的共同的高位二进制数据位(称为地址“前缀”prefix)，用此信息可从该节点的路由表中选取出最合适的下一跳节点的IP地址，再利用地址解析协议(ARP)即可获得下一跳的物理地址(例如以太网接口卡的48比特MAC地址)。IP数据报由此得以在连接不同网络或子网段的网关型节点主机(即路由器)之间逐跳转发，实现跨局域网络的数据报传递。

在实现方式上，IP网络上的每个主机节点都必须具备一个路由表，其中的每个路由表条目给出了一个地址前缀(类似162.105.48.0/20，包括一个起始地址和一个子网掩码)所对应的下一跳节点的信息，包括下一跳的IP地址、往下一跳发送数据报的本地网卡的IP地址、以及表示该下一跳节点的距离(或优先级)的某种度量值(metric)。当路由表中包括多个不同下一跳节点的条目时，距离度量有助于选择最短或最合适的路径。

■具有扩展地址的IPv4数据报的处理

本发明扩大IPv4寻址范围的总原则是尽量保持与IPv4兼容，即不改动IPv4已有的技术方案，一切改进只为把网络层地址范围扩大一些。本发明在这个兼容性约束原则下实现对IPv4寻址技术的扩展。根据这个思路，本发明的技术方案首先要求如附图1所示的IPv4数据报头部格式必须被完整地保留，在此前提条件下再考虑唯一的实质性改进，即如何把数据报头部中的两个32位的IP地址字段扩展成为更大的地址字段，同时在某个特定标志(存在与否或取值)的指示下又可去除所增加的扩展部分，回到IPv4的32位源地址和目的地址字段。

实现这个发明思路的唯一办法是在IPv4数据报头部之内引入某种标志信息，当处于IPv4兼容状态时，这个标志不存在或者其取值不造成任何不兼容性，而当地址被扩展时，该标志字段能够被显著和唯一地识别，并指明了源地址和/或目的地址所对应的扩展部分所在的字段位置及其长度。

根据本发明的优选实施方案，一种新的数据报头部选项200被引入，专门用于指示IPv4数据报头部中源地址字段或目的地址字段是否被扩展以及所扩展部分的数据位长度。本发明称这种数据报头部选项为“地址扩展选项”，它具有标准的IPv4选项的数据格式，但是使用了与现有IPv4已定义的所有选项都不同的选项类型码(Option type code).该选项不仅易于识别和计算处理，而且具备巨大的地址扩展范围。本发明使用这个实施方案实现了一个能够与IPv4保持完全的兼容性、使用可变长度的地址、具有20级地址扩展层次的网络层地址方案和数据报寻址技术。本发明选择这种地址扩展方案作为最佳实施例。与IPv4的情形对应，该方案的技术细节包括：新的扩展地址格式、地址扩展信息在IPv4数据报头部的设置方式、带有扩展地址的IPv4数据报的路由方法等几个方面，详述如下。

IPv4++扩展地址的格式：

本发明所述的“地址扩展”是指在IPv4地址的前面(高数据位)增加新的地址位，而“分级扩展”是指每次扩展只增加一个高位字节(一个8位组octet)，即每一个新增的高位地址字节表示一个地址扩展级别。在IPv4地址的后面(低位)扩展地址数据位也是可行的、可获得等价的效果，只是这种方式的新地址需要引入与IPv4有所不同的路由处理。

根据本发明的实施例，IPv4数据报头部中的32位地址字段可以被扩展到最长19个级别，其中每个扩展级别是在原有地址的最高数据位之前增加一个字节的高位地址字段。(最大扩展级别之所以是19级的原因见下文“IPv4++数据报”头部格式说明。)

本发明实施例所提供的这种地址扩展部分最长可达19个字节(152比特)，因而可形成最长23字节(184比特)的IP地址。采用类似于IPv4地址的点分十进制表示方法，可把这种最长23字节地址的每个字节表示为一个0到255之间的十进制数，并从最低位字节开始，每4个字节分成一组，各组之间用‘-’字符连接起来，表示成如下形式：

x₁₉.x₁₈.x₁₇-x₁₆.x₁₅.x₁₄.x₁₃-x₁₂.x₁₁.x₁₀.x₉-x₈.x₇.x₆.x₅-x₄.x₃.x₂.x₁-a.b.c.d

不同扩展级别的地址具有不同的长度，但任一级的扩展地址都至少包含最低一组的4个字节a.b.c.d，对应未扩展的32位IPv4地址。在32位IPv4地址的高位不断增加各个地址扩展字节x₁直到x₁₉，形成各级“扩展地址”。从x₁到x₁₉之前的任何一级x_j(j＝0..19)所组成的地址高位字段x₁...x_j为扩展级别j的“地址扩展部分”。其中，扩展级别j＝0的扩展地址就是未扩展的32位IPv4地址；扩展级别j＝1的扩展地址集合是一个40位的地址空间；扩展级别j＝2的扩展地址集合是一个48位的地址空间，等等；而扩展级别j＝19的扩展地址集合是一个184位的地址空间。

与定长的IP地址方案不同，本发明的上述20个级别的扩展地址的每一个级别所形成的IP地址(包括扩展级别为0的32位地址)都是有效的地址，可被分配给网络节点并用于IP数据报寻址(即应用在IP数据报头部的地址字段之中)。这样，本发明实施例所提供的总的IP地址空间就是由0级、1级、2级、...18级和19级扩展地址分别形成的20个子空间的并集。显然，这个地址空间比16字节的IPv6地址空间要大得多，足以应对极为久远的未来时期内互联网发展的需求。

按照IPv4地址分配规则，网络号(NetID)为0的地址表示尚未设置(或暂不关心)的网络号，保留用于动态地址配置等特殊目的，不会分配给主机节点。因此，类似如下形式的所有19个级别的地址扩展字节为0的扩展地址也都是保留地址，其中所有下标中的扩展级别数字只是作为便于阅读的提示信息：

0₁₉.0₁₈.0₁₇-0₁₆.0₁₅.0₁₄.0₁₃-0₁₂.0₁₁.0₁₀.0₉-0₈.0₇.0₆.0₅-0₄.0₃.0₂.0₁-162.105.63.90

0₁₈.0₁₇-0₁₆.0₁₅.0₁₄.0₁₃-0₁₂.0₁₁.0₁₀.0₉-0₈.0₇.0₆.0₅-0₄.0₃.0₂.0₁-162.105.63.90

.........

0₂.0₁-162.105.63.90

0₁-162.105.63.90

注意0.0-162.105.63.90(2级扩展)和0-162.105.63.90(1级扩展)分别属于不同扩展级别的地址空间，因此是两个不同的地址。同样，地址扩展字节为255的如下扩展地址也是广播保留地址：255₁₉.255₁₈.255₁₇-...-....-...-255₄.255₃.255₂.255₁-162.105.63.0。

与IPv4地址的格式一致，IPv4++扩展地址内部也是由两个部分组成：地址高位部分为一个网络地址(网络号NetID)，表示本地网络(或者子网段)在整个互联网上的一个独一无二的ID号码；地址的低位部分为一个主机号(或更准确地，为网络接口号Interface-ID)，表示在本地网络中一个主机(网卡)的唯一的逻辑地址。而一个IP地址中那些数据位是网络号是由子网掩码(作为网络管理的配置参数)决定的。本发明的扩展地址与IPv4地址的差别在于更大的子网掩码设置范围，可以提供更多的网络层次化组织。这些在内部分层划分的网络(子网段)具有相同的NetID前缀，因此在路由表中可以被汇聚成为一个路由表项。

同时，IPv4的CIDR记号也可同样用于扩展地址，例如68-162.105.80.0/8+24即68-162.105.63.0/32表示一个包含256个连续的扩展地址的地址块，其起始地址为68-162.105.80.0，终端地址为68-162.105.80.255。

带有IPv4++扩展地址的IPv4数据报格式及其地址处理：

根据本发明实施例，上述分级的可变长度的地址扩展字节是通过一种新的数据报头部选项而加入到数据报头之中的。这种选项具有标准的IPv4选项格式，但是使用了与现有IPv4已定义的所有选项都不同的选项类型码，从而能够在数据报头部中被无歧义地区分和快速识别。本发明称这种数据报头部选项为“地址扩展选项”，它明确地指示了IPv4数据报头部中源地址字段或目的地址字段之中的哪一个、或二者是否被扩展，以及源地址或目的地址的扩展部分的字节数(即扩展级别)。

附图2给出了这个“地址扩展选项”200的具体格式。这是一种使用了所谓TLV编码(Type-Length-Value encoding)的标准IPv4选项格式，即该选项由一个选项类型字节210、一个选项长度字节(整个选项的字节数)220、以及指定长度的选项数据字段230组成。根据IPv4选项规则，选项类型字节内部又被划分为3个字段：1个比特的复制标志(Copyflag)211、2比特的选项类型码(Option type/class code)212、以及余下5个比特的选项号(Option number)213。

本发明实施例地址扩展选项的“选项类型”字节210设置为二进制“111x xxxx”，其中x表示一个数值可变(0或1)的二进制数据位。该字节的3个字段的设置情况如下所述：

首先，选项类型字节的最高位是复制标志，指示在发生数据报分片时是否把整个选项(TLV三部分)复制到分片后的每一个较小的数据报的头部之中：复制标志为1表示需要这种复制，而为0则表示仅把该选项复制到分片后的第一个数据报中。显然，本发明实施例的地址扩展选项包含了源节点和/或目的节点的扩展IP地址，必须被复制到所有分片之后的数据报头部之中才能形成正确的扩展地址，故复制标志位须设为1。

其次，选项类型字节高位的第2和第3位组成一个2比特的“选项类型码”字段。目前IPv4仅定义了两个选项类型码值：00(选项用于网络控制目的)和10(选项用于调试用途)。另外两个码值01、11则被保留未用。在现有的IPv4选项中没有任何一个选项具有这两种类型码。本发明实施例的选项类型码值可选取为11。当然，取选项类型码值为10也具有完全一致的技术效果。

最后，选项类型字节的余下5个比特(即“111x xxxx”的后5位)为选项号，是一个表示某种整数值的字段，该整数的具体含义依赖于选项类型码的取值。本发明实施例将这个字段定义为“地址扩展选项”的选项数据部分所包含的源地址的扩展字节数n_s(即源地址的扩展级别)。当然，将该字段定义为目的地址的扩展字节数n_d(即目的地址的扩展级别)也是等效的。

按照上述设置，“地址扩展选项”的选项长度字节220的数值是2+n_s+n_d，其中n_s、n_d分别是源地址和目的地址的扩展级别。而“地址扩展选项”的选项数据部分230由源地址的扩展部分231与目的地址的扩展部分232串接而成，并且这两个部分的字节数分别是n_s和n_d。附图2明确地表示了上述两点。根据本发明实施例，源地址的扩展级别n_s和目的地址n_d的取值范围都是在0到19之间，分别指示源地址和目的地址的20个扩展级别。在n_s、n_d都是0的情形(0级地址扩展)，“地址扩展选项”达到其最小的长度，即2字节，此时其选项数据部分不会在该选项中出现。

通过使用上述这种“地址扩展选项”，本发明实施例的19级IPv4地址扩展部分就能被简洁、紧凑和无歧义地引入到IPv4数据报头部的选项字段中。

附图3是带有本发明实施例所使用的19级可变长的地址扩展信息的IPv4数据报的格式。通过在IPv4数据报头部的选项字段中放置上述“地址扩展选项”200，32位IPv4源地址或目的地址或两者的地址扩展部分被加入到IPv4数据报头部内，即“地址扩展选项”的选项数据字段230中。

因此，地址扩展选项的首字节(即选项类型字节)被用作一个特定的标志字段。当该标志字段存在时，数据报头部中的源地址字段或目的地址字段之中的至少一个与地址扩展选项的选项数据字段之中的数据位结合，组成比32位更长的地址，即上述分级扩展的可变长度的IPv4++地址。而当该选项类型字节不存在时，IPv4数据报头部的32位源地址字段和目的地址字段都没有被扩展。为便于描述，本说明书在下文的适当语境中将带有IPv4++扩展地址的IPv4数据报简称为“IPv4++数据报”。

根据IPv4规范，数据报头部选项字段的最大长度是40个字节，因此“地址扩展选项”的总长度满足2+n_s+n_d≤40.由于最长的扩展地址必须能够被应用在数据报收发的任意两端节点，因此源地址扩展部分的最大长度n_s-max与目的地址扩展部分的最大长度n_d-max应该相等，故n_s-max＝n_d-max＝19。这就是本发明实施例的扩展地址的最大扩展级别(地址扩展部分的字节数)为19级的原因。如附图3所示，当源地址和目的地址的扩展部分都达到19个字节时，IPv4++数据报头部选项字段全部被“地址扩展选项”200占据，此时数据报头部长度达到了最长的60字节。

上述这种利用“地址扩展选项”在数据报头部设置可分级扩展的变长IP地址的方法具备了本发明所期待的优点：它不仅实现了向后兼容IPv4的地址扩展(本发明的目的之一)，而且不会对IP层之上的传输层协议(UDP和TCP)造成影响(本发明的目的之二)。本说明书后续部分还会说明这种地址扩展方法还支持一种简单高效的兼容IPv4的SocketAPI地址扩展方案(本发明的目的之三)。同时，该地址扩展选项不仅具备巨大的地址扩展范围，而且非常易于识别和计算处理。

附图4给出了一种在IPv4数据报头部中检查是否存在上述“地址扩展选项”以及提取扩展之后的完整IP地址的操作流程图。网络节点的网络接口(网卡)在接收到一个IPv4数据报之后即启动一个预先设定的中断例程(通常为较低优先级的软件中断方式)。附图4给出的方法即可放在这个中断例程中应用。该方法的步骤如下：

■首先，步骤410检查IPv4数据报的4比特“头部长度”字段的数值是否大于5，否则不存在头部选项字段，转结束。该头部长度是以4字节为单位的，因此头部长度字段大于5表示头部至少有24字节，即包含至少一个4字节的选项字段；

■然后，步骤420在头部选项字段中查找本发明实施例的地址扩展标志字段，即一个数值为“111x xxxx”的字节，它是地址扩展选项的首字节210(选项类型字节)；

■步骤430判断该字节是否存在。如果不存在，则转结束；如果在头部选项部分找到了这个标志性字节，则在步骤440按照附图2确定的选项数据格式，取该字节的后5比特为源地址扩展部分的字节数n_s，并将该选项的总长度减去2再减去源地址扩展部分的字节数n_s之后得到目的地址扩展部分的字节数n_d；

■然后，步骤450从选项200的数据字段230中分别得到相应字节数的源地址扩展部分231和目的地址扩展部分232，分别与32位的IPv4源地址和目的地址字段组合成为更长的扩展地址。

网卡中断例程按上述方法处理完IPv4数据报中的“地址扩展选项”200之后，即调用操作系统内核中的IPv4协议处理模块，对数据报进行路由处理和IP上层协议的处理。本说明书的下文进一步说明了如何修改操作系统的IPv4协议处理模块，使之能够使用本发明实施例提供的扩展地址。

因此，从带有地址扩展信息的IPv4数据报中识别和提取扩展地址是一个简单高效的过程。本说明书的附图5至8给出了几种典型的地址扩展样例，并在其中给出了“地址扩展选项”的3个字段在各种情况下的具体取值情况。

附图5是本发明实施例所使用的源地址和目的地址的扩展级别均为1的IPv4数据报。“地址扩展选项”的首字节(即选项类型字节)的取值为二进制“1110 0001”(16进制值为0xE1)，其后5位的选项号取值为1，表示源地址的扩展长度为1个字节；整个选项的长度为4字节，故选项的第二个字节取值为二进制“0000 0100”；选项数据字段为两个字节，分别是IPv4源地址字段和目的地址字段的1个字节的扩展部分，组成了两个40位的扩展地址。

附图6是本发明实施例所使用的源地址的扩展级别为2、目的地址的扩展级别为4的IPv4数据报。“地址扩展选项”的总长度为8个字节，其3个字段分别为：“1110 0010”，“00001000”，以及2字节的源地址扩展部分和4字节的目的地址扩展部分，分别组成48位的源扩展地址和64位的目的扩展地址。

根据本发明实施例，如果源节点发出的数据报使用了没有扩展的IPv4地址，但在数据报头部设置了“地址扩展选项”，则表示源节点的数据报处理系统已经升级，同时仍然配置成为只使用IPv4地址。这里，地址扩展部分长度为0字节的扩展地址(即0级扩展地址)表现为常规的IPv4地址。

附图7是本发明实施例的一种带有地址扩展标志选项的数据报头部，其中源地址是作为0级扩展地址的IPv4地址，而目的地址的扩展级别为1。“地址扩展选项”的总长度为3个字节，并在其后附加了一个作为4字节长度补齐的全0的字节(选项字段结束标记)。其3个字段分别为：“1110 0000”，“0000 0011”，以及1字节的目的地址扩展部分，其中选项数据字段中不存在源地址的扩展字节(0级扩展)。这种类型的IP数据报表示源节点的操作系统已具备扩展地址处理能力，但目前正使用0级地址配置(例如该节点以前分配的IPv4地址)。

附图8是另一种带有本发明实施例的地址扩展信息的数据报头部，其中源地址和目的地址的扩展级均别为0(即无扩展的IPv4地址)。“地址扩展选项”的总长度为2个字节，在其后附加了两个取值为0的字节，其中前一个字节作为选项字段结束标记，后一个字节是IPv4头部填充(padding)字节。地址扩展选项的两个字段分别为：“1110 0000”，“0000010”，其中选项数据字段长度为0，因而没有出现在这个选项中。这种类型的IP数据报表示源节点的操作系统都已具备扩展地址处理能力，但与目的节点一样仍在使用作为0级扩展地址的IPv4地址配置。

由上述例子可见，IPv4++数据报的头部的最小长度为24字节，这包括如附图5、7、8所示的3种情况。而最小的地址扩展选项为2字节，对应附图8所示的在两个使用IPv4地址的IPv4++节点之间所收发的数据报。

带有IPv4++扩展地址的数据报路由处理：

基于相同的网络地址内部格式以及数据报格式的兼容性，对带有IPv4++扩展地址的IPv4数据报(IPv4++数据报)进行路由的方法与上文所述的IPv4数据报路由方法是完全一致。由于地址长度增大，用IPv4++地址查找路由表条目的速度会有不同程度的下降。不过根据IPv4++地址的分级层次化特征，路由表的组织和查找方式可获得一定的优化。由于IPv4++地址的每一个扩展级别对应一个相对独立的IP地址空间，可把各个地址级别的路由信息集中组织，以利于快速查找。

路由地址的汇聚是把路由表不同条目的IP地址前缀的公共部分提取出来，作为单一的路由表条目来查找，由此减小路由表的规模、提高路由查找的效率和IP数据报的传递速度。扩展地址的地址扩展部分可构成相对独立的地址前缀，本身就是一种路由地址汇聚机制。IPv4++的19个扩展地址级别可以支持这种地址前缀的汇聚，每一级的扩展地址都可以作为一个汇聚的层次标识符(Layer ID)。这样，每一级的扩展地址作为一个独立的地址空间可以汇聚在一起，从而缩小路由表的规模和查找范围。

根据本发明的实施例，路由表查找和缓存模块为每一个地址扩展级别都单独建立一个路由表，而对于每一个级别内的地址则使用与IPv4路由表查找算法相同的算法(LC-trie查找算法)。利用上述分层的路由汇聚，并基于这种路由表划分方法，对扩展地址的下一跳信息的查找效率可与IPv4地址的处理效率相近。

另外，附图5至8还进一步体现了本发明的技术方案对IPv4++数据报进行路由处理所具有的一个特别的功能：具有不同级别扩展地址的节点之间可以直接传递数据报，而无需借助任何类似IP-in-IP隧道、地址翻译等间接方式。尽管IP地址的长度不同，本发明的方法对不同级别的扩展地址的路由处理方式是统一的。而这个特性对于升级现有的庞大的IPv4网络具有特殊的意义。

在扩展地址的实际应用中，地址的扩展是从最低级开始逐步增加地址长度，仅当低级别的扩展地址耗尽之后，高一级的扩展地址才会被引进和分配。本发明提供的在不同级别的扩展地址之间保持直接通信功能的这个特征具有巨大的应用价值，即：引进和使用较长的扩展地址并不会使得先前已经分配和正在使用的较短的地址失去功效，——特别是，作为最小(0级)扩展级别的IPv4地址在本发明的技术方案中是永久有效的，完全没有必要被废止；仅仅只要把当前的IPv4节点所使用的互联网数据报处理软件模块做一次升级(类似操作系统的动态链接函数库文件的替换)，使之支持本发明的地址扩展方法即可。多级扩展地址可平等并存的这个技术特征是其它各种扩展IPv4的定长地址方案(例如IPv6)无法支持的。对于IPv6而言，如果要使用比IPv4更长的网络地址，就必须废止全部已分配和正在使用中的IPv4地址，并且还要弃用(升级或废弃)所有IPv4系统和设备。

本发明通过使用逐字节(分级)扩展的可变长IP地址方案实现了不同长度IP地址的并存与统一应用。利用这个特性，现有的庞大IPv4网络的地址分配现状本身无需变动或升级。相反，每个已分配的IPv4地址都不必弃用、可永久地使用下去；需要升级的只是网络主机操作系统的IP地址处理模块。因此，现有的各类计算机和各种网络设备都可维持使用当前的IPv4地址配置，而整个互联网的升级可采取逐个节点平滑升级的方式。本发明的这个技术特性为全球互联网地址空间的升级提供了一种接近最低破坏性的技术迁移模式，也是本发明相对于IPv6这类定长地址技术的一个“杀手级”优势。

从编码原理上看，本发明实施例的分级地址扩展方式与变长码格式的UTF-8字符集编码(参见RFC 3629)有类似之处。在UTF-8中，包含较多字节的UTF-8字符与包含较少字节的UTF-8字符是平等地共存和应用的，且它们的处理方法完全一致，——特别是，7位ASCII字符编码作为最短的UTF-8字符码被完整地保留，从而使得基于ASCII的大量已有的文本、数据资源、软硬件系统等都能够在UTF-8系统中继续使用。32位IPv4地址在本发明的扩展地址中的地位与ASCII码在UTF-8中的地位非常类似，被当作最短的(0级)扩展地址。IPv4地址也者类似x86微处理器指令集在x86-64指令集中的地位，即不仅被兼容地完全保留下来，而且保持永久有效，从而使得原有基于x86指令集的软件能够以二进制方式被继续使用，不会被迫废止。同时，IPv4++地址的分配策略也可类似于Unicode字符集与UTF-8字符编码的扩充策略，即按需分配、逐级扩大。

另一方面，本发明的地址扩展方法还具有一个有趣的特性，即现有的IPv4网络也可以传递带有本发明“扩展地址选项”的数据报，只是不能识别和解释其中的地址扩展信息，而是仍然只使用扩展地址的最低位4字节(即IPv4源地址和目的地址字段)来处理数据报。因此，如果在源接点或目的节点上适当地设置一批特殊的“兼容地址”，则带有IPv4++扩展地址的新数据报可以被旧的IPv4网络正确地传递。例如，可以把地址扩展部分的字节全部为0或者全部为255的各个级别的扩展地址用作这种兼容地址，包括0₁₉.0₁₈.0₁₇-...-...-...-...-a.b.c.d或255₁₉.255₁₈.255₁₇-...-...-...-...-a.b.c.d及其各个较低级的扩展地址，其中低位的4个字节都是合法的IPv4地址。当具有扩展地址处理功能的节点被设置为这种兼容地址后，即使这些节点之间存在未升级的IPv4子网段，带有地址扩展的IPv4++数据报仍然可以在这些节点之间正常传递。

综上所述，本发明实施例的数据报处理技术包括如附图9所示的步骤，其功能是对带有IPv4++扩展地址的IPv4数据报进行处理，由此实现了一个兼容IPv4的具有更大地址范围的互联网数据报处理方法。其步骤如下所述：

■首先，步骤910对节点上的数据报格式进行判别，本方法只处理IPv4格式的数据报，如果不是IPv4数据报则转结束；

■步骤920检查IPv4数据报头部的地址扩展标志字段，即在选项字段140中查找一个数值为“111x xxxx”的选项类型字节210；

■步骤930判断该标志性字节210是否存在，如不存在，则由步骤940把数据报头部中的源地址字段120和目的地址字段130都当作32位的地址；

■如果该标志字段210存在，则由步骤950找出完整的“地址扩展选项”200的其余两个字段220、230，从中提取出源地址扩展部分231和目的地址扩展部分232，然后把数据报头部中的源地址字段120或目的地址字段130与相应的地址扩展部分230之中的数据位231、232结合，组成比32位更长的扩展地址作为新的源地址或目的地址。

■最后，步骤960利用从数据报头部之中获得的上述地址信息对数据报进行路由处理和其它高层协议处理。

同时，该方法所实现的积极技术效果和优点已被列举在“发明内容”部分。

■在操作系统内核及Socket API中增加扩展地址处理

计算机操作系统通过网络协议处理模块来实现网络通信功能。网络协议处理模块通常在操作系统内核中实现，该模块的代码设计以“套接字”结构(C语言变量名通常为structsocket{})和“套接字地址”结构(C语言变量名为struct sockaddr{})为中心。每一种网络协议都有一个专门的套接字地址结构和一个套接字结构，它们通过通用类型的套接字地址结构struct sockaddr{}组成一个统一的应用程序调用接口，即通用的套接字编程接口(Socket API)。用于实现IPv4协议的套接字地址结构和套接字结构分别是structsockaddr_in{}和struct inet_sock{}.

得益于完全的IPv4兼容性，本发明实施例所提供的上述地址扩展技术方案可以很简单地被添加到现有操作系统的IPv4协议处理模块代码中，为之增加对带有分级扩展地址的IPv4++数据报处理的功能。这本质上是对现有IPv4代码进行相对简单的修改，即把与处理IPv4数据报的地址字段相关的C语言代码做一次系统化的替换式修改，而不用编写新的协议处理模块。只要把涉及32位IPv4地址的数据结构和函数修改为使用本发明实施例的20级可扩展的变长地址结构，即可实现IPv4++数据报的处理功能。相对地，由于IPv6地址无法与IPv4的套接字地址结构保持兼容，且IPv6数据报格式是重新定义的，在操作系统中增加IPv6数据报处理功能必需编写与IPv4模块独立无关的协议处理内核模块。

IPv4协议处理模块和IPv4 Socket API的中心对象是一个标准化的互联网(INET)套接字地址结构struct sockaddr_in{}。附图10是该数据结构的内存格局。该结构的长度为16个字节，但后8个字节是取值为0的填充字节，以使该结构的长度与通用的套接字地址结构struct sockaddr{}的长度相同。如附图10所示，除填充字段之外，该结构共有3个字段：一个16位字段sin_family(取值AF_INET)指示本地址族(address family)为IPv4，另一个16位字段sin_port是IP上层的传输协议(即TCP或UDP)所要使用的端口号(port number)，第三个字段sin_addr{}即32位的IPv4地址。与IPv4数据报头部字段的字节顺序一样，这3个字段都是所谓大头字节顺序(big-endian byte order)，即包含多个字节的数字的高位部分须存放在地址较低的字节内，也就是优先传送数字的高位字节。

根据本发明实施例的上述地址扩展方案，我们把附图10所示的IPv4套接字地址结构改进成为附图11所示的扩展形式，其中包括5个字段：前3个字段与IPv4的结构完全相同，从而保持了兼容性；在原来的8个0值字节填充字段的空间内增设了两个新的字段，即地址扩展级别ext_level和地址扩展部分的字节数组ext_addr[]，其中数组ext_addr[]的实际长度就是地址扩展级别ext_level。因此，ext_level字段取值为0就是“0级地址扩展”的含义，此时数组ext_addr[]的长度为0，即不存在地址扩展部分。这正是IPv4套接字地址结构所要求的取值，即ext_addr[0]为0。故附图11所示的扩展的套接字地址结构在ext_level为0时就回到了附图10所示的IPv4套接字地址结构。

在原有的IPv4套接字地址结构的16字节的空间内，地址扩展字节数组ext_addr[]的最大长度为7(包括ext_addr[0]至ext_addr[6]7个字节)，即地址扩展级别ext_level最大为7级。在实际应用中，当所有7级以内的扩展地址集合都被用完之后，可在原有IPv4套接字地址结构之后附加12个字节的填充空间(即字节ext_addr[7]至ext_addr[18])，即可实现最大为19级的地址扩展级别ext_level。

为便于说明代码编写，用C语言定义一个新的组合地址数据结构ip4pp_addr{}：

typedef struct ip4pp_addr{

uint32_t v4_addr；

uint8_t ext_level；

uint8_t ext_addr[19]；}ip4pp_addr_t；

该结构包含一个IPv4地址字段v4_addr、一个地址扩展级别字段ext_level和一个最长为19个字节的地址扩展字节数组字段ext_addr[]，这也就是把修改后的套接字地址结构struct sockaddr_in{}之中的三个关于扩展地址的字段单独组成一个数据结构。

利用如附图11所示的修改后的套接字地址结构struct sockaddr_in{}以及上述组合地址结构struct ip4pp_addr{}，可按如下步骤在现有操作系统的IPv4协议处理模块的代码中增加本发明实施例的扩展地址处理功能：

■把各个类似“uint32_t address”的4字节IPv4地址变量声明都改为以24字节的组合地址结构“ip4pp_addr_t address”为类型的变量；

■把所有带有IPv4地址参数的函数

f(uint32_t address，...)

都改为

f(ip4pp_addr_t＊address_ptr，...)

其中address_ptr是指向一个已存在的变量ip4pp_addr_t address的指针；

■把使用32位IPv4地址处理数据报路由的程序模块改为使用组合地址结构structip4pp_addr{}来组织和查找路由表，并按照前文所述的分层路由表划分和路由汇聚的方法进行优化，提高使用struct ip4pp_addr{}类型的扩展地址变量查找下一跳路由表条目的运行效率。

按照上述相对简单的改进办法，通过把IPv4模块代码中凡是涉及4字节IP地址和子网掩码的变量都替换成为上述24字节的组合地址和组合掩码变量，即可在现有操作系统内增加对带有本发明实施例的扩展地址的IP数据报的处理。所涉及的具体代码部分有：socket对象在内核中的数据结构表示，路由表结构，与socket和路由表操作相关的函数，IPv4数据报处理流程中有关IP地址、子网掩码、选项字段的处理部分等。同时，按照这个方法改进的IP协议处理模块对不带地址扩展选项的IPv4数据报的处理结果与原来的结果完全相同。

在应用程序方面，基于IPv4SocketAPI的应用程序是通过使用附图10所示的套接字地址结构struct sockaddr_in{}以及一组特定的库函数来调用操作系统内核中的IPv4协议处理模块的各种数据报处理功能。只要将套接字地址结构struct sockaddr_in{}改进为如附图11所示的带有地址扩展级别和扩展地址数组的套接字地址结构，应用程序即可使用与IPv4 Socket API相同的一组库函数来调用操作系统内核中经过上述代码修改的IPv4协议处理模块的功能，收发带有扩展地址的IPv4++数据报。因此，IPv4的SocketAPI经过非常简单的套接字地址结构的扩充就可以支持IPv4++数据报的处理。

为了在保持与IPv4 Socket API兼容的同时调用具有分级扩展地址处理功能的SocketAPI，应用程序需要遵循一个地址设置规则：在程序中无需把某个级别为j的扩展地址x_j.x_j-1.….x₁-a.b.c.d转换成为一个大的整数地址(或者j+4个字节的数组)，而总是把它的扩展地址部分x_j.x_j-1.….x₁和基本地址部分a.b.c.d分别处理，从而正确地设置如附图11所示的改进后的套接字地址结构。

附图12给出了一个使用改进后的Socket API的样例程序，它是一个以C语言编写的TCP客户端应用程序，通过设置改进的套接字地址数据结构来连接一个具有1级扩展地址“68-162.105.80.123”的Web服务器(使用TCP端口80)。程序中还列出了改进的套接字地址struct sockaddr_in{}的定义。该程序首先用服务器的地址和端口设置新的sockaddr_in{}结构，然后使用标准的Socket API函数与服务器建立TCP连接，在连接成功之后即可向服务器传递带有“地址扩展选项”的IPv4++数据报。

注意在附图12中，除了两行代码，即设置sockaddr_in{}结构中的地址扩展级别字段ext_level(第45行)和地址扩展字节数组ext_addr[]中的元素(第46行)，该程序主函数的其余部分与IPv4 Socket API程序是完全相同的。也就是说，把这两行代码除去后，函数就回到了常规的Socket API程序，从而只使用IPv4格式的数据报进行通信。而如果设置了非0数值的地址扩展级别字段ext_level，则通过同样的Socket API库函数向内核的协议处理模块传递sockaddr_in{}地址结构参数，操作系统内核就使用级别为ext_level的扩展地址，在IPv4数据报头部的选项字段中设置“地址扩展选项”，从而向目的计算机发送IPv4++数据报。因此，本发明的技术方案通过对现有IPv4 Socket API进行很小的修正即可提升各种网络应用程序的功能，使之能够在更大的IP地址范围内应用。

另一方面，保持这种与IPv4套接字地址结构兼容性的另一个显著的技术效果是：IPv4 Socket API应用程序如果是使用动态链接(dynamic linking)方式调用API库函数，则可无需任何修改就能够以二进制值代码方式正常地运行在具有IPv4++地址处理功能的IPv4协议模块上。当前主流的操作系统都以动态链接库、共享库或动态装卸模块的方式提供API库函数。因此，基于本发明的地址扩展方法的Socket API可以直接支持现有的大量IPv4应用软件和系统，实现了二进制方式的向后兼容性，能使它们继续运行、持久有效。同时，升级现有操作系统使之支持本发明的地址扩展技术也比较简单，只需更换相应的动态链接函数库文件即可。这种二进制兼容性也是本发明的方法和系统相对于其它IPv4改进技术的一个显著优势。

上述这个技术效果是IPv6无法实现的。IPv6不仅不提供二进制代码方式的兼容性，也不以源代码方式兼容现有的IPv4 Socket API应用程序。另外，目前的IPv6协议实现是与IPv4协议并列在一起，组成所谓“双IP栈”(dual IP stack)系统。在操作系统内核中，二者是两个完全独立的协议处理模块，不相干地各自运行。这种临时性的兼容系统往往会给应用程序带来大量的复杂性。例如，由于内核中的套接字数据结构只能绑定在一个协议地址结构上，如果一个服务器应用程序希望同时能够接受IPv4和IPv6连接，它就必须分别为IPv4套接字地址struct sockaddr_in{}和IPv6套接字地址struct sockaddr_in6{}各创建一个套接字，并分别绑定两种不同的套接字地址，以便能够独立地收发IPv4和IPv6数据报。这两个套接字不能发生混用例外，并且要求应用程序管理好二者的数据缓冲性质、并发连接控制、同步或者异步I/O方式、线程同步等复杂问题。

基于本发明实施例的Socket API应用程序则没有这种基于双IP栈系统的缺点，因为系统中只有一个IPv4协议栈，即经过改进而具备了扩展地址数据报处理功能的IPv4协议处理模块。由于扩展的套接字地址完全兼容IPv4套接字地址，在操作系统内核中的套接字结构实际上是被绑定在同一个套接字地址结构struct sockaddr_in{}上。在该结构中，应用程序既可以设置旧的IPv4地址，也可以设置新的分级扩展地址，系统内核会按照应用程序的设置(字段ext_level的值)自动处理相应的IP地址类型。这样，应用程序只需使用单个套接字即可同时收发IPv4数据报或IPv4++数据报。这极大地简化了IP应用系统的开发和维护。

另外，只要操作系统使用了合适的“兼容地址”作为本地网卡的IP地址，新的应用程序还可以同现有的(尚未升级的)IPv4主机通信，即发送以“0级扩展地址”为目的地址的IPv4++数据报。

■TCP/IP其余协议及应用层协议的地址扩展方法

本发明实施例的地址扩展方法实现了对IPv4网络层地址的分级扩展，有效地增大了IPv4数据报的可寻址范围。为使本发明的技术方案发挥最佳技术效果，还有必要对TCP/IP协议集合中与IPv4地址以及IP数据报处理相关的其它协议进行一定的改进或调整，使得基于TCP/IP的整个互联网能够应用本发明的地址扩展技术。本说明书在这部分对此作一简述，主要涉及如何让IPv4的主要辅助协议、传输层协议以及部分基础应用协议等三个层次的IPv4相关协议能够应用本发明的20级可扩展IP地址的功能。

本发明实施例是通过在IPv4数据报头部引入一种“地址扩展选项”而扩大了的IP数据报的寻址范围。如果要让整个网络节点设备(例如个人计算机、服务器、IP路由器、IP交换机等等)能够应用好这种扩展地址方案，则不仅要为IPv4模块本身提供IP数据报地址扩展信息处理功能，而且还要扩展与IPv4相关的其它基础协议的所用到的IP地址范围，最终让整个TCP/IP协议集合都能适应IPv4数据报寻址范围扩大带来的积极技术效果。

以一个IPv4路由器为例，当其操作系统内核中的IPv4处理模块经过上述代码修改获得了IPv4++数据报的收发和路由处理功能之后，在其IP层内还需进一步增加如下功能：

-其ARP(地址解析协议)处理模块能够支持可分级扩展的IP地址，即可以询问本子网内某个扩展IP地址所对应的MAC层地址(例如48位以太网卡地址)，并能够用自己网卡上的MAC地址答复针对其绑定的扩展IP地址的ARP查询；

-其ICMP(互联网控制消息协议)模块能够支持扩展IP地址，包括0级扩展地址；

-其IGMP(互联网组消息协议)模块能够支持扩展IP地址，包括0级扩展地址。

同时，该系统的传输层协议(即TCP和UDP)、当前运行的应用层的路由协议(例如RIP、BGP等)和若干与IP地址密切相关的应用层协议(例如DNS、DHCP等)都应能够适应这种IP层的分级地址扩展功能，同时仍然能够处理(兼容)IPv4地址。

与处理IPv4数据报的内核模块的情形类似，上述地址范围修改涉及网络节点系统的TCP/IP模块中的三个层次的协议处理模块(IP层、传输层、应用层)。原则上与IP地址相关的数据结构和函数都需要修改，而前文所述的代换式修改方法完全适用。不过，经过特定的设计，基于本发明扩展地址的IPv4数据报处理方法可以避免改动一部分协议，使得尽可能多的与IPv4相关的协议完全不受IPv4地址扩展的影响，其中最重要的部分是：传输层协议UDP和TCP可以不受IP数据报地址扩展的影响。各层相关协议的改进或调整情况分述如下。

IP层：

与IPv4直接相关的网络层协议包括IPv4的辅助协议，即ARP、RARP、ICMP和IGMP，另外还有一部分直接基于IPv4的应用相关的网络层协议，主要包括IPsec(IP层安全协议)、VPN(基于私有地址和IP-in-IP隧道的虚拟私有网络应用)、Mobile IP(IPv4的移动环境应用协议)等。

首先是与网络层地址到物理地址映射相关的协议ARP和RARP(后者目前已被DHCP取代)。ARP和RARP都是通用的协议地址解析协议，本身即可适用于任何网络层地址到物理地址的映射。因此二者本身无需修改，只需把其中有关地址映射请求和应答消息中的IP地址长度字段和IP地址字段的设置进行少量补充即可：对于IPv4地址，该地址长度字段取值为4(个字节)；而对于扩展地址，该地址长度字段取值为24，并且原IPv4地址字段的内容改为由上述struct ip4pp_addr{}所定义的24字节的组合地址数据结构。

ICMP和IGMP分别是基于IP协议的上层消息传递协议，分别辅助IPv4实现数据报传递错误报告与控制、组播(多播)成员管理。在增加对本发明的IPv4++扩展地址的支持时，凡是不涉及IP地址的ICMP和IGMP消息都不需要修改；凡是涉及到IP地址和子网掩码的消息，则所有收发IPv4++数据报的节点都使用扩展地址即可，而接收节点可通过IP头部是否使用IPv4++地址扩展选项而确定ICMP和IGMP消息中的地址是否为扩展格式。所有扩展地址字段的格式同样都是上述struct ip4pp_addr{}所定义的24字节长度的组合地址结构。

基于IPv4的IPsec、VPN和Mobile IPv4的数据报进行相似的修改即可支持扩展地址，即将它们的数据报头部和IP上层消息中的所有IP地址字段修改为级别为j＞0的扩展地址，其格式为struct ip4pp_addr{}；而当j＝0时，则保留原有的32位整数作为IP地址字段。

传输层：

互联网传输层的协议包括UDP和TCP。它们实现了基于端口号的IP地址复用，本身的数据报结构和处理过程都是与网络层相对独立的。与IP数据报有关的信息主要体现在二者所使用的伪头部中，即UDP和TCP各自都需要使用一个伪IP头部计算校验和，其中包括IPv4头部中的源地址和目的地址。目前基于IPv4的UDP和TCP都是使用32位的IP地址。

当IPv4数据报头部使用了本发明的分级扩展地址时，现有的TCP和UDP协议处理代码和驱动程序模块可通过如下一个简单的规则而避免任何修改：即完全忽略本发明设置在IPv4数据报头部选项中的地址扩展信息，此即在计算TCP或者UDP报头的校验和字段时，仅仅使用IPv4数据报头部原有的32位源地址和32位目的地址字段来组成伪IP头部，并忽略所有源地址或目的地址的扩展部分。这等价于现有的TCP和UDP处理模块对IP层的地址扩展一无所知，因而无论是否存在本发明的地址扩展选项，它们总是照旧使用IPv4数据报头部中原有的地址字段。忽略地址扩展选项所计算出来的UDP或TCP校验和依然是可靠的，因为目前所有收发IPv4数据报的节点都是按照这样的方式设置传输层的校验和字段。

应用层：

应用层协议可以只使用UDP或TCP，也可以直接使用IP(基于所谓raw socket)。这些高层协议的请求和应答消息如果没有直接涉及IPv4地址(例如HTTP、SMTP、POP3、RPC、NFS等)，则无需任何修改即可(以二进制兼容方式)运行在使用了本发明的扩展地址的主机系统上。对于与IP地址密切相关的应用层协议(例如DNS、DHCP等)，则通过与上述修改类似的地址字段扩充方式，都可适应本发明的分级扩展地址，并保持处理IPv4地址的原有功能。下面简述DNS、DHCP和部分路由协议所需的地址扩展修改。

支持IPv4地址查找的DNS经过如下两方面的改动即可支持本发明的扩展IP地址。首先，在DNS的记录中增加一个新的“资源记录类型”编号，用于指示带有本发明的分级扩展地址的DNS资源记录。这个新的类型编号名称可设为A24，表示包含了24个字节的类型为struct ip4pp_addr{}的IP地址结构。例如，以10进制表示的5字节(1级扩展)地址的DNS记录为

A24 IN 68-162.105.80.123

该记录中的1级扩展地址“68-162.105.80.123”将被转化为一个类型为structip4pp addr{}的变量并被保存在磁盘文件中。其次，在DNS规定的应答消息中，在列出某个域名的IP地址整数值的字节序列前面必须有一个16位的地址长度字段。有如下两种方式可将本发明的扩展地址应用在DNS应答消息：1、对于级别为j的扩展地址，将此字段设置为4+j+1即可，而其后的数据就是struct ip4pp_addr{}所定义的组合地址结构的前4+j+1个字节；2、将原来的32为IPv4地址字段替换为24个字节的structip4pp_addr{}地址结构，其中只使用前4+1+j个字节，因而保留了24-(4+j+1)＝19-j个未用的字节。

另外，DNS API经过简单的修改也可支持扩展的IP地址。表示域名的IPv4地址的数据结构为struct hostent{}，其中包括指向IPv4地址struct in_addr{}的指针。只要将该指针所指向的数据类型由struct in_addr{}改为组合地址struct ip4pp_addr{}即可。现有的基于struct hostent{}的DNS API函数能够以二进制兼容方式调用修改之后的DNS API函数库。同时，比较新的基于struct addrinfo{}的DNS API则无需修改即可支持本发明的分级扩展地址，因为这些API是通过使用如附图10所示的套接字地址struct sockaddr_in{}来保存IP地址的，而如前文所述(见SocketAPI扩充部分)，这个数据结构可以通过解释为如附图11所示的数据结构而存取本发明的分级扩展地址。

DHCP用于实现对某个网段内的客户机的IP地址、掩码、路由器等信息的自动配置。DHCP客户机在启动时(或者其网卡重新联通时)向本地网段广播配置请求消息，而如果本网存在DHCP服务器，则会获得返回的配置应答消息。DHCP消息的头部包含一个7位的“Unused”字段，按目前约定其所有比特都须取值为0。可从其中分配一个比特作为一个地址扩展标志位(flag bit)，例如使用其最低位作为标志位，并约定：如果该标志位为1，则所有IPv4地址字段(包括DHCP选项字段“options”中的IPv4地址字段)都被扩展成为本发明的分级扩展地址，即struct ip4pp_addr{}所定义的组合地址。通过引入这样一个较小的改动，即可让DHCP支持本发明的分级扩展IP地址的自动配置。

路由协议(Routing protocols)是路由器之间通过使用UDP或TCP或IP(Raw datagram)来相互传送各自的路由表信息的应用层协议。与上述应用层消息的地址扩展改进相似，将这些路由协议的消息之中所有涉及IPv4地址的字段都改为由struct ip4pp_addr{}所定义的组合地址结构的格式，即可使之传递基于本发明的分级扩展IP地址的路由表条目。例如，自治系统内部所使用的基于UDP的RIP路由协议在其消息中使用32位IPv4地址保存所有路由器的地址和子网掩码。当路由器操作系统升级为支持IPv4++数据报处理时，将其发送的RIP消息中的所有这些32位地址字段修改为struct ip4pp_addr{}组合地址格式，即可传递使用了扩展地址的新的路由表信息。

另外，为系统地实现高层协议对本发明的分级扩展地址的支持，可引入一个数据报的上下位相关(Context dependent)规则：如果IP数据报处理模块接收了带有地址扩展信息的IPv4++数据报，则所有基于IP的上层其它协议模块都被告知这一点(例如通过设置一个全局的标志变量)。这样可以避免在每一种应用层协议的消息头部都引入一个表示是否使用了地址扩展功能的标志字段。

■扩展IPv4地址的其它方式

本发明的上述实施例使用了一种变长的可逐级扩展的IP地址方案，但并不排除使用定长的地址方案。在上述19个级别的扩展地址中，每一级扩展地址与32位低位地址的组合都是一种定长地址，因此上述实施例实际上包含了19种定长地址方案，即长度分别为4+1、4+2、......、4+19个字节的新IP地址。另外，定长地址方案之中的第12级地址扩展(12字节的地址扩展部分加上4字节低位地址)具有128位的地址空间，可容纳IPv6所设计的地址分配方案。这也就是说，IPv6的地址空间结构可以被完全容纳在本发明的地址空间中。

本发明的上述实施例通过使用一种特殊的IPv4数据报头部选项来扩展数据报头部中的IP地址字段。但本发明的技术方案并不限于这个方式。本发明的特征是在IPv4数据报头部之内引入某种标志信息来指示地址字段是否扩展以及如何扩展。实际上还存在其它引入地址扩展标志的实施方式。例如，在IPv4数据报头部中存在着目前唯一尚未使用(保留)的字段，它只包含一个数据位，即第49位(3比特分片标记字段中的高位比特)。IPv4规范[RFC 971]要求所有的IPv4数据报头部的这个比特的数值为0。这一个数据位无法用作地址扩展字段，但可以用作一个地址扩展的标示位(flag bit)，其值为1表示数据报中的源地址和目的地址字段已被扩展，在数据报头部其它部分的字段中存在地址扩展部分的字段，此时该数据报已不是常规的32位地址的IPv4数据报。例如，可以进一步把IPv4数据报头部的16位校验和(Checksum)字段重新解释为两个8位的地址扩展字段，或者指示在数据报头部之后、负载数据之前插入新的字段作为扩展地址字段，或者指示在数据报头部选项部分内存在某种特别格式的字段包含了源地址和目的地址的扩展部分。这些方法都能够保持IPv4的兼容性。与本发明先前的实施例相比，这样获得的地址扩展能力较低(地址仅增加一个字节)，或者形成的新的数据报不再是标准的IPv4格式，或者有可能破坏IP上层的传输协议。故这些地址扩展方式可在特定条件下应用。

上述第一种地址扩展方式，即将IPv4数据报头部100的目前尚未使用的第49比特设置为1、将16位校验和字段110解释为两个8位的源地址和目的地址的扩展字节，具有保持IP数据报头部为最小(20字节)的特点。这有利于优化IP路由器或者交换机处理IP数据报的性能，同时将32位的IP地址扩大。随着网络设备性能和可靠性的不断提高，校验和的重要性已经降低，因为在绝大多数情况下的传递都是无差错的，这使得IPv4头部校验和字段不再发挥作用。而将其作为地址扩展字段后，路由器和主机都不需要再计算头部校验和，从而提高数据报处理效率。同时，保持数据报头部为20字节固定大小有助于网络硬件加快处理数据报的速度，同样有助于提高整个网络的性能。这种地址扩展方式可形成40位长度的源地址和目的地址，其寻址范围达到了IPv4地址空间的256倍，共有近1.1万亿个地址，可作为一种特殊的1级扩展地址来使用。

另外，在这个扩展地址系统上，现有的TCP和UDP模块也可以不用任何修改即可照常运行，即：在计算TCP或者UDP报头的Checksum时，可只使用IPv4数据报头部的32-bit源地址和目的地址来组成伪头部，并忽略扩充地址字节即可。因此，这种地址扩展方式也与IPv4保持了非常好的兼容性，使得IPv4地址空间成为其子集。将现有计算机操作系统中的IPv4协议驱动程序(或动态链接库)升级为这个扩展地址处理系统之后，原有的IPv4应用程序仍然可以照常使用。这种升级可简化为函数库文件的替换，而无需使用类似IPv6兼容系统所需要的双协议栈、地址转换(NAT)或者各种隧道(例如IP6 over IP4)等复杂低效和高成本的技术。

本发明的上述实施例是作为计算机操作系统的内核模块而实现的。这里所述的计算机及其操作系统都是作为广义的术语来理解，不仅仅限于个人桌面计算机或者便携式计算机，还包括各种类型的服务器系统、路由器和交换机，以及其它类型的嵌入式计算机系统、具备IP地址或IP数据报处理功能的各类数字设备。无论应用系统的具体呈现形态有何种差异性，其内部处理IP地址和IP数据报的方法都是一致的，因而都适用于本发明所提出的技术方案。

本发明的上述实施例使用了某些特定的数据结构和处理步骤，并且基于特定的应用系统而实现。但是，任何熟悉本领域背景技术的人员都清楚地知道本发明的适用范围并不局限于以这些的特定方式。本发明的技术方案还可被应用于其它多种不同的具体实施方式。本发明的权利要求书涵盖了对该技术方案的各要素的诸多变形与替换。

Claims

1.一种处理互联网数据报的方法，通过使用IPv4格式的数据报头部(100)之中的地址信息在网络节点之间传递数据报文，其特征在于包括如下步骤：

如果该标志字段(210)不存在，则使用IPv4数据报头部中的32位源地址字段(120)和32位目的地址字段(130)分别作为源地址和目的地址；

如果该标志字段(210)存在，则把IPv4数据报头部中的32位源地址字段(120)或32位目的地址字段(130)之中的至少一个与数据报头部所包含的另一个字段(230)之中的数据位结合，组成比32位更长的源地址或目的地址。

2.根据权利要求1所述的处理互联网数据报的方法，其特征在于：所述标志字段(210)包含在数据报头部的一个特定字段(200)中，作为该字段(200)的一个组成部分(210)，并且所述用于扩展数据报头部中的源地址字段(120)或目的地址字段(130)的另一个字段为该字段(200)的另一个组成部分(230)。

3.根据权利要求2所述的处理互联网数据报的方法，其特征在于：所述特定字段为一个专用的数据报头部选项(200)，包含一个选项类型字段(210)、一个选项长度字段(220)和一个选项数据字段(230)，用于扩展数据报头部中的源地址字段(120)或目的地址字段(130)的数据位包含在所述选项数据字段(230)之中。

4.根据权利要求3所述的处理互联网数据报的方法，其特征在于：所述选项类型字段(210)的一部分数据位(213)指示在所述选项数据字段(230)之中所包含的用于扩展数据报头部源地址字段(120)或目的地址字段(130)的数据位的长度。

5.根据权利要求3所述的为互联网数据报寻址的方法，其特征在于：所述选项类型字段(210)所包含一个选项类型码(212)，其数值为在IPv4中保留未用的选项类型码，即二进制数01或者11。

6.根据权利要求3所述的为互联网数据报寻址的方法，其特征在于：所述选项(200)的最小长度为2字节，而最大长度为IPv4数据报选项字段(140)的最大长度，即40个字节。

7.根据权利要求1所述的处理互联网数据报的方法，其特征在于：所述源地址扩展字段(231)和目标地址扩展字段(232)分别是扩展后的位源地址和目的地址的高位数。

8.根据权利要求1所述的处理互联网数据报的方法，其特征在于：在计算IP上层协议的校验和时，忽略所述的扩展地址字段(200)，仅使用未扩展的IPv4数据报头部的32位源地址字段(120)和目的地址字段(130)。

9.一种处理互联网数据报的系统，通过使用IPv4数据报头部(100)中的地址信息在网络节点之间传递数据报文，其特征在于包括执行如下步骤的指令序列的操作装置或设备：

10.根据权利要求9所述的处理互联网数据报的系统，其特征在于：执行所述步骤的指令序列被包含在计算机操作系统内核的处理互联网数据报的模块之中。