IETF国際動向 – 第124回IETFより ～IPv6移行関連技術～

既に公開済みの「IETF国際動向 – 第124回IETFより ～WebおよびAI関連の動向～」「IETF国際動向 – 第124回IETFミーティング概要とBOFより-」「IETF国際動向 – 第124回IETFより～耐量子計算機暗号（PQC）標準化の進展とIETF 124のハイライト」に続いて、耐量子計算機暗号（PQC）標準化の進展についてご紹介します。今回のレポートは、山本桃歌氏にご執筆いただきました。

2025年11月、カナダのモントリオールで開催されたIETF 124に参加してきました。IETFは、インターネット技術の標準化をまとめた文章であるRFCを策定するために議論を重ねる場で、その議論の場は大きく二つに分かれます。一つは、年に3回開催される同期的なコミュニケーションの場であるIETFミーティング、もう一つは、非同期的に意見を交換し合うメーリングリストでの議論です。

私は今回、IETFのdnsop WGに出しているドラフト「draft-ietf-dnsop-3901bis」(https://datatracker.ietf.org/doc/draft-ietf-dnsop-3901bis/)の紹介を通じて、この二つの議論の場についてお話ししたいと思います。

まず、draft-ietf-dnsop-3901bisは”DNS IPv6 Transport Operational Guidelines”というタイトルで、2004年にRFCとなった同じタイトルのRFC3901(https://www.rfc-editor.org/rfc/rfc3901)をObsoleteすることを目的としたものです。

RFC3901では、IPv6の普及が限定的であった当時の前提を踏まえ、名前空間の連続性を保つために「すべてのDNSゾーンは少なくとも1台、IPv4で到達可能な権威サーバで提供されるべき(SHOULD）」、また「再帰リゾルバはIPv4-onlyまたはdual-stackであるべき(IPv6-onlyは想定しない）」といった運用指針が示されています。

これに対して3901bisでは、IPv4-only／IPv6-onlyのどちらかに依存した運用が名前空間の分断に繋がり得るという問題意識から、権威サーバおよび再帰リゾルバがIPv4とIPv6の両方をサポートすることを“ベストプラクティスとして推奨”し、現実のネットワークで安定して運用するための具体的なガイダンスを整理しています。

なお、このドラフトがめざしているのは、実装仕様そのものというより「運用のベストプラクティス」をまとめたBCP (Best Current Practice)としての位置付けです。BCPは、プロトコルの新機能を追加するというより、現場で積み重なった知見を「今、このやり方が最も妥当だ」というコミュニティ合意として残すための枠組みです。RFC3901が書かれた2004年当時と比べて、IPv6の普及状況や運用の前提は大きく変わっており、その変化を更新することに意味があると考えています。

私はDNSに関する運用を全く知らない人間です。権威サーバの運用も、フルサービスリゾルバの運用もしたことがありません。そんな私が今回のドラフトに関わっているのは、RFC3901が20年間もアップデートされていないことに疑問を持ち、今のBest Current Practiceが新たに文章としてまとめられるべきではないかと思ったからです。

学生時代、私はIPv6-onlyネットワーク内で動くDNSリゾルバを動かそうとしましたが、IPv6のみだと多くのドメイン名の名前解決に失敗することに気づきました。そのため、NAT64を活用して名前解決を行うことを提案するドラフト”IPv6-only Capable Resolvers Utilising NAT64″ (https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-only-resolver/)を提出してv6ops WGにIETF 114で発表し、その後WG Adoptionされました。

しかし、その後にこれはニッチな解決策であり、根本的な解決策ではないと考えました。そのため、このドラフトを推し進めるよりも、dnsopでRFC3901をアップデートする方が良いと考えました。そこで、2023年のIETF 118で共著者のTobias氏とともに、dnsop WGで「draft-momoka-dnsop-3901bis」の発表を行い、その後メーリングリストでの議論を重ね、2024年頭にdnsop WG文書として採択され、無事にWGで進める形になりました。

IETFのプロセスはメーリングリストのみで完結できるようになっていますが、やはり同期的な対面のコミュニケーションはとても大切です。IETFのオンサイトミーティングに参加したことで、廊下での議論から新しい視点の意見を得たり、仲間を作ったりすることができました。特に、draft-ietf-dnsop-3901bisについては、IETF 117に参加してTobiasさんと出会っていなければ一緒にドラフトを書こうとはならなかったので、対面参加の意義を強く感じます。今回のIETF 124では、IETFモントリオールに現地参加する中で、DNSコミュニティとIPv6コミュニティの両者から意見をいただき、ドラフトを改善することができました。

今回の改善の中で、特に議論になったのが「IPv6経路でのフラグメンテーションをどう避けるか」という点でした。DNSはUDPで運用されることが多い一方で、昨今はDNSSECなどの普及により応答サイズが大きくなっています。IPv6では経路途中のフラグメントがなく、Path MTU Discovery (PMTUD）やICMPv6の到達性に依存するため、ネットワークの都合で大きいパケットが落ちると、名前解決そのものが不安定になってしまいます。

そのためドラフトでは、IPレイヤのフラグメンテーションが起きない運用を意識し、たとえば「UDP応答が大きくなりすぎないようにする(EDNS(0)のサイズを現実的な値に設定する）」「大きい応答が必要な場合にTCPへのフォールバックが確実に動くようにする」といったガイダンスをより明確にしました。さらに、TCPを使う場合でも、必要に応じてTCPセッションのMSSを小さめに設定するなど、経路上で想定外にパケットが大きくならないよう配慮する、といった運用上の注意も盛り込む方向で整理しました。

こうしたコメントが多く集まった背景には、DNS運用者・実装者が「レジリエンス(壊れにくさ）」を強く重視しているという事情があります。DNSはアプリケーション以前の基盤であり、ここが不安定になると、WebもメールもAPIもすべてが影響を受けます。だからこそ、設定ミスだけでなく、IPv6の経路品質やフィルタリング、ICMPv6の扱いといった“DNSの外側”の要因で名前解決が壊れることを、できるだけ避けたいという問題意識が共有されています。フラグメンテーションの議論はまさにその典型で、単に「IPv6でも動く」だけではなく、「現実のネットワークで安定して動かす」ために、どこに落とし穴があるのかを文章として残すことが重要だと、メーリングリストを通じて改めて実感しました。

IETF 124 dnsop WGのセッションでは、WG Last Callに進みたい旨を伝え、Chairが会場の賛同を踏まえて、2025年11月下旬から12月上旬にかけてWG Last Call (WGLC）が実施されました。

WG Last Callは、WGのメーリングリスト上でWGのコンセンサスが取れているかを確認するためのものです。このWG Last Callの中で、メーリングリスト上で多くのメールが飛び交い、さらなる改善点の提案や賛同のメッセージをいただくことができました。

WGLCで印象的だったのは、技術的な内容そのものだけでなく、文書の中の「言葉の強さ」も重要な議論になる、という点でした。IETFの文書では MUST / SHOULD / MAYのような大文字のキーワード(いわゆる規範的なキーワード）を使って要件の強さを表現しますが、これは単なる英語表現のニュアンスではなく、運用者にとって「必ず守らないといけない規則」なのか、「基本は守るべきだが、正当な理由があるなら例外もあり得る推奨」なのかを決める、とても大事な選択です。

実際、権威サーバ側のIPv6到達性に関する記述について、「SHOULDではなくMUSTにすべきではないか」という指摘をいただきました。一方で、現実のネットワークには移行期特有の制約があり、たとえばNAT64などの仕組みや組織都合によって“ネイティブIPv6”にできないケースもあります。運用環境の多様性を踏まえると、強い断定はかえって現場に合わない可能性があり、今回は「めざすべき方向は明確に示しつつ、例外の余地も残す」という意味で、表現の強さを慎重に調整しました。

WG Last Callで受けた助言を反映させた結果、ドラフトはWGLCを通過しました。

WGLCは「ゴール」ではなく、むしろ次のステップへの入口でもあります。WGLCでWG内の合意が固まった後は、dnsopの外からもレビューが入り始めます。たとえば運用全般の観点から見るopsdir、DNSの観点から見るdnsdirのように、WGの枠を超えた立場のレビュアが文章を読み、用語の曖昧さや運用上の前提、他分野との整合性などを指摘してくれます。WGの中だけで読んでいると見落としがちな点が洗い出され、文書としての完成度がさらに上がっていくプロセスだと感じています。

WGLCの後は、担当AD (Area Director)による評価やIETF Last Call、IESG (Internet Engineering Steering Group)での審議といったプロセスを経て、最終的にRFC Editorの工程へ進みます。RFC Editorの段階では、技術内容に加えて、参照関係や用語の整合、文章としての明確さ(誰が読んでも同じ解釈になること）がより厳密に求められます。なお本稿執筆時点(2026年1月上旬）では、IETF Last Callは終了し、ドラフトはIESGでの審議(IESG Evaluation)段階に進んでいます。WG外からのレビューも含めて、最終調整が続いています。

今後もこのドラフトのRFC化に向けて進め、DNSがIPv6で動く未来の助けとなるドキュメントを作成したいと考えています。また、IETFで得た知識を日本のネットワークコミュニティに還元できるよう努力します。