ニュースレターNo.54/2013年7月発行

IPv6関連WG報告

6man WG(IPv6 Maintenance WG)

6man WGは、IPv6プロトコルのメンテナンスを目的としたWGです。今回は会期最終日となる2013年3月15日(金)のタイムスロットで行われたため、発表者のフライトの都合を考慮し、WGアイテム、メーリングリスト(ML)で活発に議論されているドラフト、その他のドラフトという順番に入れ替えて、プレゼンテーションが行われました。

今回は6man WGのチャーター変更に関する議論が行われ、インタフェースIDのU/Gビットにおける問題や、フラグメントおよび拡張ヘッダに関する取り組み、IPv6 over Foo(何らかの仕組み上でIPv6を使用)に関する取り組みが追加アイテムとして挙げられ、その他にもいくつか検討すべき追加アイテムの案が挙げられました。WGチェアとしては、検討アイテム以外にもコミュニティが必要としているものがあれば、これらの検討アイテムはそれを妨げるものではないとの考えを示しており、既に活動中のWGにおいては、チャーター変更はWGの活動に大きな影響を与えるものではないと感じました。

今回のセッションで議論が行われた、いくつかのトピックについてお伝えします。

現在のインターネットにおいては、IPv6拡張ヘッダがトランスペアレントに取り扱われているとは言えず、将来の拡張用に定義されたTLV形式の拡張ヘッダフォーマット(RFC 6564)を解釈できないルータやFirewallも多数存在しています。このような現状において、中間ノードであるそれらの装置が拡張ヘッダをどのように取り扱うべきかを明文化することで、問題を少しでも減らしたいというのがこの提案のモチベーションになっています。

この提案ではいかなる拡張ヘッダも転送すべきであり、Firewallなどのノードでは新規の拡張ヘッダも識別して、default設定では定義されているすべての拡張ヘッダを許容すべきとされています。またホップバイホップオプションについては、高性能ルータなどでは破棄されたり、スローパスとして扱われたりすることが想定される旨の記載が含まれています。

プレゼンテーションの最後に本提案をWGアイテムとして採択すべきかハミングが行われ、賛同者が多かったため、ML上で最終的なコンセンサス確認が行われることになりました。

※ その後、ML上でのコンセンサス確認の結果、2013年3月30日(土)にWGアイテムとして正式に採択されています。

RFC 4291にて定義されているU/Gビットは、主にModified EUI-64フォーマット生成時に用いられており、その他にはPrivacy Extensions for SLAAC(RFC 4941)、CGA(RFC 3972)、HBA(RFC 5535)、4rd(draft-ietf-softwire-4rd)などで定義されているものの、意味を成す値として用いられていません。また、それぞれの定義においても一貫性が無く、あいまいな情報として現状取り扱われているため、混乱を避けるためにU/Gビットの定義を明確に記述しようというのが本提案です。U/Gビットの有用性としては、インタフェースIDがModified EUI-64フォーマットで生成されている場合に、MACアドレス情報に変換できることから運用面で故障診断の助けになったり、U/Gビットを考慮したインタフェースID生成を行っている方式であれば、インタフェースID重複の可能性を低減させることができたりすることなどが挙げられます。

会場からは、Modified EUI-64フォーマットについて明確に記述した方がよいという意見や、IPv6 Addressing of IPv4/IPv6 Translators(RFC 6052)もU/Gビットを考慮しているので参照した方がよいといった意見がありました。

なお、その後のプレゼンテーションでは、6man WGチェアであるBob Hinden氏より6man WGのMLで行われた多くの議論の結果として、インタフェースIDには特別な意味を持つビットは無く、いかなる文書もインタフェースIDに意味を持たせるべきではないとの結論に至ったことが説明されました。

ISATAP(RFC 5214)などはインタフェースIDに独自の定義を行っているという会場からの意見に対しては、各ドキュメントで独自の定義を行うことは構わないが、それ自体は何ら保障が無いものである(例えばインタフェースIDの競合は無いと想定することはできない)と発言されました。

本提案をWGアイテムとして採択すべきかどうかは、ML上でコンセンサス確認が行われることになりました。

※ その後、ML上でのコンセンサス確認の結果、2013年3月30日(土)にWGアイテムとして正式に採択されています。

本提案は、Unicast-Prefix-based IPv6 Multicast Addresses(RFC 3306)や、Embedding the Rendezvous Point(RP) Address in an IPv6 Multicast Address(RFC 3956)にてreservedとして定義されている領域(17-20ビット)を、すべてのIPv6マルチキャストアドレスで汎用的に使用可能なフラグとして定義しようというものです。この新しいマルチキャストアドレスのフォーマットの定義により、あいまいなフラグの解釈を明確にしつつ、将来の拡張も容易にしていこうというものです。本提案では、これを実現するために分離されているビットを、フラグビットとして取り扱うことをMUST要件としています。

会場からは、マルチキャストのフィルタリングを行う際にこのフラグビットが影響を与えるかもしれないので、このビットを独立したビットとして扱うか、あるいはビットのグループとして扱うかを明確にする必要があるとのコメントがありました。提案者からは、これはIPv6マルチキャストが広く普及する前に定義を変更する、最後のチャンスであるとの考えが示されました。

プレゼンテーションの最後に本提案をWGアイテムとして採択すべきかハミングが行われ、賛同者が多かったため、ML上で最終的なコンセンサス確認が行われることになりました。

※ その後、ML上でのコンセンサス確認の結果、2013年3月30日(土)にWGアイテムとして正式に採択されています。

□6man WG
http://tools.ietf.org/wg/6man/

□第86回IETF 6man WGのアジェンダ
http://www.ietf.org/proceedings/86/agenda/agenda-86-6man

v6ops WG(IPv6 Operations WG)

v6ops WGは、IPv6運用上の問題解決のための議論を第一優先として、その他にはIPv6普及に向けた運用上のガイドラインなども取り扱うWGです。2013年3月11日(月)と13日(水)の二つのタイムスロットで実施されましたが、いずれのタイムスロットでも、予定していた時間よりかなり早く終了するという状況でした。

今回のセッションで議論が行われた、いくつかのトピックの概要についてお伝えします。

本ドキュメントは、NAT64の展開シナリオと運用上の経験について記載されたもので、Working Group Last Call(WGLC)を終えた段階にあります。今回のプレゼンテーションは、WGLC中に寄せられたコメントとしてStateless NAT64に関する記述を含めるかどうかと、今後の進め方について確認を求めるものでした。また、WGLC中のコメントなどフィードバックが少なかったため、このまま標準化を進めるべきかどうか提案者としては懸念している、という発言がありました。

会場からは、タイトルがExperienceからConsiderationsに変更された点について、ドキュメントは提案者の経験に基づき記述されており、より一般的な情報として参照できるレベルとは言えないので、Experienceに戻すべきだという指摘がありました。また、Google社がWebページの表示を高速化する目的で開発したSPDYのような、持続性のあるセッションを扱うプロトコルの存在が、NATデバイスに与える影響についての知見が不足しているので、Experienceに戻すべきだとの意見もありました。今後の進め方として、タイトルをExperienceに戻して、かつ現在のコメントを反映した版で再度WGLCが行われることになりました。

本提案では、3GPPネットワークにおいて、DHCPv6-PDが利用できない環境下について取り扱っており、User Equipment(UE)の3GPPモバイルインタフェースがモバイル網からRAで/64のプリフィクスを取得した際に、同じプリフィクスをLANでも使用可能にするための、次の三つのユースケースについて提案しているものです。

1. UE上にグローバルアドレスを一切保持しないケース
2. グローバルアドレスをLAN側だけに割り当てるケース
3. 同じグローバルアドレスをエニーキャストアドレスとして3GPPモバイルインタフェースとLAN側の両方に割り当てるケース

なお、別の手法として既にRFC 4389として標準化されているND ProxyがありますがExperimental Statusであり、またループ回避に関する制限事項があることが、本提案の動機になっています。

会場からは、おのおののユースケースにおいて、ローカルアプリケーションに与える影響についても考慮すべきとのコメントがありました。WGLCを行うかどうかについての確認では1/4程度の賛同は得られたものの、ML上での議論を継続して判断することとなりました。

その後すぐにML上で議論が開始され、IETF会期後半まで非常に多くの議論が行われました。3GPP standardに違反しないのかとか、USBドングルやdriverの存在により想定外の挙動になったりしないのかとか、短期/中期解として本方式を使うのではなく、やはりDHCPv6-PDを使うべきではないかなど多くの提案やコメントが寄せられました。

本提案は、スイスのSwisscom社が展開しているIPv6 CPEのセキュリティ要件を参考例として、セキュリティレベルとEnd to Endの接続性を適度にバランスしたポリシーを提供することを目的としたものです。実際、マーケティング部門はセキュリティを重要視するのに対し、多くのエンジニアはEnd to Endの接続性を重要視しているので、良い落としどころを見つけて情報提供することがこの提案の主旨であると言えます。

これまでの標準化の議論では、Recommended Simple Security Capabilities in CPE for Providing Residential IPv6 Internet Service(RFC 6092)がすべてのInbound Trafficをブロックするか許容するかの2択としているのに対して、Advanced Security for IPv6 CPE(draft-vyncke-advanced-ipv6-security-03)[Expire]では、IPSやReputation Databaseなどを必要とするなどハードルがかなり上がっているため、ほどよくバランスされたセキュリティポリシーを必要としているという背景事情があります。

会場からは、新しいアプリケーションやインシデントなどの事情によりポリシー変更を伴う場合に、どのようにしてドキュメントを更新していくのかといった質問や、このセキュリティポリシーにより実際にどの程度のインシデントが抑制されているのかなど、運用上のフィードバックがより必要であるとの発言がありました。提案者によると、Swisscom社は2012年からIPv6 CPEを展開しているが、今のところインシデント報告はされていないとのことでした。

その後、本提案をWGアイテムとして採択すべきかハミングが行われましたが、賛成／反対が半数ずつに分かれたため、ML上で継続して議論を行うことになりました。

本ドキュメントでは、Unique Local IPv6 Unicast Addresses(RFC 4193)自体のメリット／デメリットの分析とともに、ULAの使用が推奨されるユースケースのガイドとして記述されています。なお、推奨されるユースケースとしては、次の3点が記述されています。

1. インターネット接続から独立した、いわゆる閉域ネットワークでULAのみを利用
2. ULAとGUA(グローバルユニキャストアドレス)の両方を利用
3. 特別なユースケースとして、B2Bのようなプライベートネットワーク間の接続における利用や、NAT64プリフィクスとしての利用、上位レイヤにおける識別子としての利用

なお、ULA + Proxyや、ULA + NPTv6は、取り得るユースケースとしては分析されていますが、推奨されるユースケースには含まれていません。

会場からは、ULAとGUAの両方を利用する場合、大規模ネットワークでは誰がそれを実際にやってるのか疑問だという意見があり、小規模での適用なら同意できるとコメントされました。また、特別なユースケースは、おのおのPros/Consがあるはずで推奨されるユースケースではないので、ユースケースの整理はより明確に記述すべきといったコメントがありました。その他のコメントとしては、ULAの境界ルータではどのように振る舞うべきかといった事項が記述されておらず、明確な記述が必要だとするコメントもありました。

その後、本提案をWGアイテムとして採択すべきかハミングが行われましたが、少数の賛成と、反対はほぼ無しという結果だったため結論は出さず、ML上で継続して議論しつつ、方向性を決定していくことになりました。

※ 会期終了後から本稿執筆時に至るまで、ML上で数多くの議論が行われていますが、ULAの運用経験がまだまだ少ないことから、ドキュメントのカテゴリはBCP(Best Current Practice)ではなく、Informationalとして進めようという意見が大多数となっている状況ではあるものの、まだ結論は出ていません。

□v6ops WG
http://tools.ietf.org/wg/v6ops/

□第86回IETF v6ops WGのアジェンダ
http://www.ietf.org/proceedings/86/agenda/agenda-86-v6ops

筆者が共著者の1人として、v6ops WGに提案していた464XLAT: Combination of Stateful and Stateless Translation(draft-ietf-v6ops-464xlat)ですが、IETFの会期直前にRFC Editor Process(AUTH48 status)に進むことができたため、本セッションでプレゼンテーションを行うことはありませんでした。

なお、本提案は 2013年4月3日(水)にRFC 6877として正式に発行されました。

(参考URL) http://www.necat.co.jp/press/2013/pre_01.html

この場をお借りしまして、464XLATの提案をご支援いただきました関係者の皆さまにお礼を申し上げたいと思います。さまざまなアドバイスやご支援をいただきまして、本当にありがとうございました。

softwire WG(Softwires WG)

softwire WGは、IPトンネリングを用いてアクセス網などのネットワークを構成する手法を取り扱っていますが、ここ数年は特にIPv4アドレス在庫枯渇対策技術にフォーカスした議論が行われています。現在のチャーターでは、6rd、DS-Liteに加え、MAP-E等のステートレスソリューションが対象となっています。

今回議論された中で筆者が特に興味を持ったのは、Unified IPv4-in-Softwire CPE(draft-ietf-softwire-unified-cpe-00)の提案でした。この提案は、一つのCPEがDS-Lite、Lw4o6(Lightweight 4over6)、MAP-Eなどの複数のIPv4 over IPv6機能を有する場合に、このようなCPEはどのように振る舞うべきか、またおのおのの方式でどのようなパラメータが必要で、どのような方法でプロビジョニングを行うのかといった内容が記述されています。会場からは、各方式のパラメータを取得する具体的な方法や、MAP-Tなど他の方式の扱いはどうするのかなどについて、コメントや意見が寄せられました。

その他には、MAP-EのWorking Group Last Call(WGLC)に向けた最終確認、Lw4o6のupdate(前述のUnified CPEとの関連を説明)、DS-Lite MIB、Softwire Mesh MIB、MAP-E MIBなどの各種MIB(Management Information Base)定義の提案、DS-Liteの障害検知や冗長化方法に関する提案などが行われました。

※ Lw4o6はML上でのコンセンサス確認の結果、2013年4月5日(金)にWGアイテムとして正式に採択されています。なお、MAP-Eは現在WGLC中です(2013年4月9日現在)。

今回、softwire WGは、2013年3月11日(月)と13日(水)の二つのタイムスロットで実施されましたが、v6ops WGと同様にいずれのタイムスロットでも、予定していた時間よりかなり早く終了するという状況でした。これまで長らく続けられてきた、IPv4アドレス在庫枯渇対策技術の乱立による激しい議論は、ようやく収束したと言えそうです。

□softwire WG
http://tools.ietf.org/wg/softwire/

□第86回IETF softwire WGのアジェンダ
http://www.ietf.org/proceedings/86/agenda/agenda-86-softwire

(NECアクセステクニカ株式会社 川島正伸)