メインコンテンツまでスキップ

7. NAT64およびDNS64を使用したIPv6のみのネットワークのサポート (Supporting IPv6-Only Networks with NAT64 and DNS64)

多くのIPv6移行プロトコルが標準化され展開されていますが、ほとんどはクライアントデバイスに対して透過的です。NAT64 [RFC6146] とDNS64 [RFC6147] の組み合わせ使用は、展開されている人気のあるソリューションであり、クライアントデバイスの変更を必要とします。これらのネットワークを処理する1つの可能な方法は、クライアントデバイスのネットワークスタックが464XLAT [RFC6877] を実装することです。464XLATには、ユーザースペースソフトウェアの変更を必要としないという利点があります。ただし、アプリケーションがIPv4リテラルを使用している場合、パケットごとの変換が必要であり、クライアントアプリケーションソフトウェアがネイティブIPv6をサポートすることを奨励しません。464XLATをサポートしていないプラットフォームでは、Happy EyeballsエンジンはこのセクションのNAT64とDNS64を使用したIPv6のみのネットワークを適切にサポートするための推奨事項に従うべきです (SHOULD)。

このセクションで説明されている機能は、ホストがこれらのネットワークの1つを検出した場合にのみ有効にすべきです (SHOULD)。これを実現するための簡単なヒューリスティックは、ネットワークがルーティング可能なIPv6アドレス指定を提供し、ルーティング可能なIPv4アドレス指定を提供せず、DNSリゾルバーアドレスを提供するかどうかを確認することです。

7.1. IPv4アドレスリテラル (IPv4 Address Literals)​

クライアントアプリケーションまたはユーザーがIPv4アドレスリテラルに接続したい場合、Happy EyeballsエンジンはそれらのためにNAT64アドレス合成を実行する必要があります。ソリューションは"Bump-in-the-Host" [RFC6535] に似ていますが、Happy Eyeballsライブラリ内に実装されています。

ホスト名の代わりにIPv4アドレスがライブラリに渡されると、デバイスは"Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" (IPv6アドレス合成に使用されるIPv6プレフィックスの発見) [RFC7050] を使用してNAT64プレフィックスをネットワークにクエリし、次に"IPv6 Addressing of IPv4/IPv6 Translators" (IPv4/IPv6トランスレータのIPv6アドレス指定) [RFC6052] で説明されているエンコーディングを使用して適切なIPv6アドレス (または複数のアドレス) を合成します。合成されたアドレスは、DNSクエリの結果であるかのようにアドレスのリストに挿入されます。接続試行は上記のアルゴリズムに従います (セクション5を参照)。

7.2. 破損したAAAAレコードを持つホスト名 (Hostnames with Broken AAAA Records)​

執筆時点では、有効なAレコードと破損したAAAAレコードに解決されるホスト名が少数ですが無視できない数存在します。これは、一見有効なIPv6アドレスを含むが、通常のポートで連絡してもこれらのアドレスが決して応答しないAAAAレコードとして定義されます。これらは、例えば以下のような原因で発生する可能性があります:

  • DNSゾーン構成におけるIPv6アドレスの入力ミス

  • ルーティングブラックホール

  • サービス停止

この文書の他のセクションに準拠するアルゴリズムは、デュアルスタックネットワーク上でこのようなホスト名を正しく処理しますが、NAT64とDNS64を使用するIPv6のみのネットワークでは必ずしも正しく機能しません。DNS64再帰リゾルバーは、AAAAレコードの否定的な ("エラーなし応答なし") 応答を送信する権威ネームサーバーに依存して合成を行うため、これらの特定のホスト名のレコードを合成せず、代わりに破損したAAAAレコードをパススルーします。

これらのシナリオをサポートするために、クライアントデバイスはDNSに対してAレコードをクエリし、その後ローカル合成を実行する必要があります。これらのタイプのホスト名はまれであり、DNSサーバーの負荷を最小限に抑えるために、このAクエリはクライアントが最初に受信したAAAAレコードを諦めたときにのみ実行する必要があります。これは、"Last Resort Local Synthesis Delay" (最後の手段のローカル合成遅延) と呼ばれるより長いタイムアウトを使用することで実現できます。遅延は2秒が推奨されます。タイマーは最後の接続試行が開始されたときに開始されます。このタイマーが起動したときに接続試行が成功していない場合、デバイスはIPv4アドレスのDNSをクエリし、有効なAレコードを受信すると、それがアプリケーションによって提供されたかのように扱います (セクション7.1を参照)。

7.3. 仮想プライベートネットワーク (Virtual Private Networks)​

一部の仮想プライベートネットワーク (Virtual Private Network, VPN) は、デバイスからのDNSクエリを処理するように構成されている場合があります。構成には、すべてのクエリまたは"*.internal.example.com"などのサブセットが含まれる場合があります。これらのVPNは、192.0.2.0/24などのIPv4アドレス空間の一部のみをルーティングするように構成することもできます。ただし、内部ホスト名が外部IPv4アドレスに解決される場合、基盤となるネットワークがIPv6のみである場合、これらは問題を引き起こす可能性があります。例として、"www.internal.example.com"が正確に1つのAレコード198.51.100.42を持ち、AAAAレコードを持たないと仮定しましょう。クライアントは会社の再帰リゾルバーにDNSクエリを送信し、そのリゾルバーはこれらのレコードで応答します。デバイスには接続先のIPv4アドレスしかなく、そのアドレスへのルートがありません。会社のリゾルバーは基盤となるネットワークのNAT64プレフィックスを知らないため、アドレスを合成できません。同様に、基盤となるネットワークのDNS64再帰リゾルバーは会社の内部アドレスを知らないため、ホスト名を解決できません。このため、クライアントデバイスは会社のリゾルバーを使用してAレコードを解決し、解決されたIPv4アドレスがアプリケーションによって提供されたかのように、ローカルでIPv6アドレスを合成する必要があります (セクション7.1)。

に最終更新