第115回IETF Meeting報告

2022年11月5日から11日にかけて、第115回IETF Meeting（以下、IETF 115）が、英国ロンドンの現地会場とオンラインによるハイブリッド形式で開催されました。

今回のFROM JPRS増刊号ではIETF 115から、FROM JPRS編集局が注目した話題についてお伝えします。

• IETF 116 Yokohamaに関心をお持ちの方へ
  • 「The Tao of IETF」の新バージョンが公開
  • 託児サービスの提供
  • IETF 116 Yokohamaの開催予告
• 開催の状況
• DNS関連RFCの発行状況
• DNS関連WGの状況
  • dnsop WGの状況
  • dprive WGの状況
  • add WGの状況
• 次回のIETF Meetingについて

次回の第116回IETF Meeting（以下、IETF 116）は、横浜での開催が予定されています。国内での開催は2015年11月に横浜で開催されたIETF94以来、8年ぶりとなります。

本号ではIETF 115全般の話題の中から、IETF 116に関心をお持ちの方・参加をご検討されている方に役立つ情報をお届けします。

▼「The Tao of IETF」の新バージョンが公開

2022年9月9日に、IETFの初心者向けガイド「The Tao of IETF（以下、Tao）」の新バージョンが公開されました[*1]。

Taoは、IETF会合・WGの仕組み・関連する組織・標準化プロセスなどを平易な文章で紹介しており、IETFになじみのない人や初めて参加する人が「IETFのやり方」を理解するのに役立つ文書となっています。

Taoの最初のバージョンは1994年に公開されました。当初はRFCとして発行・改訂されていましたが、2012年からはIETFの公式Webページで公開されています。Taoの改訂作業はメーリングリストとGitHubによる、公開の場で進められています[*2]。

今回の改訂は2019年5月以来3年ぶりとなり、新型コロナウイルス感染症の拡大を受けた、オンラインミーティングに関する記述などが追加されています。

なお、旧バージョンではありますが、2012年11月2日版のTaoの日本語翻訳版が、IETFの公式Webページで公開されています[*3]。

▼託児サービスの提供

IETF 115では、現地参加者向けに託児サービスが提供されました[*4]。

また、会合では、2023年以降に開催されるすべてのIETF Meetingで託児サービスの提供を予定している旨が、IETFチェアから発表されました。

▼IETF 116 Yokohamaの開催予告

IETF 116の開催予告が、ホストを務めるWIDEプロジェクトの関係者から発表されました。

発表では、協賛を表明したスポンサーの一覧が示され、日本への入国にはワクチン接種証明または陰性証明が必要になること、開催時期は桜の季節であり、訪日の良い機会であることなどが共有されました。

IETF 115には、世界各地から1,600人以上が参加しました。会合終了後の公式発表によると参加者数は現地852人、オンライン766人で[*5]、2019年11月にシンガポールで開催されたIETF 106以来、3年ぶりに現地参加者数がオンライン参加者数を上回りました。

英国では「COVID-19と共に生きる（Living with COVID-19）」政策が実施されており、現地会場の一般エリアやロンドン市内では、マスクを着用している人は見受けられませんでした。しかし、現地会場では受付時に新型コロナウイルス感染症の検査キットが無償配布され、会議室でのマスクの着用が義務付けられるなど、感染拡大防止のための対策が継続して実施されました。

IETF 114の開催直後に発行されたRFC 9276以降、DNS関連のRFCは発行されていません。

本稿執筆時点で、dnsop WGから提案されたHTTPS/SVCBリソースレコード（以下、RR）（draft-ietf-dnsop-svcb-https）とadd WGの3本の提案（draft-ietf-add-ddr、draft-ietf-add-dnr、draft-ietf-add-svcb-dns）の作業が終了しており、RFC発行待ち（RFC Ed Queue）となっています。

これらのうち、HTTPS/SVCB RRの提案はtls WGが標準化作業を進めているEncrypted ClientHello[*6]の仕様（draft-ietf-tls-esni）を参照しているため、RFCの発行は、そのRFCの発行後になると見込まれています。

また、add WGの3本の提案は前述したSVCB RRを使っており、draft-ietf-add-dnrは前述したEncrypted ClientHelloの仕様を参照していることから、RFCの発行は、これらのRFCの発行後になると見込まれています。

▼dnsop WGの状況

dnsopはDNS Operationsに由来しており、権威DNSサーバー・フルリゾルバーや登録情報の管理など、DNSの運用全般に関するガイドラインの作成を目的としています。WGでは、運用上の課題に着目したDNSプロトコルの拡張・メンテナンスも活動項目としています。

▽特殊用途ドメイン名.altの予約（draft-ietf-dnsop-alt-tld）

DNSではない名前空間のためのTLD「.alt」を、特殊用途ドメイン名[*7]として予約するための提案です。

特殊用途ドメイン名の取り扱いは、RFC 6761で定義されています。しかし、2015年10月に実施された.onion[*8]の予約においてRFC 6761に存在する複数の問題点が指摘され、それらをまとめたRFC 8244が、2017年10月に発行されました[*9]。本提案は.altを予約・利用することで、RFC 8244で指摘された問題点を解決することを目的としています。

今回のWGでは作業を進めるため、リゾルバーにおける.altの特別扱いの有無、ルートサーバーの負荷を軽減するための.altの委任の要否、.arpaゾーンのようにセカンドレベルドメインを予約・委任する場合の管理など、作業を進める上での要考慮点が参加者に共有・議論されました。

本提案の初版は2014年に作成され、現在まで長年にわたり断続的に議論されてきましたが、最終的な合意には至っていません。本件が取り扱う内容にはIETFでの技術的な検討だけでは解決が難しい項目も含まれており、WGでの合意形成にはまだかなりの時間を要すると考えられます。

▽DNSプロキシーの制御オプション（draft-homburg-add-codcp）

スタブリゾルバーからDNSプロキシーを制御するための、EDNS0[*10]オプションを定義するプロトコル拡張の提案です。

DNS over TLS/HTTPS/QUICなど、スタブリゾルバーがフルリゾルバーとの通信で使うプロトコルの種類が増えています。こうしたプロトコルをスタブリゾルバーにそのまま実装すると、スタブリゾルバーのコード量が増え、構造が複雑になる恐れがあります。

そこで、複数のプロトコルでフルリゾルバーと通信可能なDNSプロキシーを別途準備し、スタブリゾルバーとフルリゾルバーの間に挿入することで、スタブリゾルバーを複雑化させることなく、それらのプロトコルをサポートできるようになります。本提案ではこの形で使われるDNSプロキシーを、スタブリゾルバーからDNSクエリで制御する仕組みを提供します。

提案には、フルリゾルバーの選択・通信手段の指定・トラストアンカー[*11]の提供などのオプションが含まれています。今回のWGでは、Connect by Name[*12]というDNSライブラリを使って提案の実装・開発作業を進めていること、Unboundの開発チームがIETF 116のハッカソン[*13]で実装を試作する予定であることが共有され、継続して作業を進めることとなりました。

▼dprive WGの状況

dpriveはDNS PRIVate Exchangeに由来しており、通信の暗号化によってDNSトランザクションにおける機密性（confidentiality）を提供し、プライバシーを確保することを目的としています。

IETF 115でも前回までと同様、dprive WGは単独では開催されず、後述するaddWGの一部を割り当てる形で開催されました。

▽権威DNSサーバーが暗号通信可能かをフルリゾルバーから検出する仕組み（draft-ietf-dprive-unilateral-probing）

フルリゾルバーと権威DNSサーバー間の通信の暗号化について、フルリゾルバーから853/tcp（DNS over TLS）と853/udp（DNS over QUIC）の通信を試みることで、暗号通信が可能かを検出・記憶する提案です。

フルリゾルバーと権威DNSサーバー間の通信における暗号化の実現、機能の検出については、これまでのWGでさまざまな方式が提案されました。しかし、いずれの方式も合意に至らず、長い議論を経て現在のシンプルな方式に一本化されました[*14]。

今回のWGでは今後の方向性として、これまでの課題を反映した更新版の提案を12月半ばに公開し、メーリングリストでの議論を反映した上で、2023年1月にWGでのワーキンググループラストコール（以下、WGLC）を実施したい旨が報告され、継続して作業を進めることとなりました。

▼add WGの状況

addはAdaptive DNS Discoveryに由来しており、パブリックネットワーク・プライベートネットワーク・VPNを含むさまざまなネットワーク環境において、DNSクライアントがリゾルバーを発見・選択するための技術的な仕組みの作成を目的としています。

▽標準化作業の進捗状況

add WGでは主要な提案に関する作業を終え[*15]、スプリットホライズン環境[*16]におけるリゾルバーの発見・選択の取り扱いなど、残っている作業を進めています。

▽スプリットホライズン環境におけるローカルゾーンの権限確認（draft-ietf-add-split-horizon-authority）

スプリットホライズン環境において、DNSクライアントがローカルに名前解決されるゾーン（以下、ローカルゾーン）の権限確認の手段を提供するプロトコル拡張の提案です。

スプリットホライズン環境を実現する方法の一つとして、管理者がローカルゾーンの権威DNSサーバーを組織内のフルリゾルバーに設定し、利用者に提供する形が挙げられます。この方法は、組織内の利用者がこのフルリゾルバーのみを使う場合は有効ですが、複数のフルリゾルバーを使い分けたい場合、どのドメイン名がローカルゾーンとして設定され、管理権限を有しているかの情報を、利用者側から確認する必要があります。本提案は、そのための手段を提供します。

WGでは、.home.arpa、.localなどの特殊用途ドメイン名については対象外とし、本提案による権限確認を禁止する旨を追加したことが共有されました。

その上で、追加の課題がなければWGLCに進みたい旨が発表され、継続して作業を進めることとなりました。

冒頭でご紹介したように、次回のIETF 116は2023年3月25日から31日にかけて、横浜で開催される予定です。

JPRSは、IETF 116にゴールドスポンサーとして協賛しています。IETF 116では、IETFで取り扱う技術を採用した製品・活動の紹介の場であるBits-N-Bitesを再開する旨がアナウンスされており[*17]、JPRSは協賛社として、参加・出展を予定しています[*18]。

本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。