要約
- PPP がネットワーク層段階に入り IPV6CP が
Openedになることは、IPv6 通信の前提であって、使用可能なグローバルアドレスの証明ではない。 - グローバルアドレスの DAD を省くなら、専用プレフィックスと終端ルーター非使用という二条件を、制御交渉とは別に立証し続ける必要がある。
現地ログには、Configure-Request、Nak、再提案、Ack、そして Opened が並ぶ。手順はきれいに終わっている。それでも利用者の IPv6 セッションは始まらない。
矛盾ではない。ログが扱った範囲と、利用者が求めた範囲が違う。
RFC 5072 は PPP 上で IPv6 を運ぶ方法と IPV6CP を定める。IPv6 パケットを通信する前に、PPP はネットワーク層プロトコル段階へ進み、IPV6CP は Opened に達しなければならない。これは正当な状態条件だが、グローバルアドレスの生成や経路投入、遠端到達までを意味しない。
この文書で定義される IPV6CP オプションは 64 ビットの Interface-Identifier である。Configure-Request は一つだけを含む。両端の非ゼロ値が異なれば Ack、同じなら別値を示す Nak、双方がゼロなら Reject となる。得られる保証は、その一点間リンク上で両端の値が異なることだ。
有効な値を合意できない場合も重要である。既定値を仮定してはならず、回復手順は未規定で、手動設定が一案として挙げられるだけだ。装置が独自に回復したなら、交渉記録と回復操作を分けて残さなければならない。
合意した識別子はローカル側のリンクローカルアドレスに使われる。しかし RFC 5072 は、同じ識別子がグローバルユニキャストアドレスにも使われると考えてはならないと明記する。PPP ピアはグローバル用に一つ以上の別識別子を生成できる。IPV6CP の記録だけでは、後でどのグローバルアドレスが入ったか分からない。
DAD の扱いもこの境界に従う。交渉済み識別子から作るリンクローカルアドレスでは、点対点の両端が既に区別されているため DAD は冗長になる。グローバルアドレスでは、二つの条件を満たす場合に限って冗長と評価できる。
一つ目は、アクセスルーターが通知するプレフィックスが当該 PPP リンク専用であること。二つ目は、その終端ルーター自身が同じプレフィックスからグローバルアドレスを自動構成しないことだ。両方が成立して初めて、管理者が DupAddrDetectTransmits をゼロにすることが推奨される。
ゼロは成功値ではない。検査をしない設定値である。重複パケットを観測しない代わりに、プレフィックス割当とルーター設定を信頼する。後日プレフィックスが共有されたり、ルーターに同一範囲のアドレスが入ったりすれば、過去の Ack はその変更を検出しない。
RFC 4862 は通常、SLAAC、DHCPv6、手動の別を問わず、ユニキャストアドレスを割り当てる前に DAD を求める。明示された例外はあるが、DupAddrDetectTransmits=0 は DAD を行わないという意味である。例外採用は証拠の省略ではなく、証拠源の変更だ。
グローバルアドレスの構成経路も分かれる。ステートレスでは Router Advertisement のプレフィックスと識別子を組み合わせ、ステートフルでは DHCPv6 のようなサーバーから取得する。プレフィックス受信、アドレス取得、インターフェース割当、経路選択は同じイベントではない。
識別子の推奨も固定されていない。RFC 8064 は RFC 5072 を正式に更新し、安定した SLAAC アドレスには RFC 7217 の意味的に不透明な方式を推奨し、安定したリンク層アドレスの埋め込みを避けるよう求めた。標準の更新履歴は、個別装置の実装証明ではない。
さらに IPV6CP の開通は認証そのものではない。RFC 5072 はアクセス制御、認証、暗号化を別の保護として扱い、MD5 を使う方式にはリプレイの危険があると述べる。制御状態が整っても、対向の身元や許可が十分とは限らない。
再現可能な運用記録には、LCP 状態、認証・認可、IPV6CP 全交換、両端識別子と生成方式、リンクローカルアドレス、グローバル取得方式、プレフィックスと有効期間、DAD 結果または二条件の根拠、実装済みアドレスと経路、実パケットの送信元、対向応答、アプリ結果を別々に残すべきだ。
これは RFC にない義務を足す話ではない。Heng Lu の現実層の考え方に沿い、制御の合意、設定状態、パケット観測、利用結果を検証可能な辺で結ぶ提案である。
Sources
- RFC 5072 — PPP 上の IPv6
- RFC 5072 — 正式テキスト
- RFC Editor の RFC 5072 情報
- RFC 5072 の正誤情報検索
- IETF Datatracker の RFC 5072
- IETF Datatracker の RFC 5072 履歴
- RFC 1661 — Point-to-Point Protocol
- RFC 2472 — 旧 IPv6 over PPP 仕様
- RFC 4291 — IPv6 アドレス体系
- RFC 4861 — IPv6 Neighbor Discovery
- RFC 4862 — IPv6 ステートレス自動設定
- RFC 7217 — 意味的に不透明なインターフェース識別子
- RFC 8064 — 安定 IPv6 識別子の推奨
- RFC 8200 — IPv6
- IANA — PPP フィールド割当
- Heng Lu — Running-Code Primacy
- Heng Lu — Minimum Initial Specification
- Heng Lu — Reality Layers
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
