メインコンテンツへジャンプする

JPNICはインターネットの円滑な運営を支えるための組織です

ロゴ:JPNIC

WHOIS 検索 サイト内検索 WHOISとは? JPNIC WHOIS Gateway
WHOIS検索 サイト内検索

ニュースレターNo.41/2009年3月発行

第73回IETF報告 全体会議報告

はじめに

2008年は、IPv4アドレスの在庫枯渇や、DNSSECの導入、経路制御のセキュリティ、暗号アルゴリズムの移行など、インターネットの運用に関する話題に事欠かない年でした。

IETFの中の、これらの話題に関係するWGでは、インターネットのアーキテクチャを踏まえた上で、技術課題の解決に向けた議論が行われています。今回の第73回IETFでは、新たな経路制御アーキテクチャに関する議論とデザインを行うResearch Groupであるrrgと、NATの要件や挙動を明確化してIPv4とIPv6の相互の通信をサポートするBCPを策定するbehave WGに、各々三つの時間枠が取られていました。

通常、WGセッションの時間枠は一つか二つですので、通常のWGよりもアジェンダが多いことがうかがわれます。後半で簡単にご紹介したいと思います。

概要

第73回のIETFミーティングは、2008年11月16日から21日にわたって、アメリカのミネソタ州・ミネアポリスで開催されました。昼間の外気温は、摂氏マイナス6度と寒い時期です。しかし、ミネアポリスでは過去に5回IETFミーティングが開かれており、古参の参加者にとっては、おなじみの場所であるようです。

受付デスクでバッジなどを受け取った後の筆者
受付デスクでバッジなどを受け取った後の筆者

参加登録者数は962名で、前回に比べ221名減でした。国別の内訳は、第1位がアメリカ(50%)、2位が日本(10%)、3位はドイツ(5%)でした。初日はIEPGミーティングやチュートリアルが行われ、2日目以降にはWGのセッションが、4日目の水曜日にTechnical PlenaryとOperations and AdministrationPlenaryの二つのPlenaryが行われました。

ホスト企業はGoogle社で、Cisco社、Juniper社、Infoblox社の3社がスポンサー企業でした。

Technical Plenary

Technical Plenaryでは、ホスト企業であるGoogle社のプレゼンテーションとIABで議論が進められているドキュメント「Evolution of the IP Model」の紹介が行われました。

PlenaryのGoogle社のプレゼンテーションでは、Google社がIETFをサポートする理由として、オープンソースが真のオープンスタンダードにつながり、オープンスタンダードがインターネットの発展につながっていくのだ、という考え方が紹介されました。また4日目の昼休みに行われる、Google Open SourceProgramとAndroidに関する説明会のお知らせもありました。

□Google and Open Source
http://code.google.com/opensource/

「Evolution of the IP Model」は、さまざまなドキュメントで述べられていたIPのサービスモデルと、その発展についてまとめることを目的としたドキュメントです。

□Evolution of the IP Model
http://tools.ietf.org/id/draft-thaler-ip-model-evolution-01.txt

IPの基本的なモデルはRFC791に書かれており、例えば、送信前にあて先のホストとシグナリング処理を行わず、ただアドレスを指定して送信する、といったことや、パケットサイズが可変であるといったことが定義されています。また、IPで通信するホストの、トランスポートプロトコルに関する要件が書かれたRFC1122では、送信インタフェースの選択の仕方に応じて“Strong Host”や“Week Host”といった区別がされており、日頃意識はしていなくても、IPのサービスモデルに対して前提だと考えられている事が、いくつも存在していると言えます。

しかし、IPサービスモデルの発展に伴い、上位レイヤやアプリケーションがそのサービスモデルに期待してもいいこと、すなわち“前提”があいまいになってきており、場合によっては誤解されていると言われています。

この状況は、近年の新しいプロトコルを策定する場面で問題となっています。例えばStream Control Transmission Protocol(SCTP)※1のように優れたプロトコルでも、NATを超えられないという理由でインターネットで使えないことがあります。この問題は、NATを前提とするかどうかといった考え方の違いに直接的な原因があると言えますが、より広く捉えると、プロトコルの策定や実装の段階で、IPのサービスモデルに対して置かれている前提が、多くの人の間で共有できていないことに原因があると言えます。「Evolution of the IP Model」は、プロトコルの設計を行ったり、実装を行ったりする人が、同じ前提を持つことを目指して、上位レイヤやアプリケーションから見たIPサービスモデルの性質をまとめています。

Operations and Administration Plenary

Operations and Administration Plenaryでは、Postel ServiceAwardの発表とIETFチェアの活動報告などが行われました。

今回のPostel Service Awardは、10回目です。今年の受賞者はLa Fundacion Escuela Latinoamericana de Redes(EsLaRed)という非営利団体です。ラテンアメリカとカリブ海地域における情報通信技術の普及への貢献が称えられました。

□Coveted Jonathan B. Postel Service Award Granted to EsLaRed
http://www.isoc.org/awards/postel/eslared.shtml

IETFチェアのRuss Housley氏からは、IETFの概況が報告されました。現在115のWGがあり、第72回IETF以降、97のRFCが出ました。同じ期間に、新しいInternet-Draft(I-D)が389作成されました。この他の主な報告事項を以下にまとめます。

 - RFCの修正がまとめられる、ErrataのWebページに「ドキュメント更新待ち」のステータスが追加された。

□RFC Errata
http://www.rfc-editor.org/errata.php

 - IANAのリクエストの処理状況が公開されており、処理待ちは、常に15以下に抑えられている。

□IANA Statistics for IETF-related Requests
http://www.iana.org/about/performance/ietf-statistics

  - IETFのドキュメントやWGの議事録などをさかのぼって閲覧できるDatatrackerのプログラムが、第73回IETFミーティングが始まる前日の2008年11月15日に開かれたイベント、“Code Sprint”を通じてバージョンアップした。

□datatracker(デフォルトでI-D Trackerが表示される)
http://datatracker.ietf.org/
全体会議の様子
全体会議の様子

ホットな話題に関係するWG/RG

最後に、冒頭であげた話題に、IETFではどのようなWGが関係しているのかについて、筆者なりに紹介したいと思います。IETFのWGは多数あり、カバーできていない可能性がありますので、ご参考程度に留めてください。

IPv4アドレスの在庫枯渇とIPv6

IEPGミーティング
http://www.iepg.org/
RIRの動向に加えて、4バイトAS番号の利用状況などを含めたインターネット経路制御やDNSSECについての議論も行われている。

behave WG
http://www.ietf.org/html.charters/behave-charter.html
NATの要件や挙動を明確化してIPv4とIPv6の相互の通信をサポートするBCPを策定するためのWGである。IPv6のためのNATやCarrier Grade NAT(CGN)も主にこのWGで議論されている。

v6ops WG
http://www.ietf.org/html.charters/v6ops-charter.html
IPv6の運用に関するWGで、IPv6の普及動向やトンネル技術、NAT技術等多岐にわたって議論されている。

6man WG
http://www.ietf.org/html.charters/6man-charter.html
IPv6プロトコルのメンテナンスを行うWG。実装の上で明らかになった課題にも取り組んでいる。

経路制御のセキュリティ

sidr WG
http://www.ietf.org/html.charters/sidr-charter.html
経路制御プロトコルの新しいセキュリティ・アーキテクチャについて議論しているWG。主にリソース証明書について議論されている。経路制御プロトコルとの関係については、rpsec WGでまとめられたセキュリティ要件が引き合いに出されることがある。

DNSSEC

dnsext WG
http://www.ietf.org/html.charters/dnsext-charter.html
DNSSECを含めたDNSの拡張について扱うWG。DNSSECに関するRFCが多数出されている。dnsopWGでも、関連するI-Dが作られている。

暗号アルゴリズムの移行

pkix WG
http://www.ietf.org/html.charters/pkix-charter.html
PKI関連のドキュメントを扱うWG。電子証明書で使われる暗号アルゴリズムについて議論されている。

s/mime WG
http://www.ietf.org/html.charters/smime-charter.html
S/MIMEのメッセージ形式であるCMSで、扱うことのできる暗号アルゴリズムについて議論されている。最近の2回のIETFでミーティングは行われなかったが、MLでの議論は行われている。

tls WG
http://www.ietf.org/html.charters/tls-charter.html
TLSにおける暗号アルゴリズムについて議論されている。TLSにおける共通鍵暗号についても、I-Dが作成されている。

新たな経路制御プロトコル

rrg
http://www.irtf.org/charter?gtype=rg&group=rrg
経路制御プロトコルの多岐にわたる問題解決や再検討を行うResearch Group(Internet Research Task Force(IRTF)のグループ)である。最近のミーティングでは、LISP(Locator/ID Separation Protocol)の実装に関する話題が多いようである。


次回の第74回IETFミーティングは、2009年3月22日から27日に、アメリカのサンフランシスコで行われます。

なお、既にご存知の方はいらっしゃるかと思いますが、2009年11月の第76回IETFは、日本の広島で開催される予定です。ホストを務めるのはWIDEプロジェクトです。この機会を生かして、IETFのディスカッションに参加されてみてはいかがでしょうか。インターネットのアーキテクチャや、最新のプロトコルに関する本場の議論に、気軽に参加できるチャンスだと思います。

(JPNIC 技術部/インターネット推進部 木村泰司)


※1 Stream Control Transmission Protocol(SCTP)
SCTPは、通信相手と複数の論理的なパスを確立できる、コネクション型のトランスポートプロトコルです。一つのネットワークインタフェースが使えなくなるなど、TCPではコネクションが失われてしまうときにも、別のパスに切り替えることでコネクションを継続できる「パス管理」の機能を持っています。コネクションを維持したまま無線LANと有線LANを切り替えたり、別のネットワークに移ったりすることを実現する応用方法が研究・開発されています。

このページを評価してください

このWebページは役に立ちましたか?
よろしければ回答の理由をご記入ください

それ以外にも、ページの改良点等がございましたら自由にご記入ください。

回答が必要な場合は、お問い合わせ先をご利用ください。

ロゴ:JPNIC

Copyright© 1996-2024 Japan Network Information Center. All Rights Reserved.