Amazon Web Services ブログ

AWSおよびハイブリッドネットワークにおけるデュアルスタックIPv6アーキテクチャ – パート2

この記事はDual-stack IPv6 architectures for AWS and hybrid networks – Part2 (記事公開日: 2022 年 6 月 8 日) を翻訳したものです。

AWS とハイブリッドネットワークアーキテクチャにおけるIPv6 に関するシリーズのパート1 では、最も一般的なデュアルスタック設計のいくつかを調査しました。デュアルスタックAmazon Virtual Private Cloud (Amazon VPC) とAmazon Elastic Compute Cloud (Amazon EC2) インスタンス、インターネット接続、インターネット向け Network Load Balancer と Application Load Balancer のデプロイメント、さらに VPC とハイブリッド接続などです。このパート２の旅に飛び込む前に、チェックしてみることをお勧めします。

AWS やオンプレミスの内部ネットワークに IPv6 を採用する主な理由の1 つは、大規模なマルチリージョンデプロイメントやコンテナの導入により、プライベート IPv4 空間への負荷が増大していることです。2021 年11 月には、IPv6 専用のサブネットとデュアルスタック Amazon VPC のサポートを開始し、これらのサブネットで IPv6 専用のNitro EC2 インスタンスを起動する機能も提供されました。

IPv6 アーキテクチャの旅のパート2では、IPv6 専用サブネット、内部デュアルスタック ELB のサポートとIPv6 専用ターゲット、DNS64、NAT64、Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Relational Database Service (Amazon RDS)、AWS PrivateLink IPv6 Support によって動作する、AWS とハイブリッドネットワークで活用できる IPv6 アーキテクチャについて調査します。各参照サービスの設定オプションに関する詳細情報については、各セクションのドキュメントリンクを参照することをお勧めします。

このブログでは、以下の IPv6 とデュアルスタックアーキテクチャを対象としています。

  1.  IPv6 対応の Amazon VPC における IPv6 専⽤サブネットと EC2 インスタンス
  2. デュアルスタック AWS ネットワークにおける NAT64 と DNS64 を使⽤した IPv4 専用のサービスやワークロードとの後⽅互換性
  3. Application Load Balancer および Network Load Balancer を使用したデュアルスタックアプリケーションエンドポイントと IPv6 ターゲットグループ
  4. デュアルスタック Amazon VPC における Amazon EKS の IPv6 サポート
  5. デュアルスタック Amazon VPC におけるAmazon RDSとAWS PrivateLinkのIPv6サポート

Amazon VPC の構成と、言及されているサービスのデュアルスタック機能および構成オプションについて理解していることを前提としています。さらに、IPv6 プロトコルの定義、アドレスの種類、設定メカニズムについても知っておく必要があります。ここでは、IPv4 と IPv6 の両方を使用するアーキテクチャの実装について、インターオペラビリティーとベストプラクティスに焦点を当てて説明します。

1. IPv6 対応の Amazon VPC における IPv6 専⽤サブネットと EC2 インスタンス

デュアルスタック VPC で IPv6 専用サブネットと EC2 インスタンスをサポートすることで、大量のIP アドレスを消費するワークロードをスケールアップすることができます。さらに、政府が定める IPv6 専用ネットワーク環境の導入要件を満たし、変換ソフトウェアやシステムの必要性を最小限に抑えることで、シンプルでコスト効率の高い、パフォーマンス重視のアーキテクチャを構築することができます。

VPC は引き続きデュアルスタックであり、IPv4 専用サブネット、デュアルスタックサブネット、IPv6 専用サブネットを同じ VPC 内に混在させることができます。これにより、IPv6 ネイティブのワークロードを作成し、IPv4 のみ、またはデュアルスタックのワークロードと共存させることができます。VPC 内の各IPv6専用またはデュアルスタックサブネットには、固定の/64 IPv6 プレフィックス長があります。IPv6 専用サブネットの作成方法の詳細については、こちらのブログとドキュメントを参照してください。

IPv6 アドレス計画を管理するいくつかの原則について説明する価値があります。IPv6 では、IPv4 アドレス計画の出発点である “このサブネットに何台のホストを置く予定ですか？” という質問は意味を持ちません。IPv6 アドレス計画を検討するとき、主な関心事は、”いくつのサブネットが必要で、どのようにしてそれらのサブネットを割り当て、論理的でスケーラブルなアドレス計画を策定し、より効率的にネットワークを運用できるか？”ということです。

VPC の設計をもう一度考えてみましょう。IPv6 専用のサブネットを作成したとき、VPC 内のトラフィックパターンと、VPC 外の接続性をどのように確保するかを見てみましょう。

a. VPC 内部フロー

次の図は、2つのデュアルスタックサブネットと 2つの IPv6 専用サブネットを持つ VPC の例を示しています。

Figure 1: Amazon VPC IPv6-only internal flows

上図で強調表示されている最初のトラフィックフロー（1）ですが、VPC 内のIPv6 専用の通信に対応しています。VPC 内の IPv6 専用リソースは、IPv6 スタックを使用して他のIPv6 専用リソースと通信できます。2 番目のフロー（2）では、VPC 内のIPv6 専用リソースとデュアルスタックリソース間の通信は、IPv6 プロトコルスタックを使用して可能です。どちらのフローもVPC 内にあるため、VPC のセキュリティコントロール（セキュリティグループ、ネットワークACL）が通信を許可していれば、サブネットのパブリック or プライベートの性質は影響をしません。

次に、IPv6 専用のワークロードのインターネット接続について見てみましょう。

b. インターネット接続

IPv6 が有効な VPC では、3つのタイプのサブネット(IPv4 専用、デュアルスタック、IPv6 専用)すべてで同じセキュリティ制御と実施メカニズムを維持できます。VPC 内のワークロードのセキュリティ特性によって、プライベートおよびパブリックサブネットへの配置が決定されます。

パブリックIPv6専用サブネット

パブリック IPv6 専用サブネットのインターネット接続は、デュアルスタックサブネットと同じ仕組みで、インターネットゲートウェイ（IGW）を送信と受信に使用します。デュアルスタック接続の詳細については、このシリーズのパート1を参照してください。次の図は、IPv6 専用パブリックリソースのパブリックIPv6 接続のトラフィックフローと、対応するルートテーブルを示しています。

Figure 2: Public IPv6-only subnets Internet connectivity

パブリック IPv6 専用リソースの双方向接続は、サブネットCIDR からIPv6 アドレスを使用して実現され、Elastic IP および IPv4 トラフィックのIGW レベルで発生する1 対1 ネットワークアドレス変換（NAT）は必要ありません。VPC で作成したルートテーブルには、IPv6 専用のサブネットかどうかに関係なく、VPC のIPv4 とIPv6のCIDR ブロックの両方がローカルルートとして含まれます。

プライベートIPv6 専用サブネット

プライベートサブネットのインターネット接続は、クライアント・サーバー通信モデルに厳密に縛られています。IPv4 とIPv6 両方のルーティング設定により、プライベートサブネット内にデプロイされたワークロードは、パブリックエンドポイントへの接続を開始し、応答トラフィックを受信することができます。IPv6 専用サブネットの場合、Egress-only IGW はこの通信フロータイプを適用するVPC コンポーネントで、インターネットからプライベート IPv6 専用インスタンスへのIPv6 接続が開始されることを防ぎ、アドレスまたはポート変換に依存せずに、戻りのトラフィックのみを許可します。

Figure 3: Private IPv6-only subnets Internet connectivity

次に、IPv6 では、IPv4 ネットワークで使用されているネットワークアドレス変換（NAT）は必要ないことを考えましょう。NAT44 をセキュリティの仕組みと考える人もいますが、セキュリティのコミュニティは長年にわたってその神話を払拭しようとしてきました。攻撃がエスカレートしている今日の環境では、NAT44（またはNAT66）がなぜ不十分なのかを理解する必要があります。これは、単純なインバウンド・トラフィックの拒否だけでなく、受信及び送信のポイントにさまざまな種類のセキュリティ・サービスが存在することを認識することから始まります。ベストプラクティスでは、AWS Shield と Shield Advanced、AWS Network Firewall、AWS Web Application Firewall（AWS WAF）、セキュリティグループ、ネットワークACL などのサービスを利用して、DDoS 保護、ポートおよびプロトコルフィルタリング、Web アプリケーションフィルタリングを実装する必要性を示しています。

2. デュアルスタック AWS ネットワークにおける NAT64 と DNS64 を使用した IPv4 専用のサービスやワークロードとの後方互換性

プロトコルのバージョンの違いは、ネットワークの参加者が話たり理解できる言語として考えることができます。IPv4 とIPv6 では、2 つのバージョン間に直接的な互換性がないため、ネットワーク内のホストはまったく異なる言語を話します。IPv6 専用のワークロードへの移行は、インターネットと内部ネットワークの両方で、IPv4 専用のエンドポイントやサービスとの後方互換性を維持する必要性が生じます。

ネットワーク通信は通常、DNS（ドメインネームシステム）解決に基づいており、クライアントがサービス名をトラフィックの送信に使用できる IP アドレスに解決します。VPC で実行されている IPv6 専用のワークロードは、IPv6 ネットワークパケットのみを送受信することができます。したがって、クエリに応答してIPv6 アドレスを提供するために、DNS解決が必要です。デフォルトでは、VPC 内のワークロードは、それらが構成されている IP プロトコルバージョン(IPv4 または IPv6)に関係なく、DNS解決に Amazon Route53 Resolver を使用します。DNS64 がない場合、IPv6 専用インスタンスから IPv4 専用のサービスに対する DNS クエリは、使用不可能な IPv4 アドレスを返します。

IPv4 と IPv6 間の通信ギャップを埋めるために、サブネットレベルの設定を使用して DNS64 を有効にすることができ、DNS64 を使用すると、Route53 Resolver はネットワークの IPv6 のみの部分を識別し、元のレコードが IPv4 のものであっても、IPv6 アドレスで DNS クエリに応答することができます。Route53 Resolver はDNS64 が有効な IPv6 専用サブネットの IPv6 専用のインスタンスからクエリを受け取ると（1）、レコードを検索して元の IPv6 アドレス（レコードにIPv6 アドレスが含まれている場合）、またはIPv4 アドレスによく知られている64:ff9b::/96 プレフィックスを付加した合成 IPv6 アドレス（2）のいずれかを返します。

Figure 4: DNS64 resolution from IPv6-only subnet

図では、IPv4 アドレスに64:ff9b::/96 のプレフィックスを付加しているため、ドット付き10 進数で表現しています。IPv6 専用のEC2 インスタンスが受信して使用するアドレスは、16 進数で表記された有効なIPv6アドレスです。たとえば、64:ff9b::10.1.1.20 は、16 進数で表記すると64:ff9b::a01:114 となります。DNS64 の動作の例を見てみましょう。

[ec2-user@i-01f432eb0e6efecb7~]$ dig AAAA ip-10-1-1-20.ec2.internal
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> AAAA ip-10-0-5-24.ec2.internal
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14364
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ip-10-1-1-20.ec2.internal.     IN      AAAA

;; ANSWER SECTION:
ip-10-0-5-24.ec2.internal. 60   IN     AAAA       "64:ff9b::a01:114"
;; Query time: 12 msec
;; SERVER: fd00:ec2::253#53(fd00:ec2::253)
;; WHEN: Sat Mar 19 23:43:46 UTC 2022

;; MSG SIZE  rcvd: 82

IPv6 専用インスタンスにはトラフィックを送信するためのIPv6 アドレスがあり、トラフィックを送信することができます。しかし、送信先にはIPv6 パケットを理解することができません。したがって、IPv6 専用インスタンス(3)から発信されたIPv6 パケットを、IPv4 専用 の送信先(4)が理解できる IPv4 パケットに変換するNAT64 が必要です。IPv6 専用サブネットには、そのルートテーブルに、NAT ゲートウェイをターゲットとする既知のプレフィックスである 64:ff9b::/96 を宛先とするルートを必要とします。

Figure 5: DNS64 and NAT64

宛先が IPv4 専用のサービスやエンドポイントは、同じVPC 内、インターネット、またはAWS やハイブリッドプライベートネットワーク（4）に配置できます。また、AWS Transit Gateway を使用して、IPv6 からIPv4 の後方互換性のために一元化された NAT64 インターネット Egress VPC と IPv4 フローのために NAT44 を使用できます。簡略化された以下の図では、IPv4 専用の宛先への可能なすべてのパスのサブセットを示しています。

Figure 6: NAT64 in a hybrid network

IPv6 専用インスタンスと IPv4 専用インスタンスには( ip-10-1-1-20.ec2.internal と i-01f432eb0e6efecb7.ec2.internal )が異なる名前が付けられていることに気付いたかもしれません。そこで、VPC のDNS とリソースの命名の仕組みを明らかにしておきましょう。VPC 内の Route53 Resolver に依存するDNS解決は、Resolver がルックアップ処理を実行する際に従う階層構造に基づいています。第1 にプライベートDNS（すなわちVPC に関連するRoute53 Private Hosted Zone）、第2 にVPC DNS（IP ベースまたはリソースベースの命名メカニズムで定義）、第3 にパブリックDNS（すなわちパブリックHosted Zones またはパブリックDNS）です。VPC DNS の設定を詳しく見てみると、IPv6 専用サブネットと EC2 インスタンスの起動により、リソースベースのネーミングが利用できるようになりました。これはインスタンスレベルの設定で、IPv6 専用のインスタンスではデフォルトで有効、デュアルスタックインスタンスではオプションです。次の表は、インスタンスのIP タイプに応じて、VPC DNS ネーミングで利用可能なオプションをまとめたものです。

Table 1: Amazon VPC DNS naming

VPC DNS レコードタイプはインスタンスレベルの設定であり、同一VPC 内、同一サブネット内ではIPベースの命名とResource ベースの命名の両方が共存可能です。アプリケーションが通信に必要な IP アドレスを取得するために、それらをどのように活用するかが重要です。IP ベースと Resource ベースのネーミングの詳細については、IPv6 専用サブネットのブログを参照してください。

DNS64 とNAT64 は、IPv6 専用のサブネットで有効化すること覚えておくことが重要です。デュアルスタックサブネットで DNS64 を有効にすると、デュアルスタックインスタンスは、同じ IPv4 宛先アドレスのA レコードとAAAA レコードの両方を受信することになります。OS レベルの設定は、ほとんどの場合、IPv6 を優先プロトコルとして選択します。したがって、通信は IPv4 プロトコルを直接使用せずに、NAT64 ゲートウェイを経由します。

3. Application Load Balancer および Network Load Balancer を使用したデュアルスタックアプリケーションエンドポイントと IPv6 ターゲットグループ

IPv4 アドレスによる制限を超えてAWS上のアプリケーションやワークロードをスケールできるように、Amazon Application Balancer と Network Load Balancer は内部と外部の両方でのデュアルスタック動作、および IPv6 ターゲットによるエンドツーエンドの IPv6 をサポートしています。

ロードバランサーを作成するとき、内部向けかインターネット向けかという図式と、IPv4 かデュアルスタックかというIP アドレスの種類を選択することができます。デュアルスタックのネットワークロードバランサーの場合、ロードバランサーのサブネットの IPv4 と IPv6 の範囲から手動でIPv4 とIPv6 アドレスを指定するか、もしくはAWS が動的に選択します。アプリケーションロードバランサーは、そのスケーリングメカニズムにより、ロードバランサーサブネットの CIDR から IPv4 と IPv6 アドレスが自動的に割り当てられます。設定の詳細については、Application Load Balancer と Network Load Balancer のドキュメントを参照してください。

ターゲットグループを作成するとき、ターゲットグループの IP アドレスの種類を選択することができます。これは、ターゲットと通信し、そのヘルスステータスをチェックするために使用されるIP バージョンを制御します。NLB と ALB の両方が特定の IPv6 ターゲットグループで IPv6 ターゲットをサポートし、IPv6 ターゲットグループは、TCP または TLS リスナーを持つデュアルスタック ALB または NLB にのみ関連付けることができます。次の図は、VPC 内で IPv6 専用サブネットを使用する内部 ALBのデプロイを示しています。

Figure 7: Application and Network Load Balancer with IPv6 targets

Application Load Balancer および Elastic Load Balancer ターゲットのセキュリティグループ設定に、クライアント IPv6 CIDR およびまたは VPC IPv4 と IPv6 CIDR を含める必要があります。詳細な推奨事項については、Application Load Balancer のセキュリティグループの推奨事項とNetwork Load Balancer ターゲットのセキュリティグループの推奨事項を確認してください。また、これらについてはこのシリーズのパート1 では詳しく調査しました。

IPv6 ターゲットを持つデュアルスタックロードバランサーの重要な考慮事項は、ネイティブのクライアント IP アドレス保存機能です。IPv6 をターゲットとする Network Load Balancer では、IPv6 をターゲットとするデュアルスタックロードバランサーへの IPv6 接続に対してクライアントIP アドレスの保持が有効になっています。クライアントIP アドレスの保存は、IPv6 からIPv4、またはIPv4 からIPv6 に変換されたトラフィックには影響しません。このトラフィックタイプの送信元 IP アドレスは、常に NLB の IP アドレスになります。したがって、ターゲットに IP アドレスを送信するために、Proxy Protocol v2（PPv2）を設定する必要があります。次の表は、Network Load Balancer のクライアントとターゲットの接続に使用されるプロトコル（IPv4 またはIPv6）と、クライアント IP アドレス保存の設定に基づいて、ターゲットが持つクライアント IP アドレスの可視性をまとめたものです。

Table 2: Client IP Address Preservation

4. デュアルスタック Amazon VPC における Amazon EKSのIPv6 サポート

Kubernetes は多くの人気を得ており、コンテナ化されたアプリケーションをデプロイするための標準となりつつあります。Amazon EKS は、Amazon VPC 内またはオンプレミスで Kubernetes ベースのアプリケーションを実行するために使用できるマネージドコンテナサービスです。IPv6 対応の EKS クラスターをデュアルスタック Amazon VPC とサブネットにデプロイし、IPv6 アドレスのみがポッドに割り当てられるようにすることができます。ネットワークの観点から、IPv6 対応環境でのコンテナの採用は、VPC 内の既存のあらゆるワークロードとスムーズに相互運用できます。Amazon EKS のさまざまな IPv6 トラフィックパターンについて説明しているこちらのブログを参照してください。

5. デュアルスタック Amazon VPC におけるAmazon RDSとAWS PrivateLinkのIPv6サポート

デュアルスタック Amazon VPC 内の新規および既存の Amazon Relational Database Service（Amazon RDS）インスタンスに対して IPv6 を有効にすることで、デュアルスタック IPv6 デプロイメントを拡張することができます。RDS は、すべての AWS リージョンで、RDS MariaDB、RDS MySQL、RDS PostgreSQL、Microsoft SQL Server、およびOracle エンジンにおいて IPv6 をサポートしています。デュアルスタックモードをサポートする DB サブネットグループを作成するには、DB サブネットグループに追加する各サブネットに、 IPv6 の CIDR ブロックが関連付けられていることを確認します。また、デュアルスタックデータベース向けのサブネットグループには、IPv4 専用とデュアルスタックのサブネットを混在させることはできないので注意してください。詳細については、Amazon RDS の詳細なデータベースアドレス設定ドキュメントをご確認ください。AWS PrivateLink は現在、サービスとエンドポイントで IPv6 をサポートしており、IPv6 導入を迅速化し、クライアントとサービスプロバイダーの両方の展開で IPv6 専用のサブネットを使用して環境を拡張することが可能です。AWS PrivateLinkのIPv6 導入と設定の詳細については、こちらのブログとドキュメントを参照してください。

まとめ

このブログで、現在AWS上で作成できるIPv6 専用およびデュアルスタックネットワークアーキテクチャのシリーズを締めくくります。このシリーズは全てのアーキテクチャを網羅するものではありませんが、AWS でのIPv6 導入の旅が促進されることを願っています。このブログについて質問がある場合は、Amazon ネットワーキングとコンテンツ配信フォーラムで新しいスレッドを開始するか、AWS サポートにお問合せください。

Alexandra Huides

Alexandra Huides は、アマゾンウェブサービスの戦略的アカウントをサポートするシニアネットワーキングスペシャリストソリューションアーキテクトです。彼女は、拡張性と耐障害性に優れたAWS環境向けのネットワーキングアーキテクチャの構築と開発において、お客様を支援することに重点を置いています。仕事以外では、旅行、新しい文化や経験の発見、ハイキング、読書が好きです。

Ankit Chadha

Ankit Chadha は、AWS のグローバルアカウントをサポートするネットワーキングスペシャリストソリューションアーキテクトです。MPLSバックボーン、オーバーレイ/アンダーレイベースのデータセンター、キャンパスネットワークなど、さまざまなネットワーキングソリューションの設計と構築に13年以上の経験があります。余暇には、クリケットをしたり、猫の信頼を得たり、伝記を読んだりするのが好きです。

本ブログは、ソリューションアーキテクトの櫻井が翻訳しました。原文はこちらです