(レポート) NET204: IPv6 in the Cloud #reinvent
こんにちは、虎塚です。
re:Invent 2016の「NET204 - IPv6 in the Cloud」を動画で聴講したのでレポートします。
講演者は、AWSのAndrew DickinsonさんとAlan Halachmiさんです。前半のインターネットでのIPv6の状況とIPv6の基本についてはDickinsonさんが、後半のAWSでのIPv6についてはHalachmiさんがお話しされました。
- セッション動画: AWS re:Invent 2016: IPv6 in the Cloud: Protocol and AWS Service Overview (NET204) - YouTube
レポート
インターネットでのIPv6の状況
2016年11月時点で、全世界でのIPv6導入率は13%、USでの導入率は30%です。利用者のホットスポットとして、次のようなネットワーク関連の大企業が、50〜80%の導入率を示しています。
- Comcast
- AT&T
- T-mobili
- British Sky Broadcasting
- Verizon
Windows, Mac, Linuxなど多くの主要なOSベンダーは、すでにIPv6対応を謳っています。ブラウザやクライアントライブラリなど、ソフトウェアでのサポートも同様です。
IPv6の基本
IPv4との違いを中心に、IPv6の基本的な事項を説明します。
- IPv4の32bitより4倍大きな128bitのアドレス空間を提供
- 引き続きCIDR記法が利用可能
- TCP/UDP/ICMPのコンセプトも同じ
IPv6がIPv4と違う点を次に示します。
- アドレスの書き方
- NATがない
- その他諸々
- プライベートアドレッシングが異なる
- ルーターのフラグメンテーションがない
- DHCPv4とDHCPv6は名前しか似ていない
- ARPの代わりにNDP
- より多くのダイナミックアドレスの選択肢
アドレスの書き方
まず、アドレスではドット表記を使いません。代わりにコロンで16進数表記を区切り、「2001:dv8:a:1ae::2」のように書きます。コロンが連続するのは、すべて0の場合のショートカット表記です。
IPv6にはNATがない
IPv4とIPv6のおそらく最も大きな違いは、IPv6にはNATがないことです。
- IPv6はEnd-to-Endの考え方
- セキュリティは、IPアドレスの隠蔽ではなく、ファイアウォールによって実現
- すべてのホストがグローバルに到達可能であるべき
なぜ私たちがIPv4でNATを使っていたかというと、15年前にアドレスを使い果たしてしまったからです。NATの利点は、インフラの内部構造を隠蔽できたことでした。欠点は、アドレスが重複してぶつかること、管理が難しいsplit-horizon DNS、アプリケーションが破損したりトリッキーになったりすることなどです。
IPv6でNATを使わない理由は、巨大なアドレス空間があること、隠蔽はセキュリティではないこと（プライバシーをもたらしはするが）、そしてNATがもたらす多くの問題を解決するためです。
しかし、インターネットでホストが外にさらされているのは、まるで裸のようなものだと感じるのではないでしょうか？ それに対してはこう質問します。ホストにEIP (IPv4のパブリックIPアドレス) を付けるよりも、裸だと感じますか？ これらは同じことです。
ここでクイズです
IPv4だけを持つホストは、IPv6だけを持つホストに直接アクセスできるでしょうか。正解は「できません」です。他の組み合わせでは、次のようになります。
IPv4のユーザとWebサイト
IPv4だけを利用するユーザが、IPv4だけを持つWebサイト (仮にwww.amazon.com) にアクセスするには、DNSサーバに問い合わせます。DNSは、www.amazon.comに対応するIPアドレスを返します。ユーザは、ソケットを開いて通信を開始します。長年やってきたのがこの形式です。
IPv4のユーザ / デュアルスタックのWebサイト
次は、WebサイトがIPv4とIPv6を両方持つ場合 (デュアルスタック) です。
IPv4だけを利用するユーザが、デュアルスタックのWebサイト (仮にwww.netflix.com) にアクセスするには、DNSサーバに問い合わせます。DNSは、www.netflix.comに対応するIPv4のIPアドレスを返します。ユーザは、通信を開始します。ユーザがIPv6を気にする必要はありません。
デュアルスタックのユーザとWebサイト
デュアルスタックのユーザが、デュアルスタックのWebサイト (仮にwww.netflix.com) にアクセスするには、DNSサーバに問い合わせます。DNSは、www.netflix.comに対応するIPv4とIPv6の両方のIPアドレスを返します。
Webサイトにアクセスするには、IPv4とIPv6のどちらを使えばよいのでしょうか。RFC 6724に定義されているとおり、デュアルスタックのクライアント側が、IPv4とIPv6のどちらを使うかを選択します。多くの場合はIPv6のほうが好ましいでしょう。Webサイト側は、ユーザにどちらを使わせるかを決めることができません。
AWSでのIPv6
AWSサービスでIPv6をサポートした最初のサービスは、IoTサービスでした。IoTのDevice Gatewayでは、IPv6を利用できます。
さらに、最近S3もIPv6をサポートしました。なお、S3 Transfer Accelerationは、CloudFrontのエッジネットワークを使ったサービスです。つまり、CloudFrontもまたIPv6をサポートしています。
CloudFrontのIPv6有効化は、新しいディストリビューション作成時にはデフォルトでオンになっています。クライアントからCloudFrontはIPv6で通信し、ClpudFrontからオリジンのEC2へはIPv4でアクセスします。X-Forwarded-Forヘッダには元のIPv6アドレスが入っています。
Amazon WAFの内部でもIPv6をサポートしています。送信元アドレスをアクセス拒否用のマッチングルールに記述してアクセスすると、リクエストがブロックされます。クライアントがIPv6を使用してアクセスしてきたことを、エッジサービスが把握しています。
Route 53は、IPv6越しにアドレスを解決できます。また、DNS解決をIPv6に転送することで、ホストのルックアップにIPv6の使用を強制させることもでいます。
また、クライアントがIPv6を使ってアクセスしてきた場合に、EC2のサーバログに残すことができます。ちょうどこの日(※2016年12月1日)、VPC内のEC2でIPv6がサポートされました。
VPCを作成する時に、AWSがネットワークを/56のユニークなアドレス空間に配置します。/64のサイズのサブネットを作成する時に、IPv6をオンオフするかを設定できます。/64と/56のネットワークは固定されますが、これは現在のIPv4の/64よりも大きな空間であることに留意してください。サブネットを切り直す必要に迫られることはないだろうと思います。
最後に、egress-only internet gateway (EIGW) を紹介します。EIGWは、すべてのインスタンスにパブリックアクセスを提供します。しかし、プライベートサブネットでは、デフォルトでEIGW経由でルーティングさせます。VPC内からの内部トラフィックは通しますが、外からの通信はインスタンスに到達できません。
他に、セキュリティグループ、NACL、Internet Gatewayも、IPv6をサポートして機能します。
VPC内のIPv6サポートは、US Eastリージョンでローンチしましたが、すぐに他のリージョンでもサポートする予定です。
おわりに
AWSの各種サービスにもIPv6サポートが徐々に入ってきました。本セッションでは、各サービスの状況を横断的にざっくり聞くことができてよかったです。これを機にVPCのIPv6サポートについて把握しておきたいと思います。
それでは、また。
