JPNIC News & Views vol.2219【臨時号】IETF国際動向 - 第124回IETFより〜IPv6移行関連技術〜

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    __
    /Ｐ▲        ◆ JPNIC News & Views vol.2222【臨時号】2026.3.9 ◆
  _/ＮＩＣ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.2222 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2025年11月にカナダ・モントリオールで開催された第124回IETFミーティング
のレポートを、連載にてお届けしています。本号では、dnsop WGで活躍され
ている山本桃歌氏による、「draft-ietf-dnsop-3901bis」に関する取り組み
についてご紹介します。

本号の内容は、JPNICブログでもお読みいただけます。

  JPNICブログ：IETF国際動向 - 第124回IETFより
               ～IPv6移行関連技術～
  https://blog.nic.ad.jp/2026/11619/

なお、これまでに発行した第124回IETF関連の記事については、下記のURLか
らバックナンバーをご覧ください。

  □第124回IETF報告
    ○第124回IETFミーティング概要とBOFより
      https://blog.nic.ad.jp/2025/11444/
    ○WebおよびAI関連の動向
      https://blog.nic.ad.jp/2026/11495/
    ○耐量子計算機暗号（PQC）標準化の進展
      https://blog.nic.ad.jp/2026/11611/

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ IETF国際動向 - 第124回IETFより ～IPv6移行関連技術～
                                                              山本桃歌
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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で得た知識を日本
のネットワークコミュニティに還元できるよう努力します。


   ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
      わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
                  ◇              ◇              ◇
            メールマガジン以外でも、情報を発信しています！
             JPNICブログ   https://blog.nic.ad.jp/
             X(Twitter) https://x.com/JPNIC_info
   Instagramもはじめました！ https://www.instagram.com/jpnic_info/

      YouTubeでは各種セミナー資料や解説動画などを公開しています
             https://www.youtube.com/@JPNIC_info
   ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃ https://feedback.nic.ad.jp/2222/1f10a2acb5b7cbec6e6eb8e27bd0241e ┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃ https://feedback.nic.ad.jp/2222/c6e8766f1f9e2750eb1d0074df2e2d8f ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  JPNICの活動はJPNIC会員によって支えられています  ■■■■■
  :::::  会員リスト  ::::: https://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト :::: https://www.nic.ad.jp/member/ (PASSWORD有)
□┓ ━━━  N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛          お問い合わせは  jpnic-news@nic.ad.jp  まで          ┗┛
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  ━━ JPNICへのご連絡/お問い合わせは極力電子メールでお願いします ━━
  ■ 各種お問い合わせ先：https://www.nic.ad.jp/ja/profile/info.html ■
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 JPNIC News & Views vol.2222 【臨時号】

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          101-0047 東京都千代田区内神田2-12-6 内神田OSビル4階
 ＠ 配信先変更・停止  https://wwww.nic.ad.jp/ja/mailmagazine/#regist
 ＠ 問い合わせ先 jpnic-news@nic.ad.jp
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
            本メールを転載・複製・再配布・引用される際には
        https://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
   ◇ JPNIC Webにも掲載していますので、情報共有にご活用ください ◇
登録・削除・変更   https://www.nic.ad.jp/ja/mailmagazine/
バックナンバー     https://www.nic.ad.jp/ja/mailmagazine/backnumber/
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■     News & ViewsはRSS経由でも配信しています！    ■■■■■
::::: https://www.nic.ad.jp/ja/mailmagazine/backnumber/index.xml :::::
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

■■◆                          ＠ Japan Network Information Center
■■◆                                     ＠  https://www.nic.ad.jp/
■■

Copyright(C), 2026 Japan Network Information Center
このページを評価してください
