最終回　NAT64でIPv6端末をIPv4サーバにつなげよう


A10ネットワークス株式会社
山村剛久
2012/5/29

フラグメンテーションのサポート

　第2回で紹介したとおり、IPv6では、経路上のルータでフラグメンテーションは行わず、経路上の最も小さいサイズのMTU（Maximum Transmission Unit）に調整する実装となっています。

　対処は、基本的にはSLB-PTの場合と同じです。一例としてAXシリーズでは、InboundまたはOutboundインターフェイスで、MTUよりも大きいパケットに対するフラグメンテーションをサポートしています。一般に、NAT64におけるフラグメンテーションは下記のような場合に有効です。

  • ネットワークにMTUサイズが違うリンクが多数存在する場合
  • クライアントがMTU Path Discoveryを行わず、超過パケットをフラグメントしないといけない場合

　AXでは、下記のフラグメンテーション（Fragmentation）オプションがデフォルトで有効になっています。

  • inbound - inbound IPv6パケットのフラグメント
  • outbound - outbound IPv4パケットのフラグメント

　inbound IPv4パケットのフラグメンテーションは、デフォルトでは無効（disable）です。DF bitがセットされたInbound IPv4パケットはフラグメントされずに、ICMP unreachable messageを送信元へ返信します。

　これらの動作は、以下のオプション設定で変更可能です。DF bitがセットされている場合の動作を変更します。

nat64 fragmentation inbound {df-set send-icmp |[df-set] drop |[df-set] ipv6}

　　df-set send-icmp：inboundのフラグメントされたパケットに対しては送信者へICMP unreachable Messageを送信します。
　　drop	：パケットをドロップさせます。
　　Ipv6	：IPv6フラグメンテーションをします。

　デフォルトでは、ipv6オプションとdf-set send-icmpオプションが有効となっています。

nat64 fragmentation outbound {drop |ipv4 |send-icmpv6}

　　drop	：フラグメントされたパケットをドロップさせます。
　　ipv4	：IPv4パケットフラグメントします。
　　send-icmpv6：フラグメントされたIPv6パケットに対してICMPv6 Type 2 code 0（Packet Too Big）を送信します。

　デフォルトでは、ipv4オプションが有効となっています。

■TCP mms-clampingによる方法

　TCP MSS（Maximum Segment Size）は送受信できる最大データ長を表し、端末間のTCPハンドシェイクによって決められます。TCP/IPの最大パケット長であるMTU（Maximum Transfer Unit）からTCP/IPヘッダサイズの40バイト（IPヘッダ20バイト、TCPヘッダ20バイト）を引いた数値がMSSになります。

　通常IPv4クライアントは、IPv4ヘッダとTCPヘッダを許容する値をとりますが、IPv6ヘッダを許容するのに十分な値にはなりません。そこでAXシリーズは、サーバからIPv6ネットワーク側のクライアントへの返信に、サーバからの返信パケットが確実に入るよう調整します。

　そのため、MSSの値を確認し、必要に応じてサーバ側にリクエストを送信する際のMSSを変更します。この処理を「MMS Clamping」と呼んでいます。TCPのハンドシェイクによって決められるので、UDP通信では利用はできません。

　AXシリーズでは、下記のオプションにより動作を変更できます。

nat64 tcp mss-clamp {none | fixed n | subtract s [min n]}

　　none：AXシリーズはMSSを変更しません。
　　fixed：AXシリーズは指定のMSSに変更します。
　　Subtract：AXは下記の計算により特定のバイト数よりも大きい場合にMMSに減算します。
　　　　MSS - 40バイトの値が416バイトよりも大きい場合、MSSから40バイトを減算します。
　　　　MMS - 40バイトの値が416バイトに等しい、もしくは小さい場合416バイトをMSSに使用します。

HTTPならばリンク先のリライトは原則不要に

　SLB-PTでは、aFleXなどの機能を利用して、コンテンツ中のリンク先のホスト名の書き換えなどを行いました。例えば、コンテンツ中のリンク先として、「IPv4.example.com」（IPv4アドレスのサーバ）といったホスト名が書かれていた場合、動的にipv6.example.com（IPv6アドレスのサーバ）といったホスト名に書き換えることで、IPv6のサーバへリダイレクトさせることができます。たとえ、オリジナルのコンテンツでリンク先がIPv4サーバになっていたとしても、これで大丈夫です。

　NAT64/DNS64の場合には、このような書き換えは不要となります。たとえIPv4サーバのホスト名がリンク先として指定されていても、DNS64の機能によって自動的にIPv6との違いを吸収する形で名前解決を行い、目的のIPv4サーバに対してNAT64の機能を使ってアクセスできるからです。

　このように、Webサーバへのアクセスに関しては問題ないのですが、他のアプリケーションについては注意が必要です。アプリケーションの中には、ペイロードにアドレス情報を組み込んでいるものや、コントロール用とデータ用で異なるポートを使用するものなども存在します。そういったアプリケーションに関しては、ALG（Application Layer Gateway）という特殊な機能が必要となります。ALGはアプリケーションごとの特性も見て変換を行う機能です。

　なお、AXシリーズの場合は、現時点では以下のプロトコルに対してALG機能を提供しています。これはあくまで一例で、ALG機能の有無は、お使いのNAT64サポートデバイスにより異なります。

nat64 alg ftp enable　（FTP）
nat64 alg rtsp enable　（RTSP）
nat64 sip rtsp enable   (SIP)
nat64 alg tftp enable  (TFTP)

　ALGは、FTPやSIPのような標準的なプロトコルへのゲートウェイ機能を提供しますが、独自アプリケーションなどはALGでのカバーは不可能です。サーバアプリケーションに手を入れて、IPv4に依存しないコードへ変更するといった工数が必要になる場合もあります。

NAT64セッションログの保存

　安定運用の観点から、またセキュリティの観点からも、アクセスログの収集は必須の機能です。AXシリーズでは、NAT64のセッションログを外部サーバに出力可能です。出力先として複数の外部サーバを設定した場合は、ソースIPのハッシュを使用し、出力する外部サーバを決定します。よって、特定のソースIPのセッションログを、毎回同じ外部サーバに出力させることもできます。

　ログ関連の設定方法は、1ページ目に示したサンプル設定ファイルのグリーンの部分となります。Ip nat templateのオプションを変更することで、出力されるログの内容を変更させることもできます。

■設定例

ip nat template logging lsn_logging 
  log port-mappings both 
  log sessions

■出力されるセッションログ例

Jul 9 08:19:49 ax6 NAT-TCP-N: [2001:240:6d4:40::44]:35100<-->[64:ff9b::40e9:b763]:80, 64.233.183.99:80<-->10.111.0.102:35100
Jul 9 08:19:49 ax6 NAT-TCP-C: [2001:240:6d4:40::44]:35100 -> 10.111.0.102:35100
Jul 9 08:19:51 ax6 NAT-TCP-D: [2001:240:6d4:40::44]:35100<-->[64:ff9b::40e9:b763]:80, 64.233.183.99:80<-->10.111.0.102:35100
Jul 9 08:19:51 ax6 NAT-TCP-F: [2001:240:6d4:40::44]:35100 -> 10.111.0.102:35100

日時　ホスト名　種別　変換前送信元IPv6：Port <--> 宛先IPv6：Port, 変換後宛先IPv4 : Port <--> NAT変換後送信元IPv4 : Port　<- NAT-TCP-N / NAT-TCP-Dに関して
日時　ホスト名　種別　変換前送信元IPv6：Port -> NAT変換後送信元IPv4 : Port  <- NAT-TCP-C / NAT-TCP-Fに関して

C : NAT Mapping Created
F : NAT Mapping Freed
N : Data Session Created
D : Data session Deleted

当面続く「移行期」への備えを

　2012年6月6日には、全世界的な取り組みである「World IPv6 Launch」が始まります。全世界のメジャーなWebサイトが、恒久的なIPv6対応を図るという取り組みで、いよいよIPv4とIPv6が共存する世界が始まります。われわれA10ネットワークスも、今回の連載で紹介したIPv4/IPv6移行ソリューションやIPv6ロードバランサを通じて、World IPv6 Launchの一翼を担っています。

　より先進的なユーザーの中には、たとえ外の世界がまだIPv4だとしても、「これからのうちのインフラはIPv6で作っていくぞ！」と考えている方もいらっしゃるでしょう。自社イントラネットの中だけであれば、力技で、サーバやクライアントすべてのIPv6化は可能かと思います。

　しかし「The Internet」にアクセスしないネットワークは、よほど機密性の高いネットワークやラボ環境などでもない限り、あり得ないでしょう。たとえイントラネットがIPv6化されたとしても、これからしばらく続くであろう移行期には、The Internet上のIPv4サーバへのアクセスも必要になります。そういう場合には、今回紹介したNAT64/DNS64のようなソリューションが重要となります。

　この連載では3回にわたってIPv6への移行方法に関してお話させていただきました。IPv6移行ソリューションにはいろいろな種類があり、ネットワーク構成や目的に応じて使い分ける必要があるということがご理解いただけたかと思います。

　繰り返しになりますが、IPv4アドレスの配布はすでに枯渇しました。もうIPv4だけのネットワークを考える時代は終わりを迎えました。ネットワーク構成やお使いの機器によって選択できるソリューションは異なると思いますが、まずは可能な部分から、移行策の検討を始められてはいかがでしょうか。
最終回　NAT64でIPv6端末をIPv4サーバにつなげよう
  一台二役を果たす「NAT64/DNS64」
AXシリーズにおけるNAT64/DNS64の設定例
フラグメンテーションのサポート
HTTPならばリンク先のリライトは原則不要に
NAT64セッションログの保存
当面続く「移行期」への備えを
「Master of IP Network総合インデックス」

　



Master of IP Network フォーラム 新着記事
＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

注目のテーマ

Master of IP Network 記事ランキング

本日 月間
＠IT