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

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

ロゴ:JPNIC

WHOIS 検索 サイト内検索 WHOISとは? JPNIC WHOIS Gateway
WHOIS検索 サイト内検索
===================================
    __
    /P▲         ◆ JPNIC News & Views vol.600【臨時号】2008.12.16 ◆
  _/NIC
===================================
---------- PR --------------------------------------------------------
━━━ 未来へ加速するチカラ「smartSTREAM(スマートストリーム)」━━━
★★★ 大規模イベントのライブ中継実績多数あり!! ★★★
ブロードバンド&ユビキタス時代の映像配信をトータルサポートします。
詳しくは…>>http://www.smartstream.ne.jp/
━━━━ NTTスマートコネクト(株) info@nttsmc.com ━━━━━━━━━
----------------------------------------------------------------------
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.600 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2008年11月16日から21日の6日間にわたり、アメリカのミネアポリスで開催さ
れた第73回IETFのレポートを、本号より連載でお届けします。

まず[第1弾]として、本号では全体会議の報告をお送りします。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第73回IETF報告 [第1弾]  全体会議報告
                           JPNIC 技術部/インターネット推進部  木村泰司
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◆はじめに

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 Administration Plenary
の二つのPlenaryが行われました。

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


◆Technical Plenary

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

PlenaryのGoogle社のプレゼンテーションでは、Google社がIETFをサポートす
る理由として、オープンソースが真のオープンスタンダードにつながり、オー
プンスタンダードがインターネットの発展につながっていくのだ、という考え
方が紹介されました。また4日目の昼休みに行われる、Google Open Source 
Programと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)(*)のように優れたプロ
トコルでも、NATを超えられないという理由でインターネットで使えないこと
があります。この問題は、NATを前提とするかどうかといった考え方の違いに
直接的な原因があると言えますが、より広く捉えると、プロトコルの策定や実
装の段階で、IPのサービスモデルに対して置かれている前提が、多くの人の間
で共有できていないことに原因があると言えます。
「Evolution of the IP Model」は、プロトコルの設計を行ったり、実装を行っ
たりする人が、同じ前提を持つことを目指して、上位レイヤやアプリケー
ションから見たIPサービスモデルの性質をまとめています。

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


◆Operations and Administration Plenary

Operations and Administration Plenaryでは、Postel Service Awardの発表
と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が
            多数出されている。dnsop WGでも、関連する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用語集】をご参照ください。
            http://www.nic.ad.jp/ja/tech/glossary.html
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
___________________________________
■■■■■  JPNICの活動はJPNIC会員によって支えられています  ■■■■■
  :::::  会員リスト  :::::  http://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト ::::  http://www.nic.ad.jp/member/(PASSWORD有)
□┓ ━━━  N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛          お問い合わせは  jpnic-news@nic.ad.jp  まで          ┗┛
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
===================================
 JPNIC News & Views vol.600 【臨時号】

 @ 発行         社団法人 日本ネットワークインフォメーションセンター
                 101-0047 東京都千代田区内神田2-3-4 国際興業神田ビル6F
 @ 問い合わせ先   jpnic-news@nic.ad.jp
===================================
___________________________________
           本メールを転載・複製・再配布・引用される際には
       http://www.nic.ad.jp/ja/copyright.html をご確認ください
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
登録・削除・変更   http://www.nic.ad.jp/ja/mailmagazine/


■■◆                          @ Japan Network Information Center
■■◆                                     @  http://www.nic.ad.jp/
■■

Copyright(C), 2008 Japan Network Information Center

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

このWebページは役に立ちましたか?
ページの改良点等がございましたら自由にご記入ください。

このフォームをご利用した場合、ご連絡先の記入がないと、 回答を差し上げられません。 回答が必要な場合は、お問い合わせ先をご利用ください。

ロゴ:JPNIC

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