IPv6オペレーションズフォーラム: マルチプレフィックス問題は終息せず −NAT66に関わる諸問題− JPIX 石田良樹さん これまでの経緯と1回目の続き 逆にアクセスという目で見た時にやらなければならない点に関して そもそも、マルチプレフィックス問題 複数のプレフィックスが設定可能な仕様 あるエンドノードからパケットを出す場合にパケットにつけるソースアドレスとしてどのプレフィックスをつけるか どれを付ければ上流に行けるか それを解決すれば良い ポリシーテーブルを自分で書けば良い Vistaならばprefixpolicyを書けば良い それで解決可能 それを普通のコンシューマに望むのか? インターネットの話はある Closedネットワークとしても作れる Closedネットワークを作るためにv6を使うという問題 クローズドな部分だけでDNSを使う場合 これが良く言われて来たマルチプレフィックス問題 HGWが2つのISPについている 赤いISPで行く場合と青いISPで行く場合 赤いISPで行くのに青いISPで出すとどうなるか フィルタリングされるのが一般的 ソースにどのprefixを使うか ASPのアドレスをどうするのか? じゃあ、DNSをどういう風に付けるのか? 3年以上前から問題があった 巷で言われている「マルチプレフィックス問題」はこれに限らない NTT-NGNが網内にIPv6を利用している FLETS2サービスの次世代版 v6の接続性問題も検討することになった 結果としてマルチプレフィックス問題が発生することが判明した 網内で使っているのと、ISP用の両方が登場する可能性が登場した IPv6インターネットへの接続性の検討の話だったはず マルチプレフィックス問題と言われるようになった 一般的なマルチプレフィックス問題とNGNの話が併存するようになった 外部IPv6インターネットへの接続性の問題だった その課題の中の一つとしてマルチプレフィックス問題があったと思います NTT-NGNのマルチプレフィックス問題 問題が複雑 ネットワークトポロジの問題 NTT-NGNではアクセスネットワークとして存在していた NTT-NGNが閉域網だ IETFで解決してもNTT-NGNでは解決しない 純粋に技術的な問題だけではなく、ビジネスやかかるプレイヤーの多さ リミットが決められている 時間的余裕が全然なかった デッドラインが決まっていたのが問題を複雑にしていた 今更ながら案1〜案4 案1から案4があります 案3はISPがいらないという形になる それを変更した形 案4 アドレスはISPが持ち込み 最終的に決まった案2と案4に関しては後で 解決策その1ートンネル方式案2 IPv6インターネットはトンネルして、NTT-NGNの閉域網内サービスはNAT66を使う トンネル方式の概要 従来のフレッツサービスと同じトンネルを利用する トンネル終端装置はNTT東西が用意する 宅内にアダプタを設置する事にしました v4だとアドレスが一つ v6だとネットワークアドレスが振って来る マルチプレフィックス問題はNAT66で解決 NGN独自サービスではDNSを使う アダプタで反応してしかるべく対処する NTT-NGNの基本サービスです 基本として提供されるサービスということになりました 当初はHGWに追加だったのですが、費用面の問題などでアダプタを配下に収容という形で進んでいます 秋葉原などで購入できるようになるかと言われています 将来的にはHGWとアダプタの一体型が提供される ISPから見ると、FLETSと同じになると思います ただし、トンネルは別になると思われます 案4ネイティブ方式 ISPから持ち込もうよ、ただし3社までね ネイティブ方式の概要 トンネルを有せずにnative イーサのフレームがそのまま流れる IPv6アドレス ユーザが望めば別ですが、グローバルアドレスは一つだけ NTT-NGN独自サービス利用のためにエンドユーザが利用するDNSに細工が必要 NTT東/西の網内ではどの接続事業者を。。。。 NTT-NGNのIPv6外部接続はこの2方式になりました 8月6日の認可 すったもんだはありましたが トンネル方式 ネイティブ方式のいずれも認可されました え?まだ実は何も決まってない NAT66ってどうすんのよ。。。 どんな仕様にするの? どんな問題がおきるの? エンジニア/オペレータは理解してるの? IPv6 NATの憂鬱 SoftBank BB 印南てつや氏 宅内機器構成とNTT-NGNのサービス ネイティブ方式は無条件で折り返しサービスがある v6のNATはSNIと折り返しサービスを使う時に使われる NATでソースアドレスで変換して使われる NTTのサービスは3階建て SNIが一番下(ANI) UNI-NUI,折り返しサービス NNI,ISP接続のためのNNI,IPv6 Tunnelを使用 IPv6 NATいろいろ!? v4ではNAPT型、ポートが変わる ソースアドレスは一つを使う v6でも同様の事ができるだろうなと 戻りを考えなくてはならない 何を何に変えたのかを保持しなければならない 6の場合、長いのでprefixを変換 前半部分だけマッピングルールを作る 残りの半分はいじらないというルールでやる prefixだけをスワッピングをする 同じサイズだと後半変わらない形でやると簡単 調べたら、IETFでもそういう提案がされている チェックサムさえも再計算しないというドラフトもあった 世の中的にはNAT66はstateless型という事もある 必ず/64を使う ホスト部の64ビットは変えない v6の場合はほとんどぶつからないでしょうと 特別な物を用意しない その時はあきらめるという仕様 要は色々なものがある アプリケーションって平気なんだっけ? SNIとUNI-UNIの折り返しにしか使用されないなら、。。。。 NATを作るにはIPSECだのSIPなど NATは基本無い方が良いと考えている 何かいろいろ難しいのですが 宅内に二つのIPv6ネットワーク アダプタはv4に関しては何もしない v6に関してはルータ ISPからもらったv6アドレス LAN AにPCを挿すかどうか?はありますが、 LAN AとBの通信はどうなるのか? 家の中にNATがあるというのがキモイ 経路制御入れるならば、二つのPCを通過させれば良いではないか 面倒だなと 外廻ったら?LAN Aは外に行けない 折り返しサービス トンネルサービスとネイティブ方式が折り返しを使う場合 ISPから与えられた方に通信をしようとする、でも、2のユーザは折り返しを使えるので中を通ろうとする ということは、ネイティブ方式側からの通信はNATのためにうまく通らない トンネル方式ユーザは網内折り返し方式は使わない方がいいかも でも、そうも言ってられない 現実的なマルチプレフィックス問題の解決方法としてIPv6 NAT使わなくてはならないものならば エンドユーザは使いたいサービスによってNATの仕様を慎重に選びましょう マルチプレフィックス問題は終わっていない 2011のサービスイン時までに解決すべき課題や山積です