IPv6の話題で非常によく登場するのが移行技術
これまでさまざまな技術が提案されてきましたが、
今回は、
CPEベンダから見たIPv6
- ──NECアクセステクニカさんとIPv6の関わりを教えてください。
2000年ごろから国内外でIPv6が騒がれ始め、
弊社内でも 「IPv6技術をキャッチアップしていこう」 ということになり技術調査を開始しました。その後、 IPv6が動作するプロトタイプ機を開発し、 某通信事業者様とも実際に製品開発を開始させていただきました。 - ──NECアクセステクニカさんはIPv6に関していろいろと取り組まれている会社というイメージがあるのですが、
なぜそんなにIPv6に情熱を注がれているのでしょうか？ 弊社のホームゲートウェイ事業は通信事業者様向けと量販系の民需品の2つがあります。通信事業者様向けですと、
どうしても通信事業者様ごとに要求仕様が異なってくるんですね。そのため、 通信事業者様によって採用される技術や考え方が異なります。 弊社としましては、
どのようなご要望にも迅速にお応えできるように、 ある程度先行して技術をキャッチアップしておく必要があります。IPv6もその1つです。 - ──現在の民需品の御社シェアはどれぐらいですか？
申し訳ありませんが、
市場シェアに関してはお答えできません。量販店に並んでいる数社のベンダさんとしのぎを削っていますが、 おかげさまで多くのお客様にご利用いただいております。 - ──NECアクセステクニカさんのCPEは、
NECさんのCPEと考えても正しいですか？ はい。弊社の社名が表すように、
弊社はNECグループにおいてパーソナルアクセスネットワーク商品をご提供している会社となります。 - ──通信事業者向けシェアに関しては、
たとえばAtermのシェアを想像すればいいわけですかね？ 通信事業者様向けの商品と量販系の民需品では市場が異なるので単純に比較はできませんが、
たとえばIPv6に対応したCPEに関して、 すでに多くの通信事業者様にご採用いただいております。 - ──IPv6という視点でCPEに日本国内で入れている機能はどういったものを入れていますか？
民需品に関しては残念ながらまだIPv6対応製品をリリースしておりませんので、
現在はIPv6パススルー機能をご利用いただいている状況です。 通信事業者様向けですが、
通信事業者ごとにさまざまな機能が搭載されています。WAN側の機能だと、 DHCPv6-PDを使用するのが一般的です。 ちなみにNTT様のIPv6 PPPoE接続サービスに対応した機種では、
IPv6アダプタガイドラインに準拠した機能を実装しています。たとえば、 IPv6 PPPoE上でDHCPv6-PDを動作させたり、 閉域網との通信用にIPv6 NAT機能を実装しています。 LAN側の機能も通信事業者様の要求仕様によって異なりますが、
ステートフルDHCPv6サーバ、 ステートレスDHCPv6サーバ、 DHCPv6-PDサーバなどの機能が求められます。もちろん一般的なRAも動作させます。 - ──通信事業者向けと民需品は、
どこが違うのでしょうか？ 一番大きく違うのが、
通信事業者様向けではCPEを管理するためのマネジメント機能が搭載されている点です。また、 事業者様によってはIP電話用の実装が入っていたり、 ユーザの設定負担を軽減するためのゼロコンフィグ機能などが入っている場合もあります。 - ──ところで、
DHCPv6のステートレス方式って何で存在しているのでしょうか？ IPv6では、
SLAAC （Stateless Address Auto Configuration） を使ってRAにより自身のIPv6アドレス設定ができるのですが、 DNSサーバ情報を取得することは一般的ではありませんでしたので、 DNSサーバ情報などのサーバ情報を取得する目的でステートレスDHCPv6サーバが使われています。 IPv6アドレスも配布するステートフルDHCPv6サーバとは異なり、
クライアント個々のステートをサーバが保持しておく必要がありませんので実装が軽く済みます。 しかし、
最近になって、 RAオプションを使用してDNSサーバ情報を提供する方法が正当な方法として使用できるようになりました。RFC5006では実験目的のステータスでしたが、 RFC6106に改訂されスタンダードトラックに昇格しました。これにより、 現状、 DNSサーバを提供する方法として、 ステートフルDHCPv6、 ステートレスDHCPv6、 RAオプションの3種類の方式が存在しています。ただし、 RAオプションによるDNSサーバ情報取得をサポートしている端末がほとんどない状態ですので普及には時間がかかるものと思われます。 今後、
PC等の端末で、 RAオプションによるDNSサーバ情報取得がサポートされてくると、 ステートレスDHCPv6の必要性は薄れてくるかも知れません。とはいえ、 RAオプションで提供できる情報はDNSサーバ情報とDNSサーチリスト情報のみなので、 たとえば、 SIPサーバやNTPサーバの情報などを取得することは現状できません。 DHCPv6サーバで提供できる情報と同じ情報をRAオプションでも提供すればよいのではと考えている人もいますが、
レイヤバイオレーションの観点からRAオプションでいろいろな情報を提供することを嫌う人もいるので、 今後の動向を見ていく必要がありますが、 3つの方式が混在した状況はしばらく続きそうです。
464XLATの仕組みと現状
- ──CPEベンダとしてのIPv6まわりでの苦悩というものはありますか？
IETFでのIPv6に関する標準化がなかなか落ち着かない点ですね。
前述のように実験目的であったRFCがスタンダードトラックに昇格したり、
IPv6が実際に使われるようになって運用面でのフィードバックがかかり、 IPv6の基本仕様にも見直しがかかっている部分もありますので、 これらアップデートにもベンダとして適切に追従していく必要があります。 その他にも、
IPv4/ IPv6共存技術に関する提案が多数ある点も悩ましい問題です。WAN側で採用される技術 （6rd、 DS-Lite、 464XLAT、 MAP-Eなど） が通信事業者様によって異なりますので、 実装する技術が増えると、 その分テスト項目も増えますしバグも発生しやすくなりますので、 技術のバリエーションが増えることでベンダとして得られるものはほとんどありません。 そういった観点で、
各方式を決定している標準化組織に積極的に関わって行く必要があると考えています。既に多数の方式が出てきてしまっていますが、 IETFに参加して筋のよい方式が生き残るよう誘導できないかと活動しています。 - ──464XLATは多数の方式が出ない方式ですか？
IPv4とIPv6が混在する過渡期にはトランスレーションサービスが必ず必要になるだろうということで、
JPIX様にてIPv6からIPv4へのトランスレーションサービスを検討されていました。 しかしながらIPv6からIPv4へのトランスレーションサービスは、
そもそもIPv6ユーザが少ない状況ではすぐに必要とされるわけではなく、 それよりも先にIPv4アドレス枯渇に対するソリューションが必要であるとJPIX様からご相談を頂いたのがきっかけでした。 当初の検討では、
CPE側はNAT-PTをベースとしたいわゆるステートフルトランスレーションの方式でしたが、 仕様を検討していく中でできたのが、 CPE側をステートレストランスレーションとする現在の464XLAT方式です。 - ──464XLATの仕組みを簡単に教えてください。
トランスレーションを2回行うことでIPv4サービスを提供する方式です。
センター側装置はステートフルトランスレーションを行い、
CPE側はステートレストランスレーションを行います。CPE側をステートレスにしたのは、 なるべく実装を軽くしたいという想いがあっての判断です。 DS-Liteと似ていて、
センタ側でのみNATを行う方式なので、 実際の通信が開始されてからポート番号の割り当てが行われます。そのため、 IPv4アドレスの使用効率が非常に良いというメリットがあります。 MAP-Eのようなポート制限のかかったNAT方式だとあらかじめ利用するポート番号の範囲が決まっているので、
ユーザがまったく使っていなくても特定範囲のポート番号が専有されてしまい、 IPv4アドレスを効率的に利用できません。 もうひとつの特長としては、
すでにRFCとして標準化された技術を組み合わせて使っているという点が挙げられます。 現在、
IETFで提案されているIPv4/ IPv6共存技術の中には標準化が終わってないものも多いのですが、 464XLAT方式に関しては前述の通りベースとなる部分は既にRFCが発行されており、 プロダクト的にも実装が完了しているものの組み合わせであり、 デプロイしやすいこともメリットです。 その他にも、
トランスレーションを用いているため、 近い将来IPv4からIPv6への通信またはその逆の通信が必要になった際にもわずかな修正を加えるだけで本来のトランスレーション通信が実現可能という点もメリットになります。 - ──464XLATで利用している標準化が終わっている技術は何ですか？
464XLAT方式は、
RFC6145 （IP/ ICMP Translation Algorithm） とRFC6146 （Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers） の2つがあれば実現できますが、 どちらも標準化が完了しています。センター側装置でRFC6146、 CPE側でRFC6145をそれぞれ実装していれば利用できます。センター側装置は、 Cisco、 Juniper、 A10 Networks、 F5 Networksなど多くのベンダですでにご利用いただけます。 - ──標準化の状況を教えてください。
2011年11月に台湾の台北で開催された82nd IETFで最初の提案を行い、
2012年8月にIETFのv6opsワーキンググループでラストコールがかかりました。現在はIESGプロセスに入っていまして順調に標準化作業が進んでいます。 - 464XLAT: Combination of Stateful and Stateless Translation－ietf.
org - http://
tools. ietf. org/ html/ draft-ietf-v6ops-464xlat-08
- 464XLAT: Combination of Stateful and Stateless Translation－ietf.
- ──提案からラストコールまで早いですよね。
おかげさまで、
表向きは順調に標準化を進めることができています。 提案当初、
464XLAT方式はIPv4/ IPv6共存技術の1つということで、 softwireワーキンググループに提案を行いました。しかしながら464XLAT方式はすでに標準化されたRFCの組合せで実現できる方式ですので、 プロトコル仕様を決めているsoftwireワーキンググループでの標準化は合わないだろうとの判断のもと、 v6opsワーキンググループに提案し直すという判断をしました。 v6opsワーキンググループではコミュニティからの評判も良く、
すぐにワーキンググループドラフトに昇格できたのが良かったのだろうと思います。その後も多くの有益な議論を重ねつつ、 順調に標準化作業が進んでいます。 - ──softwireで何回出しましたか？
softwireワーキンググループでの提案は一度だけで、
文書としても2度の改版のみでした。 最近の苦労話としては、
7月末にカナダのバンクーバーで開催された84th IETFの直前に、 464XLAT方式は新しく立ち上がったsunset4ワーキンググループで議論すべきでは？ とv6opsワーキンググループのチェアに提案され、 急にv6opsワーキンググループからsunset4ワーキンググループに追い出された感じになってしまいました。そこで仕方なく、 会期初日の月曜日にsunset4ワーキンググループでプレゼンを行ったのですが、 そこではv6opsワーキンググループで標準化を進めるべきであるというコメントを多くいただけました。 その後、
v6opsワーキンググループのチェアと調整を行い、 会期最終日となる金曜日のv6opsワーキンググループでのタイムスロットをいただいて、 プレゼンができました。さらに、 v6opsワーキンググループでは会場からワーキンググループラストコールのラフコンセンサスを得ることもできました。結果的に非常にスムーズに進んでいるようにも見えるかもしれませんが、 実際はそれぞれのタイミングで水面下の見えない苦労をしています。 - ──最後の質問ですが、
IPv4/ IPv6共存技術はさまざまなものが乱立していますが、 実際はどのようなものが使われていくとお考えですか？ 技術ごとにメリット、
デメリットがありますのでどれを採用するかは事業者様次第だと考えています。ただ、 ベンダの立場としましては、 先ほどお話させていただいたとおり、 筋の良い方式が生き残るよう誘導していきたいと考えています。 IPv4/
IPv6共存技術にはできないこともあります。たとえば、 464XLAT方式をはじめとするIPv4アドレスを共有する技術では、 本質的に使えないアプリケーションがあります。しかし、 そのようなアプリケーションを救うために実装を複雑化させるのは我々の本意ではなく、 それよりもIPv6の普及を最優先に考えた上で、 IPv4はできるところまでやりましょうというのがこの方式を提案している想いでもあります。 - ──ありがとうございました
