設計思想

routerd は、ルーターを「設定ファイルの集まり」ではなく「状態を持つリソースの集合」として扱います。このページでは、実装上の判断基準を説明します。

YAML を意図の中心に置く

YAML はルーターの意図を表します。routerd は、YAML とホストの現在状態を比べ、必要な差分だけを適用します。作業手順の記憶ではなく、読み返せる定義を重視します。

状態を持つ処理は専用デーモンに分ける

DHCPv6-PD、DHCPv4、PPPoE、ヘルスチェックのような処理は、タイマー、再起動後の復元、イベント履歴を持ちます。これらを一度きりのコマンドに押し込むと、リース更新や障害時の観測が不安定になります。

そこで routerd は、状態を持つ処理を小さな専用デーモンとして動かします。デーモンはリースや内部状態をファイルに保存し、Unix ドメインソケットで状態を公開します。routerd 本体はその状態を読み、下流のリソースを調整（リコンサイル）します。

壊れた IPv6 を LAN に出さない

DHCPv6-PD が失われているのに、古いプレフィックスの RA・AAAA・LAN アドレスを出し続けると、利用者からは「IPv6 があるように見えるのに通信できない」状態になります。routerd は、委任されたプレフィックスの状態を確認できないとき、下流の IPv6 提供を止める設計を取ります。

小さな部品をイベントでつなぐ

routerd は、ひとつの大きな手続きでルーター全体を処理するのではなく、小さなコントローラーをイベントでつなぎます。たとえば DHCPv6-PD が Bound になると、LAN アドレス、RA、DHCPv6 サーバー、DNS 応答、DS-Lite、IPv4 経路へと順に状態が伝わります。

この形にすると、どの段階で止まったかを見つけやすくなります。

OS 差分は閉じ込める

Ubuntu、NixOS、FreeBSD では、同じ意図でもホスト側の表現が異なります。routerd は、pkg/platform の機能フラグと OS 別の生成器で、この差分を閉じ込めます。利用者向けのリソース名は、できるだけ同じ形に保ちます。

いまは互換性よりも正しい名前を優先する

現在は出荷前の v1alpha1 です。過去には、DHCP 系の Kind 名とバイナリ名を、互換用の別名を残さずに RFC 表記（DHCPv4* / DHCPv6*）へ揃え直しました。出荷前のこの段階では、将来ずっと残ってしまう誤った名前を避けることを優先します。