要約

  • RFC 5220は、デフォルトの送信元アドレス選択が、インターネットから戻れないプレフィックスを選んでしまう「半閉鎖」IPv6ネットワークを例示した。
  • 送信元アドレスを決めるのはホストで、次のルーターを決めるのは経路側である。RFCが記録したのは両者のずれ得る条件であり、実際の導入例や障害率、すべてのマルチホームホストの挙動ではない。

有効なプレフィックスが二つあっても、返信は一つの道しか通れない

2008年7月に公開されたRFC 5220は、複数のプレフィックスを持つリンクでIPv6アドレス選択が直面する運用上の問題をまとめた情報提供文書だ。新たなパケット形式を定めたわけではない。RFC 3484のデフォルトの送信元・宛先選択が、特に利用者が個々のホストを調整できない環境で難しくなる場面を整理している。

中核にあるのは「半閉鎖ネットワーク」の例だ。小規模な拠点が二つの上流ネットワークにつながっている。一方は通常のインターネット接続、もう一方はVPN経由の閉じたネットワークである。ホストは双方から有効なIPv6アドレスを受け取る。閉域内の同僚は内部アドレスでそのホストに接続できるが、公衆インターネット上のサーバーは同じアドレス宛てに返信を返せない。

ホストが公衆ネット上の宛先へ接続を始めると、問題が表面化する。RFC 5220の例では、最長一致プレフィックスの規則によって閉域側のアドレスが送信元に選ばれることがある。一方、拠点のデフォルト経路はパケットを通常のISPへ送るかもしれない。そのISPは自ら割り当てていない送信元プレフィックスを破棄し得る。パケットが外へ出ても、サーバーの返信先は閉域プレフィックスであり、公開経路からは戻せない。「アドレスが有効」と「通信が往復できる」は別の確認事項だ。

RFCは二つの断点を分けている。上流の入口フィルターが、そのISPに属さない送信元を拒否する場合。もう一つは、送信パケットが受理されても半閉鎖の戻り先に返信を届けられない場合だ。どちらも単なるDNSの問題ではなく、ホストのアドレスが不正だった証拠でもない。

プレフィックスだけでは上流の方針が分からない

RFC 3484は候補アドレスを比較するデフォルト規則を示すが、パケットをどのISPが運ぶか、選ばれたプレフィックスに返信を届けられるかまでは自動で知らせない。そのためRFC 5220は、ホストの選択とネットワークの経路方針の調整としていくつかの問題を扱う。半閉鎖の例ではホストのポリシーテーブルを書き換えれば避けられるが、誰かがトポロジーを把握し、変更のたびに設定を更新する必要がある。

文書は対象範囲も区別する。既存の選択枠組みで扱える問題と、追加情報や別の仕組みが要りそうな問題を整理する一方、すべてのマルチホームIPv6ネットワークに不具合があったとは主張しない。運用時にどれだけ起きたかも測っていない。図が示すのは検討すべき故障形態であって、実際の障害報告ではない。

後の標準はこの境界の一部を明示した。RFC 6724はRFC 3484を置き換えた。2016年の標準化文書RFC 8028は、複数プレフィックス環境での第一ホップルーター選択を扱い、広告されたプレフィックス、送信元アドレス、実際の出口を関連付ける。これは標準議論の進展を示すが、2008年の問題がどれほど一般的だったかも、現実のネットワークで返信経路を調べなくてよいことも意味しない。

規格の警告はトラフィックの統計ではない

RFC 5220の歴史的な価値は、関連するが代用できない事実を分けた点にある。送信元アドレス、次ホップ、ISPのフィルター、戻りの到達性は互いに影響するが、どれか一つだけで他を証明することはできない。RFCにはもっともらしい構成と分析がある一方、OSの調査、パケットキャプチャ、特定の障害、修正前後の測定はない。誤った選択をしたホストの数や、その後の標準が実接続をどれほど改善したかは、実装・運用の別の証拠が必要だ。

出典

  1. RFC 5220 — 複数プレフィックス環境におけるデフォルトアドレス選択の問題
  2. RFC 3484 — IPv6のデフォルトアドレス選択
  3. RFC 6724 — IPv6のデフォルトアドレス選択
  4. RFC 8028 — 複数プレフィックスネットワークでホストが選ぶ第一ホップルーター
  5. RFC 2827 — ネットワーク入口フィルタリング
  6. RFC 4193 — IPv6ユニークローカルユニキャストアドレス
  7. RFC 5220のRFC Editor情報ページ
  8. RFC 8028のRFC Editor情報ページ