近日，國際互聯(lián)網(wǎng)工程任務(wù)組（也被稱為IETF）發(fā)布了一套新標(biāo)準(zhǔn)：RFC 8064，《有關(guān)穩(wěn)定IPv6接口標(biāo)識符的建議》。這個新標(biāo)準(zhǔn)正式更新了14個IETF標(biāo)準(zhǔn)，包括IPv6尋址架構(gòu)。本質(zhì)上來看，RFC 8064建議部署和使用RFC 7217以生成穩(wěn)定IPv6地址。該RFC的發(fā)布是先前IPv6尋址安全和隱私方面工作的成果，特別是RFC 7217本身，還有RFC 7707和RFC 7721。

IPv6背景知識

傳統(tǒng)算法通過無狀態(tài)地址自動配置（SLAAC）生成穩(wěn)定IPv6地址，這種算法被設(shè)計為使用底層鏈路層地址作為地址的接口標(biāo)識符來生成地址。

隨著時間的推移，人們已經(jīng)意識到通過IPv6地址執(zhí)行主機(jī)跟蹤的風(fēng)險。由于MAC地址通常為獨一無二，并且它們被嵌入在IPv6地址中，所以主機(jī)標(biāo)識符容易由IPv6地址泄漏。為了應(yīng)對這個問題，IETF發(fā)布了針對臨時地址的標(biāo)準(zhǔn)，這些臨時地址通常與傳統(tǒng)（穩(wěn)定）IPv6地址一起使用。然而，盡管臨時地址可幫助緩解主機(jī)跟蹤的特定向量，但I(xiàn)Pv6主機(jī)跟蹤的其他向量以及傳統(tǒng)地址掃描機(jī)制的漏洞等問題仍然未被解決。

IETF在IPv6地址安全和隱私方面不斷努力，最終發(fā)布了一個提案，以替代傳統(tǒng)算法來生成IPv6地址。不過，這個IPv6更新提案在相關(guān)IETF工作組（被稱為6man）被推遲。6man工作組決定將所提出的算法作為RFC7217發(fā)布，但不會正式取代傳統(tǒng)SLAAC算法。這意味著沒有正式更新IETF標(biāo)準(zhǔn)。

雖然RFC7217的發(fā)布是IPv6更新，但沒有任何標(biāo)準(zhǔn)推薦或者強(qiáng)制執(zhí)行其部署和使用，因此，當(dāng)時傳統(tǒng)SLAAC算法仍然是生成穩(wěn)定IPv6地址的推薦方法。

隨后，有關(guān)IPv6地址安全和隱私的兩個RFC的發(fā)布（即RFC 7707和RFC 7721）為IETF采取最后一步奠定了基礎(chǔ)，即讓RFC 7217中提到的算法取代傳統(tǒng)SLAAC算法。

這最終在2017年2月發(fā)布RFC 8064得以實現(xiàn)，該RFC建議部署和使用RFC 7217生成穩(wěn)定地址，并建議不要使用在IPv6地址嵌入鏈路層地址的任何地址生成機(jī)制。

語義模糊的接口標(biāo)識符

RFC 7217 IPv6更新指定了算法來生成IPv6接口標(biāo)識符（以及IPv6地址），在相同網(wǎng)絡(luò)內(nèi)穩(wěn)定，但隨著節(jié)點從一個網(wǎng)絡(luò)移動到另一個網(wǎng)絡(luò)而發(fā)生變化。該算法可用以下表達(dá)式來總結(jié)和體現(xiàn)：

IPv6_IID = Hash(Net_Prefix, Net_ID, Net_Iface_ID, Secret_Key)

其中：

Hash()：加密安全哈希函數(shù)

Net_Prefix：本地路由器發(fā)布的IPv6前綴

Net_ID：可選網(wǎng)絡(luò)標(biāo)識符，例如WiFi網(wǎng)絡(luò)的服務(wù)集標(biāo)識符

Net_Iface_ID：底層網(wǎng)絡(luò)接口的標(biāo)識符（例如網(wǎng)絡(luò)接口名稱）

Secret_Key：秘密值，通常在系統(tǒng)安裝期間作為隨機(jī)值初始化，并在重新啟動時保持不變

基本上來說，IPv6接口標(biāo)識符是通過對多個參數(shù)連接計算安全散列來獲得，最常見的是本地路由器（Net_Prefix）和秘密密鑰（Secret_Key）公布的網(wǎng)絡(luò)前綴。

只要節(jié)點保持在相同網(wǎng)絡(luò)，它將維護(hù)和配置相同的IPv6地址，這是因為散列函數(shù)的所有參數(shù)保持不變。另一方面，由于網(wǎng)絡(luò)前綴會改變，所以一旦節(jié)點連接到不同的網(wǎng)絡(luò)，IPv6接口標(biāo)識符將會改變。同時，如果節(jié)點返回到之前連接的網(wǎng)絡(luò)，它將配置與之前相同的IPv6地址，因為用于計算該IPv6接口標(biāo)識符的所有參數(shù)都將與原來情況相同。

部署IPv6更新

截至本文發(fā)稿時，至少存在以下RFC 7217部署：

Linux kernel v4.0;

NetworkManager v1.2.0-0.3.20151112gitec4d653.fc24;

dhcpcd 6.4.0; 以及

macOS Sierra.

Linux內(nèi)核部署是第一個RFC 7217部署，因此，也可作為參考部署。然而，Ubuntu以及Fedora等最受歡迎的Linux版本使用NetworkManager應(yīng)用程序包進(jìn)行網(wǎng)絡(luò)配置而部署依靠內(nèi)核。自1.2.0-0.3.20151112gitec4d653.fc2版本起，NetworkManager已經(jīng)部署RFC 7217。隨著主流Linux版本的新版本發(fā)布，所以主流版本都應(yīng)該會支持RFC 7217規(guī)定的新算法。Fedora等受歡迎的Linux發(fā)行版已經(jīng)提供默認(rèn)啟用的新算法。

在很多Linux發(fā)行版（例如Raspbian）中，dhcpcd安裝包被用于網(wǎng)絡(luò)配置。Dhcpcd自6.4.0版本就已經(jīng)支持RFC 7217，當(dāng)前版本的Raspbian已經(jīng)在默認(rèn)情況下啟用RFC 7217規(guī)定的算法。

最后，主流操作系統(tǒng)macOS Sierra也增加對RFC 7217 IPv6更關(guān)心支持，并在默認(rèn)情況下啟用該新算法。

還有一些最流行的操作系統(tǒng)最新版本也已經(jīng)支持RFC 7217，Android也將支持RFC 7217。

在筆者撰寫本文時，Microsoft Windows并不支持RFC 7217，但根據(jù)Windows中增加的很多其他安全和隱私改進(jìn)（例如MAC地址隨機(jī)化），再加上RFC 8064的共同作者隸屬于微軟的事實，微軟應(yīng)該會在未來某個時間增加對RFC 7217的支持。