IETF勉強会＆座談会の様子 ～ミーティング参加のTips/DNSエラーの拡張によるDNSSEC導入への影響
tech_team IETF JPNICのイベント インターネットの技術国際的な標準化の動向を参加者の方々がより身近に感じていただけるよう「IETF勉強会＆座談会」を2021年6月4日(金)に開催いたしました。内容は、IETFにおけるリモート参加がどのように行われているのか、新しいMPLS (Multi Protocol Label Switching)とWebのトランスポートに関するライトニングトーク、DNSSECの検証の際に起きるエラー等をクライアントに伝えられるエラーの拡張RFC8914についての座談会です。
〇IETF勉強会&座談会
日時：2021年6月4日(金) 15:00～17:00
主催：Internet Society日本支部(ISOC-JP)
一般社団法人日本ネットワークインフォメーションセンター(JPNIC)
後援：WIDEプロジェクト
会場：オンライン
参加費：無料
IETF勉強会＆座談会 開催のご案内
https://www.nic.ad.jp/ja/topics/2021/20210524-01.html（JPNIC）
https://www.isoc.jp/wiki.cgi?page=IETF110Update（ISOC-JP）
勉強会＆座談会
これまでInternet Society日本支部(ISOC-JP)とJPNICでは、IETFミーティングの開催後にIETF報告会というセミナー形式のイベントを行ってきました。IETF報告会はIETFミーティングの参加者やIETFの標準化活動に詳しい方が動向などをまとめてお話しし、参加者はそれを無料で聴講できるイベントです。
IETF報告会のプログラムはISOC-JPのインターネット標準化推進委員会(ispc)で検討されています。日本からのIETFミーティングへの参加者が6年程前から減少傾向であること(*1)と併せて、標準化技術について日本語で議論できる場が少ないことから、今回のイベントが企画されました。
(*1) IETF標準化動向 [第1弾] ～IETF109からIETF110にかけて～ | JPNIC BLOG
https://blog.nic.ad.jp/2021/6393/
標準化の議論がなされている技術は、ミーティングの参加者のみならず私たちも関与できるものですが、議論を行う機会が少なければ、技術の改良や発展そのものに対する関心が薄れたり受動的に捉えたりする向きが広がることが考えられます。このイベントでは、勉強会に加えて座談会のパートを用意し、参加者がIETFミーティングの参加者と同じ目線で発言しやすいようにすることで、勉強会に参加するだけでは得られない情報を得やすくし、議論もするという意図で企画を進めました。
参加者の発言のしやすさを向上させるため、ストリーミング配信や録画配信を行いませんでした。
参加者の内訳とアンケート結果
IETF勉強会＆座談会の参加者は62名でした。アンケート結果(回答数24)によると、30代の参加者が最も多く(45.8%)、次いで40代(20.8%)および50代(20.8%)でした。過去、IETF報告会に参加したことがある人が58.3%で、今回のIETF勉強会＆座談会が初参加であった人は41.7%でした(図1)。
図1 今後の参加に関するアンケート結果。「オンライン開催なら参加予定」(36.8%)が
「現地開催/オンライン開催に関わらず参加予定」(42.1%)に次いで多い結果となった。
IETF勉強会＆座談会のプログラム
勉強会＆座談会は大きく三つのパートに分かれていました。一つ目は「リモート参加してみた＆Tips／IETFミーティング参加に関わる座談会」です。リモート参加のためのオンラインツールであるMeetEchoの使い方やIETFのアジェンダページの使い方など紹介と、日頃、IETFミーティング参加していないが、リモート開催であるために参加したという観点での体験談が行われ、座談会が行われました。二つ目はライトニングトークで、新しいMPLS、QUICとWebのトランスポートに関する標準化動向の共有でした。三つ目はDNSエラーの拡張(RFC8914)に関する座談会です。それぞれを簡単に紹介します。
リモート参加してみた＆Tips／ミーティング参加に関する座談会
この一年でIETFミーティング参加者の多くはリモート開催に慣れてきており、その利便性から、今後、現地開催が行われるようになっても、リモート環境の提供は行われていくと考えられます。リモート参加には現地開催とは異なる特徴があるとともに、この1年を通じて参加のTipsが得られているようですので、その情報交換のための時間として「リモート参加してみた＆Tips」は行われました。
JPNICの塩沢からリモート参加の方法や特徴をフレッシュな目線で紹介いたしました(図2,図3)。
図2 リモート参加に関するまとめ。複数のWGに並行して参加しやすくなり
議事メモが充実。参加のハードルは下がっている。(IETF報告会＆座談会資料より)
図3 ツールの紹介。IETFアジェンダ・ページには、会議参加のためのMeetEcho、
議事メモのためのCodiMDといったツールへのリンクがまとめられている。
録画は登録なしに閲覧可。(IETF勉強会＆座談会資料より)
また、JPNICの根津からは、IETFミーティングへの参加経験がほとんどない、そして技術者ではない視点での所感を紹介いたしました(図4)。
図4 オンライン参加に関する所感のまとめ。参加にかかる費用が低い上に、リモートゆえに
全体を俯瞰しやすい、同僚に相談しやすいといった意見。(IETF勉強会＆座談会資料より)
図5 JPNICの根津による「一緒にやりたいこと」。IETFの概要やトレンドを一覧できる
サイトや白書の必要性を指摘した。(IETF勉強会＆座談会資料より)
参加者からは「IETFの概要やトレンドなどを、技術者でない人にも一覧できるサイトや白書を作りたい！」という意見(図5)に賛同する声の他、標準化された技術が使われている分野として技術を紹介する仕方もある、といったアイディアが寄せられていました。その他にIETFミーティングの参加中に発言のメモが残るJabberのログが閲覧できるページ(Index of /jabber/logs/)の情報もありました。
Index of /jabber/logs/
https://jabber.ietf.org/jabber/logs/
ライトニングトーク
2件の発表がありました。
〇 IETF110頃からのMPLSの最近のお話, 栃尾祐治氏(ISOC-JP ispc,富士通)
新しいMPLSラベルスタックに関するインターネットドラフトについて紹介されました。最近、この仕様に関連するインターネットドラフトが急増しており、デザインチーム（Open MPLS DT）が立ち上がって議論が進行しているようです。今後、MPLSラベルスタックの定義が後方互換性を維持しつつ更新され、新たなネットワーキングやアプリケーションが生まれるかもしれない、とのことでした。
Open MPLS DT(Design Team)
https://trac.ietf.org/trac/mpls/wiki/MPLSOpenDT
〇 Webのトランスポート関連(仮), 後藤ひろゆき氏
QUICのRFCが公開されたこと(下記)とHTTP/3のRFCの策定状況、近年設立されたWebTransport WGで標準化が進められるインターネットドラフト、つまり主要な技術の内容が決まったことが紹介されました。WebTransportは、WebSocketのようにHTTP上で双方向のアプリケーション通信を実現する仕組みで、下位層としてQUIC、HTTP/3、Websocket over HTTP/2などが位置づけられます。Webのトランスポートに新たな動きがあるようです。
QUICのRFC（IETF報告会＆座談会資料より）
– RFC8991 Version-Independent Properties of QUIC
– RFC9000 QUIC: A UDP-Based Multiplexed and Secure Transport
– RFC9001 Using TLS to Secure QUIC
– RFC9002 QUIC Loss Detection and Congestion Control
旬の話題の座談会 ～Extended DNS Errors (RFC8914)～
DNSエラーの拡張（Extended DNS Errors – RFC8914)は、2020年10月にRFCとなった仕様で、DNSのリカーシブリゾルバー（キャッシュサーバ）が、エラーの内容を従来よりも詳しくユーザー側（DNSクライアント）に返すことができるようにするものです。例えば、DNSSECが導入されたドメイン名において従来であればSERVFAILというエラーでしかなかったものが、ネットワークエラー・署名の期限が切れている・応答内容が改ざんされているといった明確な理由が分かるようになります。DNSエラーの拡張が記述されたRFC8914の詳細をJPNICブログで紹介しています(下記)。
IETF 標準化動向 [第2弾] ～IETF109からIETF110にかけて DNS関連動向～
https://blog.nic.ad.jp/2021/5675/
〇DNSエラーの拡張によるDNSSEC導入への影響
従来のSERVFAILの場合、エンドユーザーの観点では何の説明もなくアクセスできない状況が起きる状況です。これはDNSSECの導入、リソースレコードへの署名を行うかどうかの判断に影響すると考えられます。ユーザーが問題を回避しにくいということは、サービスを提供する立場では、DNSSEC導入のメリットをデメリットが超えていると受け取られる可能性があります。今後、DNSエラーの拡張が導入され、キャッシュサーバやWebブラウザ等のユーザー環境が対応した場合、例えば、発生したエラーがネットワークエラーであれば再度アクセスすることで解消することが分かるなど、デメリットが低減されていくとが考えられます。
図5 DNSエラーの拡張のまとめ。DNSエラーの拡張について、エンドユーザ、
ネットワークサービス提供・オンラインのサービス提供の三つの立場について議論された。
参加者の間では、エラー内容を表示するためにDoHを使うのが良いのではないか、サービス提供者としては、メリットは理解できるが何が起きるのかがまだ分かりにくい、といった意見が挙げられました。
〇DNSエラー拡張の実装状況
最後にJPNICの小山からDNSエラーの拡張の実装状況が紹介されました。
図6 DNSエラー拡張（Extended DNS Errors – EDE）の実装状況。
サーバ実装ではNSD、PowerDNS Recursorが完了している。
参加者の間で、Google Chromeで実装が進められている、Amazon Route 53でサポートを開始、他に「DNS Access Denied Error Page」といったエラーを伝える方法が提案されている、といった情報交換が行われていました。
座談会と今後
座談会という形式で行った本会では、報告会という形式よりも参加者同士の情報交換が活発に行われていた印象です。ご参加のみなさまとして、感想や意見を述べやすい会合になっていましたら幸いです。
次のIETFミーティングであるIETF111は2021年7月26日～30日にオンラインで開催されます。今後も情報交換の場だけでなく、議論や意見交換の場を企画していきたいと思います。