面對 IPv6 我們從未準備好 - 從陽交大網路位址政策看待 NAT66

如果要說通訊技術類相關學術領域之領頭，陽交大如果算不上台灣第一，那敢叫板的可能只剩台大，ESA 這三個縮寫代表著 Engineering、Science、Administration，鋪下了電機、資通訊、光電的基礎。

就連網路也特立獨行

說到陽交大那就不得去說他的網路地位。不，不是說 140.113 有多厲害，沒有人敢跟 112 與 118 叫板，但台灣網際網路的地位中，陽交大是有 AS (Antonomous System) 編號，並使用 BGP 協定與多家電信進行互聯的大學。相較於其他大學依賴於教育部與 TWAREN (台灣高品質學術網路) 的路由，陽交大算是非常講究「網路自主性」的學校。

教育部於 1998 年提供了 140.113 之後，交大在數年後自己申請了 211.76.240.0/20 這一段 IP，並且獨立出 AS (即 AS18185)，上游為 SeedNet 聯合數位。雖然當時為何申請這一段 IP 已經查無根據，但這在台灣所有大學中是絕無僅有的。因為這個慣例是直到 2022 年的 7 月，臺灣科技大學申請了 103.191.22.0/23 並獨立出 AS63899 之後才打破。

（交大僅僅在教育部提供 140.113 後的四年內便申請成立 AS）

IPv6 方面交通大學早年非常的積極主動。相較於其他大學等待教育部核發 2001:288 的位置，交大直接自己來，自己申請 2001:F18 並成立 AS9916，此時台灣接上 IPv6 網際網路才不到三年，申請的速度甚至快過 GSN （政府網際網路）

雖然我不否認申請 AS 從來就不是什麼困難的事情，只要錢夠，去註冊申請一組沒有什麼大不了的。但我想給各位一個概念：拿到 AS Number 與 IP 網段是一件事情，放上網際網路通行又是另一件事情：因為這可不是簡單的「我去跟ＯＯ電信申請個網路的問題」。

我們這邊不把問題談的複雜，我們以一個簡單的例子來說：你申請了網段，有了 AS，需要讓他可以在你的公司之中生效使用：

1. 申請「企業型」或「固接專線」上網到你的公司所在地：
   簡言之：我買你的線（無論實線或虛擬）接到網際網路，買你的頻寬，但不買你的 IP 位置
2. 購買 IP-Transit 服務：
   簡言之：因為我沒有能力自己介接這麼多 ISP，所以我需要你來協助幫我路由這一段 IP 到我的路由器上，包含未來所有產生的流量也需乘載。

那各位對於這兩項服務所需費用有概念嗎？（以下費率 2025 年 9 月取得）

1. FTTx 企業型（注意：不是光世代固定制！或是其他的 OO 固定制，這些使用的 IP 仍然由 ISP 擁有納管）計價方式：電路月租費（已包含頻寬費用）
   
   
   
   
   
2. 固接專線，計價方式 線路價 ＋ 通信費
   
   
   
   
   

我們假設公司設點新竹，離最近的電信交換局很近，10 公里內，那麼就 1G 的線與頻寬：

1. FTTx 企業型： 712,000
2. 固接專線：330,464 + 900,000 = 1,230,464

這是一個非常可觀的數字，就算只有 100M，也足夠讓一間公司就僅網路開支就高的非常可觀。（這邊我們不探討其他常用方法，包含 VPN 接入等）

所以當我們看看陽交大目前與個不同電信之簽約互聯：

我能很明確的告訴你，陽交大對他的網路很敢花錢，也很敢建設。就陽交大目前的規模，已經足夠勝任一間中型 ISP。（交大的對外總頻寬 70G 左右，服務約 5 萬多人，相較於僅服務嘉義市的世新有線電視，5.5 萬用戶數，對外總頻寬只有 16G。按照此類標準，交大若要當 ISP 是足夠服務一個縣市的。）

很超前的技術，管理方案卻提不出來也跟不上

近期終於把實驗室算是建設到一定程度，網路也上線了，身為 IAIS 智能研究所丙組（資訊通信組）的教授，又曾任於會接觸電信服務的公司，我會要求 IPv6 服務再也正常不過。

• 我是那個當知道 He.net 與 Sixxs 有提供 v6 Tunnel 時，還特地去換了路由器讓 6in4 會 Work 的人 (2007 年)
• 我是那個當知道中華電信有提供 IPv6 試驗服務就立刻跑去櫃檯申請服務還繳費的人 (2011 年)
• 我是那個當進公司第一件事情是把整個公司一星期內全部 Dual-Stack 的人 (2023 年)
• 我是瘋到有試驗過純 IPv6 內網，並使用 NAT64 使 v6 去上 v4 網路的人 (2024 年）

我對 IPv6 不僅僅是執著，而是當我們明知盡頭將到，卻看著許多人無法跳離 IPv4 的舒適圈。IPv6 不僅是一種對於外來的準備，而更是對自己先行的挑戰。

然而近幾日與陽交大網管的互動... 能看得出，就算是身為台灣網路最前衛的大學，對於 IPv6 的管理方案仍然與 IPv4 依舊：

所以看起來他們仍然想要的做法還是：

• 每個系所有自己的網段，學校對於每個系所有一個路由器管理 (這裡的一個未必是實體上的一個，可能是虛擬的，例如一台路由器管轄 N 個網段)
• 每個系所必須自行處理 IP 的配發

非常典型的 IPv4 管理方法，其管理方式也在許多學校施行已久，而且這樣可以有效地減低資網中心的管理需求，並把部分責任切分出去。而我能很明確地說，很可能最後會變成 IPv6 位置是　IPv4 位置的衍伸，例如：114.113.255.254，那 IPv6 就可能是像 2001:F18:113:255::254 之類的。這樣不僅省去了系所不需要懂 IPv6，不懂網路的人也就照表操課。

管理上確實沒有問題：

• IPv6 確實可以使用該方法進行管理，而且完全不衝突

但這邊會產生的問題如下，也是很典型傳統網管人員對於 IPv6 的認知誤區，我們先假設目前在僅只純 IPv6 的環境中做挑論，以下問題會立刻顯現:

• 如果有人需要擁有自己的子網路呢 ? (別笑，這件事情發生的比你想的多非常多，只要你家有一台分享器，你就在用自己的子網路，架設一台路由器在實驗室或辦公室太平常了)
• /64 已經是 IPv6 Defacto 的最小子網單位 (請見 RFC7421)，再切會導致更小的子網之中部分特性出嚴重問題，例如 SLAAC 自動定址服務可能會訂出一個規定外的位置，或是根本不會運作。
• IPv6 是沒有 Defacto NAT 標準的，因為 IP 原本設計的目的是在於互聯，NAT 會製造互聯問題，所以當上面不配發子網給下面時就會發生子網路中沒有 IP 可以配發的窘境。
• 
  
• 支援 IPv6 Passthrough 的設備是少到你無法想像
• 我們假設為了解決上述問題，所以將假想的路由器作為可以 "自動無視 IPv6 流量"，就像路由器對於 IPv6 的流量如一台 Switch 一樣，直接穿透。但實際上有支援這項設定的「家用路由器」只有華碩跟 TP-Link (到目前我有接觸過的)，不可能所有人都願意花這麼多錢去買 Cisco。而且這樣又產生了另一個問題：是不是底下子網的設備又必須要跟別人討論誰的 IPv6 Range 在哪呢 ? 怎麼進行自動設定 ? 所有設備都要手動設定 ? 包含你的手機連上了自己實驗室的區域網路... ?

這是個很典型的誤區：拿 IPv4 的管理方法去管 IPv6。但這會導致非常多的問題，包含 IPv6 的穿透率。

IPv6 DHCP-PD 與消滅 NAT，又要貪 NPT，融合成了管理上的怪物

IP 最初設計的目的是在於無障礙的互聯，NAT 對於許多人來說是福音，但對於設計 IP 的人來說是個噩夢，與最後的折衷 - 因不可否認的是在 1993 年的當時，對於 IPv4 的枯竭已經認為是無可避免。當人們發現連接的網路因為逐漸減少而競價的位置而越來越貴，網路的可擴展性也受到了限制。

NAT 很好的解決了這個問題，試想:

• 我們上網時並不會一次使用完全部的 Sessions (65535)，多數情形之下我們僅用接近數百，其中有許多會在通訊結束後消除。所以數個通訊裝置使用一個 IP 是可行的。
• 當我們上網 (主動向外連線時)，若有一表可以記錄出去的連線，與內網對應的關係設備，屆時連回來不會導致問題。(所以網外連取得服務是毫無阻礙，但連入確會有問題就是在這裡，因為表中沒有規定。這時我們就要設定 Static NAT)

這讓 NAT 完全符合絕大多數的人的使用用途，因為多數的網路使用者「並不提供服務」。

而且，NAT 提供了非常高的可管理性與靈活度

• 外界網路如何改變，與內部網路毫無關係，內部怎麼搞，跟外面也沒關係，同時也讓網路備援變得很容易: WAN1 IP 斷了 ? 那就改 Table 換 WAN2 IP 出去吧，內網什麼都不用改。
• 外界連入連線「是被強制管理的」(不設定進不來)，增加安全性

很可惜的，NAT 並非 IPv6 的標準，某些方面，NAT 在 IPv6 中是希望被消滅的東西:

• IPv6 的位置數已經多到連每一粒沙都可以有位置還會有剩，為什麼還要 NAT ?
• 如果沒有位置數量的問題，NAT 就沒有存在的必要性 (請記住 NAT 當初創造的目的是因為 IP 不足，其附帶效果並非當時設計時所想到的)

DHCP-Prefix Delegation (簡稱 DHCP-PD) 某些方面就是為了以上而準備的。

• 因為無法預料會有多少子網，所以我先預備「子網池 (Prefix Pool)」，你有需要，你宣告需求(Prefix Delegation)，我給你。

所以就日前 ISP 通常的處理方式如下，假定擁有 2001:db8/32

• 路由一段到指定路由器，例如: 2001:db8:1::/48
• 路由器 A 切分 1. 所屬管轄網路的子網，以及 2. 可配發的子網
  可能會類似如下: 
• This Subnet: 2001:db8:1::/64
• Prefix Delegation Pool: 2001:db8:1:100::/56, Allow-Size 64...

要特別注意 This Subnet 跟 PD-Pool 對上游來說都要是可以被路由到的地方。

當 DHCP-PD 發生時 (舉例，下層路由器送來 Prefix Delegation Size 64)，會發給更下層的路由器以下資訊:

• WAN IPv6: 2001:db8:1::55 (任何在 2001:db8:1:: 之中的可用位置)
• LAN IPv6: 2001:db8:1:101::/64 (注意這裡核發的是網段，不是位置，任何在 Pool 內可以發的網段都能用)

接著路由器自己本身會新增路由條件

• For Any to 2001:db8:1:101::/64 Goto 2001:db8:1::55

直到這裡才算完成。

(DHCP-PD 例圖，與上述講述例子無關，但是 Workflow 相同)

但這裡我想各位已經看到了非常多的問題，就算是 DHCP-PD 本身也無法逃脫

• 就算是接近無限的位置 (IPv6)，當取得資源是有價時，就不可能予取予求
• 請問一個客戶最多可以拿多少網段 ?
• 如果限制 /64，那客戶如果底下又分給其他的 AP 呢 ? (想想學生宿舍)
• 那如果我配了 /48 (65536 個 /64) 這樣合理嗎 ? 可是台灣的制度，一次是配 /32，那這樣 65536 個 /48 不很快就全配光了 ?

可以看的出來，沒有了 NAT，不僅僅是增加了 ISP 的管理負擔，同時也減少用戶的內網彈性:

• DHCP-PD 每次配發都會改變 (目前不是所有的 ISP 都支援 Prefix Hint (就是點名我要哪個 Prefix)，畢竟這個會踩到服務區隔，好比光世代固定制)，每次我的內網 IP 都會變，那我要怎麼管理內網 ?
• Fail-Over 跟 Load-Balancing 這樣要怎麼做 ?

為了應付上述的問題，而又推出了 RFC6292，簡稱 NPTv6 (注意! 不是 NAT! 比較像是 NAT44 裡面的 1-to-1 NAT + NAT-DMZ 的概念)

NPTv6 基本上的想法很簡單:

• 把一內網逐一對應到一外網
• 外網若改變，只需改變 NPT 中對應的外網，內網無須改變

這就能讓 Fail-Over 與 Load-Balancing 順利達成

可是有沒有注意到：

• 這些零零總總的設計從未考慮做為一個使用者，當擁有自己的私有網路時的延展性 ?
• 這些東西似乎都是針對 ISP 已經提供服務的環境做設想

作為陽交大，你在等待哪一個 ? 是等淘汰的 NAT66 死灰復燃 ? 還是向前 ?

對於 IPv6 零零總總的管理問題，以及目前無論是 ISP 與使用者方面，各有其要面對的問題

• ISP 只能滿足大部分區間用戶的需求，不可能無限滿足，但 IPv6 使得 ISP 必須管理更多
• 用戶對自己的子網路失去絕大多數位置的控制權

NAT66 (就是把現行的 NAT44 改為 IPv6 版本)，就是正解。只是:

• 沒有任何一個家用產品支援 NAT66，甚至是更簡單的 NPT66
• 甚至就連企業級產品也不一定都支援 NAT66 (例如 Cisco ISR 系列)

如果政府不斷向前推行 IPv6，這樣的作法，能有多少通透率 ? 何況自建私有網路的興盛程度... 能是一個網管人員不知道的嗎 ?

我不期待交大能做的多超前，但至少做到如坊間 ISP 目前施行的模式:

• 一個 WAN IPv6 加上一個對應的 LAN IPv6 /64 子網

不想使用 DHCP，也可以，有申請 IPv6 的人從其 IPv4 衍生位置，生成其對應網段:

• 140.113.255.254 -> 2001:F18:113:255::254 (WAN) -> 2001:F18:A255:254::/64
  (備註: 以上只是舉例，必須特別注意衍生網段是否在實際操演中可路由)

給予設定的方式也不需改變，只要給 IPv4, IPv6 WAN 與 IPv6 LAN

SLAAC,  DHCPv6 與 /64 的重要性

IPv6 定址中主要分為兩類

• 無狀態定址 (Stateless / SLAAC)
• 路由器廣播網路大小與 RA (Router Advertisement)，有些會附帶 RDNSS (Recursive DNS Service Location)，IPv6 位置請自訂 (通常是透過一組函數計算出來，一般是跟網卡的 MAC 有關)
• 有狀態定址 (Stateful / DHCPv6)
• 基本上跟認知的 DHCP 相同，所以能提供固定位置等。但要注意的是，支援 DHCPv6 的設備並不多，Android 全部設備都不支援，IoT 設備也幾乎相同。(想想看是 Implement 整個 DHCPv6 Stack 比較簡單，還是幾個 Hash Function 就可以決定位置比較簡單 ?)
• 混和式 (Stateless, Stateful 不同程度的同時存在)
• 兩者可以同時存在，也可以部份存在。常出現的會是位置 SLAAC，但是 DNS 資訊由 DHCPv6 提供，或者是同時配發 Stateless 與 Stateful 位置

64 這個大小非常重要，因為 SLAAC Process 預設就是以 64 作為單位去產生隨機位置，這也就是為什麼在 Stateless 在比 /64 更小的網路會有機會無法運作 (可能產生了一個在網路大小之外的位置)。而且 DHCP-PD 至今仍將 /64 作為最小單位，目前似乎沒有方法能讓 DHCP-PD 發比 /64 更小的單位 (至少在 KEA-DHCP 與 Cisco ISR 系列都不行)

在之前的服務公司是有發生過因為部門太多，而當時的商用 Cable 服務只願意配發一組 /64 的問題，我曾經有刻意切分為 /80 一個單位，在固定 IP 或 DHCPv6 的情形下，運作是毫無問題的

只是 /64 作為 SLAAC 定址的這件事情是有引起討論的，有些人認為 /64 作為基本網路大小太大，再加上經常 ISP 會碰到只願意發一組 /64 的窘境，SLAAC 未來會不會尊重宣告網路之大小來產生位置有待商榷 (RFC8273 - 仍在討論中)

NAT 在互聯阻攔，但是他達到了從未有的管理便利與穿透力

IPv6 為了使得網際網路減低複雜度，NAT66 變成了如禁忌一般，既不上檯面，卻在某些廠商中遊走的功能。至今，沒有一個廠商有開發如 NAT44 這麼簡單的 NAT66，一接就通， 一開就有，就算企業級產品似乎也必須使用者自行透過 CLI / Scripting 的方式來達成。

雖然在整體網路中，多重 NAT 始終是設計上的大忌，但使用別忘了，NAT 提升了子網路非常大的延展性，DHCP-PD 將原本用戶應該有的私有網路位置自主權，在 IPv6 裡面銷聲匿跡，全部回到了 ISP 手上，導致用戶無所適從...

而我們似乎仍然在尋找一個不需要 NAT，卻提供這些便捷的方法，走進未來。

當我們在急功近利的消除 NAT 時，我們已經正在懷念當我們內網是自由的時候。

下次我來寫怎麼用 Fortigate 50E 做到 NAT66吧...

看起來短時間內陽交大是不會改變的了

Wayne. 待續

9 月 27 日