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

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

ロゴ:JPNIC

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

ニュースレターNo.39/2008年7月発行

IPv6関連WG報告

2008年第一回のIETFは、2008年3月9日(日)から3月14日(金)まで、米国フィラデルフィアにて開催されました。3月8日は、米国中部で天候が荒れ、乗り換え便が遅れたため、到着が真夜中になるなど、日本からの参加者に少なからず影響が出たようです。

本稿では、会期中に議論された、IPv6に関連したトピックスをいくつか紹介します。

IEPGミーティング(Internet Engineering and Planning Group)

IEPGミーティングは毎回、IETFミーティングが始まる直前、日曜日の午前中に開催されています。今回は、IPv6関連トピックスとして、Randy Bush氏より、NANOG(The North American Network Operators' Group)ミーティング、APRICOT(Asia Pacific Regional Internet Conference on Operational Technologies)ミーティングの会場ネットワークで実施された、IPv6 only環境実験の報告がありました。これは、多くの人にIPv6が利用可能なことを知ってもらうこと、ならびに実際に利用した際に問題点を発見することを目的として大々的に実施されており、今回のIETFのネットワークでも実施されていました。

環境としては、IPv4によるインターネット接続性の提供を停止し、IPv6/IPv4変換を実施するプロトコルトランスレータと、IPv4ノードへのDNSクエリをIPv6に見せかけるALG(Application Level Gateway)を設置するというものでした。実験結果として、多くの人が、IPv6のみの環境でもインターネットアクセスができたとレポートしていること(実利用に足りたのは、参加者の半数にも満たなかったとのことですが)、UNIX以外のOSでは不具合が発見されたこと、中でもMacOSでは、DNS周りに大きな問題があることなどが報告されていました。

□IEPGのWebサイト
http://www.iepg.org/

6man WG(IPv6 Maintenance WG)

6man WGは、IPv6のプロトコル自体のメンテナンスを実施するWGです。今回は、水曜日の午前中にミーティングが開催されました。主な議題として、

  • ノード要求仕様の改訂(draft-ietf-6man-node-req-bis)
  • IPv6のサブネットモデルに関する議論(draft-wbeebee-on-link-and-off-link-determination)
  • IPv6アドレス選択機構(draft-ietf-6man-addr-select-sol)
  • IPv6拡張ヘッダに関する議論
    • draft-krishnan-ipv6-hopbyhop
    • draft-krishnan-ipv6-exthdr

などが挙げられます。「ノード要求仕様の改訂」は、現在、RFC4294として出版されている「IPv6 Node Requirements」文書を改版しようという提案です。

今回の大きなポイントとしては、IPv6では従来、ノードに実装が必須とされていたIPsecを、必須条件から外してはどうかというものでした。これは、センサーなどの非力なノードではIPsecの実装が困難なこと、また、他のセキュリティ機構が存在する場合などには、IPsecが必ずしも必要でない場合があるということが議論の根拠となっています。しかしながら、IPsecを必須条件から外すことは、RFC2460など、既存のIPv6の基本文書に対する影響が大きいことや、IETFの他のエリアへの影響もあることから、まずはセキュリティエリアのディレクタに問い合わせることになりました。ミーティング会場での雰囲気では、数的にはIPsecを必須条件から外すことへの賛同の方が多かったものの、反対もそこそこ多く、合意にはまだ時間を要しそうです。

「IPv6アドレス選択機構」は、アップリンクを複数持つサイトの場合、ノードは、それぞれのアップリンクから割り当てられた複数のIPv6アドレスを持つため、通信の際に通信相手に応じた適切なIPv6アドレスを始点アドレスとして選択しないと通信に失敗することがあるという問題を、どのように解決するか、という議論です。v6ops WGにて、アドレス選択機構に対する問題提起および要求条件文書の議論を終え、前回のIETFから、解決方法を6man WGにて議論することとなっています。四つの解決方法が提起されており、そのうちの一つであるDHCPv6を用いた方法の利点が重点的に主張されました。白熱した議論となり、一定の賛同はありましたが、アドレス選択機構は重要であり、広い視点からの解決案の検討が必要であるなどの意見もあり、継続議論となっています。

「IPv6拡張ヘッダに関する議論」では、基本拡張ヘッダの一つであるhop-by-hopオプションについて、不正な利用の可能性があるため、何らかの対処をとるべきであるという問題提起がなされました。オプションを廃止するといった案も出されましたが、廃止ではなく、何らかの解を検討することになりました。同時に、IPv6の拡張ヘッダについて、標準フォーマットを規定すべきである、という提案もなされました。IPv6拡張ヘッダは、基本フォーマットが定義されていない、新規に定義された場合には、既存実装では拡張ヘッダのサイズがわからない可能性があります。これを防ぐため、標準的なTSVフォーマット(Type/Size/Value)を導入しようというものです。これについては賛同が多く、WGとして検討していく方向となっています。

6man WGですが、前回に引き続き、今回も既存仕様に手が入るような提案がなされています。引き続き、動向に注視する必要があります。

□6man WG
http://www.ietf.org/html.charters/6man-charter.html
□第71回IETF 6man WGのアジェンダ
http://www3.ietf.org/proceedings/08mar/agenda/6man.html
写真:トランスレータ実験
comcast社提供による会場のネットワークのトランスレータ実験
(写真提供: 前田朋孝氏(京都大学/WIDE Project))

v6ops WG(IPv6 Operations WG)

IPv6とIPv4の共存技術、IPv6のディプロイメントに関する話題を扱うv6ops WGのミーティングは、前回に引き続き、Transition session、General sessionの2コマがそれぞれ、火曜午前と、金曜午前に開催されました。IPv4アドレス在庫枯渇が現実味を帯びてきたこともあって、IPv6への注目度は高まっているためか、1コマ目のセッションでは、ミーティングに用意された部屋が人でいっぱいになり、急遽さらに広い部屋に移るという事態になりました。また、当初のプログラムでは、それぞれの提案は、その内容に応じて関連した方のセッションに割り振られていましたが、時間や話者の都合により、実際にはセッションタイトルにほぼ関係なく、提案と議論が行われました。

Transition sessionの時間では、主にIPv6の導入に関し、さまざまな議論が実施されました。今回は特に、移行に関する技術的なトピックスのみでなく、移行を促すためにいつまでに何をしなければならない、といった「移行プラン」を制定しよう、という話がありました。これについては、かなり多くのコメントがあり議論されましたが、政策的な話はIETFですべきでない、といったコメントもありました。

その他、「現状あるIPv4/IPv6共存技術とIPv6移行技術と、IPv6/IPv4混在状態の分析」、「移行時のインターネット接続ノードに対する要求条件(既存IPv4ノードに対し、変更を求めてはならないなど)」、「上位プロトコルへの影響などの各種要求条件」に関する議論がありました。また、IPv4アドレス在庫がなくなった後でもIPv4インターネットへの接続性を提供するため、「トランスレーション技術を用いてIPv6ネットワーク上でIPv4パケットを通過させる技術(v4v6v4)の提案」などが実施されました。後者のトランスレーション技術については、IETF71の会場ネットワークに実装され、実地でその有効性がデモンストレーションされていました。

また、移行技術ではありませんが、IPv6にてエンドユーザーにアドレスブロックを割り当てる際には、DHCPv6-PDが利用されることが多くなっており、その際に割り当てたアドレスブロックに対する経路情報をどのようにISP内に注入すべきかについて、議論がありました。これは、DHCPの標準化を実施しているDHC WGで始まった議論ですが、オペレーションの観点からのコメントが募集されています。

金曜日のGeneral sessionでは、Transition以外のv6ops WGの継続的案件と、火曜日に残った議題などに関して議論が行われました。IETFの正式な会期は金曜日午前中までとなっていますが、従来から、このコマに割り当てられるセッションは少なく、また、人の多く集まるセッションは木曜日までに終了していることが多いことから、金曜日には会場にいる人が少なくなっています。今回も、火曜日に比べてかなり人の少ないセッションとなっていました。

議論は、エンドサイトに対するIPv6アドレス割り当てサイズを定義しているRFC3177の見直しから開始されました。このRFCでは、エンドサイトに割り当てるIPv6アドレスサイズを/48にすることが規定されており、実際にアドレス配布を実施しているRIRでも、以前はこの文書に合わせて推奨割り当てサイズを/48としていました。しかしながら、主にアドレスの無駄使いを防ぐ、といった観点から、この割り当てサイズの変更が議論になり、RFC3177の改版議論と併せて、RIRでの推奨割り当てサイズの変更が実施されました。

RFC3177の改版は途中、議論が沈静化したこともあり、しばらく放置されていましたが、今回、再び議題に挙げられ、議論が実施されました。しかしながら、以前の議論の際にも問題となった、アドレス割り当てサイズに関する内容は、IETFで議論するものではないといった意見や、技術に特化した内容にすべきだという意見など議論が収束せず、引き続きメーリングリストで議論することとなっています。この他、Transition sessionの残議題として、IPv6/IPv4トランスレータに関する議論、また、前回から引き続き、不正ルータ広告の防止に関する議論、カスタマサイトにおけるセキュリティ確保に関する議論などが行われました。参加人数はそれほど多くありませんでしたが、活発な議論となりました。

□v6ops WG
http://www.ietf.org/html.charters/v6ops-charter.html
http://www.6bone.net/v6ops/
□第71回IETF v6ops WGのアジェンダ
http://www3.ietf.org/proceedings/08mar/agenda/v6ops.html

第71回IETFミーティングの各種情報は、以下のURLより参照可能です(いくつかのWGでは、議事録も掲載されています)。

□全体プログラム、WGアジェンダ、発表資料
https://datatracker.ietf.org/meeting/71/materials.html
 (2009年4月16日現在、 http://www.ietf.org/proceedings/08mar/ に移動)
□録音
http://videolab.uoregon.edu/events/ietf/
 (2009年4月16日現在、 ftp://videolab.uoregon.edu/pub/videolab/media/ietf71/ に移動)

(NTT情報流通プラットフォーム研究所 藤崎智宏)

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

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

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

ロゴ:JPNIC

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