第81回IETF Meeting報告

今回のFROM JPRSでは、2011年7月24日から7月29日にかけてカナダのケベックシティで開催された第81回IETF Meeting（以下、IETF81）で議論された話題の中から、JPRSが特に注目したものについてお伝えします。

homenet WG（*1）は「Home Networking」に由来する、家庭内LANなどの比較的小規模なネットワーク内、及びネットワーク間におけるさまざまな技術課題について取り扱うWGです。homenetは従来のhomegate BOF（ブロードバンドルーターなど、家庭内に置かれるゲートウェイ機器における技術課題について取り扱う）における活動を引き継ぐ形で、今回のIETF81から正式なWGとなりました。

 

既に、従来からのPCやスマートフォン、ゲーム機などにとどまらず、録音／録画用の機器やデジタルカメラ／ビデオカメラなど、コンシューマー向けのさまざまな機器がネットワーク接続機能を標準搭載するようになってきています。また、IPv4アドレスが在庫枯渇を迎えIPv6の普及促進が図られる中、家庭内ネットワークにおいてもIPv4／IPv6双方への対応や多種多様なプロトコル／サービスの円滑な利用が重要な課題となってきています。

このような状況を踏まえhomenet WGでは、家庭内ネットワークの円滑な利用のために考慮すべきさまざまな技術課題について、IPv6やDNSなどの関連する既存のWGと協調を図りながら解決していくことを目的としています。

homenet WGでは最初に取り組むべき課題として「基本設計（architecture）」を挙げ、その後取り組む課題として、

• ネットワークプレフィックスの設定（prefix configuration）
• 経路制御（routing）
• 名前解決（name resolution）
• サービス検出（service discovery）
• 境界セキュリティ（perimeter security）（*2）

 

の五つを挙げています。WGでは今後2012年末までの予定で、これらの課題における標準化活動を集中的に進めていく予定です。

DNSの運用における標準化活動を進めているdnsop WGでは、AS112プロジェクト（以下、AS112）におけるIPv6関連ゾーンへの対応、DNSSECにおけるKSK（鍵署名鍵）ロールオーバーの自動化などについての発表と議論が行われました。

AS112のIPv6関連ゾーンへの対応

AS112は、本来インターネットに送出すべきではないプライベートアドレス（RFC 1918）やIPv4リンクローカルアドレス（RFC 3927）に対するDNS逆引き検索をまとめて処理することにより、in-addr.arpaゾーンを管理する権威DNSサーバーの負荷を軽減することを目的としています。AS112には専用のAS番号（112）とIPアドレスブロック（192.175.48.0/24）が割り当てられ（*3）、IPエニーキャストを用いた世界的な分散運用（*4）が実施されています。

 

IETF81ではAS112が取り扱うDNSゾーンとしてこれまでのIPv4関連ゾーンに加え、以下に示すIPv6関連ゾーンを追加する提案が示され、WGとして合意されました。今後、実現のための標準化活動が進められていくことになります。

• 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa (Unspecified)（*5）
• f.f.ip6.arpa (Multicast)
• 8.e.f.ip6.arpa (Link-Local Scope)
• 9.e.f.ip6.arpa (Link-Local Scope)
• a.e.f.ip6.arpa (Link-Local Scope)
• b.e.f.ip6.arpa (Link-Local Scope)
• c.e.f.ip6.arpa (Link-Local Scope)
• d.e.f.ip6.arpa (Link-Local Scope)
• e.e.f.ip6.arpa (Link-Local Scope)
• f.e.f.ip6.arpa (Link-Local Scope)
• 0.0.c.f.ip6.arpa (Unique Locally Assigned)
• 0.0.d.f.ip6.arpa (Unique Locally Assigned)
• 0.0.0.0.1.0.0.2.ip6.arpa (Teredo)

（draft-michaelson-as112-ipv6-00より引用）

 

KSKロールオーバーの自動化に関する議論

DNSSECでは、一連の作業が子ゾーン内のみで完結するZSK（ゾーン署名鍵）ロールオーバーの自動化は比較的容易であり、BIND 9.7で導入されたスマート署名やOpenDNSSECなど、自動化を支援するツール群が作成／導入され始めています。それに対し、KSKのロールオーバーでは親ゾーンが登録／公開するDSレコード（以下、DS）と子ゾーンが公開するKSKを厳密に同期させる必要があることから、完全な自動化は困難であるとされてきました。

IETF81ではKSKロールオーバーの自動化を実現する上での問題点の洗い出しが行われ、その中で現在提案されている二つの方法が紹介されました。

一つ目の提案（draft-barwood-dnsop-ds-publish-02）は、DSと同じフォーマットを持つ新しいリソースレコードであるCDS（Child DS）を導入し、

• 子は親に登録するためのDSを、CDSにより自分のゾーンで公開
• 親は子のCDSを定期的にチェックし、自分のゾーンのDSに自動的に反映

という手順により、KSKロールオーバーの自動化を実現しようとするものです。二つ目の提案（draft-mekking-dnsop-auto-cpsync-01）は、RFC 2136で定義されているDynamic Updateを用いて親のDSを更新するもので、従来からのNSレコードやグルーレコードの親子間における同期についても、その対象としています。

これらの提案はいずれも子による親のDSの能動的な更新を実現しようとするものであり、導入には慎重な検討が必要であるという意見が多く寄せられました。

また、DSの更新ではEPP（*6）やWebインターフェース、あるいは電子メールでの申請などが既に運用されており、導入の際にはそれらとの整合性の考慮が必要であること、WGにおける議論や提案はそれら既存の方法を置き換えるのではなく、新しいツールを提供する形が適切であるといった意見などが寄せられました。

 

weirds bar BOFを開催

IETF81ではWEIRDS（WHOIS-based Extensible Internet Registration Data Service）と呼ばれる、Webサービスを用いた次世代のWHOISについて議論するためのbar BOF（*7）が開催されました。

 

bar BOFでは現在のWHOISの問題点（標準的な国際化手法がない、構造・フォーマットなどが標準化されていないなど）が挙げられ、かつてWHOISを置き換えるために開発が進められたCRISP／IRIS（RFC 3981として2005年に標準化）がなぜ普及しなかったかについての考察が行われました。

考察では、IRISには満たすべき仕様が多い、いわゆる「ヘビーウェイト」なプロトコルであることから実装に工数を要することが理由の一つとして挙げられ、それを解決するためにWEIRDSではWebベースのプロトコル、いわゆるRESTful（*8）なWebサービスとすることが基本コンセプトとして示されました。

また、bar BOFでは問題点の確認と今後の方向性に関する指針が示され、今後メーリングリストで議論を継続していくこととなりました。

 

IEPGは、インターネットサービスオペレーターにより構成される、インターネット全体に関する運用環境や運用技術に関する技術的調整を円滑に進めるためのグループです。IEPGでは毎回、IETF Meetingに併設する形で会議を開催しており、初日（日曜日）の開催が通例となっています。

今回のIEPGでは、2011年6月に実施されたWorld IPv6 Day（*9）における状況が、関係者から集中的に報告されました。

 

今回はそれらの中から、RIPE NCCが世界中に設置している観測点（vantage points）における計測結果と、その分析により得られた知見についてご紹介します。

RIPE NCCにおける計測結果と得られた知見

RIPE NCCのバート・ウェイネン氏から、今回のWorld IPv6 Dayに参加した主なサイトについて、

• DNSにおけるA及びAAAAレコードの有無
• ping／ping6コマンド及びtraceroute／traceroute6コマンドの実行結果
• IPv4及びIPv6によるHTTP接続の状況の変化

の点に注目、分析した結果と得られた知見について発表がありました。

発表では、DNSの設定について、

• 参加サイトの権威DNSサーバーにおけるキャッシュ／ネガティブキャッシュのTTL値が大きかったため、World IPv6 Dayへの参加開始／終了が想定以上に遅れたサイトがあったこと

が報告され、それにより得られた知見として、

• 自サイトのTTL値の設定内容と、それによるデータの切り替わりのタイミングをあらかじめ把握しておくことが重要
• 障害発生時の切り戻しを円滑に実施できるように、設定変更に当たりTTL値を可能な範囲で短くしておくことが重要

が発表されました。

また、期間中に実際に発生したトラブル事例として、

• Webサーバーの設定ミスにより、IPv4では正常に表示されるサイトがIPv6ではエラー（ページが見つからない：404 Not Found）となった
• 期間終了後、AAAAレコードがDNS上やキャッシュ上に残っている間にIPv6のWebサーバーをシャットダウンしたため、接続障害や遅延が発生した
• IPv6接続をプロトコル変換装置経由で提供したため、すべてのIPv6アクセスが同一のIPv4アドレスからのアクセスと見なされ、予期しない帯域制限がかかり、接続障害が発生した

などが紹介され、こうした障害発生時における担当者への連絡方法やそのための連絡先データベースの維持管理、運用者向けメーリングリストやtwitterなどによる、即時性を持った情報交換が重要であることなどが挙げられました。

次回の第82回IETF Meeting（IETF82）は2011年11月13日から11月18日にかけて、台北で開催されます。なお、IETF81の全体会議（Plenary）において、会場確保の都合などからアジア地域での開催はその後しばらく予定されていないことが発表されています。

インターネットの標準化活動に直接参加できる機会として、IETF Meetingの場は貴重です。日本から参加しやすいアジア地域での開催となる、次回のIETF82にぜひ参加されてみてはいかがでしょうか。

本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。
「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。