=================================== __ /P▲ ◆ JPNIC News & Views vol.249【臨時号】2005.03.31 ◆ _/NIC =================================== ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ◆ News & Views vol.249 です ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2005年3月6日~11日の6日間にわたり米国・ミネアポリスで開催された、第62 回IETFのレポートを<前編><後編>に分けてお届けします。 今号では、<前編>として全体会議報告とIPv6関連WG報告をお送りします。 インターネット技術に関する最新動向満載ですので、どうぞじっくりご覧くだ さい。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ◆ 第62回IETF報告 <前編> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ …………………………………………………………………………………………… 1. 全体会議報告 JPNIC IPアドレス検討委員会メンバー NTT情報流通プラットフォーム研究所 藤崎智宏 …………………………………………………………………………………………… 2005年3月6日~11日まで、米国ミネアポリスのヒルトンホテルにて第62回 IETF(*1)が開催されました。ミーティング期間中は最高気温氷点下の日が続き、 また会議期間の後半では吹雪になるなど、極寒のIETFとなりました。 このところIETFへの参加人数は減少傾向ですが、今回は1,167名(IESG(*2)プレ ナリにおける発表)と、前回(第61回 ワシントンDC: 1,311名)、前々回(第60回 サンディエゴ: 1,469名)に比べ、今回は更に減少してしまいました。しかしな がら国別でみると前回の26国から28国に増えており、また、依然として多くの 企業からの参加があることから、標準化ミーティングとしての重要性には変わ りありません。なお、国別の参加人数比にはこのところそれほど変動はなく、 今回は米国、日本、韓国、ドイツ、といった順番になっています。 今回のIETFでは、約110のワーキンググループ(WG)ミーティング、及びBoFが 実施されました。また前回は全体会議が水曜日夜の一コマのみでしたが、今回 は通例通り、水曜日の夕刻、木曜日夕刻と2コマ開催されています。 ◆ IESG Plenary IETF Plenaryミーティングは3月9日(水)に行われ、IETF参加状況報告、ネット ワーク環境報告、RFCエディタやIANA(*3)からの報告等が実施されました。 今回はミーティングにスポンサーがつかなかったため、ボランティアベースで ネットワークの設営、運用が実施されたとのことでしたが、そのためか無線 LANの基地局が落ちたり、対外通信ができなくなったりと、ネットワークのク オリティに少々難がありました(全体会議中にも通信ができなくなったことが 数回ありました)。無線ネットワークに関しては、IETFでは暗号化なしのネッ トワークのみが提供されることが多いのですが、今回はそれに加え、固定WEP 暗号通信、所謂Dynamic WEP通信の3種がサポートされていました(もっともそ れに気がついていないユーザーも多かったようです)。 前回サンディエゴのミーティングからは、4つのWGが設立され、11のWGが閉鎖 されています。また、約55のRFCが発行された、との報告がありました。 また、IETFの議長がHarald Alvestrand氏からBrian Carpenter氏に代わったこ との紹介がありました。Harald Alvestrand氏は、2001年よりIETFの議長を務 め、その間IETFの組織変更等、重大な役目を果たされました。 次回のIETFは、2005年7月31日~8月5日、フランスのパリにてフランステレコ ムのスポンサーのもと開催されます。 ◆ IAB(*4) Plenary IAB Plenaryは3月10日(木)に行われ、IAB議長からの報告、IRTF(*5)よりHIP RG (Host Identity Protocol Research Group) からのプレゼンテーション、 技術トピックとしてボーイング社のモビリティシステムの紹介がありました。 IAB議長からは、最近のIABでの話題として、DNSでの「名前」と「サービス」 についての関連や、DNSを拡張する際の方式、NAT越え機構の選択などがあがっ ていることの報告や、IRTF、ISOC(*6)、IAOC(*7)に関連した活動の報告が ありました。 HIP RGの報告では、現在検討を進めているHIPプロトコルについての紹介があ りました。HIPは、TCP/IPスタックのネットワーク層において、現在一つとし て扱われている識別子情報(Identifier)と場所情報(Locator)を分離すること で、通信のIP層のプロトコル独立性の確保、マルチホームや移動ノードへの対 応を実現しよう、というものです。現在、テスト実装が公開されており、既存 の実装やインフラストラクチャへの影響、HIPの概念そのものの検討、DDos対 応、移動ネットワーク対応などの新機能の検討が進んでいるとのことです。 ボーイング社からは、現在ボーイング社が提供している航空機内インターネッ トについての技術解説のプレゼンテーションが実施されました。現在、航空機 内でインターネットサービスを提供するために、物理層としては衛星通信を、 IP の移動性を実現するためにはBGPを利用しているとのことで、航空機のよう な移動距離が多大になる場面ではホームネットワークとの距離のためにモバイ ルIP関連技術の適用が難しいこと、BGPによる移動性の実現を選んだ理由など の紹介がありました。移動時間の長い長距離路線でインターネットアクセスが できることは非常に便利だと思いますが、その反面、どこにいても仕事が降っ てくるようになるのはつらそうです。 (*1) IETF:Internet Engineering Task Force http://www.nic.ad.jp/ja/basics/terms/ietf.html (*2) IESG:Internet Engineering Steering Group http://www.nic.ad.jp/ja/basics/terms/iesg.html (*3) IANA:Internet Assigned Numbers Authority http://www.nic.ad.jp/ja/tech/glos-ij.html#02-IANA (*4) IAB :Internet Architecture Board http://www.nic.ad.jp/ja/basics/terms/iab.html (*5) IRTF:Internet Research Task Force http://rfc-jp.nic.ad.jp/what_is_ietf/ietf_section3.html (*6) ISOC:Internet Society http://www.nic.ad.jp/ja/tech/glos-ij.html#02-ISOC (*7) IAOC:IETF Administrative Oversight Committee …………………………………………………………………………………………… 2. IPv6関連WG報告 JPNIC IPアドレス検討委員会メンバー/ NTT情報流通プラットフォーム研究所 藤崎智宏 NTT情報流通プラットフォーム研究所 加藤淳也 …………………………………………………………………………………………… ◆IPv6(IP version 6)WG IPv6 WGは3月8日(火)の午後、一コマ実施されました。今回はアジェンダ数も 少なく、また、従来に比べて参加者も非常に少ない印象がありました。 話し合われた主なトピックスは、 ・ユニークローカルIPv6ユニキャストアドレス(Unique Local Address(ULA))」 について ・RFC3513(IPv6アドレス構造)、RFC2461(IPv6の近隣探索)、RFC2463(ICMPv6) の改版 ・IAB IPv6アドホック委員会の紹介 ・URIでのIPv6スコープの記述について などです。 IPv6 WGで扱っている、ドキュメントの現状については、 http://www.innovationslab.net/~brian/IETF62/IPv6/IPv6DocumentStatus.html にまとまっています。 ULAは、廃止が決まったIPv6サイトローカルアドレスの代替となるアドレスで、 その重要性からも標準化が急がれています。今回は、IESGからのDNS逆引きに ついての意見に対する議論がありました。IPv4のプライベートアドレスと同様、 ULAは広域インターネットでの利用は許されていませんが、このアドレスに対 するDNSのアドレス逆引き要求が広域インターネットに流出した場合の影響に ついての議論です。この問題は、主にオペレーションに関するものですが、 ULAの仕様文書に、問題の指摘、及び推奨対処方法を記述することになりまし た。 IAB IPv6アドホック委員会は、IPv6におけるアドレス割り振り手法や、逆引き DNS移行(ip6.int廃止)などを検討し、IANA等に情報提供を実施する委員会です。 この委員会は、最近増えてきたRIRからIANAへの大規模IPv6アドレス割り振り 要求に対して、割り振り可否の判断のための意見が欲しいというIANAの要請に よって組織されました。今後、長期的な観点からのIPv6アドレス利用について、 RIRへのIPv6アドレス委譲サイズ、ISPへのIPv6アドレス割り振りサイズに関す る提言を実施していく予定となっています。 URIでのIPv6スコープ記述についての議論では、URIにおいて、スコープ付き IPv6アドレスを記述する際の、スコープの記法についての問題提起です。現在 はアドレス記述に、[v6.fe80::cafe:f00d%de0]のように'%'を利用してスコー プを記述しますが、URI記法では%が別な意味を持っているため、これをどうす るか、というものです。別な記号を使う、URI仕様に従った表記を使う、等が 提案されましたが、メーリングリストにて継続議論となっています。 □IPv6 WG http://www.ietf.org/html.charters/ipv6-charter.html http://playground.sun.com/pub/ipng/html/ipng-main.html □第62回 IETF IPv6 WG のアジェンダ http://www.ietf.org/ietf/05mar/ipv6.txt (藤崎智宏) ◆v6ops (IPv6 Operations) WG IPv6の普及促進やIPv6ネットワークの運用技術を議論するv6ops WGは3月9日 (水)に2時間30分の一コマが設けられました。前回(第61回)のワシントンDCで の会合はv6ops WGの議論の進め方について大きな転機でしたが、第62回の会合 までにtc(tunnel configuration)BoFが立ち上げられ、トンネル(特にIPv4 ネッ トワーク上でIPv6を透過させるトンネル)を使った移行技術は議論の場がv6ops WGからtc BoFへ移されました。tc BoFの初会合も今回のIETFミーティングで開 催されました。その内容は別途報告します。これまでトンネル構成方法に多く の時間を費やしていたためすべての議題を消化し切れなかったり、議論の時間 が十分に取れないことがしばしばありました。しかし今回の会合からは、移行 に関する検討やセキュリティに関する考察など、本来v6ops WGが主要な課題と して扱うべき内容に十分な時間が割かれていました。 まずRFC2766(NAT-PT)をExperimental(実験的プロトコル)と位置づけ利用しな い方向となったこと、及びトンネル設定に関する議論が対象外となったことを 受け、チャータの見直しが行われました。実際にノウハウとして世の中で利用 されることを意識し、タイムスケールやオペレーターの実経験の重視が提唱さ れています。 目立ったセキュリティに関する議論として、NATを使ったIPv4環境において担 保されているセキュリティと、IPv6で実現されるセキュリティの比較を行い、 そのギャップを考察する発表がありました。IPv6のセキュリティはIPv4のそれ に比べて劣るものではありませんが、NATの有無やアドレッシング、運用形態 などから差異が生じる部分もあるため分析が行われていました。IPv6への移行 を達成する上でIPv4と同等かそれ以上のセキュリティを確保することは必要で あり、チェアを含めて高い関心が示されていました。現在、この内容はWGの課 題として扱われることが決まっています。 また第61回の会合に引き続き、WIDEプロジェクトによるIPv6Fixの活動内容が 報告されました。すでにIPv6が普及を始めていますが、いくつかの不具合が報 告されています。IPv6Fixは普及の阻害とならないようにこれらの問題対処す る活動です。今回の発表ではonlink assumptionと呼ばれるIPv6の仕様に基づ く不具合や、JPRSと共同で行った不適切な挙動を示すDNSの調査結果などが報 告されていました。実践的な手法や調査結果に対して会場から高い関心が示さ れていました。 □v6ops WG http://www.ietf.org/html.charters/v6ops-charter.html □第62回 IETF v6ops WG のアジェンダ http://www.ietf.org/ietf/05mar/v6ops.txt ◆tc (tunnel configuration) BoF tc(tunnel configuration)BoFでは、IPv4インターネット上でIPv6を透過させ るためのトンネルを自動設定する方式が議論されました。長らくv6ops WGにお いて扱われていたテーマでしたが、毎回議論が集中し多くの時間が割かれてい たため、v6ops WGから議論を分離することになりました。今回のtc BoFはその キックオフにあたる会合です。 IPv6 over IPv4トンネルにより接続性を提供するにあたり、想定されている利 用環境は、ISPはコアネットワークがIPv6に対応したものの、カスタマエッジ などアクセスネットワークの近傍がIPv6に未対応であり、顧客に対してIPv4の 接続性のみを提供している状況が仮定されています。また顧客はdual stackの 端末を持ち直接接続されているケースと、NAT対応のブロードバンドルータの 配下に接続されているケースが想定されています。日本国内でもIPv6ネイティ ブ接続サービスが提供されていないISPとその顧客の環境に合致する点も多い です。 今回のtc BoFで議論されたプロトコルや方式は、端末やブロードバンドルータ が、トンネルの終端となるホストを発見するエンドポイント発見方法と、その エンドポイントとトンネルリンクを自動設定するプロトコルです。前者のエン ドポイント発見のために、well-known IPv4 unicast addressを用いる方法や DNSに新しいリソースレコード(TEP RR)を設ける方法などが提案されました。 またトンネルの自動設定プロトコルについては、v6ops WGにて議論されている 当時からさまざまな手法が提案されています。今回のtc BoFでは下記の提案方 式が列挙されていました。 ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) STEP (Simple IPv6-in-IPv4 Tunnel Establishment Procedure) AYIYA (Anything In Anything) TSP (IPv6 Tunnel Broker with the Tunnel Setup Protocol) L2TP (Layer2 Tunneling Protocol) それぞれのプロトコルの概要説明と比較が行われ、リンク確立のネゴシエーショ ンや認証に必要なトラフィックのオーバーヘッド、またカプセル化のオーバー ヘッドなどの検討を行っていました。上記のようにたくさんの方式が並立して おり、今回のBoFでも議論は収束していません。すでにFreenet6(*8)で利用さ れているTSP(Tunnel Setup Protocol)は比較的支持を集めていましたが、標準 として採用するほど明確なコンセンサスが得られておらず、プロトコルの策定 にはしばらく議論が続くものと思われます。 ただし会場に集まった聴衆の関心は高く、WGとなるコンセンサスは取れていた ようです。WG化された場合はOPS(Operations & Management)エリアではなく INT(Internet)エリアに属することになります。 □第62回 IETF tc BoF のアジェンダ http://www.ietf.org/ietf/05mar/tc.txt ◆Multi6 WG/Shim6 BoF (Site MultiHoming by IPv6) 3月8日(火)の午後のセッションにてIPv6上のマルチホーム方式を検討する Multi6 WGの会合が開かれました。Multi6として開催されるセッションは今回 が最後となりクロージングを迎えます。以降は、新規に発足するShim6に検討 の場が移されます。これまでMulti6ではOPS(Operations & Management)エリア のWGでした。しかしMulti6 WGでは前回の会合の段階で、マルチホーム手法の 基本的な設計が終了したことと、実際にマルチホームに必要なプロトコルを策 定するため、INT(Internet)エリアへ議論の場を移すことになりました。Shim6 BoFについて詳しくは後述しますが、Shim6のチェアはMulti6のチェアがそのま ま留任となっています。最後の会合での議題ですが、目新しい提案はなくこれ まで提案されていたドラフトのアップデートがあっただけです。 failure-detection(通信パスの切断の検知方法)、hash-based address(アドレ スの安全な交換方法)、Multi6方式によるマルチホームでの機能項目の分析な ど、後継のShim6で要素技術となる方式について議論されました。議事は淡々 と進み、クロージングを迎えました。Multi6での議論の成果はShim6のインプッ トとして引き継がれます。 一方、Shim6はIETF会期最終日3月11日の午前のセッションにてキックオフBoF が開催されました。取り扱う内容はMulti6で検討されていたマルチホーム解法 を引き継ぎ、エリアを変更してMulti6で扱う範囲を少ししぼったものとなって います。当日の議論ですが、まずShimアーキテクチャのおさらいが提示されま した。ここで改めてその内容を復習すると、Shimアーキテクチャでは、レイヤ 3(IPv6層)とレイヤ4(トランスポート層)の間にShim層と呼ばれるレイヤを新た に導入します。またホストを特定する指示子としてULID (upper-layer identifier)なる概念を導入してレイヤ4以上からはこのIDを用いてホストを特 定します。Shim層がULIDとレイヤ3のIPv6アドレス(Shimアーキテクチャではロ ケータと呼ばれる)をマッピングする役目を担います。ULID はレイヤ4以上か ら参照されると述べましたが、IPsecが機能するような考慮も取り込まれてい ます。 当日の議論の様子に戻りますが、概念的なアーキテクチャの提示はあったもの の切断検知や上位層との連携など具体的な要素技術やプロトコルはまだ具体化 していません。参加者の中にはresearch groupでの研究が必要な段階ではない か?と意見もありました。またモビリティに関する機能を議論の対象として取 り込むべきか否か意見があり議論が巻き起こりましたが、時間内に収束しませ んでした。まだMulti6で積み残した課題が多数あり、標準の策定には長期化が 予想されます。 しかしながら、議論を継続させることについては会場から賛同が多数得られて おり、WGの設立のコンセンサスは取れていると思われます。 □第62回 IETF Multi6 WG のアジェンダ http://www.ietf.org/ietf/05mar/multi6.txt □第62回 IETF Shim6 BoF のアジェンダ http://tools.ietf.org/agenda/62/shim6.html □Shimアーキテクチャ "Architectural Commentary on Site Multi-homing using Level 3 Shim" http://www.ietf.org/internet-drafts/draft-huston-l3shim-arch-00.txt (*8) Freenet6:Hexago社が提供するIPv6アドレスへの接続性実証サービス http://www.freenet6.net/ (加藤淳也) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ わからない用語については、【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.249 【臨時号】 @ 発行 社団法人 日本ネットワークインフォメーションセンター 101-0047 東京都千代田区内神田2-3-4 国際興業神田ビル6F @ 問い合わせ先 jpnic-news@nic.ad.jp =================================== 登録・削除・変更 http://www.nic.ad.jp/ja/mailmagazine/ ■■◆ @ Japan Network Information Center ■■◆ @ http://www.nic.ad.jp/ ■■ Copyright(C), 2005 Japan Network Information Center