要約

  • RFC 6334 は DHCPv6 オプション 64 で DS-Lite の B4 に AFTR 名を渡す。名前は接続の試行を可能にするが、DNS 解決、トンネル確立、NAT 状態、戻りの通信までは保証しない。
  • Tomek Mrugalski は David W. Hankins と同 RFC を共同執筆した。顧客側の手順を絞る一方、AFTR の配置、共有 IPv4 容量、高可用性、運用記録はサービス事業者の責任として残る。

「AFTR を受信」はサービス完了ではない

ホームゲートウェイの記録に「AFTR 名受信」とあれば、DHCPv6 の一段階は確認できる。だが、その名前を B4 が使う DNS から解決できたか、返された IPv6 アドレスへ到達できるか、トンネルが張れたか、AFTR が当該フローの変換状態を作れたかは別の問いだ。外向きの IPv4 パケットが変換されたとしても、応答が同じ利用者へ戻ったとは限らない。管理画面の緑色表示は、どの段階を観測したのかを示さなければ、サービスの証明にはならない。

RFC 6334 が定める OPTION_AFTR_NAME はコード 64 の DHCPv6 オプションで、AFTR を指す完全修飾ドメイン名を運ぶ。AFTR は Dual-Stack Lite の事業者側終端であり、B4 は顧客側でソフトワイヤを開始する機能だ。このオプション自体には、トンネル、容量予約、IPv4 変換バインディング、アプリケーション応答は含まれない。端点を示す設定値と、その端点が提供するサービスを分けて考える必要がある。

IPv4 の処理を上流へ移す DS-Lite

DS-Lite では、IPv6 接続を使いながら、IPv4 のみを話す機器やサービスへの通信を続けられる。家庭内の機器はプライベート IPv4 アドレスを使い、B4 が IPv4 データグラムを IPv6 にカプセル化する。事業者網にある AFTR はそれを取り出し、共有された公開 IPv4 アドレスを使ってアドレス変換を行う。端末ごと、家庭内機器ごとに一つずつ公開 IPv4 アドレスを割り当てる必要がなくなる一方、利用者のフローをどの AFTR が扱い、応答をどう戻すかは事業者の設備に集まる。

RFC 6333 は、利用者を AFTR ごとにまとめ、需要に応じて別の AFTR を追加したり、アクセス網に近い場所へ配置したりする構成を説明する。これは容量を増やすためのアーキテクチャ上の選択肢であって、特定の ISP が現在どの規模で導入しているか、コストがいくらかを示す実測ではない。B4 が受け取る名前は、事業者が管理する共有サービスの入口を選ぶ材料となる。入口を選ぶ規則と、入口の裏側に十分な容量や冗長性を用意する仕事は別である。

RFC 6334 が定める境界

B4 は OPTION_ORO にオプション 64 を含めて要求する。要求に含めなければ、サーバーは AFTR 名を返信しない。受信側は長さやドメイン名の形式を検証する。IANA の DHCPv6 登録簿も、コード 64 をクライアントの ORO で要求可能な単一インスタンスのオプションとして記録している。

その後の選択にも上限がある。名前に対する AAAA 応答に複数の IPv6 アドレスが含まれていても、B4 は今回のインターフェースで一つを選ぶ。ひとつのインターフェースで同時に複数の DS-Lite トンネルを張る仕組みではない。複数の AFTR-Name オプションや候補名を受けた場合も、仕様上の処理は先頭の一つを使う。従って、利用者側であらゆる障害時に別 AFTR へ切り替わるロードバランサーや自動フェイルオーバーが定義された、と読むことはできない。

DHCPv6 の Reply が示すのは、ある取引で要求された設定値が返ったという事実までである。DNS の回答、B4 のトンネル状態、AFTR の受け入れ、NAT バインディング、戻りのパケット、アプリケーション応答は、それぞれ別の観測で確かめる。オプションの仕様が接続成功までを請け負わないことは欠点ではない。各段階を混同しないための明確な境界である。

名前から戻りパケットまで、証拠をつなぐ

実際の障害対応では、設定名を受け取った時刻と、DNS の回答を得た時刻を対応させる。どの IPv6 アドレスを選んだか、その時点の B4 インターフェースとどう結び付けたか、トンネル開始が成功したかを確認する。事業者側では、受信したソフトワイヤ、AFTR の負荷、変換バインディングの生成と失効、戻りパケットの配送を同一フローと時刻で照合する。最後に制御された IPv4 到達性チェックを行えば、どこまで進み、どこで止まったかを説明しやすい。

これらの記録がなければ、同じ「IPv4 が使えない」という問い合わせが、DNS キャッシュ、IPv6 経路、CPE の実装、AFTR の容量、ファイアウォール、NAT 状態、宛先アプリのいずれに由来するかを分けにくい。DHCP チーム、名前解決チーム、CPE 開発、バックボーン、AFTR 運用、サポートの境界は、パケット上の境界と一致しない。顧客へどの事実を約束するかを決めるなら、各担当が受け渡す証拠と、障害時にそれを結び付ける相関キーも決めておく必要がある。

RFC 7227 は、後年の DHCPv6 オプション設計ガイドラインとして、既存実装で採用しやすい形式、要求と応答、カーディナリティ、検証、リレー、互換性を整理する。RFC 6334 より後の 2014 年に公開された文書なので、同 RFC の設計を生んだ原因として扱うことはできない。むしろ両者を並べることで、短いフィールドを仕様にする際にも、既存クライアントや運用者が扱える詳細を明記することが重要だと分かる。

共同執筆者としての貢献をどう読むか

RFC 6334 は David W. Hankins と Tomek Mrugalski の共同執筆である。RFC 7227 も五人の著者による文書であり、現在の DHCPv6 基本仕様である RFC 9915 も複数の著者によって作られた。RFC の著者名は公開された標準化の記録であり、個人が単独でネットワークへ配備したことや、事業者の現在の設定を管理することの証明ではない。ISC のプロフィールや IETF Datatracker の記録は、Mrugalski の DHCP 開発・標準化活動の文脈を示すが、採用率や市場シェアを測るものではない。

この区別は小さなものに見えるが、貢献を評価するときに重要である。標準は共通の接続点を設ける。実装者はそれを装置に組み込み、事業者は自らの容量、冗長性、アドレス資源、記録方式に合わせて運用する。公開されたオプション登録や RFC は設計の存在を証明しても、稼働中の AFTR、利用者数、障害実績、性能を証明しない。IPv4-as-a-Service の比較を行う RFC 9313 も方式間の選択肢を整理する資料であって、DS-Lite が全ての事業者に最適、あるいは現在主流だという証拠ではない。

仕様からサービスまでの距離

RFC 6334 が渡すのは、事業者の判断で選ばれた端点名である。顧客側では、要求、検証、名前解決、選択、トンネル確立が続く。事業者側では、端点の到達性、共有 IPv4 容量、変換状態、戻り経路、可用性が続く。エンドユーザーのアプリケーションが応答するまでには、さらに複数のネットワークやサービスが関わる。どの段階も、前段が成功しただけでは証明されない。

DHCPv6 のログに「AFTR 名を受信」と記すなら、それは正確な観測として価値がある。次に必要なのは、B4 が何を解決し、どこへトンネルを張り、AFTR がどの変換状態を作り、応答が戻ったかという別の記録である。端末の設定を簡素に保つ設計は、事業者の可用性責任を消すのではなく、そこへ移している。

出典