要約

  • RFC 6276 では、ホーム外のモバイルルーターは DHCPv6 Prefix Delegation を始める前にホームエージェントへ登録する。この時点では受け取るプレフィックスをまだ知らない場合がある。
  • 有効な DHCPv6 PD リースが特定プレフィックスの Binding Cache Entry 追加条件である。登録確認や DHCPv6 Reply だけから、転送、到達性、配達を結論づけることはできない。

運用画面の「Binding Update accepted」は、すべてが整ったように見える。しかし RFC 6276 の順序は逆の教訓を与える。ホーム外のモバイルルーターは、プレフィックス委任の DHCPv6 メッセージを始める前にホームエージェントへ登録しなければならない。まだどのモバイルネットワークプレフィックスを要求できるか分からないからである。

最初の記録は登録である。これは処理を開始するための Mobile IPv6 の関係を示すが、将来のプレフィックスを示さない。次に、モバイルルーターは requesting router、ホームエージェントは delegating router として DHCPv6 を交換する。Solicit、Advertise、Request、Reply の列は委任を記録する。RFC 3633 によれば、委任側がプレフィックスを選び、要求側は期限内にその責任を負う。Reply は委任と期限の記録であって、下流ノード、トンネル、実パケット、サービス応答の観測ではない。

重要なのは第三の記録である。RFC 6276 は DHCPv6 信号完了後、ホームエージェントが委任プレフィックスを binding cache に加えるよう定める。しかも有効な DHCPv6 Prefix Delegation リースがそのプレフィックスに存在する場合だけ追加し、存在しない場合は追加してはならない。RFC の目的は、まだモバイルルーターへ委任されていないプレフィックス宛てのトラフィックをホームエージェントが転送しないことである。

従ってこれは、特定プレフィックスについての制御面上の許可であり、パケット受領証ではない。転送が実行されたこと、ルーターが現在到達可能なこと、下流リンクに端末があること、アプリケーションが成功したことは示さない。RFC 6275 も、部分到達性、アクセス制御、サービス発見など、モバイル／無線の全問題を解決しないと明記する。

Heng Lu の最小仕様という読み方では、登録、委任、リース付きキャッシュ更新を別々の事実として残す。強い運用結論には、それぞれを結ぶ識別子と別のデータ面観測が要る。Haddad の著者表記は共同の仕様への関与を示すだけで、実在するネットワーク、ホームエージェント、トンネルや結果への責任を示さない。

出典