進行DHCP IPV6連接的時候，經常遇到設備獲取過一次地址后，在短時間內再次重新主動進行一次DHCP IPV6連接，會連接失敗，從抓包來分析就是上行服務器不響應。

?通過與服務器方的溝通，了解到一點，服務器會記錄請求設備的mac和DUID（是唯一標識一臺DHCPv6設備(包括客戶端、中繼和服務器)的標識符,用于DHCPv6設備之間的相互驗證），發現的設備DUID會一直變動，導致校驗失敗，所以服務器就不響應了。

找到原因，接下來就到了分析源碼的時候了：

/** 2 bytes for the 'duid type' field.* 2 bytes for the 'htype' field.* (not stateless) 4 bytes for the 'current time'.* enough bytes for the hardware address (note that hw_address has* the 'htype' on byte zero).*/len = 4 + (ip->hw_address.hlen - 1);if (duid_type == DUID_LLT)len += 4;if (!buffer_allocate(&duid->buffer, len, MDL))log_fatal("no memory for default DUID!");duid->data = duid->buffer->data;duid->len = len;/* Basic Link Local Address type of DUID. */if (duid_type == DUID_LLT) {putUShort(duid->buffer->data, DUID_LLT);putUShort(duid->buffer->data + 2, ip->hw_address.hbuf[0]);putULong(duid->buffer->data + 4, cur_time - DUID_TIME_EPOCH);memcpy(duid->buffer->data + 8, ip->hw_address.hbuf + 1,ip->hw_address.hlen - 1);} else {putUShort(duid->buffer->data, DUID_LL);putUShort(duid->buffer->data + 2, ip->hw_address.hbuf[0]);memcpy(duid->buffer->data + 4, ip->hw_address.hbuf + 1,ip->hw_address.hlen - 1);}

這里就是填充DUID字段的地方，發現DUID有兩種類型，一種是LL類型，也就是Link-Layer Address，DUID填充內容為設備mac地址；另外一種就是LLT類型，也就是Link-Layer Address Plus Time，DUID填充內容為設備地址加上時間。前面報文中的設備使用的就是LLT類型DUID，加上了4字節的當前時間，所以肯定每次DHCP IPV6請求的DUID字段內容就會不同。

所以針對會校驗 DUID的服務器，我們就需要將DUID類型改變為LL，即字段內容為設備mac地址，這樣就保證了每次的請求DUID都相同了。

一般的開源DHCPv6代碼，DUID類型都是可以通過參數可配置的，所以啟動時加上使用LL類型的DUID參數即可，修改后的DUID如下圖報文所示：

總結

以上是生活随笔為你收集整理的记录DHCP IPV6遇到的问题（一）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。