ネットワーク
本会議場ネットワークの作り方
JANOG31 Meeting本会議場で提供したネットワークの構想から設計、構築までを JANOG Meeting本会議場ネットワークの作り方 にまとめました。
会場ネットワーク情報
JANOG31本会議場には、以下6つのネットワークを提供しております。
| SSID | 説明 |
|---|---|
| janog31 | 本会議用NW (802.11a) |
| janog31-bg | 本会議用NW (802.11b/g) |
| janog31-map-e1 | MAP-E実験用NW1 |
| janog31-map-e2 | MAP-E実験用NW2 |
| janog31-464xlat | 464XLAT実験用NW |
| janog31-ds-lite | DS-Lite実験用NW |
| janog31-hana | HANA実験用NW |
- 暗号方式はWPA2です。
- 暗号キーは、会場で配布するパンフレットでご確認ください。
- IEEE802.11a対応の端末をお持ちの方は、なるべくjanog31をご利用ください。
- 会場内での無線LAN AP(モバイルルータ等)のご利用はお控えください。
- 端末や通信のセキュリティについては、ご自身において対策を講じてください。
- ネットワークは全て、IPv4/IPv6デュアルスタック環境です。
- 会場ネットワークでの成果について対外発表をすることがあります。
- 発表における基礎データとして、会場ネットワークで計測したトラフィックデータを使用することがあります。
- トラフィックの測定方法は、SNMP、NetFlowおよびsFlowです。なお、個人を特定する情報の収集は行いません。
ネットワーク構成
回線・機材提供
JANOG31の会場ネットワークは、以下企業及び有志のご協力により構築しております(敬称略・五十音順)。
- インターネット環境提供
- グリー株式会社
- 接続回線・機材提供
- IP Infusion Japan 合同会社
- 株式会社インターネットイニシアティブ
- A10ネットワークス株式会社
- NECアクセステクニカ株式会社
- エヌ・ティ・ティ・コミュニケーションズ株式会社
- 有限会社銀座堂
- シスコシステムズ合同会社
- 独立行政法人 情報通信研究機構(NICT)
- 古河ネットワークソリューション株式会社
- 丸紅アクセスソリューションズ株式会社
- 三井情報株式会社
- ヤマハ株式会社
- ネットワーク設計・設営
- JANOG Softwire WG
- JANOG31実行委員会およびJANOG運営委員
実験ネットワークについて
JANOG31では通常のdual stackネットワークの他、「IPv4/IPv6移行・共存技術」と「新世代ネットワーク」の2つのテーマに沿って
- 3種類のIPv4 over IPv6技術
- MAP-E
- DS-lite
- 464XLAT
- 広域ネットワークの自動構築を実現するHANA(Hierarchical Automatic Number Allocation)
を用いた実験ネットワークを無線LANにて提供します。
IPv4 over IPv6技術について
2012年9月14日にはRIPE NCCでも最後の1ブロックからの割り当てが始まりました。IPv4アドレスの世界的枯渇を迎え、IPv6への緩やかな移行を実現するためのIPv4/IPv6共存技術が必要とされています。なかでもIPv4 over IPv6技術は、ISPなどの多数のユーザを持つ事業者が、IPv4の消費を抑えながら、なおかつdual stackで数多くの顧客を収容する手法として注目されています。
現在、IETF(特にSoftwire WG)にて数多くのIPv4 over IPv6技術の提案がされておりますが、その中でも注目される3つの技術を利用したNWを、今回のJANOG31では用意しました。
IPv4 over IPv6技術は一般的に、
(Private)IPv4------(CPE)------IPv6------(PE)------(Global)IPv4
- カスタマ側装置(CPE)
- プライベートIPv4からIPv6-NWに接続する装置
- プロバイダ側装置(PE)
- IPv6-NWからグローバルIPv4-NWに接続する装置
の2つの装置と機能により、離れたIPv4空間がIPv6に橋渡しされることによって成り立っています。
それぞれの技術について、各装置の機能と名称が異なります。
| MAP-E | DS-Lite | 464XLAT | |
|---|---|---|---|
| 方式 | トンネリング | トンネリング | 2段トランスレーション |
| PE側セッション | ステートレス | ステートフル | ステートフル |
CPE
(名称/機能)
|
CE
NAPT44+トンネリング
|
B4
トンネリング
|
CLAT
ステートレストランスレーション
|
PE
(名称/機能)
|
BR
トンネリング
|
AFTR
NAPT44+トンネリング
|
PLAT
ステートフルトランスレーション
|
特に、ステートレスにグローバルIPv4アドレスを割り当てるMAP-Eでは、1CPEに割り当てられるポート数が制限されることから、今回のNWでは、ポート割当て数の異なる2つのNWを用意しました。
- 参考資料:
MAP-E
技術について
MAP-Eはステートレスなトンネリング方式によりIPv4 over IPv6を実現します。
MAP-Eでは、IPv4 over IPv6パケットのIPv4アドレス/ポートとIPv6アドレスの対応が一意に決まります。CEは付与されたIPv6 prefixから、MAP特有のルール [1] によってグローバルIPv4 Network用のIPv4アドレス/ポートレンジを生成します。
CEがプライベートIPv4 Networkからパケットを受けた時、CEはNAPT44により、受けたパケットを上記のIPv4アドレス/ポートに変換します。NAPT44変換後のパケットはIPv6 EncapsulationされIPv6 Networkに送出されます。BRがIPv6 Networkからパケットを受けた時、BRは受けたパケットをDecapsulationし、得られたIPv4パケットをグローバルIPv4 Networkへ送出します。
BRがグローバルIPv4 Networkからパケットを受けた時、BRは受けたパケットのIPv4宛先アドレス/ポートからMAP特有のルールによってIPv6宛先アドレスを作成します。グローバルIPv4 Networkからのパケットは上記のIPv6宛先アドレスでEncapsulationされ、IPv6 Networkに送出されます。CEがIPv6 Networkからパケットを受けた時、CEは受けたパケットをDecapsulationし、NAPT44変換を行い、得られたIPv4パケットをプライベートIPv4 Networkへ送出します。
特徴について
MAP-Eはステートレスであるため、BRはユーザ数やセッション数ではなくトラフィック量に応じた設備投資が可能であり [2] 、冗長構成を容易に構築できます。
標準化の動向
2010年から議論されてきた4rdの技術の中のなかで、IPv4アドレスとport番号のマッピングルールを洗練させ、統一したのがMAPとして定義されました。現在は、IPv4パケットをカプセル化(Encapsulation)する方式であるMAP-Eが主流で、標準化が進められています。
※MAP-E以外にもIPv4パケットをトランスレーションするMAP-Tが存在します。
janog31-map-e1とjanog31-map-e2の違いについて
上記のように、MAP-Eではmapping ruleにより、各CPEに固定の数のportが割り当てられます。今回のJANOG31会場NWでは、
- 1つのCPEに240portを割り当てるNW(janog31-map-e1)
- 1つのCPEに30portを割り当てるNW(janog31-map-e2)
の2種類を用意しました。
janog31-map-e1に接続したユーザは、全ユーザで240portを共用します。janog31-map-e2では、30portを共有します。多数のユーザが接続した環境では、ポート枯渇が発生する可能性があります。JANOG31参加者に30portという厳しいport restriction環境を体験していただくために用意しました。
会場ネットワークでのMAP-E
BRで2社の実装、CEで4社の実装を提供いただいております。無線LANの関係で、全てを同時に提供することができないため、以下のスケジュールで各実装の切り替えを行います。
1日目のBRにはIP Infusion(IPI)のソフトウェアの実装、2日目の切り替え後は古河ネットワークソリューション(FNSC)のルータ、FX5000を使用しています。CEにはインターネットイニシアティブ(IIJ)のSEIL/X1、FNSCのF60、銀座堂浅間さんのASAMAP、ヤマハのRTX1200が参戦しました。
IPIとASAMAPの実装はソフトウェアでの提供となっているため、それぞれPCルータとして動作させます。FNSCのFX5000は通信事業者向けのマルチサービスルータで、直流48V入力のためAC/DCコンバータを挟むほどの大型で本格的なルータです。
会場ネットワークではIPv4とIPv6の経路が異なります。各CEとExp-GWの間はIPv6オンリーのセグメントになっています。IPv6パケットはExp-GWから上流のJANOG-GWにそのまま抜けて行きますが、IPv4パケットはCEでカプセル化されてIPv6パケットとなった後、Exp-GWでBRの方向へルーティングされ、BRでカプセル化解除された後、Exp-GWにてIPv4でルーティングされます。
なお、BRの切り替えについては2日目のセッション「 Softwire WG活動報告 」の中でデモを行います。実験概要は下図の通りですが、skypeによるビデオ中継を投影しながら切り替えます。どうぞお楽しみに!
- 参考資料:
DS-LITE
技術について
近年のIPv4の枯渇問題を踏まえ、IPv4の延命策として考えられたのが、ISP側で多数のIPv4プライベートアドレスを大規模にNATして、ひとつのIPv4グローバルアドレスに多くの顧客を収容する、LSN(Large Scale NAT)/CGN(Carrier Grade NAT)という考えでした。このLSN/CGNの利用モデルとして、IPv4ネットワークをアクセス網に使うのがNAT444、そして、IPv6網を使うのが、今回紹介するDS-Liteという技術です。DS-Liteは、IPv4 over IPv6トンネルをベースとした、ステートフル方式のIPv4/IPv6共存通信技術です。ユーザ側から外部インターネットに出る通信の際は、B4が、IPv4パケットをIPv6でカプセル化し、ISPの管理するIPv6網をトンネリングさせます。その後、AFTRが、B4とのトンネルを終端し、IPv6のカプセル化を解きます。そして現れた元のIPv4プライベートアドレスを、IPv4グローバルアドレスへと変換し、外部インターネットへ接続します。
特徴について
DS-LiteはIPv4 over IPv6トンネリング技術であるため、同じLSN/CGNの利用モデルであるNAT444とは異なり、NATを一段階しか行いません。そのため、ISP側はシェアドIPv4アドレスを用意する必要がなくなります。つまり、アクセス網にはIPv6ネットワークだけを用意すればよいため、単一プロトコルで動かすことが出来、運用が容易となります。しかしながら、ユーザ側のCPE(B4)へのデュアルスタック機能搭載必須、ログ取得の複雑化、冗長化必須などといった、デメリットもあります。
標準化動向
2013年1月現在、標準化は完了しており(RFC6333)、シスコシステムズ、A10ネットワークス、ジュニパーネットワークス各社が、AFTR機能を実装しています。また同時に、AFTRの機能をOSSへの実装する動きもあります。
会場ネットワークでのDS-Lite
DS-LiteではAFTRにA10ネットワークスのAX2500を採用しました。AX2500は後述の464XLATのPLATを同時にこなしています。B4には2つの実装が参加しました。1日目はNECアクセステクニカのRG-A45Iで、2日目はIIJのSEIL/X1がB4として動作します。SEIL/X1は公式にはDS-Liteをサポートしていませんが、B4としての動作の可能性があったため、挑戦してみました。
- 参考資料:
464XLAT
技術について
464XLATは、クライアントサイドでIPv4/IPv6変換を行い，プロバイダ側ではIPv6/IPv4変換を行うことで、IPv6のみのネットワークを経由して、IPv4インターネットに接続することを可能にする技術です。
なお、464XLATの名前は文字通り、46のプロトコル変換(XLAT:トランスレーション)と64のプロトコル変換(XLAT:トランスレーション)を組み合わせて使用することから命名されています。
464XLATを利用する際、クライアント側に置かれるCLAT(Customer side XLAT)では、ステートレスなアドレス変換を行います。なお、IPv6アドレスにIPv4アドレスを含んだパケットフォーマットにて通信が行われます。プロトコル変換の際にパケットのフラグメント処理が必要であれば、フラグメントヘッダを付加して送信を行います。
プロバイダサイドに置かれる装置は、PLAT(Provider side XLAT)と呼びます。PLATではステートフルなIPv6/IPv4変換(NAT64)を行います。IPv4プロトコルへの変換時にプールされているグローバルIPv4アドレスを利用します。
特徴について
464XLATを利用して通信する場合、クライアントサイドではステートレスなプロトコル変換とフラグメント処理を行う機能を実装するだけで済み、IPv4 NAPTの機能も不要となるため、実装がシンプルになり、比較的処理コストも少なく済みます。
また、プロバイダサイドでは通信が発生した時点でポートが確保されるため、予めポートを確保するMAP方式(MAP-E、MAP-T)よりも、IPv4アドレスを効率よく利用することができます。
しかし、PLATではアドレスとポートの対応を保持し、ログを取る必要があります。
なお、プロトコル変換を用いた技術であるため、IPv4 - IPv6間で通信を行いたい要求が出てきた際にも、小規模な対応により実現可能なため、投資コストを抑制しつつ、IPv6へのスムーズな移行を行うことができます。
標準化の動向
CLATで用いられるステートレスなアドレス変換技術は RFC6145 [1] として、2011年4月にRFCとなりました。同様に、PLATで用いられるステートフルなプロトコル変換技術も同時期に、RFC6146 [2] として標準化されました。
464XLATは、RFC6145とRFC6146の2つの技術を組合せた技術として、ITEFのv6opsワーキンググループにて標準化が進められています [3] 。現在、IESG Reviewが行われており、RFC発行に向けた最終段階に入っています。
なお、上記の通り、標準化が完了した技術の組合せであるため、ベンダー側の実装も進んでおり、PLATに対応した機器としては複数のベンダー(Cisco、Juniper、A10 Networks、F5 Networks等)が利用可能です。CLATに対応した装置としては、NECアクセステクニカのプロトタイプ機やAndroid用のcode [4] やNokia n900用のcode [5] などが提供されています。
会場ネットワークでの464XLAT
464XLATはInterop Tokyoなどでも実績のあるA10ネットワークスのAX2500とNECアクセステクニカのCL-AT1000Pのコンビで運用されています。AX2500はPLATと同時にDS-LiteのAFTRとしても動作しています。IPv4/IPv6/IPv4変換の世界をお楽しみください。
- 参考資料:
HANA
1日目の昼休み13時50分からNICTによるHANAの発表とデモンストレーションを実施します。詳しくは こちら をご覧ください。
| 1/24 | 13:50 | 発表と経路迂回デモ |
| 1/24 | 15:45 | 経路迂回デモ |
| 1/24 | 13:05 | 経路迂回デモ |
| 1/24 | 15:50 | 経路迂回デモ |
HANA(Hierarchical Automatic Number Allocation)はNICTで研究されている新世代ネットワークの技術の1つで、広域ネットワークに対して自動で階層的に位置情報(アドレス)を付与する技術です。自動でアドレスが割り当てられるため、ネットワーク機器へのIPアドレスの設定作業が不要になり、運用の負荷やアドレス設定ミスなどの人為故障が軽減されます。
HANAでは上位ネットワーク(AS)から下位ネットワークに対して階層的にアドレスを割り振っています。このとき2つの上位ネットワークに対してマルチホームを行なっているネットワーク内の機器には、上位の2つのネットワークからそれぞれ2つの位置情報が割り当てられます。つまりアドレス空間を2つ持ちます。これによって経路の集約が可能になります。またマルチホームを行なっているネットワークでは複数のアドレスが利用できるために障害発生時にアドレスを変えることで迂回経路をすぐに確保することが可能になります。HANAプロトコルは上位ネットワークから位置情報の割り当て情報が降ってくるというイメージで、これが途絶えることで通信断を検知します。
JANOG31ではHANAを用いた実験ネットワークを構築し、本会議中に上位ネットワークにあたる部分で障害を発生させ、アドレスが切り替わることで迅速に迂回路を確保するデモンストレーションを行います。なお、通常のPCではHANAプロトコルに対応していないため、アドレスを2つ受け取って切り替えて使うということができません。そのためIPv4ではNAPTした後NAT/DHCPルータがHANAクライアントの役割を行います。IPv6ではRAを用いて擬似的にHANAの環境を再現します。
HANAの実験NWの構成と経路迂回デモ
HANA実験ネットワーク構成
図にJANOG31におけるHANAの実験ネットワークトポロジーとHANAによって割り当てられるアドレスを示します。
Top ISPにはIPv4/26、IPv6/56が割り当てられています。図には記載していませんが、ISP1、2はTop ISPに対してIPv4/28、IPv6/58を割り当ててもらうためのmidfix requestを送り、Top ISPはmidfixackでISP1に0.0.0.16/26-28(IPv4)と0:0:0:40/56-58(IPv6)、ISP2に0.0.0.32/26-28(IPv4)と0:0:0:80/56-58(IPv6)のmidfixを割り当てます。同様にEDGEはISP1、2の両方に対してIPv4/29、IPv6/59のmidfix requestを送り、両者からmidfix 0.0.0.8/28-29(IPv4)と0:0:0:20/58-59(IPv6)を割り当ててもらいます(一般的には2つの上流ISPから割り当てられるmidfixは同じ値とは限らない)。これによって自動的に階層的なアドレスの付与が実現されます。ISP1、2から割り当てられるmidfixはISP1のものの方が優先度が高く設定されるため、EDGEはISP1のアドレスを使用するようになります。
昼休みと午後の休憩の時間にTop ISPとISP1の間のリンクを切断し、インターネットへの通信の経路をISP2経由に切り替えるデモンストレーションを行います。
HANAによる経路迂回デモンストレーション
Top ISPとISP1の間のリンクを切断すると、ISP1を経由するHANAの広告が停止するため、EDGEとNATはISP1から割り当てられたアドレス(赤色)の使用を止め、ISP2から割り当てられたアドレス(青色)を使用するように切り替えます。IPv4ではNAPTの外部アドレスが変更になり、IPv6ではクライアントに割り当てられるアドレスが直接変わります。
HANAを用いたネットワークにおける経路迂回は次のような特徴を持ちます。
- IGP/EGPの収束に必要な時間がHANAの伝送時間に置き換わるため、高速に迂回路が設定される
- 送信元アドレスが変わるため、TCPセッションが切れる
デモンストレーション中は
- 外部サーバにpingを打ち続けて、tcpdumpでping送信元のアドレスが変わったことを確認する※HANA配下のクライアントからのSSHは切断されるので気をつけてください
- mtrやtracerouteを実行して経路を確認する
といった方法で経路迂回が行われる様子をお楽しみいたければと思います。
以下に各ノードでのHANAの設定を記します。非常にシンプルなコンフィグになっていることが一目でお分かりいただけると思います。
#top nodename=top hanad_v4_uppersites="0.0.0.0/0" hanad_v6_uppersites="0:0:0:0::0/0" hanad_v4prefixes='x.x.x.0/26' hanad_v4prefixlen=26 hanad_v6prefixes='x:x:x::/56' hanad_v6prefixlen=56 lower_interfaces="eth2" hanad_midfixoffer_priority_for_eth2=1 # ISP1 nodename=isp1 upper_interfaces="eth1" lower_interfaces="eth2" hanad_v4prefixlen=28 hanad_v6prefixlen=58 hanad_midfixoffer_priority_for_eth2=10 # ISP2 nodename=isp2 upper_interfaces="eth1" lower_interfaces="eth2" hanad_v4prefixlen=28 hanad_v6prefixlen=58 hanad_midfixoffer_priority_for_eth2=100 # Edge nodename=edge upper_interfaces="eth1 eth2" lower_interfaces="eth3" hanad_v4prefixlen=29 hanad_v6prefixlen=59 hanad_midfixoffer_priority_for_eth3=1 # NAT nodename=nat upper_interfaces="eth1" ifconfig_v4prefixlen_for_eth1=30 hanad_v4prefixlen=30 hanad_v6prefixlen=60 dhcpserver_interfaces="eth2" hanad_dhcpserver_v4pool_for_eth2="0.0.0.2-0.0.0.3" hanad_dhcpserver_v6pool_for_eth2="::0:0:0:2-::0:0:0:ff" hanaroute_dhcp_script=$HANABIN/dhcpd-nat.sh
- 参考文献:
ソーシャルボタン
(最終更新日: 2013.03.04)
