訂閱以接收新文章的通知:

利用 DNS 估算 IPv6 全球採用情況

2023/12/14

閱讀時間:15 分鐘
Using DNS to estimate the worldwide state of IPv6 adoption

為了使一台裝置能夠使用恰當命名的網際網路通訊協定 (IP) 與網際網路上的其他裝置進行通訊,首先必須為其指派一個唯一的數字位址。該位址的外觀取決於所使用的 IP 版本:IPv4 還是 IPv6

IPv4 於 1983 年首次部署。它是催生了現代網際網路的 IP 版本,並且至今仍然佔據主導地位。IPv6 的歷史可以追溯到 1998 年,但直到最近十年,它才開始獲得巨大的關注——從不到 1% 上升到 30% 到 40% 之間,具體取決於報告方、報告內容和測量方式。

隨著連線裝置的增長遠遠超過可用的 IPv4 位址數量,並且其成本不斷上升,IPv6 提供的更大位址空間本應該使其成為目前的主導通訊協定。然而,正如我們將看到的,事實並非如此。

Cloudflare 多年來一直是 IPv6 的堅定倡導者,並且我們一直透過 Cloudflare Radar密切關注 IPv6 在網際網路上的採用情況。Radar 已經推出三年了,仍然是一個相對較新的平台。如果要追溯到更早的時間,我們可以簡單地向 APNIC1(五個地區網際網路註冊管理機構 (RIRs)之一)的朋友求助。透過他們追溯到 2012 年的資料,我們可以看到 IPv6 在 2017 年年中之前經歷了一段看似指數級的增長期,之後進入了線性增長期,目前仍在持續:

由於兩種通訊協定之間缺乏相容性(必須同時為裝置指派 IPv4 和 IPv6 位址)以及事實上網際網路上的所有裝置仍然支援 IPv4,IPv6 的採用速度減慢了。然而,IPv6 對於網際網路的未來至關重要,因此需要繼續努力增加其部署。

Cloudflare Radar 與 APNIC 和當今大多數其他來源一樣,發佈的資料主要反映了網際網路服務提供者 (ISP) 部署 IPv6 的程度:用戶端。這是一個非常重要的角度,直接影響終端使用者,但還有等式的另一端:伺服器端

考慮到這一點,我們邀請您跟隨我們進行一個快速實驗,我們的目的是瞭解伺服器端 IPv6 的採用情況,以及用戶端實際上(或可能)能夠透過 IPv6 與伺服器通訊的頻率。我們將依靠 DNS 進行此探索,正如他們所說,結果可能會讓您感到驚訝。

用戶端的 IPv6 採用情況(來自 HTTP)

從 Cloudflare 的角度來看,截至 2023 年 10 月,整個網際網路的 IPv6 採用率約為所有流量的 36%,根據一天中的時間和一周中的日期略有變化。如果排除傀儡程式,這一估計值將上升至 46% 以上,而如果排除人類,則該估計值會下降到近 24%。這些數字指的是透過 IPv6 提供的 HTTP 請求在所有啟用 IPv6 的內容(預設設定)中所占的份額。

對於這項工作來說,最重要的是人類傀儡程式的數量。造成這兩種流量採用率差距的原因有很多——從所使用的大量用戶端軟體對 IPv6 的支援程度不同,到流量來源的眾多網路內部 IPv6 部署程度不同,再到這些網路的規模不同,等等,但這都是後話了。如果您對某個國家或網路的數據感到好奇,可以查閱 Cloudflare Radar 和我們的 2023 年度回顧報告。

等式的兩端

讀者可能會指出,對「用戶端-伺服器」等式中的「用戶端」一側進行測量,只能說明問題的一半:要讓支援 IPv6 的「用戶端」透過 IPv6 與伺服器建立連線,伺服器也必須支援 IPv6。

這就提出了兩個問題:

  1. 伺服器端採用 IPv6 的程度如何?
  2. 用戶端採用 IPv6 與伺服器採用 IPv6 的一致性如何?

有幾種可能的答案,取決於我們談論的是使用者、裝置還是傳輸的位元組數等等。我們將把重點放在連線(稍後就會明白為什麼),我們提出的綜合問題是:

在典型的使用模式下,支援 IPv6 的用戶端在連接網際網路上的伺服器時,能夠使用 IPv6 的頻率如何?

典型的使用模式包括人們每天造訪某些網站的頻率高於其他網站,或者自動用戶端呼叫 API。我們將透過 DNS 來瞭解這一點。

進入 DNS

無論是使用傳統的 IPv4 通訊協定還是更現代的 IPv6 通訊協定,用戶端在嘗試透過名稱與伺服器建立連線之前,都必須在網際網路的電話簿——網域名稱系統 (DNS)——中查找伺服器的 IP 位址。

在 DNS 中查找主機名稱是一個遞迴過程。要查找伺服器的 IP 位址,必須在多個 DNS 權威伺服器上追蹤網域階層(伺服器名稱的點分隔元件),直到其中一個伺服器傳回所需的回應。不過,大多數用戶端不會直接這樣做,而是讓一個稱為遞迴解析程式的中間伺服器代勞。Cloudflare 就營運著這樣一個任何人都可以使用的遞迴解析程式:1.1.1.1

舉個簡單的例子,當用戶端向 1.1.1.1 詢問「www.example.com」所在的 IP 位址時,1.1.1.1 會先向 DNS 根伺服器3詢問有關「.com」的資訊,然後向 .com DNS 伺服器詢問有關「example.com」的資訊,最後向 example.com DNS 伺服器詢問有關「www.example.com 」的資訊,後者直接瞭解該資訊並用 IP 位址進行答覆。為了讓下一個提出類似問題的用戶端更快地得到答案,1.1.1.1 會快取(暫時記憶)最終答案和中間的步驟。

這意味著 1.1.1.1 能夠很好地統計用戶端嘗試查找 IPv4 位址(A 類查詢)的頻率嘗試查找 IPv6 位址(AAAA 類查詢)的頻率,覆蓋了大部分可觀察到的網際網路。

但是,用戶端如何知道何時詢問伺服器的 IPv4 位址或 IPv6 位址?

簡而言之,可以使用 IPv6 的用戶端會同時請求 IPv4 和 IPv6 位址,即為它們希望連接的每台伺服器進行單獨的 AAAAA 查找。這些支援 IPv6 的用戶端在獲得非空 AAAA 答覆時將優先透過 IPv6 進行連接,無論它們是否也獲得非空 A 答覆(正如我們將看到的,它們幾乎總是會得到非空的 A 答覆)。推動這種現代性偏好的演算法被稱為 Happy Eyeballs,如果您對細節感興趣,可在此查看。

我們現在可以開始查看一些實際資料了…

用戶端的 IPv6 採用情況(來自 DNS)

第一步是透過從 1.1.1.1 的角度測量用戶端 IPv6 部署並將其與我們開始時的 HTTP 請求數量進行比較來建立基準線。

計算用戶端使用 IPv6 連接到 1.1.1.1 的頻率很有誘惑力,但由於以下幾個原因,結果會產生誤導,其中最重要的一個原因隱藏在顯而易見的地方:在用戶端可用來透過 1.1.1.1 服務執行 DNS 查找的 IPv4 和 IPv6 位址集合中,1.1.1.1 是最容易記住的位址。理想情況下,使用 1.1.1.1 作為遞迴解析程式的支援 IPv6 的用戶端應設定以下全部四個 IP 位址,而不僅僅是前兩個:

  • 1.1.1.1 (IPv4)
  • 1.0.0.1 (IPv4)
  • 2606:4700:4700::1111 (IPv6)
  • 2606:4700:4700::1001 (IPv6)

但是,當涉及手動設定時4,人類會發現 IPv6 位址不如 IPv4 位址好記,而且不太可能進行設定,因此認為 IPv4 位址就足夠了。

與此相關但不太明顯的干擾因素是,許多支援 IPv6 的用戶端即使設定了 1.1.1.1 的 IPv6 位址,仍然會透過 IPv4 執行 DNS 查找,因為分散查找可用位址是一種流行的預設選項。

從 DNS 用戶端活動評估 IPv6 採用情況的更合理方法是計算 AAAA 類型查詢占 A 類型查詢總量的百分比(假設 IPv6 用戶端始終同時執行這兩種查詢5,如前所述)。

那麼,從 1.1.1.1 的角度來看,按查詢量計算,用戶端的 IPv6 採用率估計為 30.5%。這略低於我們從 HTTP 流量中觀察到的同期資料 (35.9%),但兩種不同視角之間的差異並不出人意料。

關於 TTL 的說明

不僅遞迴解析程式會快取 DNS 回應,大多數 DNS 用戶端也有自己的本機快取。您的 Web 瀏覽器、作業系統甚至是家用路由器都會保留答案,希望能加快後續查詢的速度。

每個答案在快取中保留的時間取決於隨 DNS 記錄傳回的存留時間 (TTL) 欄位。如果您熟悉 DNS,可能會想知道 A 和 AAAA 記錄是否具有相似的 TTL。如果不相似,則對於這兩種類型種的一種,我們可能會收到更少的查詢(因為它在用戶端層級快取的時間更長),從而使最終的採用數據產生偏差。

這裡的圓形圖細分了 1.1.1.1 回應 A 和 AAAA 查詢時傳回的最小 TTL6。兩種類型之間存在一定差異,但差異很小。

伺服器端的 IPv6 採用情況

下圖顯示了 A 和 AAAA 類型查詢獲得非空回應的頻率,揭示了伺服器端的 IPv6 採用情況,讓我們更接近我們想要的答案:

按查詢量計算,伺服器採用 IPv6 的比例估計為 43.3%,明顯高於用戶端。

雙方同時接受的頻率

如果由 1.1.1.1 處理的 IP 位址查詢中有 30.5% 可以使用 IPv6 位址連接到預定目的地,但其中只有 43.3% 的查詢得到了非空回應,那麼這就為我們提供了一個很好的基礎,說明用戶端和伺服器之間的 IPv6 連線頻率大約為 13.2%

熱門網域的潛在影響

根據 Radar 前 100 清單中的網域的查詢量衡量,IPv6 伺服器端採用率為 60.8%。如果我們從整體計算中排除這些網域,之前的 13.2% 數字將下降至 8%。這是一個顯著差異,但並不意外,因為前 100 個網域占 1.1.1.1 所有 A 和 AAAA 查詢量的 55% 以上。

如果今天在這些非常受歡迎的網域中有更多部署 IPv6,那麼觀察到的採用率就會明顯提高,支援 IPv6 的用戶端使用 IPv6 建立連線的機會也會隨之增加。

結束語

觀察整個網際網路採用 IPv6 的程度可能意味著不同的事情:

  • 計算具有 IPv6 網際網路存取能力的使用者
  • 計算支援 IPv6 的裝置或這些裝置(用戶端和/或伺服器)上的軟體;
  • 計算流經 IPv6 連線的流量(以位元組為單位);
  • 計算 IPv6 連線(或單個請求)的比例。

在本次練習中,我們選擇查看連線和請求。考慮到只有從幾個不同的角度才能真正理解基本現實,我們看到了三種不同的 IPv6 採用數據:

  • 在計算 Cloudflare CDN 提供的 HTTP 請求時為 35.9%(用戶端);
  • 在計算 1.1.1.1 處理的 A 和 AAAA 類型 DNS 查詢時,為 30.5%(用戶端);
  • 對同樣來自 1.1.1.1 的 AAAA 類型 DNS 查詢的積極回復率為 43.3%(伺服器端)。

我們從 DNS 角度結合了用戶端伺服器端的數據,來估計透過 IPv6 而非 IPv4 與第三方伺服器建立連線的頻率:僅為 13.2%

要提高這些數字,ISP、雲端和託管提供者以及企業都必須提高其網路裝置的 IPv6 可用率。但是,大型網站和內容來源在使支援 IPv6 的用戶端更頻繁地使用 IPv6 方面也發揮著關鍵作用,因為在對 Radar 前 100 的網域的查詢中,有 39.2%(占 1.1.1.1 的所有 A 和 AAAA 查詢的一半以上)仍然限於僅 IPv4 的回應。

對於全面採用 IPv6 的目標,網際網路還沒有完全實現。但是,所有相關各方的持續努力可以幫助它繼續向前發展,甚至可能加速進展。

在伺服器端,Cloudflare 多年來一直透过為所有网域提供免費的 IPv6 支援來推進這項全球性的工作。在用戶端,1.1.1.1 應用程式會自動為您的装置啟用 IPv6,即使您的 ISP 不提供任何 IPv6 支援。而且,如果您碰巧管理僅 IPv6 的網路,1.1.1.1 的 DNS64 支援也可以滿足您的需求。

***
1Cloudflare 的公用 DNS 解析程式 (1.1.1.1) 與 APNIC 合作營運。您可以在原始公告部落格文章和 1.1.1.1 的隱私權原則中閱讀更多相關資訊。
2有關 DNS 如何工作的更多資訊,請參閱我們網站中的「What is DNS?」區段。如果您喜歡動手學習,我們建議您看看 Julia Evans 的「mess with dns」。
3任何遞迴解析程式都已經事先知道 13 個根伺服器的 IP 位址。Cloudflare 還透過向 E 和 F-Root 執行個體提供 Anycast 服務來參與 DNS 的最頂層,這意味著 1.1.1.1 不需要走很遠就能完成第一個查找步驟。
4使用 1.1.1.1 應用程式時,會自動設定全部四個 IP 位址。
5為了簡單起見,我們假定純 IPv6 用戶端的數量仍然少得可以忽略不計。總體而言,這是一個合理的假設,我們所掌握的其他資料集也證實了這一點。
61.1.1.1 與其他遞迴解析程式一樣,傳回調整後的 TTL:記錄的原始 TTL 減去自上次快取記錄以來的秒數。空 A 和 AAAA 答覆將按照 RFC 2308 指定的網域授權機構起始 (SOA) 記錄中定義的時間進行快取。

我們保護整個企業網路,協助客戶有效地建置網際網路規模的應用程式,加速任何網站或網際網路應用程式抵禦 DDoS 攻擊,阻止駭客入侵,並且可以協助您實現 Zero Trust

從任何裝置造訪 1.1.1.1,即可開始使用我們的免費應用程式,讓您的網際網路更快速、更安全。

若要進一步瞭解我們協助打造更好的網際網路的使命,請從這裡開始。如果您正在尋找新的職業方向,請查看我們的職缺
Cloudflare Radar (TW)IPv6 (TW)DNS (TW)繁體中文

在 X 上進行關注

Cloudflare|@cloudflare

相關貼文

2023年10月26日 下午1:00

2023 年第三季 DDoS 威脅報告

在過去的一個季度,DDoS 攻擊激增了 65%。遊戲和博彩公司受到最嚴重的攻擊,Cloudflare 緩解了數千起超流量 DDoS 攻擊。最大規模的攻擊達到了 2.01 億 rps。在過去的一個季度,DDoS 攻擊激增了 65%,而 Cloudflare 緩解了數千起針對 HTTP/2 Rapid Reset 漏洞的超流量攻擊。請閱讀我們的報告,深入瞭解各個地區和產業的最新 DDoS 攻擊趨勢...