DHCPv6服务器与客户端主机交互协商域名阶段
此时,地址分配的工作已经完成,而且客户端与服务器都知道了对方和域名有关的信息,双方开始协商域名。本文在这一阶段提出一种DHCPv6协议报文类型:DNS更新报文(DNS-UP-DATE)。
DHCPv6客户端如果对前面收到的reply报文中的本地域名表示同意,则将该服务器作为自己的域名动态更新代理,并向其发送 DNS-UPDATE报文,该报文将携带上面的客户主机名称选项和本地域名选项,而且状态码(state code)选项中的status-code 字段设为成功(success)。客户端也有可能不同意,因为此时客户端有可能移动到了外地网络,而其又不愿意改变以前所在域的本地域名。此时,客户端可以选择执行以下的操作:停止进行域名的动态更新工作;重新寻找新的DHCPv6服务器作为自己的域名动态更新代理;自己进行远程域名更新操作,即向自己移动以前的家乡域中的DNS服务器发送DNS-UPDATE报文,如图3所示。
图3域名协商
如果服务器收到了DNS-UPDATE报文,则检查内部的记录,查找是否已经有其他客户端使用此名称(hostname1)进行了域名的更新,如果没有则向客户端发出reply报文,其内容与收到的 DNS-UPDATE报文一致,state code选项中的status-code字段为success。表示DHCPv6服务器接受此名称,并得到对该客户端域名动态更新的授权,随后进入第三部分的操作。如果发现已经有其他客户端使用此名称进行了域名的更新,则向客户端发送reply报文,其内容与DNS-UPDATE 报文一致,但是客户主机名称选项的内容为服务器根据收到的客户主机名称在不产生域名冲突的情况下推荐使用的一个名称(hostname2),而且state code选项中的state-code字段为未知错误(unspecfail)。
客户端收到这种表示出现错误的reply报文后即知道了自己的名称已有人使用,这时客户端可以选择执行以下操作:停止进行域名的动态更新工作;使用服务器推荐的名称(hostname2)并重新发送DNS-UPDATE报文;更换其他主机名称(hostname3)并重新发送DNS-UPDATE报文。
如果双方协商成功,则DHCPv6服务器将该客户端主机IP地址和域名的正向及反向映射记录下来,再进入与DNS服务器进行交互的阶段。如果服务器没有收到DNS-UPDATE报文则意味着服务器没有得到客户端的域名动态更新授权" 此时该服务器将不再进行下面的操作。
这一阶段本文设计了域名协商机制来解决未来互联网将出现大量移动用户从而导致域名发生冲突的可能性很高的问题。IETE草案规定通过域名更新发起者(可以是DHCPv6客户端或者服务器)和DNS服务器进行报文交互来处理域名冲突的问题,而本文提出的方案在第二阶段,也就是 DNS服务器参与更新操作之前,就由DHCPv6客户端和服务器双方对域名进行协商来处理域名冲突的问题 这就降低了第三阶段再发生域名冲突的可能,也就减轻了DNS服务器的负担。较之 IETE草案,本文提出的方案将草案中DNS服务器与域名更新发起者对域名冲突问题的处理很大程度上转移到了域名协商阶段,可以极大地减小DNS服务器上出现域名冲突的可能性,从而优化了整个更新过程,提高了效率。另外,提出了更新代理的概念,只有得到客户端授权的服务器才能进行客户端域名的动态更新,简化了IETE草案中关于谁进行更新操作的讨论,使得更新过程更加可靠。
责任编辑:小草