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

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

ロゴ:JPNIC

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

ニュースレターNo.52/2012年11月発行

第84回IETF報告
IPv6関連WG報告
~6man WG、v6ops WG、softwire WGについて~

6man WG (IPv6 Maintenance WG)

6manは、IPv6仕様の軽微なメンテナンスを行うWGです。新たなトピックを含め、今回のセッションでは、9個のドキュメントについて議論が行われました。そのうち、新規のものやWGアイテム採択が決まったものなどを中心に、概況をお伝えします。

  1. Reliable Router Solicitations(信頼性のあるルータ要請メッセージ)
    draft-krishnan-6man-resilient-rs-01.txt

    現在の仕様では、RS (Router Solicitation)メッセージは、ネットワークインタフェースの初期化時に規定回数送信するのみとなっています。これらのパケットが到達しなかった場合、または到達してもその応答のRA (Router Advertisement)がホストに到達しなかった場合には、ホストはルータが不在であると見なし、それ以降RSメッセージの送信は行わないようになっています。しかし、パケットがロストした場合に備えて、信頼性を向上させるため、RSを送信し続けるべきであるとの提案がなされました。この提案は賛成者多数で、WGアイテムとして採択される見込みとなっています。

  2. Optimal Transmission Window Configuration Option for ICMPv6 Router Advertisement(ICMPv6ルータ広告の最適転送ウィンドウ設定オプション)
    draft-savolainen-6man-optimal-transmission-window-00.txt

    テザリング機能を持ったスマートフォンなど、バッテリーの制約が厳しい装置がゲートウェイとして動作する場合、その装置の配下にある複数端末から定期的にパケットが送信され、またそれらの端末が非同期的にパケットを送信する場合に、3Gリンクのアップダウンが頻繁に繰り返され、バッテリーの消費が激しくなることが問題として提起されました。その解決策として、RAを拡張し、これらの定期的なパケットの送信タイミングを合わせるような送信ウィンドウ情報を、端末に配布する提案がなされました。しかし、「こういった下位レイヤの情報を、RAというIPレイヤのパケットで配布するべきではない」といった意見や、「送信間隔を合わせるためにゲートウェイ装置においてキャッシュ機能が必要となり、アプリケーションへの影響が懸念される」などの慎重意見が出され、WGアイテムとしての採択には至りませんで した。

  3. Security Implications of Predictable Fragment Identification Values(予測可能なフラグメントID値のセキュリティ問題)
    draft-gont-6man-predictable-fragment-id-02.txt

    IPv6でパケットを断片化する際、断片の識別子に予測可能な値を用いていると、攻撃に利用される可能性があり、これを乱数化するべきであるとの提案です。実際にいくつかの実装における対応状況の紹介もあり、既に修正が施されている実装もあるものの、今後新規に出てくる実装などのために、RFCの修正という形で対応すべきである、との提案がなされました。これを受けての議論は「この問題を一般化し、IETF全体としてこのような予測可能な値を初期値として利用することに対して、警鐘を鳴らすような技術文書を発行すべきではないか」といった話題が中心となりました。この問題に対するIAB(Internet Architecture Board)による一般的な勧告文書の発行と、プロトコル個別の対応が、並行して進められる見込みとなっています。

  4. Current issues with DNS Configuration Options for SLAAC(DNS設定オプションの現在の問題点)
    draft-gont-6man-slaac-dns-config-issues-00.txt

    RFC6106において、RAを用いてDNSサーバ情報を配布するオプションが規定されていますが、この方式の問題点が指摘されました。複数のルータが存在する場合に、使用するDNSサーバがフラッピングしてしまうこと、またこのオプションの有効期間が短いため、RAがロストした場合に、ホストが利用できるDNSサーバ情報が無くなってしまい、通信ができなくなってしまう、という問題点が指摘されました。その解決策として、受信側で対処する方法なども含め、いくつかの方法が提示されましたが、「仕様上のバグである」という認識が大勢を占め、「既存の仕様を修正する」という方向で進められることになりました。

v6ops WG (IPv6 Operations WG)

v6opsは、IPv6の運用やIPv6への移行技術について議論を行うワーキンググループ(WG)です。今回もトピックが多く、会期5日目の2012年8月2日(木)と、最終日の3日(金)のそれぞれ午前中、2日間にわたってセッションが行われました。その中でいくつか興味深かったトピックの概況をお伝えします。

  1. 464XLAT: Combination of Stateful and Stateless Translation(ステートフルとステートレスプロトコル変換の組み合わせ)
    draft-ietf-v6ops-464xlat

    IPv4からIPv6、そしてIPv6から再度IPv4へのプロトコル変換を行うことにより、IPv6 onlyのバックボーンを経由して、IPv4の接続性を実現する方式の提案です。既存の技術を組み合わせた方式であり、新たなプロトコルの策定は不要であることが特徴です。後述するsoftwire WGのスコープと一部重複しているとの意見があり、標準化を進めるWGをどこにするべきか、などについて議論がありましたが、今回のセッションではv6opsでBCP(Best Current Practice)として標準化を進めるという方向が示されました。ただ、Informationalではなく、BCPということで、どういった環境・適用先(Applicability)において“Best”なのか、について明示することを求められ、それを盛り込んだ改版文書をもって、WGLC(WG Last Call)を開始することになりました。

  2. Semantic IPv6 Prefix(意味を持たせたIPv6プリフィクス)
    draft-jiang-semantic-prefix

    「これは悪いアイデアである」と断った上で提案されたのが、IPv6 PrefixにSemantics(意味付け)情報を埋め込む、という方式です。「IPv6のアドレス空間を浪費することになり、短所があることは認めるが、ただ多くのサイトにおいて意味を持たせたアドレッシングを行われることが予想されるため、それをよりうまくする方法を考えよう」という趣旨の提案でした。しかし会場からは、「そもそものモチベーションが理解できない」、「現状で問題無い」また「意味を持たせていることがサイト外に知られた場合にセキュリティ脅威となる」などの否定的な意見が大勢を占める結果となりました。

また、次回のIETF85会合よりも前に、v6ops WGの中間会合(Interim Meeting)の開催を検討しているとのアナウンスがありました。RIPE65ミーティングと併催する形で、2012年9月29日(土)を予定しているとのことです。

softwire WG

softwireは、IPトンネルを用いてアクセス網などのネットワークを構成する技術を扱うWGですが、ここ数年はもっぱら、ISPなどのアクセス網におけるIPv4アドレス在庫枯渇対策・IPv6移行促進技術についての議論がメインのトピックとなっています。

これまで、IPv6バックボーンを介して、アドレス共有されたIPv4の接続性を提供し、かつユーザー単位でのステートは中継装置において保持しない方式について議論が活発に行われてきました。前回のIETF会合では、MAP-E/MAP-Tおよび4rd-Uと呼ばれる方式が対立し、投票の結果ほぼ同数となり、その後メーリングリスト(ML)上で、対立する両方式をどちらもWGアイテムとして採択し標準化を進めるという、チェアからの提案があったという経緯がありました。しかし、両方式はやはり目的・適用先が同一であるため、IETFの基本原則に則って方式を1本化すべきである、との意見が多く、今回のセッションでも1本化のための議論が行われました。

MAP-E、MAP-T、4rd-U改め4rdという三つの方式についてその差分を明確にし、その差分が重要であるかどうか、という議論が行われた後に、まず、MAP-EとMAP-Tという方式を一つの方式と見なすべきか、それとも別々の方式と見なすべきか、という挙手が行われました。挙手の結果は、ほぼ同数となったため、ここで異例のコイントスによって、別々の方式と見なすべきである、とその場では結論づけられました。その後、三つの方式について挙手が行われ、MAP-EがMAP-Tおよび4rdに大差を付ける票を獲得しました。正式にはMLでの投票をもって決定されますが、長らく続いたこの議論にようやく終止符が打たれる見込みであり、標準化の先行きが不透明であったために実装・導入をためらっていたベンダー・事業者が動き出すことになるかもしれません。

画面:● ミーティングのアジェンダのAndroidアプリ
● ミーティングのアジェンダはAndroidアプリとしても配布されています

(NTTサービスインテグレーション基盤研究所 ネットワーク技術SEプロジェクト 松本存史)

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

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

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

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

ロゴ:JPNIC

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