6/06/2017

IPv6の課題 (RIPE 74)

ブタペストで開催されたRIPE 74についてジェフ・ヒューストンが興味深い印象を書いてくれている。特に、IPv6のところが興味深い。

IPv6

RIPE会議では常に数多くの興味深いIPv6のプレゼンがあり、この会議も例外ではなかった。

IPv6デプロイ・ストーリー

(省略)

IPv6セキュリティの課題

これらの会議で多くのプレゼンは、共通の価値観を繰り返す傾向にある。しかし、時々いくつかのプレゼンはそれらの価値に意図的に異議を申し立て、よくある偏見に直面する。IPv6セキュリティのエノ・レイのプレゼンがそうだ。彼が議論するテーマの多くのは、IETFでの議論に戻る事、あるいは関連するIPv6 WGの有無を注意する事で始まる。我々は気味の悪い自己利益、政治などを、ボランティア組織の中で聞いてきたし、本来の目的を事実上弱体化させてきた。このポイントが6manという特定のIETFグループにおいて、長い間に及んできた事だと思う。強固なスタッフだ!

彼は不明確なSLAACとDHCPv6の間の関係、ND(neighbor discovery)とMLD(Multicast listner discovery)、RAのフラグ間の相互作用、ルーティングテーブル、アドレス選択メカニズム、MTU問題を批判している。

振り返ってみると、ARPからマルチキャストベースの近隣探索への移行を正当化することは難しい課題だ。もし、RFCの数とサイズを記述され、続いて技術を明確にしようとするなら、そのようなメトリックARPは、RFC4861の94ページとそれに続く6つの明確なRFCを比較するのがとても有効である。

複数のIPアドレスやアドレススコープ(リンクローカルを考えて欲しい)のコンセプトは、かなりの混乱と曖昧さの原因となっており、これと言って有益な機能を果たしていないように思える。ローカルホストの意思決定構造が大きくなり、コードを間違える可能性が高くなる。更にもう一度、いくつかのRFCがIPv6アドレススコープやアドレス選択を明確にしようとしている。

拡張ヘッダの利用も同様に批判されている。拡張可能なプロトコルというコンセプトは、プロトコルが将来の進化に適用できる試みとして、魅力的に思えるが、かなりのコストが掛かる。複雑さが増し、コード判定を増やし、おそらく可変性も増加する。IPv6データグラムの拡張ヘッダには可変タイプ、様々なサイズ、可変順序、各タイプの発生数が可変で、様々なフィールドが付いてくる。プロトコルの実装はこのレベルのばらつきにどのように対処するつもりだろうか? ジョン・ポスタルがRFC761から、堅牢の原則「自分がすることには保守的であれ、他人から受け取るものには寛容であれ」が引用される。エリック・オールマンは2011年にこの原則の再考を公表した。彼は、「おそらく、あなたが作り出しもののの控えめに、あなたが受け入れたものを更に慎重にする方が長い目で見ると一層強固かもしれない。」と主張する。そして、「他の全てと同じように、堅牢性の原則は節度を持って適用されなければならない。」と結んでいる。拡張ヘッダはこの問題の中心である。IPv6の実装は、不明な拡張ヘッダを持つパケットを通過させるべきだろうか? あるいは、ヘッダ全体がコードによって明確に理解されないパケットを通過させない方がいいという原則に基づき落とすべきだろうか? 拡張ヘッダを持つIPv6パケットの野心的な取り組みは、IPv6パケットからパケットのフラグメント制御を取り除き、拡張ヘッダの中に入れた決定がなければ、複雑な問題ではなかっただろう!

IPv6は、ルータの役割も変えている。リモートネットワークへのゲートウェイというだけでなく、ネットワーク・プロビジョニング・アーキテクチャの本質的な部分になっている。最近は、色々な種類のローカルネットワークがあり、パブリックシステム上でローカルルータになることを意図したデバイスを単純に信用すべきではない。もちろん、これは賢明ではなく、ネットワークの中の不正な要素を特定し、我々を守るためにRA GUARDがある。しかし、RFC6890で指摘されているように、パケットの断片化とRAパケットの間の相互作用が、この領域を脆弱にし続けている。

エノが述べたより一般的な見解は、進化し続けるプロトコルはより古いプロトコルを実装するデプロイされたシステムの痕跡を残すということだ。IPv6ホストでローカルインタフェース識別子を生成する方法、近隣探索、外向きパケットのアドレス選択であろうとなかろうと、IPv6はその発展経路に沿って、異なる時点で異なる動きを指定している。その結果は、IPv6はIPv4よりもとても複雑で、この複雑さはプロトコルを実装するコードとIPv6をサポートする堅牢な商用ネットワークを運用するために必要なエネルギー量の双方に示されている。

IPv6アドレス指定

いくつかの点で、"過大な(too much)"は"不十分(not enough)"と同じように大きな課題に見える。プレフィックス長は議論が続いているように見え、IPv6プレフィックス割り当ての運用方法に関する作業についてのプレゼンでは、決してIPv6アドレス計画のベストプラクティスについて合意していないことが示されている。例えば、IETFは何年か前に、公衆インターネット以外で使用するローカルアドレス・プレフィックスのある種の形態が望ましいと判断し、ULAまたは固有ローカルアドレス・プレフィックスのコンセプトが設定された。これは、IPv4のプライベートアドレス空間に類似した方法で動作する自己割り当て可能なIPv6アドレス・プレフィックスのプールである。最近、この作業によると、このようなULAの使用は"強く推奨されていない"。ポイントツーポイントリンクはどうだろうか? IPv4では/30を使用して各エンドがアドレス指定ができる。そして、サブリンク・ブロードキャスト・アドレスの両端のアドレス指定を一度に行う。よくIPv6はブロードキャストアドレスが無いため、なぜそのようなリンクに/127を使わないのだろうか? 最近再び、そのようなリンクに/64の使用を推奨するよう変更されている。そして、消費予測に関する折々かなりの議論があるにも関わらず、現在の勧告は誰にでも/48を割り当てることになっている。それは私の携帯電話も含んでいると思う!

私はこれがIPv6の進化的性質のもう一つの姿だと思う。ここでは、時間の経過と共に、プロトコルの姿を変え続けている。ここで問題となるのは、以前の決定全ての蓄積された遺産を引きずっているということで、、そのようなルールを最初から課さなかったとしても、状況はもっと混乱していた可能性はある! IPv6ソフトウェアとハードウェアの実装者に提供できる最善のアドバイスは、プレフィックサイズについては絶対に何も仮定しないことだ。

64NATあるいは464XLAT?

IPv6移行環境で選択肢を提供したことは多分残念なことである。選択肢を提供した結果、必ずいくつかのデプロイが選択肢を作って、他の選択肢は異なる選択肢を作るのだ! IPv6のデプロイにモバイル分野進出した。多くの大規模ネットワーク・プロバイダは、IPv4アドレスが不足しているため、全てのモバイルサービス・プラットフォームでユニバーサルなデュアルスタック・サービスを提供できなくなってしまった。疑う余地のない答えは、ネットワークをIPv6ネットワークとして運用する必要があったが、接続されたデバイスにIPv4サービスを提供し続けることが課題だった。

一つのモデルは事実上トンネルされたNATであり、デバイスはローカルにアドレス指定されたIPv4環境を有するが、デバイスはIPv6にカプセル化してパケットをモバイル通信ネットワークに渡す仮想IPv4インタフェースを提供する。モバイルオペレータはこれらのパケットをデカプセル化CGNに渡し、ネイティブIPv4パケットはインターネットに渡される。デバイスは、従来のデュアルスタックホストであり、アプリケーションに変更を加える必要ないと考えている。Androidは464XLATをサポートする。

AppleのiOSはそうではない。DNS64を使用する。ここでは、デバイスはIPv6のみのサービスに接続されるためIPv6専用デバイスと考えられる。インターネットはIPv6だけをサポートしている将来の世界では素晴らしいだろうが、今はそうではない多くのサービスとユーザがいる。そのため、それをごまかす方法として、DNSを呼び出している。デバイスがIPv6アドレスを持たないサービス名を照会すると、アドレスにエンコードされたIPv4アドレスを持つオペレータの6to4プロトコル・トランスレーたを指すIPv6アドレスを生成する。デバイスがIPv6パケットをこのプロトコル・トランスレーたに送信する時、デバイスは本質的にIPv4へのヘッダ変換を実行し、NATスタイルの動作を使用して、グローバルIPv4アドレスを生成する。これは、net64checkのプレゼンが示すとおり、464XLATほど単純ではない。問題の大部分は、DNSに関する混在メッセージを送信していることだ。一方では、DNSはセキュリティとプライバシを必要としているというメッセージを送り出しており、これに対処するツールとソリューションを提供している。一方では、DNS64はDNSを信頼し、全てのクライアントのDNSクエリをオペレータのDNSリゾルバに渡すことに依存しており、プライバシに大きな影響を与える可能性がある。時には選択が最善の結果ではない。