在大規模的操作下，IP 位址扼殺了網路和 Web 導向服務中的創新。在每次架構變更以及開始設計新的系統時，我們不得不提出的第一組問題是：
我們會使用或可以使用哪個 IP 位址區塊？
我們是否有足夠的 IPv4？如果沒有，可以在哪裡取得或如何取得？
我們如何使用 IPv6 位址？這是否會影響 IPv6 的其他使用情況？
噢，還有我們遷移時需要什麼樣的仔細計畫、檢查、時間和人員？
為了擔心 IP 位址而暫停工作，很耗費時間、金錢、資源。乍聽之下，這件事可能很令人驚訝，因為具有前瞻性且靈活的 IP早在 40 多年前就出現了。具有獨特的設計的 IP 位址，應該是任何網路最不需要擔心的一個項目。不過，網際網路教會我們，往往微小或看似不重要的弱點 (通常在設計時不會注意到或不可能注意到)，總是會在規模達到一定程度時出現。
我們都知道：「更多位址」絕對不會是答案。在 IPv4 中，這樣的思考類型只會造成位址缺乏，進一步推升其市場價格。IPv6 絕對有必要，但僅僅是解決方案的一部分。例如，在 IPv6 中，最佳做法顯示，僅供個人使用的最小分配是 /56 -- 亦即 272 或大約 4,722,000,000,000,000,000,000 個位址。我當然無法理解這麼龐大的數字。您能理解嗎？
在這篇部落格貼文中，我們將解釋 IP 定址為什麼會是 Web 服務 (潛在原因) 的問題，然後描述我們稱為定址靈活度的創新解決方案，以及我們學到的經驗。最棒的部分是，可能是因為定址靈活度而得以運作的新系統和架構種類。完整詳情可見於 ACM SIGCOMM 2021 最近的論文。作為預覽，以下是我們學到的一些內容摘要：
這是真的！對於可以顯示在任何單一位址上的名稱數量沒有限制；任何名稱的位址可以隨著每次新的查詢_在任何地方_變更；而且可以基於任何原因進行位址變更，可能是服務佈建或是政策或效能評估，或其他我們尚未遇到的原因……
以下說明了這一切能夠成真的原因、我們實現的方式，以及這些經驗對於_任何規模_的 HTTP 和 TLS 服務都很重要的原因。我們所根據的關鍵洞見：在網際網路通訊協定 (IP) 設計方面，很像全球郵政系統，位址從來不需要、不應需要、也絕對不需要呈現名稱。我們只是有時候將位址視為呈現了名稱。而這項方案則顯示所有名稱應分享所有位址、任何位址集合或甚至只是一個位址。
狹窄的中段是個漏斗，但也是個阻塞點
數十年的舊有慣例不自然地將 IP 位址綁定到名稱和資源。這可以理解，因為驅動網際網路的架構和軟體已從一台電腦具有一個名稱和 (通常) 一個網路介面卡的狀態進化了。接著，網際網路自然會演進成一個 IP 位址會與名稱和軟體處理序有關。
在很少需要名稱、更不需要接聽處理序的最終用戶端和網路廠商當中，這些 IP 繫結造成的影響很小。不過，名稱和處理序慣例對_所有_內容裝載、發佈和內容服務提供者 (CSP) 造成了強烈限制。一旦指派到名稱、介面和通訊端，位址大部分就會變成靜態，需要花費心力謹慎規畫變更 (如果可能變更)。
IP 的「狹窄中段」讓網際網路能夠運作，但就像 TCP 一直用來傳輸通訊協定、HTTP 傳輸應用程式通訊協定一樣，IP 成了扼殺創新的瓶頸。在下圖描述的想法中，我們看見獨立的通訊繫結 (含有名稱) 和連線繫結 (含有介面和通訊端) 在彼此之間建立了可轉移的關係。
可轉移的鎖定很難中斷，因為變更任一項會對另一項造成影響。此外，服務提供者通常使用 IP 位址呈現本身獨立於名稱存在的政策和服務層級。最終，IP 繫結成了又一項需要考慮的事項而且還沒有充分理由。
現在以另一種方式來看待這件事。思考新的設計、新的架構或更好的資源分配時，第一組問題不應該是「我們使用哪些 IP 位址？」或「我們對此是否有 IP 位址？」像這樣的問題及其答案會延緩開發和創新。
我們意識到 IP 繫結不僅是人工性質，而且根據原本前瞻性的 RFC 和標準，這也不正確。實際上，IP 位址代表連線性以外的任何內容這樣的概念，與其原本的設計背道而馳。在原始的 RFC 和相關草稿中，架構是明確的，亦即「名稱、位址和路由之間有差異。名稱指示我們尋求的內容。位址指示所在位置。路由指示如何抵達該處。」任何與較高層級通訊協定中的 SNI 或 HTTP 主機等資訊 IP 的關聯明顯違反了分層原則。
當然，我們的工作完全不是隔絕一切而存在，而是完成了長期的演進過程，以從使用慣例中解耦 IP 位址。這段演進是站在巨人的肩膀上所達成。
演進過程……
回顧過去 20 年，很容易看見對於定址靈活度的要求已經出現了一段時間，同時也是 Cloudflare 深入投資的一件事。
IP 和網路卡介面之間數十年來舊有的一對一繫結在幾年前第一個被中斷，當時 Google 的 Maglev 結合了等價多路徑 (ECMP) 並持續從許多伺服器當中的某個「虛擬」IP 位址散佈流量。離題一下，根據原本的網際網路通訊協定 RFC，這種 IP 使用方式受到禁止，對此也沒有任何虛擬性質。
許多類似的系統自此在 GitHub、Facebook 和其他地方合併，包括我們自己的 Unimog。最近，Cloudflare 設計了新的可程式化通訊端架構，稱為 bpf_sk_lookup，用來從通訊端和處理序解耦 IP 位址。
**但是這些名稱又會如何？**1997 年，HTTP 1.1 將主機欄位定義為必填，這時鞏固了「虛擬主機」的價值。這是官方首次認可多個名稱可以共存於單一 IP 位址，而且有必要由 TLS 在伺服器名稱指示欄位中複製。這些是絕對需求，因為可能的名稱數量大於 IP 位址的數量。
……顯示靈活的未來
展望未來，莎士比亞的問題很有智慧：「名稱又能代表什麼？」如果網際網路可以說話，那麼可能會說：「名稱標上了另一個位址，仍然可以連線。」
如果莎士比亞改問：「位址又能代表什麼？」則網際網路可能會有類似的答案：「位址標上了另一個名稱，也仍然可以連線。」
從這些答案的真相中，浮現出強烈的含意：名稱和位址之間的對應是任意性質。若這是真的，則只要名稱可以在某個位址連線，任何位址都能用來連線名稱。
實際上，許多位址用於一個名稱的版本已自 1995 年連同 基於 DNS 的負載平衡的推出開始提供使用。那麼，為什麼不是所有位址用於所有名稱，或任何位址在任何指定時間用於所有名稱？或者，如同我們很快就會發現的情況：一個位址用於所有名稱！但首先，先來談談達成定址靈活度的方式。
達成定址靈活度：忽略名稱，對應政策
定址靈活度的關鍵是權威 DNS，但並不是儲存在某些形式的記錄或查閱表格中的靜態名稱與 IP 對應。考慮到任何用戶端的觀點，繫結僅「在查詢時」出現。對於所有實際的對應使用情況，查詢的回應是整個請求過程中最後可讓名稱繫結到位址的時刻。
這讓人觀察到，名稱對應不是在某些記錄或區域檔案中進行，而是在傳回回應的時刻實際進行。這當中的差別很細微，但卻是重要的差異。現今的 DNS 系統使用名稱查閱一組位址，接著有時候會使用某個政策來決定要傳回哪個特定位址。這個想法以下圖顯示。查詢抵達時，查閱會揭露與該名稱有關聯的位址，然後傳回其中一個或多個位址。通常，其他政策或邏輯篩選條件會用來縮小位址選項，例如服務層級或地理區域涵蓋範圍。重要的細節是，會先以名稱識別位址，之後才會套用政策。
(a) 傳統的權威 DNS
(b) 定址靈活度
可透過反轉此關係來達到定址靈活度。我們的架構不使用預先指派到名稱的 IP 位址，而是以可能包括 (或在我們的案例中有可能不包括) 名稱的政策開始。例如，政策可能以屬性呈現，例如位置和帳戶類型，並忽略名稱 (我們在部署中已這麼做)。屬性識別與該政策有關聯的位址集區。該集區本身可能與該政策隔離，或具有與其他集區和政策共用的元素。此外，該集區中的所有位址都相等。這表示，可以傳回其中任何位址，或甚至可以隨機選取位址，不必檢查 DNS 查詢名稱。
現在暫停一下，因為有兩個真的值得注意而且落在每次查詢回應之外的可能影響：
i. 可以並且會在執行時間或查詢時間運算和指派 IP 位址。
ii. IP 與名稱對應的整個過程是確保連線的整個過程以及下游快取中的 TTL，以較大部分為主。
結果很強大，這表示，繫結本身極為短暫，可以不顧之前的繫結、解析程式、用戶端或用途而變更。此外，擴充並不是問題，我們都知道這點，因為我們已在邊緣部署。
IPv6 — 新的外衣，相同的皇帝
談論部署之前，先來解決大家視而不見的問題：IPv6。首先要釐清的是，此處在 IPv4 的脈絡中討論一切又一切的內容，會同樣在 IPv6 中套用。如同全球郵政系統，位址就是位址，無論是在加拿大、柬埔寨、喀麥隆、智利或中國，而這也包括相對靜態、彈性較差的性質。
縱使彼此同等，顯著的問題仍然存在：只要變更為 IPv6，就能理所當然地滿足追求定址靈活度的所有原因？與預期相反，答案絕對是否定！IPv6 可以緩解位址耗盡的狀況，至少在目前每個人的人生中是如此，但 IPv6 首碼和位址的豐富性讓關於繫結至名稱和資源的推論變得困難。
IPv6 位址的豐富性也有不足的風險，因為操作者可以利用位元長度和大規模的首碼，將意義內嵌到 IP 位址中。這是 IPv6 強大的功能，但也代表著任何首碼中許許多多的位址將不會被使用。
明確而言，Cloudflare 無疑是最大的 IPv6 提倡者之一，而且是基於充分的理由，而不只是因為位址的豐富性可確保延長使用壽命。即使如此，IPv6 仍稍微改變了位址繫結至名稱和資源的方式，而位址的靈活度則能確保整個過程的彈性和回應能力。
旁註：靈活度適用於每個人
對於架構及其傳輸能力還有最後一項意見：定址靈活度對於任何操作權威 DNS 的服務很實用，甚至令人嚮往。其他內容導向的服務提供者顯然是競爭者，但也是規模較小的操作者。大學、企業和政府這些組織只是幾個可以操作自己權威服務的例子。只要操作者能夠接受在傳回的 IP 位址上連線，所有人都會成為定址靈活度的潛在受益者。
基於政策的隨機位址：大規模
我們自 2020 年 6 月起就一直透過生產流量在邊緣處理定址靈活度，工作內容如下：
超過 2 千萬個主機名稱和服務
加拿大的所有資料中心 (有鑒於合理人口和多個時區)
IPv4 中的 /20 (4096 個位址) 和 IPv6 中的 /44
從 2021 年 1 月到 2021 年 6 月 IPv4 中的 /24 (256 個位址)
對於每次查詢，在首碼內部產生隨機主機部分。
畢竟，真正的靈活度測試最極端的時候，就是為每項叫用伺服器的查詢產生隨機位址時。然後我們決定實際測試構想。2021 年 6 月，在蒙特婁資料中心以及隨後在多倫多，所有 2 千多萬個區域都對應至單一位址。
在一年的過程當中，政策擷取到的每次網域查詢接收了隨機選取的位址，這從只有 4096 個位址的集合中選取，然後是 256 個，再來是一個。我們在內部將一個位址的位址集合稱為 Ao1，稍後我們會回來談論這點。
成功的措施：「這裡沒什麼好看」
讀者可能默默地問了自己一些問題：
這在網際網路上中斷了什麼？
這對 Cloudflare 系統有什麼影響？
如果我可以看見，會看見發生什麼事？
以上每個問題的簡短回答都是_無_。但是，重要的是，位址隨機化會暴露依賴網際網路的系統設計上的弱點。弱點_總是_會出現，因為設計者將意義歸因於超越連線性的 IP 位址。(此外，只要是附帶性質，可以透過使用一個位址或「Ao1」來規避其中每一項弱點。)
為了進一步理解「無」的性質，現在要從清單最下方回答以上問題。
如果我可以看見，會看見什麼？
下圖中的範例顯示了答案。從我們部署之外的「世界其餘地方」的所有資料中心，某個區域的查詢會傳回相同的位址 (Cloudflare 的全球 Anycast 系統同樣如此)。相反地，登陸在部署資料中心的每次查詢會接收隨機位址。這些可見於以下對兩個不同資料中心的連續挖掘命令。
對於可能會想知道後續請求流量的人，是的，這表示伺服器設定為在位址集區中的_所有_位址接受 2 千多萬個網域中_任何_網域的連線請求。
好的，但是 Cloudflare 的周圍系統當然需要修改吧？
並不需要。這順道透明地變更為權威 DNS 的資料管道。BGP 中的每個路由首碼廣告、DDoS、負載平衡器、已發佈的快取……，都不需要變更。
不過，有個迷人的副作用：隨機化對於 IP 位址與對於雜湊表一樣是良好的雜湊功能，這平均將任意大小的輸入對應至固定數量的輸出。如下圖所示，在隨機化之前和之後查看每個 IP 負載的措施可以看見影響，其中資料取自一個資料中心七天的 1% 請求樣本。
定址靈活度之前
/20 的隨機化
/24 的隨機化
在隨機化之前，對於只有一小部分的 Cloudflare IP 空間而言，(a) 每個 IP 最大和最小請求之間的差異 (左側 y1 軸) 是三個訂單的規模；同樣地，每個 IP 的位元組 (右側 y2 軸) 幾乎是六個訂單的規模。隨機化之後，(b) 對於先前占用多個 /20 的單一 /20 的所有網域而言，這分別減少了 2 和 3 個訂單的規模。在 (c) 將此一步驟進一步帶到 /24，256 個位址上 2 千多萬個區域的每次查詢隨機化將負載差異減少為小的常數因式。
對於可能考慮透過 IP 位址佈建資源的內容服務提供者而言，這可能很重要。由客戶產生的優先負載預測可能很難取得。上圖證明了最佳前進路徑是_向所有名稱提供所有位址_。
這在更廣的網際網路上當然會中斷某些事情吧？
答案還是否定！或許更精確的陳述是：「不，隨機化沒有中斷任何事……但這會暴露系統及其設計上的弱點。」
任何_可能_受到位址隨機化影響的系統似乎有個先決條件：某些意義歸因於超越連線性的 IP 位址。定址靈活度可保持甚至還原 IP 位址的語意和核心網際網路架構，但這將會中斷假定其意義的軟體系統。
現在先提出幾個例子，說明這為什麼不重要，然後如何對繞過弱點的定址靈活度進行小小的變更 (透過使用單一 IP 位址)：
HTTP 連線聯合可讓用戶端重複使用現有連線，以從不同的來源請求資源。在 URI 授權比對連線時允許聯合的 Firefox 等用戶端不會受到影響。不過，需要 URI 主機以將相同 IP 位址解析為指定連線的用戶端將會失敗。
非 TLS 或基於 HTTP 的服務可能會受到影響。Ssh 就是一個例子，它在 known_hosts 中維持了主機名稱與 IP 對應。有鑒於許多 DNS 記錄目前傳回多個 IP 位址，此關聯在可以理解的情況下，已經過時並且中斷。
非 SNI TLS 憑證需要一個專用 IP 位址。提供者被迫收取費用，因為每個位址只能支援單一憑證而且不含 SNI。獨立於 IP 之外，更大的問題是在沒有 SNI 的情況下使用 TLS。我們已經開始努力理解非 SNI，希望結束這個糟糕的傳統。
最初，依賴目的地 IP 的 DDoS 保護可能會受到阻礙。但我們基於兩個原因，認為定址靈活度有所助益。第一，IP 隨機化在所有使用中的位址分散了攻擊負載，有效作為層級 3 負載平衡器來運作。第二，DoS 緩解通常透過變更 IP 位址來運作，這是定址靈活度固有的功能。
多對一，一對多
我們在上千個位址中從繫結到位址的 2 千多萬個區域開始，並成功從 /20 的 4096 個位址處理為 /24 的 256 個位址。當然，此趨勢帶來下列問題：
如果隨機化透過 n 個位址運作，為什麼不透過 1 個位址隨機化？
確實，有何不可？回想上述關於透過 IP 隨機化並同等於雜湊表中完美雜湊功能的意見。設計良好的雜湊式結構會保留任何結構大小的屬性，即使大小是 1 也能如此。這樣的減少情況會是定址靈活度建構基礎的真正考驗。
因此，我們進行了測試，從 /20 位址集合到 /24，從 2021 年 6 月到一個 /32 的位址集合，還有同等的 /128 (Ao1)。這不只是能夠運作而已。這_真的_順利運作。藉由 Ao1，解決了可能透過隨機化而暴露的顧慮。例如，非 TLS 或非 HTTP 服務具有可靠的 IP 位址 (或至少是非隨機，並且直到名稱上有政策變更為止)。此外，HTTP 連線聯合解散，如同免費一樣，而我們也確實看見使用 Ao1 的聯合層級增加。
但為什麼 IPv6 中有這麼多的位址？
一項反對繫結到單一 IPv6 位址的論點是沒有這種需求，因為位址不可能用盡。這是 CIDR 前的狀況，我們認為從最好的方面來說是善意，從最壞的方面來說則是不負責任。如上所述，IPv6 位址的數量讓推論變得困難。與其詢問為什麼使用單一 IPv6 位址，我們應該詢問：「為何不用？」
是否會影響上游？是，而且還提供機會！
Ao1 揭露與 IP 隨機化完全不同的影響組合，這或許讓我們有機會放大看似微小的動作可能產生的影響，藉此進入網際網路路由和連線性的未來。
為什麼？世上長度可變的名稱數量將永遠超過固定長度位址的數量。這表示，藉由鴿子洞原則，單一 IP 位址必須透過多個名稱分享，以及透過無關方的不同內容來分享。
Ao1 放大的可能上游影響值得提出來討論，將在下文說明。雖然，到目前為止，我們在評估中並沒有看到其中任何情況，也沒有出現在與上游網路的通訊當中。
**上游路由錯誤是立即性和整體性。**若所有流量抵達單一位址 (或首碼)，則上游路由錯誤會同等影響所有內容。(因此 Cloudflare 會在不相鄰的位址範圍中傳回兩個位址。)不過，請注意，威脅封鎖也同樣如此。
**可能會觸發上游 DoS 保護。**可以想像，在單一位址上集中請求和流量可能會將上游視為 DoS 攻擊，並觸發可能存在的上游保護。
在兩種情況下，定址靈活度快速集體變更位址的功能可緩解動作。也可以進行預防，但需要開放通訊和交流。
還有最後一項上游影響：
**可能會加速耗盡 IPv4 NAT 中的連接埠，並透過 IPv6 解決！**從用戶端，允許同時連線至一個位址的數量上限是依據傳輸通訊協定連接埠欄位的大小，例如在 TCP 中大約是 65K。
例如，在 Linux 的 TCP 中，這個問題原本存在，直到最近才順利解決。(請參閱此承諾和 SO_BIND_ADDRESS_NO_PORT，位於 ip(7) 手冊頁面。) 在 UDP 中，問題仍然存在。在 QUIC 中，連線識別碼可防止連接埠耗盡，但必須使用這些識別碼。雖然到目前為止，我們尚未看見顯示這成為問題的任何跡象。
即使如此，還有就我們所知最棒的部分，這是單一位址使用情況的唯一風險，也能藉由立即遷移至 IPv6 來解決。(因此，ISP 和網路管理員們，繼續實施 IPv6 吧！)
我們才剛剛開始！
因此我們結束的方式與開始的方式一樣。不會限制任何單一 IP 位址上的名稱數量，能夠在每次查詢變更位址，基於任何原因，_您_可以建立什麼？
實際上，我們才剛開始！定址靈活度帶來的彈性和不會過時的性質可讓我們想像、設計和建立新系統與架構。我們正在規畫 BGP 路由洩漏偵測以及緩解 Anycast 系統、衡量平台等。
關於上述所有內容的其他技術詳情，以及對於許多協助實現此事之人的致謝內容，可透過此論文和簡短談話了解。即使有這些新的可能性，但挑戰仍然存在，且還有許多尚待解決的問題，包括 (但不限於) 下列問題：
可以合理表達或實施哪些政策？
是否有表達時使用的大略語法或文法？
我們能否使用正式方法和驗證，以防止錯誤或衡突政策？
定址靈活度適用於每個人，對於想讓構想獲得更廣泛的成功人更是不可或缺。歡迎在 [email protected] 提供意見和想法。
若您是博士生或正就讀同等的研究學程，並且正在尋找 2022 年在美國或加拿大以及歐盟或英國的實習。若您有興趣投入類似這樣的專案或協助 Cloudflare 開發其流量和位址管理系統，我們的定址工程設計團隊正在徵人！