計算 IPv6 子網路遮罩是指將 /0 到 /128 的前綴長度套用至 128 位元 IPv6 地址，並讀回網路前綴、第一個與最後一個數值地址、主機位元數以及總地址數。由於 IPv6 地址包含八個 16 位元十六進位欄位，子網路遮罩是以斜線前綴計數表示，而非 IPv4 使用的點分十進位遮罩。/64 前綴保留 64 個主機位元，/48 前綴保留 80 個主機位元，最大的 /0 則涵蓋整個 128 位元地址空間。運算必須使用足以容納 128 位元的無符號整數，因為 /0 範圍包含 2^128 個地址，而一般 JavaScript 數字在 53 位元之後會喪失精度。IPv6 子網路計算機使用瀏覽器原生 BigInt 運算來處理此問題，套用 RFC 5952 標準化格式，並回傳一組可驗證的數值：輸入的標準化文字、網路前綴、第一個與最後一個數值地址、主機位元數，以及精確的範圍大小。
IPv6 子網路切割與 IPv4 子網路切割的比較
來自 IPv4 的心智模型無法直接套用至 IPv6。以下三項差異決定了子網路計算的運作方式。
第一，地址是 128 位元，而非 32 位元。IPv4 的 /24 保留 8 個主機位元，產生 256 個地址的區塊；IPv6 的 /64 保留 64 個主機位元，產生數量為 2^64 的區塊。這些數字大到不適合記憶，但前綴長度公式是相同的。清除主機位元即得到網路地址；設定主機位元即得到數值上限。
第二，IPv6 沒有廣播地址。為前綴顯示的數值上限純粹是該範圍內最大的地址，它不是所有主機都會監聽的目的地，也不是一個獨立的運作角色。工具之所以將該值標示為最後一個數值地址，正是基於這個原因，而相關 RFC 文字也將其視為數值界線，而非特殊地址類別。
第三，IPv6 中標準的末端站台配置是 /64，而非 IPv4 所使用的可變主機位元數。選擇 /64 邊界是為了讓無狀態地址自動組態與標準的 64 位元介面識別碼能夠妥善契合。IPv6 的實務子網路切割，通常是為上游區塊選擇短於 /64 的前綴，並在 LAN 端保持 /64。希望比較兩種協定的地址格式的讀者，可以參閱IPv4 轉 IPv6 指南中的平行說明。
位址空間較大的一個後果是精度問題。53 位元的雙精度浮點數可以精確表示至約 9 × 10^15 的整數，但 /0 前綴包含 2^128 個值，遠大於此。IPv6 子網路計算機使用瀏覽器 BigInt 運算執行所有位元操作，因此 /0 不會被悄悄四捨五入，而 /128 也能正確產生恰好為 1 的計數。相同的精度保證也適用於介於其間的任何前綴，這就是在試算表中手動計算並非安全替代方案的原因。
根據前綴長度計算 IPv6 子網路
若要取得可稽核的子網路計算結果，請將地址與前綴貼入 IPv6 子網路計算機，並逐欄位讀回結果。
- 輸入 IPv6 地址時，可使用包含八個十六進位欄位的完整展開形式，或使用 RFC 4291 所定義的單一雙冒號壓縮形式。請移除所有中括號、區域識別碼或通訊埠後綴；這些形式並非純 IPv6 文字，將會以明確的錯誤訊息予以拒絕。
- 輸入前綴長度為 0 到 128 之間的整數。/64 是標準的 LAN 前綴，/48 是常見的站台配置，而欄位的兩個端點正好是範圍的極限。任何介於 0 到 128 之外的值都不是有效的 IPv6 前綴。
- 選擇「Calculate subnet」（計算子網路）。頁面會解析該段文字、將一處可選的 :: 序列展開為八個欄位、將這些欄位合併為單一 128 位元整數，然後套用遮罩。
- 檢視輸出內容：標準化輸入（RFC 5952 文字）、網路前綴、第一個與最後一個數值地址、主機位元數，以及精確的地址數量。在依賴該結果之前，請逐字元比對標準化形式與您的來源地址。
- 如果該結果將用於驅動組態變更，請在平台支援的工具中重新驗證，並保留先前的組態以便回復。純粹的數值前綴計算並非網路設計建議。
該計算機在您的瀏覽器中本機執行相同的運算。地址不會離開裝置，不會送出 WHOIS 或 DNS 查詢，且該頁面可搭配 RFC 3849 文件前綴使用，用於私人的規劃與文件範例。
使用 RFC 參考地址的實作範例
IPv6 前綴運算的標準範例是 RFC 4291 所給出的地址：2001:0DB8:0:CD30:123:4567:89AB:CDEF。使用 /60 前綴時，計算過程如下。
前綴佔據 128 位元中的前 60 位元，保留 68 個主機位元。網路地址是將輸入值中的這 68 個主機位元清除後所得的結果，在標準化形式中為 2001:db8:0:cd30::/60。最後一個數值地址是將所有 68 個主機位元設定後的網路值，得到 2001:db8:0:cd3f:ffff:ffff:ffff:ffff。精確的範圍大小為 2 的 68 次方，即該區塊中共有 2^68 個數值地址。主機位元數會明確回報為 68，以便能夠手動重新推導其大小。
貼上相同的地址與 /60，便可在 IPv6 子網路計算機上重複上述每一步，並將其標準化輸出與上述數值進行比對。如果工具回傳不同的標準化形式，表示輸入內容並非書面上的 RFC 範例，應在使用前先調查其中的差異。
常見的 IPv6 前綴長度及其配置用途
IPv6 的前綴長度並非任意指定，而是遵循從 IANA 一路延伸至末端站台的階層式配置模型。下表列出網路工程師最常遇到的幾個前綴長度、其代表的典型配置、決定地址數量的主機位元寬度，以及以 2 的冪次表示的地址數量。
| Prefix length | Typical allocation purpose | Host bits | Address count |
|---|---|---|---|
| /128 | Single host or loopback | 0 | 1 |
| /64 | Standard LAN segment, SLAAC boundary | 64 | 2^64 |
| /56 | Small site or residential allocation | 72 | 2^72 |
| /48 | Standard site allocation | 80 | 2^80 |
| /32 | ISP allocation block | 96 | 2^96 |
| /16 | Large registry block | 112 | 2^112 |
| /0 | Entire IPv6 address space | 128 | 2^128 |
任何短於 /75 之前綴的精確十進位地址數量，應透過 IPv6 子網路計算機取得，而非以手動展開，因為一般試算表的運算在超過 2^53 之後會喪失精度，導致結果被悄悄四捨五入。
RFC 5952 標準化輸出及其重要性
RFC 5952 定義了將 IPv6 地址書寫為文字時唯一推薦的單一方式。其規則為：十六進位字母使用小寫、欄位內的前導零予以省略、最長的兩個或以上連續全零欄位會壓縮為 ::、當兩個長度相同的連續區段平手時，以最先出現者為準。單一零欄位永遠不會被壓縮。該工具完全遵循這些規則，這代表它所回傳的標準化文字，就是大多數平台會顯示、在組態中接受，並在日誌中輸出的形式。
標準化也能讓您檢查自己的輸入。若您貼上 2001:db8::1 並使用 /64 前綴，而工具回報的標準化輸入為 2001:db8::1，則表示解析器已正確辨識壓縮形式與前導零省略規則。若標準化形式與您預期的不同，則輸入內容具有歧義，此時以標準化版本用於組態檔與文件中會較為安全。
IPv6 子網路計算機不會決定的事項
前綴計算僅回答一個問題，而且只回答一個：給定一個 128 位元地址與一個斜線前綴，其數值範圍為何。RFC 5942 明確指出，地址指派與鏈路內前綴是兩個獨立的概念；在區塊內數值相符，並不代表主機能夠在沒有路由器的情況下到達該地址，而定義路由的前綴也不是定義組態的前綴。
該工具刻意不會判斷前綴是否屬於鏈路內、可路由、已全域指派、保留、多點傳送或任一傳送。它不會查詢 WHOIS、DNS、BGP、地理位置或本機網路介面。其結果適合用於文件範例、RFC 3849 文件前綴，以及私人規劃，但無法用來確認擁有權、政策或可達性。
實務上還有兩項限制值得注意。區域識別碼（例如 %eth0）以及內嵌 IPv4 的形式（例如 ::ffff:192.0.2.1）會以明確的錯誤訊息予以拒絕。這些形式需要額外的內容（介面或混合地址模式），而純粹的數值計算無法解析這些內容。若您需要推導鏈路本機地址或 IPv4 對應地址，請移除後綴並單獨計算其數值部分，然後在計算機之上的層次中推導其區域或內嵌關係。
在將計算所得的範圍套用至生產環境的變更之前，請在網路平台支援的工具中獨立驗證，保留目前的組態以便回復，並參考具權威性的網路設計，而非僅憑數值相符。路由器、前綴資訊選項、配置政策、提供者規則、防火牆組態以及地址管理計畫，才是決定運作行為的輸入，而這些都不是計算機能夠看見的輸入。
如需更深入的說明，請參閱如何從 IP 與遮罩計算子網路位元。