IPv6対応への道しるべ

第11回 CPEベンダから見た移行技術

この記事を読むのに必要な時間:およそ 3.5 分

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方式は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はできるところまでやりましょうというのがこの方式を提案している想いでもあります。

─⁠─ありがとうございました

著者プロフィール

あきみち

「Geekなぺーじ」を運営するブロガー。

慶應義塾大学SFC研究所上席所員。全日本剣道連盟 情報小委員会委員。通信技術,プログラミング,ネットコミュニティ,熱帯魚などに興味を持っている。

近著「インターネットのカタチ - もろさが織り成す粘り強い世界」

Twitter IDgeekpage

インターネットってなんだろう?(てくらぼ)