メインコンテンツへジャンプする

JPNICはインターネットの円滑な運営を支えるための組織です

WHOIS 検索 サイト内検索 WHOISとは? JPNIC WHOIS Gateway
WHOIS検索 サイト内検索
プリント用ページ

ニュースレターNo.64/2016年11月発行

NAT64/DNS64

今回のインターネット10分講座では、IPv4ネットワークからIPv6ネットワークへの移行技術の一つである、NAT64/DNS64を取り上げます。

IPv4とIPv6の共存技術としては、通常はIPv4とIPv6を併用するデュアルスタックが用いられることが一般的ですが、NAT64/DNS64ではIPv6アドレスのみを利用したネットワークから、IPv4ネットワークのサービスに接続できることが特徴です。

そのため、デュアルスタック構成よりもIPv4アドレスの節約ができるということで、最近注目を集めている移行技術です。

IPv4アドレス利用の将来

現在のIPv6アドレスの採用については、主にIPv6アドレスと共にIPv4アドレスも配布する「デュアルスタック」がほとんどです。しかしながら、IPv4アドレスの在庫はすでに枯渇状態にあり、IPv4アドレスの新規調達は、時間の経過とともにより困難となっていく傾向にあります。

そのため、新規に立ち上がるサービスやプラットフォームではIPv6アドレスのみが利用されることがあります。例として、一般社団法人日本建築構造技術者協会(JSCA)のスマートハウス・ビル標準・事業促進検討会が取りまとめた「HEMS(Home Energy Management System)-スマートメーターBルートガイドライン」では、過剰な機能の削減や将来性などを考慮して、IPv4アドレスとIPv6アドレスのデュアルスタックではなく、IPv6アドレスのみを採用すると定められています。また、Apple社ではApp Storeへ登録されるアプリの審査基準において、2016年6月1日よりIPv6アドレスのみが割り当てられるネットワークへの対応を求めています。※1その中でIPv4アドレスへのアクセスについては、NAT64とDNS64ネットワークへの互換性が求められています。

NAT64/DNS64が利用される環境

ネットワーク機器にIPv4アドレスとIPv6アドレスの両方を割り当てるデュアルスタックの構成は、機器の処理やそれによって求められる性能や機能、管理や運用面などさまざまな要素において、IPv6アドレスのみを割り当てる構成よりもコストがかかります。ネットワークに求められる要件を新たに定めることができるケースや、装置向けの管理用通信のみ求められるケースなどではIPv6アドレスのみのネットワークの採用も可能と考えられます。しかし、Webブラウジングなどを目的とする一般的なユーザーが利用する端末向けには、現在はIPv4アドレスのみを持つコンテンツがまだ多く存在するために、それらのコンテンツへの接続性確保が必要です。現在はこの対応のためにデュアルスタックが広く用いられていますが、これはIPv4アドレスの在庫枯渇への対応とはなりません。

本稿で紹介するNAT64/DNS64技術は、ユーザーが利用する端末にIPv6アドレスのみを与えるネットワーク構成で利用される技術です。IPv6アドレスのみを持つ端末から、IPv4アドレスを利用して提供されるサービスへの到達性の確保を実現する技術となります。

ネットワーク全体を見たときは、この技術を利用するだけでは完全なIPv6ネットワークへの移行が実現されるわけではありません。エンドツーエンドの通信がIPv6アドレスを利用して行われるようになるためには、サービスの提供もIPv6アドレスによって行われる必要があります。

NAT64/DNS64を利用するようにネットワークを構築する場合、通常、ユーザー端末からサービス提供サーバまでがIPv6ネイティブで行われる通信については、NAT64は利用しないようにネットワークを構築します。これにより、DNS64によるIPアドレスの変換とNAT64によるIPv6ヘッダとIPv4ヘッダの変換は、IPv4アドレスのみを持つ装置への到達性確保を実現するためだけになされるようになります。この場合、NAT64/DNS64はサービスがIPv6での提供に対応すると利用されなくなりますので、ネットワーク全体が段階的にIPv6アドレスを利用していくことを助けることができます。なお、NAT64およびDNS64技術はユーザー端末の属するネットワークだけではなく、サービス提供側のネットワークにおいても利用することが可能です。

NAT64/DNS64の動作概要

前述の通り、NAT64/DNS64を利用する端末は、IPv6アドレスのみが割り当てられています。端末がNAT64/DNS64を利用した通信を行う際、端末はまずDNSで名前解決を行い、通信の宛先となるIPアドレスの取得を試みます。このDNSクエリはDNS64が有効となっているDNSサーバに対して行うようにネットワークが設計されます。通常は、DNSパケットを受信したDNS64サーバは、Aレコードのみが得られた場合のみ、その得られたIPv4アドレスとIPv4-IPv6変換アドレス用のプリフィクスを使ってIPv6アドレスを合成します。そして、合成したIPv6アドレスをAAAAレコードで通信を行った端末へ回答します(図1)。

図1 DNS64 動作フロー
図1 DNS64 動作フロー

これにより端末は、IPv6アドレスとなった宛先アドレスの名前解決が完了しますので、合成されたIPv4-IPv6変換アドレスを宛先として通信を開始します。ここで利用されるネットワークは、設定されたIPv4-IPv6変換アドレスを宛先とした通信がNAT64へ到達するように設計されている必要があります。NAT64には利用するIPv4-IPv6変換アドレスを登録しておきます。NAT64は、設定されたプリフィクスが宛先となっているパケットが到達した場合、そのパケットのIPv6ヘッダをIPv4ヘッダに置き換えます。変換の際には設定されたNATプールのIPv4アドレスを送信元とし、IPv4-IPv6変換アドレスに埋め込まれたIPv4アドレスを読み取り、パケットの宛先として送信します。通信に応答があった場合には、今度はパケットのIPv4ヘッダをIPv6ヘッダに付け替え、元のIPv4-IPv6変換アドレスを送信元とし、通信を開始した端末へ返送します。これによりIPv6アドレスのみが利用される環境において、IPv4アドレスによってのみ提供されるサービスへの到達性が実現されます(図2)。

図2 NAT64動作フロー
図2 NAT64動作フロー

IPv4-IPv6変換アドレス

NAT64/DNS64を利用した通信では、RFC6052で定義されたIPv4-IPv6変換アドレスをNAT64とそれを利用する端末間の通信に利用します。この変換アドレスのWell-known prefixは、64:ff9b::/96となり、IPv4アドレスは、IPv4-IPv6変換アドレスの末尾に合成されます。例としてexample.jpが192.0.20.1を持つときに、このIPv4アドレスを、IPv4-IPv6変換アドレスのWell-known prefixに合成した場合を示します。このケースの合成後のアドレスは、64:ff9b::192.0.20.1ですが、16進数表記では64:ff9b::c000:1401となります。この例の場合、IPv4アドレスの最初の1バイトの192は16進数表記ではC0、続いて0が00、20が14、1が01となります。また、Well-knownアドレス以外の/96のprefixを変換アドレスとして使用することも可能です。どのアドレスを利用する場合であっても、NAT64、DNS64そして通信に介在するネットワーク機器は同じIPv4-IPv6変換アドレス用のプリフィクスを使用するよう設定されている必要があります。

DNS64

端末がNAT64を利用するために必要なIPv4-IPv6変換アドレスは、RFC6147で定義されているDNS64を利用した名前解決で配布します。名前解決の問い合わせを受けたDNS64サーバは、まずAAAAレコードの名前解決を行います。通常、権威サーバよりAAAAレコードの名前解決ができればIPv4-IPv6変換アドレスへの合成を行わず、得られたIPv6アドレスをそのまま問い合わせを行った端末へ応答します。もしAAAAレコードが解決できなかった場合は、次にAレコードの名前解決を行います。

この後にDNS64サーバは、得られたIPv4アドレスをIPv4-IPv6変換アドレス用プリフィクスに合成し、問い合わせを行った端末へ回答します。この実装により、DNS64はIPv6ネイティブの通信を阻害しない仕組みとすることができます。

Google社はPublic DNSサービスとして、DNS64サービスを提供しています。このサービスでは、Well-known prefixである64:ff9b::/96に合成したアドレスが提供されます。なお、NAT64を利用できない端末へDNS64で合成したアドレスを配布すると、IPv4アドレスへの到達性を失うことになるので注意する必要があります。

また、Apple社はMac OS Xで、NAT64機能を試すことができるネットワーク共有機能を提供しています。この機能はIPv4のみのネットワーク状況でも動作するように設計されており、この機能で利用されるDNS64は、dns64-synthall機能が有効となっています。問い合わせ対象のホストがAAAAレコードとAレコードの両方を持っている場合であっても、Aレコードで得られたIPv4アドレスから合成したIPv4-IPv6変換アドレスを応答します。併せて、接続される端末へ分配するIPv6アドレスは、RFC5180で定義されるIPv6ベンチマークアドレスが利用されます。

端末自身でのアドレス合成

端末自身がDNS64の存在を検出し、端末自身でのアドレスの合成を行うことができるよう、ネットワークで利用されているIPv4-IPv6変換アドレス用のプリフィクス情報を提供する機能があります。この機能はPref64::/n Discoveryと呼ばれ、RFC7050で定義されています。

NAT64/DNS64ではアドレスの変換にDNSの利用が前提となっています。しかし、社内ネットワーク用途などで、IPv4アドレスを直接指定してWebブラウジングを行う場合などのIPv4リテラルアドレス宛の通信ではDNSが利用されません。Pref64::/n Discoveryは、このような通信を行う場合に用いられ、端末自身がIPv4リテラルアドレスをIPv4-IPv6変換用アドレスへの合成を行って通信することが可能です。

Pref64::/n Discoveryの動作は、まず、端末がWell-knownであるIPv4のみのドメイン名であるipv4only.arpa.に対し、AAAAレコードの名前解決を行います。ipv4only.arpa.には192.0.0.170と192.0.0.171の二つのWell-knownなIPv4アドレスが割り当てられており、DNS64機能が有効である場合、そのネットワークで有効なIPv4-IPv6アドレスに合成されて名前解決されることになります。結果として端末は、このWell-knownドメインへのDNSクエリ応答内容によって、利用するDNSサーバでDNS64機能が有効であるのか、また、その変換に用いられているIPv4-IPv6アドレス変換用プリフィクスが何であるのか理解することができます。当機能はApple社端末でのIPv4リテラルアドレスのNAT64対応に利用されているようです※2

NAT64

NAT64/DNS64を利用したネットワークでは、NAT64はRFC6146で定義されたステートフルNAT64が利用されます。ステートレスNAT64もRFC6145で定義されています。この技術では変換するためのアドレスが固定となるため、ダイナミックなアドレス割り当てがなされるアクセスネットワークでの利用環境には適しませんが、464XLATではクライアント側で利用されます。

なお、Well-knownアドレスである64:ff9b::/96は、インターネットへ広報することはできません。AS内部のネットワークでの構築に利用可能です。

他のIPv4-IPv6変換技術:464XLATについて

NAT64/DNS64技術は、端末へIPv6のみを割り当てたネットワークにおいて、DNSの名前解決を利用してアクセスをする通信のうち、IPv4アドレスのみを持つサービスへの到達性を拡張することが可能な技術です。しかし、現状では残念ながらいくつかのアプリケーションは、NAT64とDNS64技術だけでは動作させることができません。この問題を解決するために利用可能な技術として464XLATがあります。

464XLATは、必須では無いのですがDNS64を組み合わせて利用することが可能となっています。その場合、NAT64/DNS64に加えて、NAT46をクライアントで実現し、必要な通信はIPv4で行わせるという、ダブルトランスレーションの構成を構築することができます。464XLATはRFC6877で規定されており、利用する端末やその端末が属するエッジネットワークには、CLAT(Customer Side Translator)と呼ばれるステートレスNAT64機能が実装された装置によって終端されます。このCLATがクライアントのIPv4パケットのヘッダをIPv6に変換します。464XLATにおけるセンター装置はPLAT(Provider Side Translator)と呼ばれ、ステートフルNAT64を用います。ここで、パケットはIPv4に戻されます。

現在のクライアント端末の主要な実装では、IPv6アドレスでの通信が優先されますので、DNS64を用いて464XLATを構成すると、まずIPv6ネイティブの通信や、クライアントがIPv6アドレスを利用する、NAT64/DNS64の変換を利用する通信が優先されます。そして、クライアントがIPv4アドレスを利用する必要があるケースのみ、IPv4アドレスを利用して通信されることになります。

464XLATでIPv4が利用される通信は、サービスを提供するサーバー側がIPv6ネイティブ、もしくはNAT64経由での提供に対応するまでの間だけとなる特徴があります。一方NAT64/DNS64では、通信を行う端末はIPv6アドレスのみを持ちながらも、IPv4アドレスのみを持つ装置への到達性が確保されるという違いがあります。

464XLATはAndroidでは4.3から対応されており、ISOC deploy360のホームページではT-mobile社での事例紹介がされています。

まとめ

本稿では、NAT64/DNS64技術に関連したトピックスについてご紹介しました。NAT64/DNS64は真のIPv6対応を実現するという技術ではなく、IPv4とIPv6共存時代の一つの選択肢です。しかしApple社からアプリへのNAT64/DNS64技術への対応を求めるアナウンスもあり、なんらかのアプリがIPv6対応した、という際には、この技術を前提とした動作をし、IPv6ネイティブでの通信は行わないことも考えられます。そのため、IPv6対応をうたったアプリケーションの動作を確認することがあり得る技術者は、この技術について認識しておく必要があるかもしれません。

本稿執筆時点では、Akamai社の統計によると日本からAkamai社へのIPv6アクセス比率は13位となっており(表1)、日本だけが特別に対応が進んでいるという状況ではありません。海外でのIPv6アドレスの利用拡大の動向にも合わせて、国内でもIPv6アドレスの利用拡大がより進んでいくことを期待しています。

表1 Akamai社国別IPv6アクセスTOP15
表1 Akamai社国別IPv6アクセスTOP15

(JPNIC 技術部 佐藤秀樹)


※1 Apple社 IPv6 DNS64/NAT64ネットワークのサポート
https://developer.apple.com/jp/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html
※2 IETF[v6ops]Apple and IPv6, a few clarifications
https://www.ietf.org/mail-archive/web/v6ops/current/msg22275.html

このページを評価してください

このWebページは役に立ちましたか?
ページの改良点等がございましたら自由にご記入ください。

このフォームをご利用した場合、ご連絡先の記入がないと、 回答を差し上げられません。 回答が必要な場合は、お問い合わせ先をご利用ください。

Copyright© 1996-2019 Japan Network Information Center. All Rights Reserved.