IPv6-Only 與 IPv6-Mostly，究竟有何不同？
在 IETF 的技術討論中，部分術語並沒有明確且一致的定義，因此容易造成理解上的落差，甚至導致相關技術被應用於並非原本設計的場景，進而影響整體網路服務品質。
「IPv6-Only」與「IPv6-Mostly」便是典型的例子。目前，IETF IPv6 Operations（v6ops）工作小組正透過 IPv6-Only and IPv6-Mostly Terminology Definitions 草案，逐步建立兩者的明確定義。
其中一項重要共識是，IPv6-Only 與 IPv6-Mostly 必須先界定其適用範圍，否則容易造成誤解。例如，若直接描述一個網路為「IPv6-Only」，將代表整個網路完全沒有設定或使用 IPv4。然而，這樣的情況在目前並不常見，因為許多服務、應用程式以及內外部資源仍可能需要透過 IPv4 存取。
因此，更精確的說法應為「IPv6-Only 接取網路（IPv6-Only Access Network）」。也就是說，只有接取網路採用 IPv6-Only，而使用者端的 CPE 區域網路（LAN）以及營運商網路的其他部分，仍可能維持 Dual Stack 運作。
理解這些術語的適用範圍，有助於說明 IPv6-Only 與 IPv6-Mostly 並不能互相取代，而是分別針對不同的網路環境所設計。
IPv6-Only + IPv4aaS：目前最常見的部署模式
目前最普遍的 IPv6-Only 部署方式，是在接取網路採用 IPv6-Only，同時透過 IPv4 as a Service（IPv4aaS）提供 IPv4 連線能力。其中，以採用 464XLAT 的行動網路最為常見，而住宅寬頻網路也逐漸朝此架構發展。
IPv6-Only + IPv4aaS 是五種 IPv4aaS 接取網路轉換機制之一，其設計目標是在廣域網路（WAN）僅使用 IPv6 的情況下，仍維持使用者網路具備完整的 Dual Stack 功能，避免任何裝置或應用程式因缺乏 IPv4 而無法正常運作。
在此架構中，CPE 內建 CLAT（Customer-side Translator）或具備相同功能的 NAT46 機制，可協助 IPv4 與 IPv6 之間進行轉換。無論家中設備或手機分享網路時所連接的裝置使用 IPv4、IPv6 或 Dual Stack，使用者皆無須進行任何額外設定。此外，區域網路內部裝置彼此通訊時，也不需要將封包送往外部網路進行轉換，因此不會影響本地端通訊效率。
近年來，全球 IPv6 部署持續成長，尤其是在行動網路與住宅寬頻方面最為明顯。包括 Akamai、APNIC、Facebook 及 Google 等統計資料均顯示，全球 IPv6 使用率已超過五成。如果再將中國大陸納入考量，由於其對 ISP 訂有 IPv6-Only 推動要求，整體比例可能已接近七成至七成五，且仍持續增加。
然而，相較於接取網路，大多數企業與公部門的 IPv6 部署比例仍偏低，即使許多大型內容服務提供者已開始建置 IPv6-Only 資料中心，企業網路仍有相當大的改善空間。
IPv6-Mostly：專為受管理網路設計
為了協助企業等受管理網路逐步導入 IPv6，IETF 提出了 IPv6-Mostly 的概念。IPv6-Mostly 的設計目標並非取代 Dual Stack，而是在既有 Dual Stack 網路中，逐步降低對 IPv4 的依賴。
相較於傳統 Dual Stack，IPv6-Mostly 有幾項主要目標，包括減少私有 IPv4 位址與 DHCPv4 資源的使用、避免 Happy Eyeballs 自動退回 IPv4 而掩蓋 IPv6 問題、讓主機能逐步轉換為 IPv6-Only，而無須建立專屬的 IPv6-Only 網段，同時提前發現未來 IPv6-Only 環境中的相容性問題，並降低 NAT44 的使用需求。
IPv6-Mostly 建立於 RFC 8925 的概念之上。Dual Stack 主機可透過 DHCPv4 Option 108 告知系統，在指定網路介面上不需要啟用 IPv4。如此一來，便能在維持 Dual Stack 網段的前提下，使部分主機實際上以 IPv6-Only 模式運作，而不必另外建立專屬網段。
若要使用此功能，DHCPv4 伺服器必須支援 Option 108，並由網路管理者決定哪些主機可以停用 IPv4，提供更細緻的管理能力。
然而，當主機停用 IPv4 後，也將無法直接存取僅提供 IPv4 的服務。因此，只有在網路中已部署 Stateful NAT64（PLAT）時，才建議啟用 Option 108。
若還需要支援直接使用 IPv4 位址、尚未支援 IPv6 的應用程式，以及其他 IPv4 相容需求，則支援 Option 108 的主機也必須同時具備 CLAT 功能。近年來，CLAT 已逐步導入桌面作業系統，包括 macOS、Linux，以及 Windows 11 Public Preview，而行動作業系統（如 iOS、Android 與 Harmony）則早已於行動網路介面支援 CLAT，近年也開始延伸至 Wi-Fi 等其他介面。不過，由於行動網路通常不提供 DHCPv4，因此 IPv6-Mostly 並不適用於行動網路介面。
兩者的共同點
無論是 464XLAT 或 IPv6-Mostly，都需要解決 NAT64 Prefix 的發現問題。過去曾採用手動設定、3GPP 機制以及 RFC 7050 等方法，但近年逐漸改採 RFC 8781 所定義、透過 Router Advertisement（RA）傳遞 NAT64 Prefix 的方式，成為較佳的解決方案。
此外，兩者皆建議搭配 DNS64 使用。DNS64 可降低 NAT46 的轉換需求、減少 DNS 伺服器負載，並改善連線建立時間。若 DNS64 設定正確，作業系統亦可透過 Self-synthesis 機制，降低 DNSSEC 驗證失敗的可能性。
選擇適合的部署模式
IPv6-Only + IPv4aaS（例如 464XLAT）主要適用於接取網路，特別是行動網路、住宅寬頻，以及一般非受管理網路。即使是部分中小企業，只要不需對外提供大量內部服務，或僅需少量手動設定，也相當適合採用此架構。
相對地，IPv6-Mostly 則是專為受管理的企業網路所設計，其接取網路仍應維持 Dual Stack。
若將 IPv6-Mostly 套用至住宅或行動網路，則意味著接取網路必須持續維持 Dual Stack，或要求 CPE 提供 CLAT 功能。此外，IPv6-Mostly 主機與 IPv6-Only 主機之間，也無法直接與 IPv4-only 設備通訊，除非另外部署 PLAT、EAM、SIIT-DC 等機制。若由 ISP 在雲端提供相關功能，也可能導致原本應留在本地網路的流量必須往返營運商網路，增加延遲與頻寬消耗。
另一方面，許多住宅 CPE 尚未提供 CLAT，部分廠商認為其實作較為複雜。然而，文章指出，相較於實作 DHCP Option 108、PLAT、EAM 或 SIIT-DC 等功能，CLAT 並非真正困難之處；真正的挑戰在於深入理解 IPv6 與各種轉換機制，而目前已有許多成熟的開源實作可供採用。
結論
IPv6-Only 與 IPv6-Mostly 並非彼此競爭的技術，而是分別針對不同網路環境所提出的部署模式。對接取網路而言，IPv6-Only 搭配 IPv4aaS 是較適合的選擇；而在企業等受管理網路中，IPv6-Mostly 則提供了逐步邁向 IPv6-Only 的可行途徑。
最重要的仍是確保使用者的網路體驗，因此應依據不同的應用情境採用適當的技術。同時，作者也呼籲 CPE 製造商應將 CLAT 納入產品設計，並建議 ISP 積極要求相關支援，將技術能力納入設備選購考量，而非僅以價格作為唯一依據。透過市場需求或政策推動，才能促使相關設備逐步完善，進一步推動 IPv6 的普及與部署。
本文為作者個人想法，不代表TWNIC之立場，若對此內容有興趣，請參閱原文：
https://blog.apnic.net/2026/07/07/ipv6-only-vs-ipv6-mostly-appropriate-use-cases/