設計理念

routerd 將路由器視為「資源的集合體」，而非「設定檔的堆積」。本頁說明實作上的判斷依據。

以 YAML 作為意圖的核心

YAML 表達路由器的意圖。routerd 比較 YAML 與主機的現有狀態，僅套用必要的差異。重視的是可反覆閱讀的定義，而非對操作步驟的記憶。

將有狀態的處理分配給專用常駐程式

DHCPv6-PD、DHCPv4、PPPoE、健康檢查等處理，各自具有計時器、重啟後的狀態恢復，以及事件歷史記錄。若將這些塞入一次性的指令，租約更新與故障時的觀測就會變得不穩定。

因此，routerd 將有狀態的處理以小型專用常駐程式的形式執行。常駐程式將租約與內部狀態儲存至檔案，並透過 Unix domain socket 公開狀態。routerd 本體讀取該狀態，對下游資源進行調和（reconcile）。

不將損壞的 IPv6 散佈至 LAN

若 DHCPv6-PD 已遺失，卻持續廣播舊前綴的 RA、AAAA 記錄與 LAN 位址，從使用者角度看來就是「IPv6 看似存在，卻無法通訊」的狀態。routerd 的設計是在無法確認委派前綴的狀態時，停止向下游提供 IPv6。

以事件串聯小型元件

routerd 不以單一的大型程序處理整個路由器，而是以事件串聯小型控制器。例如，DHCPv6-PD 進入 Bound 狀態後，狀態會依序傳遞至 LAN 位址、RA、DHCPv6 伺服器、DNS 回應、DS-Lite、IPv4 路由。

這種架構使得在哪個階段停滯一目瞭然。

將 OS 差異封閉在內部

Ubuntu、FreeBSD 對於相同的意圖，主機側的表達方式各異。routerd 透過 pkg/platform 的功能旗標與各 OS 的產生器，將這些差異封閉在內部。面向使用者的資源名稱盡可能保持統一形式。

現階段優先採用正確的名稱而非相容性

目前仍處於出貨前的 v1alpha1 階段。過去曾將 DHCP 相關的 Kind 名稱與二進位名稱，在不保留相容別名的情況下，整理為 RFC 表記（DHCPv4* / DHCPv6*）。在出貨前的這個階段，避免留下將來難以更動的錯誤名稱是優先考量。