IPv4枯渇に係るインターネット新技術導入に向けた検討について

IPv6普及・高度化推進協議会
IPv4枯渇に係るインターネット新技術導入に向けた検討WG
WG 副査
NTTコミュニケーションズ株式会社 先端IPアーキテクチャセンタ（IAC) 担当部長
北陸先端科学技術大学院大学 高信頼NWイノベーションセンター（DNIC) 客員教授
慶應義塾大学 SFC研究所 上席（訪問）研究員

宮川 晋
2012年6月15日（金）Copyright by NTT Communications Corporation, 2012, All Right Reserved

IPv4枯渇とインターネット新技術


昨年にRIRのアドレスプールが枯渇して以来、v４アドレス枯渇に起因するさまざまな動きが活発化
CGNをはじめとするv４アドレス共有技術
 v４アドレスブロック「売買」
 v６導入本格化


一方で、HTML5をはじめとするさまざまな新しい技術が台頭してきているが、必ずしも、前項の状況を十分に踏まえた開発が行われているとはいえない状況です本WGの目標
v４アドレス枯渇技術およびv６技術と、インターネットにかかわる新技術導入に関する課題を調査
 抽出された課題に対する対策の検討
 標準化への貢献
 実際のアプリケーションや機器を用いた検証への貢献たとえばどんな課題？
（まだまだありそうですが）

HTML5/WebSocketとCGNの相性


CGNの「公平性」再考

HTML5/WebSocketとロードバランサー
 CGNの最適配置問題および”ISP SharedAddress”あるいは“Shared Transition
Space” 100.64.0.0/10 の使い方
 v６対応のファイアウォーリング
 など
少々の解説 - WebSocket関連
Websocketには「PipeLine」機能があります ひとつのTCPに複数のHTTPのコンテキストを「重畳」する仕掛けです 現在IETFで議論中でもありますHTTPの制限


もともとはHTMLファイルなどをダウンロードするための仕組み
requestを送らないとresponseが得られない
 responseが返ってこないと、requestを送れない

RFC2616でpipeline(複数reqを送信する仕組み）は規定されているが、相互接続性の問題より、通常は用いられていない

GETHTTPWebSocketが早いわけ

WebsocketとCGNの公平性
現在のCGN Requirement (draft-ietf-behave-lsnrequirement ）では、「セッション数を公平に分配する」ことを要求条件の柱に据えています Websocketが流行すると、HTML5対応のユーザ・アプリは、TCPを少ししか消費しない可能性があり、CGNでの取り扱いが「優位」になる可能性があります これは、このままのほうが良いですか？
 それとも「CGNでの公平性」を、セッション数制限＋トラフィックボリュームでの制限に拡張したほうが良いですか？
Websocketとロードバランス
一方で、Websocketをロードバランスしようとすると、ロードバランサーは、一旦Websocketを「終端」して、「ばらす」必要があります Proxyタイプのロードバランサーしかありえない？


すると証明書は必ずLBにオフロードしますか？
クラウド化されたデータセンターでもそれでいいですか？

TCPレベルで分散するNATタイプは作れないですか？
 作れるとしてv6対応のNATタイプロードバランサーは実現できますか？？？


NPTv6ではなくてNAPTになりそうですけれどそれでいいですか？

v6のファイアウォール


v6でのファイアウォールは難しいです

ヘッダの構造が自由すぎる「推奨ヘッダ順」しか許さないフィルタを使っても良いですか？
 既に一部のFWには実装が・・・フラグメンテーションしたパケットもACLできますか？

ICMPは何を通して何を通さないのが良いですか？

Access Control List on Firewall to control the packet
forwarding
FIREWALLIf a packet isfragmented,

Put it in the queue and re-assemble toidentify this packet can be go throughor notIn IPv4 , this re-assembled packet canbe placed to the our going Interface.
If needed, out going I/F will fragment asit needs. However so, in IPv6, becauseof Path MTU Discovery,
It must be fragmented as it comes into
the firewall.

Same fragmentationis required in IPv6
(It’s difficult!!)

Can be sent as reassembled in IPv4

Many Firewall implementation can not do this or, even it can do so, often it consumes
CPU power a lot.

CGNの最適配置とアドレス
Shared Transition Space （RFC6598）
100.64.0.0/10は「正しく」使えるのでしょうか？
 CGNって、ネットワークのどこにおくのが正解？
DS-LITEだったら？ 4RDならどこ？
 メールサーバやDNSは、CGNの「下」におくのが正解？それともCGNでバイパスしてルーティングする？それとも？？？
CGNとサーバの配置
ISPの顧客に対するDNSやメールサーバなどはどこに置くのが良いでしょう？
To/From the Internet

SRV

GW RT

CGN

CLIENT
CLIENT
CLIENT
CLIENT
CLIENT
CLIENT

CGNの上？

SRV

SRV

CGNの横？

CGNの下？

参加を呼びかける皆様
ASP Data Centerオペレータ
 ネットワークオペレータ（ISP、CATV、携帯など）
 機器ベンダ 標準化機関関係者
 調査・研究機関
 などなど。
 広く皆様にお声がけしたいとおもっています協力体制（予定）
北陸先端科学技術大学院大学 高信頼ネットワークイノベーションセンター
 慶應義塾大学/W3C
 NiCT StarBED技術センター
今後の予定

引き続き参加者を募り、多くのステークホルダーの方にご参加いただければとおもっております
7月をめどに「第一回会合」を持ちたいと考えており、その後、四半期に一度のペースで実会合、それ以外は主にMLでのコミュニケーショ
ンをはじめとする方法で作業を進展させたいと考えております
７月第一回会合までに「具体的な作業プラン」を作成し、皆様にご提示できるようにしたいとおもっております。
積極的な御提言、御協力をいただけますと幸いです
ご参加をご希望の方は



v6PC参加組織の方は事務局v6info@v6pc.jpまでご連絡を。
それ以外の方でも主査である中村修慶應義塾大学教授のご判断でのご参加も可能ですのでとりあえずご連絡を。

得られた成果は順次機会を捉えて公表してまいりますが、WGのロジスティックスの都合上「いわゆる情報収集のためだけ」の御参加は御遠慮くださいませ。