一种IPv6网络中实现动态域名更新的方法

摘要

一种IPv6网络中实现动态域名更新的方法。含有3个步骤；步骤一：DHCPv6服务器与客户端主机交互分配地址阶段；步骤二：DHCPv6服务器与客户端主机交互协商域名阶段；步骤三：DHCPv6服务器与DNS服务器交互阶段；本发明技术方案使得移动IPv6用户的普通PC机在不断切换的IPv6网络中随时随地的成为一台稳定的WEB服务器或者FTP服务器。基于不断变化的网络情况，着眼于未来的移动IPv6网络，面向日益增加的移动IP用户，解决了在IPv6网络中进行动态域名解析的问题，极大的方便了用户，适用于民用和商用的IPv6网络，并且有望在未来的移动IPv6网络中得到广泛的应用。

说明书

所属技术领域

本发明涉及一种IPv6网络中实现动态域名更新的方法，属于通信技术领域。

背景技术

动态域名解析(DDNS)的实现分为两个方面，他们是域名系统(DNS)和动态主机配置协议(DHCP)。

DNS全称是域名系统(Domain Name System)，它于1984年由在美国南加州大学信息科学所负责设计新网络体系结构的Paul Mockapetris提出。DNS的原始描述是通过RFC882和883，后来被RFC1034和1035取代。实际上，DNS是一个分布式数据库，它允许对整个数据库的各个部分进行本地控制。同时，整个网络也能通过客户-服务器方式访问每个部分的数据。DNS首先将整个网络分成了若干个顶级域名，每个顶级域名再分成若干个二级域名，这样下去整个网络就形成了一个类似于树型的结构。

如图2所示，DNS树上的每一个节点都有一个标识(Label)，根节点的标识是″空″(即长度为0)，其它节点的标识的长度在1到63字节之间。一个节点的域名是由从这个节点到根节点的路径上的所有标识从左到右顺序排列组成的，标识之间用″.″分隔，例如bjtu.edu.cn。每个域都是其上级域的子域(SubDomain)，比如″.edu.cn″是″.cn″的子域，而″bjtu.edu.cn″既是″edu.cn″的子域，同时也是″.cn″的子域。

国际化组织IETF在DNS上设有两个小组，域名系统运行工作组(Domain NameSystem Operations working group)，DNS扩展工作组(DNS Extensions workinggroup)。分别就DNS系统和区域的管理、DNS系统中的服务器和服务器之间、客户和服务器之间的通信数据格式和处理制定标准。现在仍有多篇草案在讨论之中，内容涉及DNS的安全、编码、与IPv6的结合等方面。上面提到的动态域名系统(DDNS)就是在RFC2136中定义的。

可以说IPv4下的DDNS系统已经非常成熟，从今天的互联网爆炸性增长就可窥一斑，网络域名数以亿计，域名服务到处都有。DDNS研究的重点已经移到了IPv6上，涉及地址支持、传输、管理运行等。国内的研究状况与国外相似。

DHCP的全称是动态主机配置协议(Dynamic Host Configuration Protocol)，由IETF设计，目的就是为了减轻TCP/IP网络的规划、管理和维护的负担，解决IP地址空间缺乏问题。运行DHCP的服务器把TCP/IP网络设置集中起来，动态处理工作站IP地址的配置，用DHCP租约和预置的IP地址相联系，DHCP租约提供了自动在TCP/IP网络上安全地分配和租用IP地址的机制，实现IP地址的集中式管理，基本上不需要网络管理人员的人为干预。而且，DHCP本身被设计成BOOTP(自举协议)的扩展，支持需要网络配置信息的无盘工作站，对需要固定IP的系统也提供了相应支持。

IETF在DHCP上设有动态主机配置工作组(Dynamic Host Configurationworking group)。研究内容包括IPv6的DHCP、NIS、对于不同设备的扩展等。IPv6的DHCP是现在的研究热点，涉及DHCP实现，时间配置，双栈等。国内这方面的研究较少，还主要集中在IPv4方面。

动态域名解析系统(DDNS)一般由两部分构成。第一部分是DNS服务器端程序，位于DNS服务商的主机上。另一部分是DHCP服务器和客户端程序，运行在DHCP服务器主机和广大用户的主机上。在每次用户连接网络的时候，DHCP服务器程序就会通过信息传递，将动态IP地址分配给运行DHCP客户端程序的主机，同时DHCP服务器通过信息交互获取客户端主机的域名，然后DHCP服务器把该主机的动态IP地址传送给位于服务商主机上的DNS服务器程序，DNS服务器程序负责提供DNS服务并实现动态域名解析服务，收到客户端通知后，服务器程序立即更新数据，将新的IP地址和客户端主机域名绑定，这样就完成了动态域名解析的服务。别人也就可以通过域名访问用户的主机了。当用户下线时，DNS要停止该域名的解析服务，以免因为同一个IP地址重复利用而引起混乱。

与本发明相关的现有技术，IPv4网络中实现动态域名解析的方法，

现有技术的技术方案：

目前流行的DDNS解决方案是针对IPv4的，它是通过DNS程序软件与DHCPv4程序软件的交互完成的。

DHCPv4程序的运行步骤：

DHCPv4的工作原理比较简单，一共有7种报文(message)类型，不同的工作步骤由不同的报文类型承担。

第一步，DHCP客户端启动后会首先以广播形式发出DHCPDISCOVER报文到网络上，以便查找一台能够提供IP地址的DHCP服务器。

第二步，当网络上的DHCP服务器收到DHCP客户端的DHCPDISCOVER报文后，它就是由IP池中挑选一个还没有出租的IP地址，然后利用广播的方式提供给DHCP客户端。

第三步，当DHCP客户端挑选好第一个收到的DHCPOFFER报文后，它就利用广播的方式，响应一个DHCPREQUEST报文给DHCP服务器。这一步的作用是通知网络上到底哪台DHCP服务器被我选中了，服务器会检查收到的DHCPREQUEST报文，如果其中所含的地址与自己所提供的一致，证明客户选择了这台服务器，否则说明自己提供的地址被拒绝了。

第四步，DHCP服务器收到DHCP客户端的要求IP地址的DHCPREQUEST报文后，就会以广播的方式给DHCP客户端送出DHCPPACK确认报文，确认信息里包含着IP地址、子网掩码、DNS地址等信息。这一步的作用是确认，如果因为某些原因不能向客户提供这个地址，服务器就向客户发出DHCPNAK报文。

第五步，客户收到DHCPPACK确认报文后，检查内部的地址与租期，如果觉得有问题，则发送DHCPDECLINE报文拒绝这个地址，然后回到第一步重新开始。如果收到的是DHCPNAK报文则直接回到第一步。

第六步，客户端可以在租期到期之前发送DHCPRELEASE报文释放地址。

另外，客户下一次可以直接申请获得相同的IP地址，省去了前两步，直接发送DHCPREQUEST报文，其中包含自己以前用过的IP地址。如果原来的那台服务器收到，则会识别出是以前的老客户，如果以前的地址还未被使用，则用DHCPPACK报文响应，如果不是原来的服务器收到或地址已被使用，则用DHCPNAK报文回复。客户收到DHCPPACK报文后，重复第五步；收到DHCPNAK报文后重复第一步。

以上就是DHCPv4完整的工作步骤。在DHCPv4服务器完成了对客户主机的IPv4地址分配之后，会向DNS服务器发出更新报文，在rfc2136中规定了这种更新报文的格式，DNS服务器收到更新报文会加以分析，如果更新成功会向DHCPv4服务器回复确认报文，以表示更新成功。更新报文分为正向更新报文和反向更新报文两种，每种报文如果更新成功DHCPv4服务器都会收到来自DNS服务器的确认回复。

当然以上所有的操作都要在实现DNS功能的代码bind-9.2.3的配置文件named.conf和实现DHCP功能的代码dhcp-3.0.1的配置文件dhcpd.conf、dhclient.conf中做相应的设置才能成功。

这样就在IPv4地址条件下实现了动态域名解析(DDNS)。

现有技术的缺点；以上这种技术最大的缺点就是受到了IPv4地址资源有限这个问题的限制。

随着IP业务的迅速增长，IP网络上应用的不断增加，原有的IP网越来越显得力不从心。IP网络正在向下一代网络演进。其网络协议也应产生重大变化。目前使用的IP协议，IPv4是70年代制定的协议，随着全球IP网络规模的不断扩大和用户数的迅速增长，IPv4协议已经不能适应发展的需要。IPv4采用32位地址长度，只有大约43亿个地址，估计在2005～2010年间将被分配完毕，这势必影响互联网的普及和深化发展，扩大地址空间已经成为互联网发展的当务之急。90年代初，有关专家就预见到IP协议换代的必然性，提出在下一代网络中用IPv6协议取代IPv4。IPv6是1992年提出的，主要起因是由于Web的出现导致了IP网的爆炸性发展，IP网用户迅速增加，IP地址空前紧张，由于IPv4只用32位二进制数来表示地址，地址空间很小，IP网将会因地址耗尽而无法继续发展，因而IPv6首先要解决的问题是扩大地址空间，IPv6有许多优良的特性，尤其在IP地址量，安全性，服务质量，移动性等方面优势明显。采用IPv6的网络将比现有的网络更具扩展性、更安全，更容易为用户提供质量服务。现在的IPv6协议是在1995年由思科(Cisco)公司的Steve Deering和诺基亚(Nokia)公司Robert Hinden完成起草并定稿的，即RFC2460。在1998年IETF对RFC2460进行了较大的改进，形成了现有的RFC2460，1998版。IPv6的其他标准也陆续由IETF的相关工作组制定出来，现已有100多项有关IPv6的RFC制定出来。

我国在互联网领域起步较晚，目前所有的合法IPv4地址数量尚且不如美国一所大学。然而巨大的市场使得我国互联网产业发展的及其迅速，这就使得国内网络运营商深切地感到IP地址不足产生的严重制约作用，可以说现有IPv4地址的资源匮乏已经成为中国的互联网和通信行业发展的瓶颈，IPv6在我国势在必行。所以，中国是全球最关心下一代互联网发展的国家之一。

IPv6作为下一代网络的核心技术得到了国家的充分重视。中国在2003年底宣布实施由国家发改委等八部委联合领导的“中国下一代互联网示范工程CNGI”新一代互联网计划，按计划，中国将在2005年底以前投资14亿元构筑连接中国各主要城市的IPv6商用骨干网，2006年正式开始IPv6商用服务，届时将形成全球最大规模的IPv6商用网。为此，IPv6已经列入许多国内网络和通信运营商的网络规划和设备生产商的产品发展规划之中，为IPv6网络的应用提供了有利的环境。

然而，虽然在理论上IPv6可以支持很多服务(移动、安全等)，但是与IPv4已经成熟的实际应用服务的丰富多彩相比，我国针对IPv6的实际应用和相关技术却尚处在研发阶段，有些领域还是空白，运营商和设备提供方能够给用户提供的服务较之IPv4还有不小差距，这就极大的限制了IPv6网络在我国的发展和普及。也必将造成IPv6网络资源的极大浪费。成为我国下一代互联网发展的障碍。

所以，同时研发针对IPv6的相关应用技术是推广我国IPv6的发展和普及我国IPv6用户的迫切要求。

发明内容

本发明是一种建立在IPv6基础上的相关应用技术，提供了一种IPv6网络中实现动态域名更新的方法。解决了在IPv6网络中动态域名解析的问题。

本发明解决其技术问题所采用的技术方案是：一种IPv6网络中实现动态域名更新的方法，含有3个步骤：

步骤一：DHCPv6服务器与客户端主机交互分配地址阶段；

通过DHCPv6客户端与服务器的交互机制，DHCPv6客户端向服务器传递客户端主机上由用户自己定义的客户端主机名称，DHCPv6服务器向客户端传递DHCPv6服务器所在域的本地域名；

本发明方案在这一阶段中提出了两种选项类型；

步骤二：DHCPv6服务器与客户端主机交互协商域名阶段；含有以下步骤；

步骤1，客户端如果对收到Reply报文中的选项的内容表示同意，则将向服务器发送DNS-UPDATE报文；

步骤2，客户端如果不同意，则向服务器发送Reply报文，其中的选项内容与收到的一致，但是State Code选项中的字段为UnspecFail，此时，更新停止；

步骤3，如果服务器收到了DNS-UPDATE报文，则检查内部的记录，查找是否已经有其他客户端使用此名称进行了域名的更新；

步骤4，如果没有则向客户端发出Reply报文，其内容与收到的报文一致，进入步骤6；

步骤5，如果发现已经有其他客户端使用此名称进行了域名的更新，则向客户端发送Reply报文，客户端可以选择停止进行域名的动态更新或者更换主机名称并重新发送DNS-UPDATE报文(回到步骤1)；

步骤6，如果双方协商成功，则服务器将该客户端主机IP地址和域名的正向及反向映射记录下来，写入磁盘；

本发明方案在这一阶段提出了一种DHCPv6协议报文类型；

步骤三：DHCPv6服务器与DNS服务器交互阶段；含有以下步骤；

步骤1，DHCPv6服务器仍然使用DNS-UPDATE报文向DNS服务器进行域名的更新，DNS服务器收到DNS-UPDATE报文后，确定所要更新的区，DNS服务器将客户端主机的域名和IP地址的正向和反向映射写入区数据文件，成为新的记录；同时，确定该记录的生存时间，更新成功后，DNS服务器向DHCPv6服务器发送Reply报文；

步骤2，如果DNS服务器收到DNS-UPDATE报文，发现在区数据文件中已经存在一个相同的客户端主机名称的记录，DNS服务器则向DHCPv6服务器发送符合DHCPv6协议的Reply报文，DHCPv6服务器将该Reply报文不变的转发给客户端，此时就回到了步骤二，客户端可以选择停止进行域名的动态更新或者更换主机名称并重新发送DNS-UPDATE报文。

本发明方案在这一阶段提出了两种DHCPv6协议报文类型；

本发明的有益效果是随着IPv6网络的普及和个人用户需求水平的提高，越来越多的个人用户已不满足上网仅仅就是浏览网页和收发邮件，他们希望拥有自己个性化的域名、建立个人网站、搭建WEB、FTP等个人服务器，从而更好地在因特网中与人交流，更好地利用因特网展示自己，更好地通过因特网远程获取资源。但是，在很多网络中地址分配方案是动态的，用户没有固定的IP地址。这样，用户需求就没法满足。尤其是在未来的IPv6移动网络中，这个问题显得尤为突出。因为那个时候，很多用户甚至目前运行的很多服务器都将移动起来，IPv6地址的不确定性非常大。而解决这个问题，只有通过在IPv6下的动态域名更新的方法。

本发明技术方案解决了IPv6网络中动态域名解析的问题。整个过程都由设备自动完成，用户不须任何人为操作。有利于IPv6技术的推广与应用。尤其是在未来的移动IPv6网络中，本发明技术方案使得移动IPv6用户的普通PC机在不断切换的IPv6网络中成为一台稳定的WEB服务器或者FTP服务器。为移动IPv6用户带来巨大的经济效益和社会效益。

本发明技术方案基于不断变化的网络情况，着眼于未来的移动IPv6网络，面向日益增加的移动IPv6用户，解决了在IPv6网络中进行动态域名解析的问题，极大的方便了用户，适用于民用和商用的IPv6网络，并且有望在未来的移动IPv6网络中得到广泛的应用。

附图说明

图1，流程图；

图2，现有技术示意图。

具体实施方式

实施例1，一种IPv6网络中实现动态域名更新的方法以下步骤：

以下是本发明方案三个阶段工作过程的描述；

步骤一DHCPv6服务器与客户端主机交互分配地址阶段；

rfc3315规定，DHCPv6协议的报文格式为：首部4个字节，分别是1个字节的报文类型(msg-type)和3个字节的传输标识符(transaction-id)，剩下的部分全部由不同类型的选项(option)字段组成。目前根据不同的功能已经被rfc确定下来的选项(option)字段一共有29个。

本发明方案在第一阶段提出了两种选项类型：

客户主机名称选项Client Hostname Option

具体格式如下：

  0                 1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

｜        option-code          |          option-len             |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                         option-data                            |

|                     Client Hostname(20 bits)                   |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

选项码(option-code)     客户主机名称(OPTION_CLIENT_HOSTNAME)

选项长度(option-len)    20

选项数据(option-data)   即客户端主机上由用户自己定义的客户端主机

                     名称，这里规定该名称不得超过20个字母

这种选项类型的用途是在本发明方案的三个阶段，DHCPv6客户端向DHCPv6服务器以及DHCPv6服务器向DNS服务器传递客户端主机上由用户自己定义的客户端主机名称，也就是向DHCPv6服务器传递以上所提出的选项格式中option-data字段的内容。

本地域名选项Local Domain Name Option，

具体格式如下：

  0                 1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|         option-code          |           option-len           |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                         option-data                           |

|                       Local Domain Name                       |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

选项码(option-code)    本地域名(OPTION_LOCAL_DOMAIN_NAME)，

选项长度(option-len)    本地域名的实际长度，

选项数据(option-data)   本地域名的内容，

这种选项类型的用途是在本发明方案的三个阶段，DHCPv6服务器向DHCPv6客户端以及DNS服务器向DHCPv6服务器传递DHCPv6服务器所在域的本地域名，也就是向DHCPv6客户端传递以上所提出的选项格式中option-data字段的内容。

步骤二DHCPv6服务器与客户端主机交互协商域名阶段

本发明方案在这第二阶段提出一种DHCPv6协议报文类型：

DNS更新报文    DNS-UPDATE

其报文格式与rfc3315中规定的以上13种报文类型相同，如下：

  0                 1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|     msg-type  |              transaction-id                   |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                                                               |

.                           options                             .

.                          (variable)                           .

|                                                               |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

msg-type          报文类型；

transaction-id    用于报文交换的标识号；

options           选项字段，可以携带前面提到的rfc中规定的29种选项和

                  前面本发明方案提出的新的选项，以完成不同的功能；

步骤三DHCPv6服务器与DNS服务器交互阶段；

本发明方案在这第三阶段提出两种DHCPv6协议报文类型：

DNS更新延长报文  DNS-UPDATE-RENEW；

DNS更新删除报文  DNS-UPDATE-DELETE；

其报文格式与第二阶段提出的DNS更新报文一致。

实施例2，以下是本发明方案三个阶段工作过程的详细描述，

第一阶段：DHCPv6服务器与客户端主机交互分配地址阶段

DHCPv6协议一共定义有13种报文类型。其协议功能较之DHCPv4有很多扩展，但是DHCPv6协议分配地址这部分功能的工作原理大致与DHCPv4相同。

第一步，客户端主机接入网络后，如果需要一个或者多个IPv6地址，首先会发送一个Solicit报文给所有的DHCPv6服务器和中继代理，寻求可用的服务器，此Solicit报文中用Client Identifier选项字段携带标识此客户端主机的DUID。

第二步，所有收到Solicit报文的DHCPv6服务器都会回复一个Advertise报文，此Advertise报文用Server Identifier选项字段携带标识此DHCPv6服务器的DUID，而且还用Client Identifier选项字段携带标识此客户端主机的DUID。

第三步，客户端主机可能会收到多个Advertise报文，并且根据其中的Client Identifier选项字段中的DUID辨别哪些是发给自己，从中选择一个服务器并发送Request报文请求地址和一些配置信息，此Request报文用ClientIdentifier选项字段携带标识此客户端主机的DUID，而且还用ServerIdentifier选项字段携带标识被选中的DHCPv6服务器的DUID。

第四步，被选中的DHCPv6服务器，也就是收到Request报文，并且发现其中的Server Identifier选项字段中的DUID是自己的DUID的DHCPv6服务器，会发送一个Reply报文响应并提供地址和请求的配置信息。没有被选中的服务器在收到以上的Request报文后，不再做出响应。

在正常的情况下，以上四步报文的交互即可完成DHCPv6服务器对客户端主机的IPv6地址的分配工作。

如果分配的地址生存时间到期而客户仍然需要这个地址，则客户端主机需要在生存时间到期之前向分配给自己地址的DHCPv6服务器发送Renew报文请求延长生存时间和更新其他的配置参数，DHCPv6服务器会回复一个Reply报文延长该地址的生存时间并更新其他配置参数。

如果客户端主机发出了Renew报文而没有得到应有的响应(可能是丢包导致)，则客户主机会向其他所有可用的DHCPv6服务器发出Rebind报文，来请求延长生存时间和更新其他的配置参数，Rebind报文中的IA选项(可能有多个)的内容包括有目前分配给此IA的所有地址。当DHCPv6服务器(有可能还是以前给客户端主机分配地址的服务器)接收到含有IA选项的Rebind报文，它会首先鉴定收到的IA选项中的信息是否与它存储的客户信息相匹配。如果DHCPv6服务器针对收到的IA选项没有找到客户记录，则服务器认为收到的IA选项中的地址不适合于客户主机接口所连接的链路。这时DHCPv6服务器可以向客户端主机回复Reply报文，这个Reply报文中含有客户端主机发到DHCPv6服务器的IA选项，IA选项中的地址的生存时间被设为零，以明确通知客户端主机IA选项中的地址已经不再有效。在这种情况下，如果服务器没有回复Reply报文，即它丢弃了Rebind报文。如果服务器发现某些地址不适合于客户主机接口所连接的链路，则会在Reply报文中将那些地址的生存时间设为零。如果服务器找到了收到的IA选项中的地址，则它会通过Reply报文将新的生存时间和配置参数告知客户端主机。以上的过程在这个IA的所有地址的生存时间到期之后就结束了，此时，客户端主机可以选择或者重新发送Solicit报文获取新的地址，或者使用其他IA中还没有到期的地址。

如果客户端在地址生存时间之内不再需要分配的IPv6地址，则发送Release报文通知分配给自己地址的DHCPv6服务器，然后释放自己的地址，服务器收到Release报文会回复Reply报文向客户确认已收到。

如果客户端检测到有其他的节点在使用分配给自己的地址时，需要发送Decline报文通知分配给自己地址的DHCPv6服务器。DHCPv6服务器接收到Decline报文，如果检测到地址的确已经分配给其他的客户，则会回复Reply报文向客户确认已收到。

当客户端移动到一个新的链路上时，分配给连接在以前链路上的接口的地址前缀可能已经不再适合新的链路。移动到新的链路有以下几种情况：

●客户端主机重新启动时，

●客户端主机接入到有线链路上时，

●客户端主机从休眠状态苏醒时，

●客户端主机使用无线技术，改变接入点时，

无论是哪一种情况，当客户端移动到新的链路上时，客户端主机必须向所有可用的DHCPv6服务器发出Confirm报文。在发出的Confirm报文中，包含分配给客户端主机这个接口的所有IA。对此进行响应的服务器会指出这些地址是否适合于客户端主机现在所在的链路，并通过Reply报文进行响应。当服务器接收到一个Confirm报文，服务器会检测报文中的地址是否适合于客户端主机目前所在链路。如果所有的地址都通过的检测，则服务器会向客户端主机回复一个Reply报文，该报文中的Status Codes选项为Success；如果所有的地址都没有通过检测，则服务器会向客户端主机回复一个Reply报文，该报文中的Status Codes选项为NotOnLink；如果服务器无法进行这项检测，则服务器不会发出Reply报文。如果在客户端主机没有接收到任何响应，就继续使用现有的地址和其他配置参数。

以上就是DHCPv6协议主要的工作过程。

rfc3315规定，DHCPv6协议的报文格式为：首部4个字节，分别是1个字节的msg-type和3个字节的transaction-id，剩下的部分全部由不同类型的选项(option)字段组成。目前已经被rfc确定下来的选项(option)字段一共有29个(编号1-30，缺少10)。如下所示：

// RFC3315：

OPTION_CLIENTID      客户端标识符号选项      1

OPTION_SERVERID      服务器标识符号选项      2

OPTION_IA_NA         非临时地址标识联盟选项  3

OPTION_IA_TA         临时地址标识联盟选项    4

OPTION_IAADDR        标识联盟地址选项        5

OPTION_ORO           选项信息请求选项        6

OPTION_PREFERENCE    优先级选项              7

OPTION_ELAPSED_TIME  共用时选项              8

OPTION_RELAY_MSG     回复报文选项            9

OPTION_AUTH_MSG      认证选项                11

OPTION_UNICAST       服务器单播选项          12

OPTION_STATUS_CODE      状态码选项              13

OPTION_RAPID_COMMIT     快速处理选项            14

OPTION_USER_CLASS       用户组选项              15

OPTION_VENDOR_CLASS     销售方组选项            16

OPTION_VENDOR_OPTS      销售方信息选项          17

OPTION_INTERFACE_ID     接口标识符号选项        18

OPTION_RECONF_MSG       重新配置报文选项        19

OPTION_RECONF_ACCEPT    接受重新配置报文选项    20

// RFC3319：SIP servers and domains

OPTION_SIP_DOMAINS      SIP服务器域名列表选项   21

OPTION_SIP_SERVERS      SIP服务器地址列表选项   22

// RFC3646：DNS servers and domains

OPTION_DNS_RESOLVERS    DNS服务器地址选项       23

OPTION_DOMAIN_LIST      域名查询列表选项        24

 // RFC3633：Prefix options

OPTION_IA_PD            前缀授权标识联盟选项    25

OPTION_IAPREFIX         IA_PD前缀选项           26

// RFC3898：NIS options

OPTION_NIS_SERVERS      NIS服务器地址选项       27

OPTION_NISP_SERVERS     NIS+服务器地址选项      28

OPTION_NIS_DOMAIN_NAME  NIS服务器域名选项       29

OPTION_NISP_DOMAIN_NAME NIS+服务器域名选项      30

本发明方案在这第一阶段提出了两种选项类型：

客户主机名称选项Client Hostname Option，

本地域名选项Local Domain Name Option，

本阶段的交互机制和这两种选项的使用具体描述如下：如图1所示，

步骤1，客户端主机接入网络后，如果需要一个或者多个IPv6地址，首先会发送一个Solicit报文给所有的DHCPv6服务器和中继代理，寻求可用的DHCPv6服务器。

步骤2，所有收到Solicit报文的DHCPv6服务器都会回复一个Advertise报文，此Advertise报文用Server Identifier选项字段携带标识此DHCPv6服务器的DUID，而且还用Client Identifier选项字段携带标识此客户端主机的DUID。

步骤3，客户端从中选择一个服务器并发送Request报文请求地址和一些配置信息。此时，本发明方案提出如果DHCPv6客户端需要和服务器对域名进行协商，就要在这个Request报文中加入本发明方案上面所提出选项类型ClientHostname选项，此选项的内容为客户端主机上由用户自己定义的客户端主机名称(hostnamel)。

步骤4，被选中的DHCPv6服务器，也就是收到携带Client Hostname选项的Request报文的DHCPv6服务器，会发送一个Reply报文响应并提供地址和请求的配置信息，并且在Reply报文中携带Local Domain Name选项，此选项的内容为客户端主机所在域的本地域名(bjtu.edu.cn)。

在正常的情况下，以上四种报文的交互和两种新的选项的传递即可完成DHCPv6服务器对客户端主机的IPv6地址的分配和双方都得到对方关于域名的信息的工作。

本发明方案的第一阶段到此结束。

第二阶段：DHCPv6服务器与客户端主机交互协商域名阶段；

此时，地址分配的工作已经完成，而且客户端与服务器都知道了对方的和域名有关的信息，双方开始协商域名。

DHCPv6协议一共有13种报文类型，rfc3315对这13种报文类型进行了编号，并且说明了不同的工作步骤由不同的报文类型承担，如下所示：

SOLICIT              恳求报文      1

ADVERTISE            通告报文      2

REQUEST              请求报文      3

CONFIRM              确认报文      4

RENEW                刷新报文      5

REBIND               重新绑定报文  6

REPLY                回复报文      7

RELEASE              释放报文      8

DECLINE              拒绝报文      9

RECONFIGURE          重新配置报文  10

INFORMATION-REQUEST  请求信息报文  11

RELAY-FORW           传递转发报文  12

RELAY-REPL           传递回复报文  13

本发明方案在这第二阶段提出一种DHCPv6协议报文类型：

DNS更新报文    DNS-UPDATE

步骤5，DHCPv6客户端如果对收到Reply报文中的Local Domain Name选项的内容(即本地域名bjtu.edu.cn)表示同意，则将向服务器发送DNS-UPDATE报文，该报文将携带上面的Client Hostname选项和Local Domain Name选项，而且State Code选项中的status-code字段为Success。DHCPv6客户端如果不同意(可能是客户端移动到了外地网络)，则向服务器发送Reply报文其中的选项内容与收到的一致，但是State Code选项中的status-code字段为UnspecFail。此时，更新停止。

步骤6，如果服务器收到了DNS-UPDATE报文，则检查内部的记录，查找是否已经有其他客户端使用此名称(hostnamel)进行了域名的更新。如果没有则向客户端发出Reply报文，其内容与收到的DNS-UPDATE报文一致，State Code选项中的status-code字段为Success。表示DHCPv6服务器接受此名称，并将进入第二阶段的操作。如果发现已经有其他客户端使用此名称进行了域名的更新，则向客户端发送Reply报文，其选项的类型与DNS-UPDATE报文一致，但是ClientHostname选项的内容为空，而且State Code选项中的status-code字段为UnspecFail。

步骤7，客户端收到这种Reply报文后即知道了自己的名称已有人使用，这时客户端可以选择停止进行域名的动态更新或者更换主机名称(使用hostname2)并重新发送DNS-UPDATE报文。

如果双方协商成功，则DHCPv6服务器将该客户端主机IP地址和域名的正向及反向映射记录下来，写入磁盘。

当然，以上的交互过程都是在网络状况良好，报文可以正常到达目的地址的情况下进行的。

在正常的情况下，以上两种报文的交互即可完成DHCPv6服务器和客户端对客户端域名的协商工作。

本发明方案的第二阶段到此结束。

第三阶段DHCPv6服务器与DNS服务器交互阶段

此时，在DHCPv6服务器将客户端主机IP地址和域名的正向及反向映射记录下来，并且写入磁盘后，DHCPv6服务器将开始构造对本区域内的权威DNS服务器的更新报文。

本发明方案在这第三阶段提出两种DHCPv6协议报文类型：

DNS更新延长报文  DNS-UPDATE-RENEW

DNS更新删除报文  DNS-UPDATE-DELETE

本阶段交互过程如下：

步骤8，DHCPv6服务器仍然使用DNS-UPDATE报文向DNS服务器进行域名的更新。该报文携带的选项类型和各个选项的作用如下：

OPTION_CLIENTID         1

OPTION_SERVERID         2

OPTION_IA               3

OPTION_IAADDR           5

OPTION_STATUS_CODE      13

OPTION_DNS_RESOLVERS    23

OPTION_CLIENT_HOSTNAME此选项类型在本发明方案在第一阶段提出

OPTION_LOCAL_DOMAIN_NAME此选项类型在本发明方案在第一阶段提出以上选项在报文中的用途如下：

OPTION_SERVERID和OPTION_CLIENTID选项是在第一阶段中进行了交互的网络中DHCPv6服务器和客户端主机的唯一性标识。

OPTION_IA选项向DNS服务器说明了IAID。

OPTION_IAADDR选项携带了分配给客户端主机的IP地址，及其生存时间。

OPTION_STATUS_CODE选项中的status-code字段为Success。

OPTION_DNS_RESOLVERS选项中携带了本区域内的DNS服务器的IP地址。

OPTION_CLIENT_HOSTNAME选项中为客户端主机名称(hostnamel)。

OPTION_LOCAL_DOMAIN_NAME选项指出了客户端主机所在的域的本地域名(例如bjtu.edu.cn)。

步骤9，DNS服务器收到DNS-UPDATE报文后，首先根据OPTION_LOCAL_DOMAIN_NAME选项确定所要更新的区(bjtu.edu.cn)，这里注意一个DNS服务器上可能有多个区的记录，如果找到OPTION_LOCAL_DOMAIN_NAME选项中所指的区，DNS服务器根据OPTION_LOCAL_DOMAIN_NAME选项、OPTION_CLIENT_HOSTNAME选项、OPTION_IAADDR选项将客户端主机的域名(hostnamel.bjtu.edu.cn)和IP地址的正向和反向映射写入区数据文件，成为新的记录。同时，根据OPTION_IAADDR选项中客户端主机的IP地址的生存时间确定该记录的生存时间，生存时间到期后DNS服务器将删除该记录。更新成功后，DNS服务器向DHCPv6服务器发送Reply报文，其中的选项字段与其收到的DNS-UPDATE报文完全一样，这样，DHCPv6服务器就知道了DNS服务器已经收到了DNS-UPDATE报文，并且新的记录已经添加成功。

如果DNS服务器收到DNS-UPDATE报文，发现在区数据文件中已经存在一个相同的客户端主机名称的记录(hostnamel.bjtu.edu.cn到某个IPv6地址的正向和反向映射)，这种情况属于不同的用户给自己的客户端主机起了相同的名字，并且通过其他的DHCPv6服务器对DNS服务器进行了更新(DHCPv6服务器可能有多个)，注意这时相同名称的客户端的IP地址是不同的，而且其生存时间可能不同。这时，DNS服务器则向DHCPv6服务器发送符合DHCPv6协议的Reply报文，其选项的类型与DNS-UPDATE报文一致，但是Client Hostname选项的内容为空，而且State Code选项中的status-code字段为UnspecFail。

步骤10，DHCPv6服务器收到这种Reply报文后即知道了该域名已有人使用，这时DHCPv6服务器将该Reply报文不变的转发给客户端。

步骤11，客户端此时可以选择停止进行域名的动态更新或者更换主机名称并重新发送DNS-UPDATE报文，此时就回到了第二阶段的步骤5。

步骤12，如果分配的地址生存时间到期而客户仍然需要这个地址，则客户端主机需要在生存时间到期之前向分配给自己地址的DHCPv6服务器发送Renew报文请求延长生存时间和更新其他的配置参数。

步骤13，DHCPv6服务器回复一个Reply报文延长该地址的生存时间并更新其他配置参数。

步骤14，这时，DHCPv6服务器向刚才的DNS服务器发出DNS-UPDATE-RENEW报文，其中的选项字段与上面的DNS-UPDATE报文完全一样，只是地址的生存时间会有所不同。

步骤15，DNS服务器收到DNS-UPDATE-RENEW报文后，查找到区中已经存在相同的记录，而且通过OPTION_SERVERID和OPTION_CLIENTID选项知道是相同的DHCPv6服务器发出的相同客户端主机的域名和地址的映射的DNS-UPDATE-RENEW报文后，则DNS服务器将在当时的时刻相应的延长这条记录的生存时间。成功后，DNS服务器向DHCPv6服务器发送Reply报文，其中的选项字段与其收到的DNS-UPDATE-RENEW报文完全一样，只是OPTION_IAADDR选项中地址的生存时间为总时间。这样，DHCPv6服务器就知道了DNS服务器已经收到了用来延长记录生存时间的DNS-UPDATE-RENEW报文，并且记录生存时间延长成功。

如果DNS服务器收到DNS-UPDATE-RENEW报文后，但是没有查询到相应的区，或者在区中没有查到相应的原始记录，将丢弃DNS-UPDATE-RENEW报文。

步骤16，如果客户端主机在地址生存时间之内不再需要分配的IPv6地址，则发送Release报文通知分配给自己地址的DHCPv6服务器，然后释放自己的地址。

步骤17，服务器收到Release报文会回复Reply报文向客户确认已收到。

步骤18，这时，DHCPv6服务器会向DNS服务器发出DNS-UPDATE-DELETE报文，其中的选项字段与上面的DNS-UPDATE报文完全一样。

步骤19，DNS服务器收到DNS-UPDATE-DELETE报文，查到相应的记录加以删除。并且发送Reply报文加以确认。

如果DNS服务器收到DNS-UPDATE-DELETE报文后，但是没有查询到相应的区，或者在区中没有查到相应的原始记录，将丢弃DNS-UPDATE-DELETE报文。

本发明方案的第三阶段到此结束。

以上就是本发明方案的三个阶段全部过程的所有操作。根据这些操作最终实现了在DNS服务器上客户端主机域名的动态添加和删除。实现了IPv6网络中动态域名解析功能。