新機能 – IPv6 専用ワークロードを IPv4 サービスに接続できるようになりました

2022 年 2 月 28 日（米国時間）、Amazon Virtual Private Cloud (VPC) NAT ゲートウェイと Amazon Route 53 の 2 つの新機能を発表しました。これにより、IPv6 専用ワークロードが IPv4 専用サービスと透過的に通信できるようになります。

一部のお客様は、数万台の仮想マシン、コンテナ、またはマイクロサービスが関係する非常に大きなワークロードを実行しています。この実行のために、IPv6 アドレス空間でこれらのワークロードの作業を行えるように設定したとします。これにより、使用可能な IPv4 アドレスが不足するという問題を回避することができ (1 つの VPC では、IPv4 アドレスの理論上の最大サイズは 65,536 個である一方で、IPv6 では /56 の範囲であり、IPv6 アドレスの理論上の最大サイズは 2^73 -1 個となります)、複雑な IPv4 ベースのネットワークを管理していることが原因となって生じるさらなる頭痛の種から解放されます (複数の AWS アカウント、AWS リージョン、またはオンプレミスネットワークに属する VPC 間で重複しないサブネットを考えてみてください)。

しかし、IPv6 ワークロードを他の IPv4 環境から切り離して実行できるのでしょうか? 多くのお客様から、複数の依存ワークロードを IPv6 から IPv4 に移行する間は、古い API を呼び出すため、または一時的な設計として、そのようなワークロードを IPv4 サービスと引き続き通信させることが重要だというお声をいただきました。IPv6 ホストから IPv4 サービスを呼び出すことができないと、移行が必要以上に遅く、困難なものとなります。そのため、一部のお客様は、メンテナンスが困難なカスタムソリューションを構築せざるを得ませんでした。

これを踏まえて、当社は、お客様の IPv6 ワークロードが IPv4 サービスと透過的に通信できるようにする 2 つの新機能をリリースします。その 2 つの新機能とは、VPC NAT ゲートウェイ用の NAT64 (「six to four」と読みます) と、Amazon Route 53 Resolver 用の DNS64 (これも「six to four」と読みます) です。

仕組み
次の図に示すように、IPv6 専用アドレスを持つ Amazon Elastic Compute Cloud (Amazon EC2) インスタンスがあり、別の EC2 インスタンスで実行されている IPv4 サービスに対して API コールを実行する必要があるとします。この図では、IPv4 専用ホストを同じ AWS アカウントの別の VPC に配置することを選択しましたが、これらの機能は、同じ VPC 内、別の AWS アカウントの VPC 内、オンプレミスネットワーク、パブリックインターネットのいずれであっても、あらゆる IPv4 サービスに接続できます。IPv6 専用ホストが認識するのはサービスの DNS 名のみです。

IPv6 専用ホストが IPv4 サービスへの接続を開始したときに発生するシーケンスは次のとおりです。

1.IPV6 ホストは DNS コールを実行し、サービス名を IP アドレスに解決します。DNS64 がなければ、Route 53 は IPv4 アドレスを返していました。IPv6 専用ホストは、その IPv4 アドレスに接続できなかったことでしょう。しかし、本日より、サブネット用に DNS64 を有効にすることができるようになりました。DNS リゾルバーはまず、レコードに IPv6 アドレス (AAAA レコード) が含まれているかどうかをチェックします。含まれている場合、IPv6 アドレスが返されます。IPv6 ホストは IPv6 のみを使用してサービスに接続できます。レコードに IPv4 アドレスのみが含まれている場合、Route 53 リゾルバーは IPv4 アドレスの前に既知の 64:ff9b::/96 プレフィックスを付加して IPv6 アドレスを合成します。

例えば、IPv4 サービスのアドレスが 34.207.250.62 の場合、Route 53 は 64:ff9b::ffff:22cf:fa3e を返します。

64:ff9b::/96 は、RFC 6052 が提案する IETF 標準で定義されているよく知られたプレフィックスです。標準を読むことは、すぐに眠りに落ちるためのIPv6 から IPv4 への変換に関するあらゆる詳細を知るための優れた方法です。

2.IPv6 ホストは 64:ff9b::ffff:22cf:fa3e への接続を開始します。64:ff9b::/96 で始まるすべてのパケットを NAT ゲートウェイに送信するように、サブネットルーティングを設定できます。NAT ゲートウェイは IPv6 アドレスのプレフィックスを認識し、そこから IPv4 アドレスを抽出して、宛先への IPv4 接続を開始します。通常どおり、ソース IPv4 アドレスは NAT ゲートウェイ自体の IPv4 アドレスです。

3.パケットレスポンスが到着すると、NAT ゲートウェイは宛先ホストの IPv6 アドレスを再入力し、よく知られているプレフィックス 64:ff9b::/96 をレスポンスパケットのソース IP アドレスの前に付加します。

これで仕組みが理解できました。さて、これらの 2 つの新機能を活用するためには VPC をどのように設定すればよいのでしょうか?

開始方法
これらの 2 つの機能を有効にするには、2 つの設定を調整する必要があります。1 つ目は DNS64 変換を必要とするサブネットにフラグを立てること、2 つ目は IPv6 サブネットルーティングテーブルにルートを追加して、IPv6 トラフィックの一部を NAT ゲートウェイに送信することです。

DNS64 を有効にするには、新しい --enable-dns64 オプションを使用して既存のサブネットを変更する必要があります。このデモでは、modify-subnet-attribute コマンドを使用します。これは 1 回限りの操作です。VPC API、AWS Command Line Interface (CLI)、または AWS マネジメントコンソールを使用して実行できます。これはサブネットレベルの設定であり、明示的にオンにする必要があることに注意してください。デフォルトでは、既存の動作は維持されます。

aws ec2 modify-subnet-attribute --subnet-id subnet-123 --enable-dns64

サブネットのルーティングテーブルにルートを追加して、DNS64 プレフィックスが付加された IPv6 パケットを VPC が NAT ゲートウェイに転送できるようにする必要があります。これは、宛先が 64:ff9b::/96 のすべてのパケットを NAT ゲートウェイにルーティングするように指示します。

aws ec2 create-route --route-table-id rtb-123 –-destination-ipv6-cidr-block 64:ff9b::/96 –-nat-gateway-id nat-123

次の図は、これらの 2 つのシンプルな設定変更を示しています。

2 つのシンプルな変更により、サブネット内の IPv6 専用ワークロードが IPv4 サービスと通信できるようになりました。IPv4 サービスは、同じ VPC 内、別の VPC 内、またはインターネット上の任意の場所に存在する可能性があります。

お客様は、既存の NAT ゲートウェイを引き続き使用でき、ゲートウェイ自体や NAT ゲートウェイサブネットにアタッチされたルーティングテーブルを変更する必要はありません。

料金と利用可能なリージョン
VPC NAT ゲートウェイと Route 53 に対するこれらの 2 つの新機能は、本日より、すべての AWS リージョンで追加費用なしでご利用いただけます。通常の NAT ゲートウェイ料金が適用される場合があります。

IPv6 専用ネットワークを構築しましょう!

— seb

原文はこちらです。