要約

  • IPV6_ADDR_PREFERENCES の成功は、アプリケーションの希望が整合した形式で受理されたことを示すだけで、希望属性の存在や採用を保証しない。
  • 属性を必須条件にするなら、選択、getsockname() による読出し、inet6_is_srcaddr() による検証を送信前に完了し、ネットワークとアプリケーションの結果は別に観測する必要がある。

監査表に「一時アドレスを優先」とある。運用担当者は、その行を「一時アドレスで送信した」と読む。設定と事実の間にある選択処理が、帳票から消えている。

RFC 5014 は、この空白を完全に埋める証明規格ではない。アプリケーションが IPv6 の既定選択規則の一部を反転させつつ、残りをホストに任せる API を定めた文書である。正確なアドレスを bind() や IPV6_PKTINFO で固定する方式とは目的が違う。

指定できる対は、home と care-of、temporary と public、CGA と non-CGA である。異なる軸は組み合わせられるが、同じ軸の両側は矛盾する。socket では EINVAL、名前解決側では EAI_BADEXTFLAGS になる。しかし、矛盾がないことと、条件を満たす候補があることは別だ。

設計の中心は「要件」ではなく「優先」である。一時アドレスを希望しても一時候補がなければ、公開アドレスが選ばれ得る。複数属性の一部だけが利用可能なら、その部分を反映し、残りは既定方針に戻る。未対応のフラグは黙って無視することが推奨される。API の成功値から実際の分岐は分からない。

さらに、想定する送信元は宛先の並びにも影響する。RFC 5014 は getaddrinfo() と socket に意味上同じ IPV6_PREFER_SRC_* を渡すよう求め、不一致の場合の動作を未定義とする。socket 設定だけを保存しても、接続前に宛先順序を変えた判断は再現できない。

明示指定は優先指定より強い。同じアプリケーションが bind() または IPV6_PKTINFO で送信元を固定すれば、その値が IPV6_ADDR_PREFERENCES より先に使われる。フラグが残っていることは、フラグが支配したことを意味しない。

厳格な条件には別の手続きがある。RFC は、優先指定だけではアプリケーション要件を保証しないと明記する。同じ設定を名前解決と socket に与え、スタックに選ばせ、getsockname() で実アドレスを読み、inet6_is_srcaddr() で属性を確認する。不適合なら通信を中止する。

ここで connect() を安易に使うと、TCP では検証前に SYN が出る可能性がある。1 パケットも先に出してはいけない場合のために、RFC は bind2addrsel() を定義し、宛先に対して選ばれるはずの送信元を送信なしで束縛する。UDP の connect() はそれ自体ではデータグラムを送らず、ローカルな選択に使える。選択済みと送信済みの境界は API に現れている。

検証結果は 1、0、-1 の三値である。1 はローカルアドレスが全フラグを満たすこと、0 は不一致、-1 は非ローカルまたは無効入力を示す。ただし 1 でも遠端到達は証明しない。home 属性は Mobile IPv6 を実装していないホストや、自宅状態のモバイルノードでも真になり得る。

属性名も過大評価してはならない。RFC 8981 の一時アドレスは、同一アドレスによる単純な活動相関の期間を縮める。匿名性全体の保証ではない。RFC 3972 の CGA はアドレスと公開鍵資料の関係を検証可能にするが、認証済み身元ではない。CGA を優先する設定は署名検証でも認可でもない。

既定値には時代差もある。RFC 5014 は RFC 3484 の公開アドレス優先を前提に書かれた。その後 RFC 6724 が置き換え、対応規則は一時アドレス優先になった。現在の挙動を知るには、実機の候補と方針版を記録するしかない。

実務上の受領書には、アプリケーションと socket、要求フラグと旧値、名前解決側の同等フラグと宛先順、無視された能力、候補集合、方針版、明示的な送信元指定、選択 API、先行送信の可否、読出したアドレス、検証の入力と三値結果、中止判断、最初の送信と応答、アプリケーション結果を別項目で残すべきだ。

これは RFC にない義務を加えるものではない。Heng Lu の現実レイヤーに従い、希望、ホスト選択、ローカル属性、パス、業務結果を混同しないための運用設計である。

出典