AWS的IPv6實踐

在AWS中設計IPv6的最佳實踐

47 min readSep 6, 2023

現今的企業，很多公司都已經在其內部網路運行了 dual-stack(IPv4/IPv6)網路協定。甚至擴展到了ISP的邊與行動網路。IPv6 的運用其實已被推遲，部分原因是 IPv4 的NAT功能。

由於Public IPv4 越來越稀缺、Private IPv4 無法在超大型網路中運作，越來越多的企業在其環境中採用 IPv6。 IPv6 沒有一種一刀切的方法。但是，在AWS中運行IPv6可以遵循一些最佳實踐來規劃並將其實施到其現有的雲端網路中。

本文解釋了採用IPv6的關鍵驅動因素，並重點介紹了最佳實踐，同時留有足夠的空間根據我們的實際案例和施作來決定如何在網路中使用 IPv6。

使用 IPv6 的原則

遵守以下 IPv6 使用原則有助於使流程和決策更易於管理：

重新評估網路安全控制 —
IPv6 提供了重新思考企業網路邊界安全方法並做出進一步改善安全狀況的設計決策的機會。
規模設計 —
更多可用的 IPv6 地址並不意味著我們可以簡化 IP 分配和規劃。因為IPv6 address用不完，意味著管理可能更複雜。
分階段採用 IPv6 —
專注於業務需求，在需要時實施 IPv6，並記住，只要有需要，IPv4 和 IPv6 就可以共存。大部分都是處於新舊系統的轉換過渡期。

IPv6提供的功能如下：

更大的地址空間 — IPv4 只有32-bit位址，IPv6則有128 bit
一個全局是唯一且分層分配的地址，基於prefix而不是address classes，以保持路由表較小且骨幹路由有效率
一種網路介面自動配置(Auto-configuration)機制
支持自身和其他協議的封裝
區分資料類型的服務類別
改進的multicast routing能力（優先於broadcasting, IPv6沒有broadcasting）
內建的身份驗證和加密
採用 IPv6 並保持與 IPv4 互操作性的方法

有關 IPv4 和 IPv6 之間主要差異的一些注意事項如下：

Header —
IPv6使用兩種不同類型的header — Main/regular與 extension 。

Main IPv6 header與IPv4 相同，儘管由於從IPv4 中的運作而產生了一些field差異。 IPv6 有一個固定的 40-byte，可以更快地處理 IP datagram。

Flow labeling —
Flow labeling是網路節點(如路由器)用來標記流量包(label packets of a flow)的new field。 Flow label “0”用於指示流量包尚未被標記。流量包分類器可以使用"flow label、來源地址和目標地址field"來識別流量包屬於哪個flow。能夠以無狀態方式處理流量包或已設置flow特定狀態的節點以flow特定方式處理流量包。

Address assignment —
可以使用 DHCPv6 和通過 SLAAC(Stateless Address Auto-Config)分配 IPv6 地址，SLAAC 利用network interface的 MAC 地址來為節點產生 IPv6 後半部的地址。

Error Correction —
IPv6 不支援header checksum，因為它被認為是冗餘的，所以會在下層協議（Ethernet）和上層協議（TCP/UDP）中進行處理。

Neighbor Discovery Protocol —
IPv6 定義了 ICMPv6 來取代 IPv4 的 ARP 和其他network discovery功能。它比 IPv4 提供了許多改良，其中包括NUD(Neighbor Unreachability Detection)，改進了在出現故障的路由器、links或移動節點時的資料包傳輸。

IPv6地址格式

IPv6 地址空間是通過使用Prefix來組合的，Prefix在邏輯上以tree的形式劃分地址空間，以便可以輕易找到從一個網路到另一個網路的路由。 IPv6 地址的主要類別分為：

GUA(Aggregatable global unicast addresses) — 2000::/3
ULA(Unique-local unicast addresses) — FC00::/7
Link-local unicast addresses — FE80::/10
Multicast addresses — FF00::/8

需要注意的是，其餘 IPv6 地址由 IETF保留，可用於新技術或在未來增加這些空間分配。

IPv6的運用策略與方法

大部分會使用IPv6的企業大概有以下兩種原因:

NAT 不再足以解決資源耗盡問題，並且對overlapping Ip address帶來了重大挑戰。
法規法令的要求

IPv6運用策略取決於其背後的驅動力。我們可能有一個短期目標，例如解決Private IPv4 不夠的問題(通常是超大企業才會有這問題)，或者能夠根據政府法規提供 IPv6 服務，而長期目標是完全轉換成IPv6 。以下是四個主要驅動力以及相應的運用策略：

Private IPv4耗盡 —
目標是新的伺服器會有可路由的IP，而不會出現 IP overlap，並且不會面臨伺服器不斷增加卻拿不到Ip address。
運用策略:
建立只有 IPv6 的VPC 和subnet。配置網段之間的路由，以便 IPv6-only 路由器可以與其他IPv6-pnly 路由器通訊。提供 IPv6 到 IPv4 轉換節點，例如 AWS NAT64 和Dual-stack load balancers。
Public IPv4耗盡 —
目標是支持連接到網際網路的IPv6-only 節點。例如，我們可能有一個 API endpoint，用於從連接到IPv6-only 網路的 IoT 設備上傳資料。 IoT 設備具有 IPv6 address，網路不提供與 IPv4 的轉換。其他設備可以在 IPv4 網路中運行。
運用策略:
建立Dual-Stack 的VPC和subnet。使用 AWS 中相應的 DNS record以Dual-stack模式配置 AWS 服務，例如Load balacneers和edge service。或者，提供獨立的IPv4-only 或IPv6-only 的endpoint。
與IPv6-only的互操作性 —
目標是支援從IPv4-only到IPv6-only 節點的連接。這是一個不太常見的案例，因為大多數endpoint在Dual-Stack模式下運行並提供NAT64的轉換。
運用策略:
建立Dual-Stack VPC，並使用它們託管 NAT46 轉換。完全採用Dual-Stack通常不切實際，因此首選提供NAT6轉換。
強制 IPv6 端點 —
目標是支持與連接到服務的IPv6-only 節點的轉換，並避免在新服務中產生技術債。制定計劃並完成不具備IPv6-only 或Dual-stack功能的舊服務的過渡。
運用策略:
建立Dual-Stack 的VPC和subnet。使用 AWS 中相應的 DNS record以Dual-stack模式配置 AWS 服務，例如Load balacneers和edge service。或者，提供獨立的IPv4-only 或IPv6-only 的endpoint。

IPv6與v4之間的轉換

儘管在Dual Stack模式下運行解決了 IPv4 和 IPv6 轉換的許多問題，但它會產生management overhead。例如，安全性變得更加困難，因為我們必須管理兩組安全規則。路由和故障排除變得更加困難，並且我們還要維護現有 IPv6與v4的DNS 紀錄。

通過 NAT64和load balancers在邊界實施Dual-stack，我們也許能夠避免使整個網路都是Dual-stack。在大多數情況下，網路的現有網段可以繼續作為 IPv4 運行，而新網段則使用 IPv6 構建。專注於實施和維運的轉換，其中Dual-stack VPC、load balancers和 AWS NAT64 gateway等 AWS 服務可幫助我們解決轉換問題挑戰。

規劃AWS網路中的IPv6運用

Elastic network interfaces可以以三種不同的模式運行：

IPv4-only
Ipv6-only
Dual-stack

IPv6 address的規劃

對於任何採用 IPv6 的企業來說，制定 IPv6 address規劃是最重要的初始任務之一。對於大多數企業來說，IPv6 與現有 IPv4 AWS 和混合網路中的 IPv4 並行運作。 IPv4 address規劃往往會隨著時間的推移而增長，因此可能會高度分散、不連續或不夠大。在 IPv6 中以某種方式簡單地複制 IPv4 address方案最初可能會被證明是有效的。然而，通過這種走節捷徑的方式獲得的任何暫時優勢最終都會被正確的 IPv6 address 規劃所提供的操作和設計的簡便性和效率所超越，該計劃包含了 IPv6 可能實現的更大分配的關鍵優勢。

IPv6 address空間的規模幾乎無限，使得地址規劃不再受到 IPv4 地址稀缺的限制。諸如VLSM(Variable Length Subnet Masking)等技術在 IPv6 中可能被視為不必要和過時的。相反，可以根據網路和分段需求為 VPC 分配重要性，從而採用一致的位置規劃。

在 AWS 中，分配給 VPC 的 IPv6 address space是從globally unique unicast address range分配的。 IPv6 地址分配有兩種選項：

AWS-assigned IPv6 VPC CIDR
BYOIPv6

AWS-assigned IPv6 VPC CIDR

預設情況下，AWS VPC 會有一個固定大小 (/56) IPv6 CIDR 。該範圍由AWS決定，因此，我們無法將連續的 IPv6 CIDR block分配給同一region中的 VPC 或基於其他自定義條件。對於在 AWS 中有大量 VPC 且更喜歡使用 IP route summarization 來簡化其整體環境的企業，BYOIPv6可能是首選解決方案。

BYOIPv6

企業如果有 IPv6 address space，則可以使用自帶 IPv6 將其導入 AWS。對於 AWS 公開advertisements的 CIDR，企業可以導入的最小 IPv6 地址範圍是 /48；對於 AWS 未公開advertisements的 CIDR，企業可以導入的最小 IPv6 地址範圍是 /56。企業還可以選擇攜帶 /48 並將其標記為non-advertisable，從而在地端機房上保持對 IP advertisements的控制。導入後，我們可以將空間中的 /56 範圍分配給同一帳號中的各個 VPC。更多的BYOIPv6，請參閱AWS BYOIP文件。

由於可以使用連續的 IPv6 block配置summarization，因此對於多區域部署，我們可以為每個region引入一個或多個 /48 或更大的prefix。考慮在 VPC route table level以及使用 AWS Transit Gateway、AWS Direct Connect 和 AWS VPN 進行route summarization。

VPC Subnet地址規劃

儘管我們可以將一個 /56 IPv6 CIDR block分配給 VPC，但 VPC subnet的 /64 長度卻是固定的。根據 IPv6 unicast addresses的通用格式，這會產生長度為 /64 的interface ID。鑑於 VPC CIDR 和subnet prefix的固定大小，我們有 8 bits用於 VPC 中的子網分配，讓我們能夠在 VPC 中創建 256 個subnet。

設計 IPv6的AWS網路

在 AWS 中規劃和實施網路通常是我們會在 AWS 中部署工作負載時執行的基本任務之一。以下是一些網路上的基本考量：

所需 VPC 的數量和性質
VPC CIDR 範圍和 IP 地址分配，包括用於對網際網路的BYOIP
subnet的數量和類型
涵蓋的AZ數量
允許的traffice path
網際網路的進出流量選項
混合連接
Inter-VPC 連接
可擴展性

儘管以上面向中的大多數同樣適用於 IPv4 和 IPv6，但現有文件大多僅在 IPv4 的背景脈絡下編寫。本節通過提供 IPv6 細節來擴充這些現有資源。 AWS 建議我們首先閱讀現有的以 IPv4 為中心的文件，以充分利用這些內容。

VCP IP地址分配

VPC 可以在Dual-stack模式下運行 — 資源可以通過 IPv4、IPv6 或兩者進行通訊。 IPv4 和 IPv6 通訊是彼此獨立的。我們無法disable VPC 和subnet的 IPv4 功能；我們需要為 VPC 分配至少一個 IPv4 CIDR range。此外，我們可以為每個 VPC 關聯最多一個 IPv6 CIDR block range(但IPv4可以)。

Subnet地址分配

將 IPv6 prefix關聯到 VPC 後，我們可以開始為每個subnet分配一個 /64 IPv6 prefix。需要注意的是，這些分配是基於每個subnet進行配置的，並且可以在同一 VPC 內混合使用或不使用 IPv6 的subnet。

subnet內資源的地址分配發生在兩個level：

VPC elastic network interface construct configuration
A resource’s networking stack configuration

Elastic network interface的IP地址

部署在 VPC 內的資源必須具有Elastic network interface。資源範例包括：

EC2 instance
Interface VPC endpoints
佈署在VPC中的Lambda functions
RDS instance

Elastic network interface是 VPC 中的邏輯構造，代表運行時資源的network adapter。每個Elastic network interface可以具有一個或多個IPv4/IPv6地址。這意味著無需為 IPv4 和 IPv6 個別設定Elastic network interface。

放置在啟用 IPv6 的subnet中的Elastic network interface可以使用 IPv6 地址進行建立和修改來分配 IPv6 地址。我們可以為每個Elastic network interface進行這樣的作法，並且可以選擇讓 AWS 自動為我們分配一個或在subnet的分配範圍內指定一個未使用的地址。在任何一種情況下，除非明確修改，否則配置的地址在Elastic network interface的整個生命週期中保持不變。

資源的networking stack的IP地址

在 IPv4 中，分配 IPv4 地址的主要方法是使用DHCP。 DHCP 基於 IPv4 的broadcast機制。 IPv6 沒有broadcast的概念，並且最初不具有 DHCP 功能。

然而，大家已經習慣了 DHCP，因此開發了 RFC 8415 來導入 DHCPv6。在缺乏broadcast功能的情況下，DHCPv6 對所有 DHCP 服務器使用眾所周知的multicast address — ff02::1:2。

VPC 內建了對通過 DHCP 為 IPv4 和 IPv6 分配地址的支援。地址分配的工作方式與傳統 DHCP中的static address reservation類似：分配給elastic network interface結構的 IP 地址決定了 VPC DHCP 基礎設施為請求地址的資源提供的 IP 地址。 VPC 還提供配置 DHCP option sets的功能，這個option sets可用於提供其他配置信息，例如要使用的域名或 DNS 服務器。 在Dual-stack設計中，option sets中使用的所有 IP 地址都必須是 IPv4。

PS:
如果我們嘗試將 IPv6 加到到現有或遷移的工作負載，Host OS可能尚未設定成使用 DHCPv6。請參閱AWS文件，為OS啟用和驗證 DHCPv6 。

PS:
DHCP是選項而不是必需的，我們可以直接在Host OS上配置Ip address。但是，VPC anti-spoofing機制會強制NIC)上配置的 IP 地址與底層elastic network interface配置的 IP 地址相匹配。 AWS 建議啟用 DHCP，即使對於需要靜態 IP 地址的資源也是如此，並在elastic network interface level管理靜態 IP 分配。

支援IPV6的AWS VPC服務

AWS 在客戶 VPC 內的保留地址公開了一組支援服務。這些服務傳統上是從 IPv4 link-local address (169.254.0.0/16) 是公開的。對於 AWS Nitro Nitro System，AWS 還使用 IPv6 ULA 提供這些服務。

IMDS(Instance Metadata Service)

Instance可以通過查詢 169.254.169.254 上可用的 IMDS 在運行時對此進行introspect。對於基於 Nitro 的instance，AWS 還在 fd00:ec2::254 IPv6 endpoint提供此服務。

Route 53 DNS resolver

VPC 具有內建 DNS resolver，位於 VPC_CIDR_BASE + 2 和 169.254.169.253。啟用 IPv6 的 Nitro instance可以通過 fd00:ec2::253 存取該服務。後面的 “IPv6 的DNS 設計”部分會更詳細地討論AWS Route 53 resolver和 DNS。

NTP server

VPC 在 169.254.169.123 提供 Stratum-3 NTP 服務器。基於 IPv6的Nitro instance可以通過 fd00:ec2::123 到達此服務器。

AWS的IPv6連接選項

AWS VPC 相互連接的方式很多。其中許多選項在Building a Scalable and Secure Multi-VPC AWS Network Infrastructure文件中的 VPC to VPC connectivity部分中進行了詳細介紹。 AWS 建議我們同時閱讀以下部分，它遵循相同的結構，同時提供有關 IPv6 運作的更多見解：

VPC peering
AWS Transit gateway
VPC subnet sharing
AWS PrivateLink

VPC peering

VPC peering是 VPC 到 VPC 連接的最簡單方法。它支援region內和跨region間連接。 Peering本身與 IP 協議無關。建立peering後，我們必須配置一個或多個靜態路由，定義哪些prewfix可到達。 IPv4 和 IPv6 prefix都可以通過同一個peering進行路由。下圖描述了兩個同時支援 IPv4 和 IPv6 的 VPC 之間的 VPC peering。 peering獨立於IP協議，subnet route table是哪些prefix可達的決定因素。

AWS Transit Gateway

AWS Transit Gateway 是一種可擴展、高度可用網路服務，用於在多個 VPC 之間建立網路連接。 Transit Gateway是一個Regional construct，並attach同一region內的 VPC。位於不同 AWS region的 Transit Gateway 可以建立peering。

我們可以使用 Transit Gateway attachment將 VPC 連接到 Transit Gateway。 attachment將elastic network interface部署到我們選擇的每個subnet中。使用 VPC subnet routing tables中的靜態路由將流量路由到 Transit Gateway，並將attachment作為next-hop。 attachment本身與 IP 協議無關，我們可以通過同一attachment路由 IPv4 和 IPv6 prefix。為了支援 IPv6，prefix使用的elastic network interface需要分配 IPv6 地址。

PS:
我們要將 IPv6 加入到具有 Transit Gateway attachment的現有 VPC 中，則其elastic network interfaces將不會自動分配 IPv6 地址；我們需要手動配置elastic network interfaces的分配。如果沒有，IPv6 流量將無法使用這個attachment。

Transit Gateway之間的IPv6流量

Transit Gateway attachment既是流量包的來源也是目的地。我們可以將以下資源附加到 Transit Gateway：

VPC
一個或多個VPN connection
一個或多個AWS Direct Connect gateways
一個或多個Transit Gateway Connect attachments
一個或多個Transit Gateway peering connections

Transit Gateway 具有一個或多個路由表。路由表可以通過靜態路由配置和來自其他attachment（VPC、Direct Connect、Site-to-Site VPN 或 Connect Peering）的動態路由的組合。無論哪種情況，都支援 IPv6 路由。

IPv6的Transit Gateway Connect Attachment

我們可以建立 Transit Gateway Connect Connect attachment，以在transit gateway和third-party virtual appliances（例如 SD-WAN 設備）之間建立連接和動態路由。

這些attachment採用 GRE protocol tunnels的形式，並支援在 VPC 中的 EC2 Instance和 TGW 之間動態交換路由。 BGP) peering促進了路由交換。 TGW connect peer使用Multi-Protocol BGP (MP-BGP) 和 fd00::/8 unique local address range的 /125 CIDR block來支援 IPv6。

MP-BGP是 BGP 的擴展，使 BGP 能夠承載多個網路層和address families的路由資訊。 MP-BGP 可以將用於multicast routing的unicast routes與用於unicast IP forwarding的路由分開處理。

AWS PrivateLink

AWS PrivateLink 在 VPC、AWS 服務和地端機房之間提供private connectivity，而不會將流量暴露到網際網路。 AWS PrivateLink 可以容易連接不同AWS account和 VPC 之間的服務，從而顯著簡化我們的網路架構。

VPC sharing

VPC sharing允許 VPC 所有者跨 AWS account共用subnet。我們可以像共享 IPv4-only subnet一樣共享Dual-stack subnet。部署到共享子網中的 IPv6 資源與部署到非共享subnet中的 IPv6 資源功能相同。

AWS VPC網際網路存取

如前上面所述，elastic network interfaces在其整個生命週期中保留其 IPv6 地址。對於 IPv4，elastic network interfaces可以有零個或多個與其關聯的Elastic IP addresses。Elastic IP addresses定義elastic network interface的 IPv4 地址和網際網路可路由地址之間的靜態 1:1 NAT 關係。

在 IPv6 中，VPC 地址已經是globally unique，因此不需要Elastic IP addresses。 AWS分配的 IPv6 地址會publicly advertised，而對於 BYOIP 範圍，這是選項的。在任何一種情況下，如果部署的資源的subnet routing table包含通過Internet gateway或僅出站流量的Internet gateway的IPv6 目的地（例如::/0），則部署的資源僅具有IPv6 網際網路可存取性。

混合連接設計(Hybrid connectivity design)

混合連接場景對於許多企業來說幾乎一定會出現。 AWS提供兩個服務來解決這些問題：AWS Direct Connect 和 AAWS managed Site-to-Site VPN。

Direct Connect

AWS Direct Connect 是一種AWS到企業地端機房的專用線路。 Direct Connect 服務的不同面向涉及 OSI 模型的不同Layer。 IPv6 是在L3相關的配置，因此 Direct Connect 配置的許多方面（例如物理連接、link aggregation、VLAN、 jumbo frame）與 IPv4 使用上沒有什麼不同。IPv6 的不同之處在於 VIF(virtual network interface) 之上的 BGP peering的地址和配置。 VIF 分為三種類型：

Private
Transit
Public

PS:
我們可以在特定的 VIF 上為每個address family配置 0 或 1 個peering，因此可以將 IPv6 配置到現有 VIF 上，而無需重新配置或部署新的 VIF。

Transit and Private VIF IPv6 peerings —
在 IPv4 中，我們可以自由選擇自己的point-to-point address，而在 IPv6 中，AWS 會自動為每個 VIF 分配 /125 CIDR，並且無法指定自行指定 IPv6 地址。

從AWS傳播到地端的IPv6 prefix

將 Direct Connect gateway直接與VGW(Virtual Private Gateway)關聯時，我們可以指定“Allowed Prefixes”。可以將其視為傳統的"prefix-list” filter,，控制向CE router傳播的prefix。 對於 IPv4，不指定filter相當於 0.0.0.0/0 — 不進行過濾。對於 IPv6，此處不指定會導致所有的路由傳播被擋住。

將 Direct Connect gateway與 Transit Gateway 關聯“Allowed Prefixes”不會充當filter，而是充當向CE router傳播的路由的靜態來源。

PS:
“Allowed Prefixes”IPv6 CIDR 的長度必須為 /64 或更短，但不能指定“::/0”。如前所述，VGW 和 Transit Gateway 在“Allowed Prefixes”參數方面的行為不同。

從地端傳播到AWS的IPv6 prefix

就從地端設備到 AWS 的路由傳播而言，儘管存在標準 Direct Connect quotas，但沒有 CIDR 限制。傳播路由的任何prefix都是地端prefix到AWS網路，不會傳播到其邊界之外。

Public VIF IPv6 peering—
與transit和rpivate VIF peering一樣，Public IPv6 peering會自動從 AWS 擁有的範圍中分配 /125。這些 IP 用於支援BGP peering，我們需要使用自己的 IPv6 prefix通過peering進行通訊。

PS:
借助 IPv4 publicV IF，可以將 AWS 分配的public IPv4 /31 與 NAT 結合使用，以支援從private addressing的地端機房進行存取。但是，對於 IPv6，我們必須在建立時擁有並指定 IPv6 prefix。需要注意的是，如果我們指定的 IPv6 prefix無法證明式我們所有的，VIF 將無法配置並保持“verifying”狀態。

透過Prblic/Private/Transit VIF路由IPv6

如果我們使用AWS-assigned CIDR blocks在VPC上，或者使用可以由AWS傳播的 BYOIPv6，我們將通過Public VIF peering 接收包含 VPC CIDR 的summary prefix。將Public VIF 與Private/Transit VIF 結合使用時，請考慮到我們的設備將在兩種類型的 VIF 上接收相同的prefix（我們VPC 的prefix）。此時，需要考慮CE router上的路由過濾，以確保不同virtual interfaces上的流量對稱。

Amazon-managed VPN

AWS Site-to-Site VPN 連接配置包含以下幾個部分：

customer gateway，是地端機房 VPN endpoint的邏輯呈現
VPN connection
地端機房的VPN設備，由customer gateway來呈現

任何 AWS S2S VPN connection都包含兩個tunnels。正是這個connection定義了 IP addressing、ISAKMP、IPsec 和 BGP peering參數。

PS:
對於IPv6，AWS 只能支援結束於 Transit Gateway VPN attachment的 IPsec tunnel

Customer gateways

雖然 AWS 在 IPsec tunnels內支援 IPv6，但底層連接是通過 IPv4 進行的。這意味著 AWS 和customer VPN 終端設備都需要Public IPv4 地址進行。在 AWS 端，該 IP 是從 AWS region的Public EC2 IP 空間自動分配的。在客戶端，這意味著我們的設備需要一個可通過網際網路存取的 IPv4 地址。

VPN Connections

單一個VPN connection可以承載 IPv4 "或" IPv6 流量，但不能同時承載兩者。配置連接時，我們可以指定在tunnel內使用 IPv4 或 IPv6。我們可以自行定義地址，或讓AWS自動配置。如果我們指定 CIDR，則它必須是取自unique-local address range fd00::/8 的 /126。如果我們不指定，AWS會從該範圍中選擇一個 /128。無論哪種情況，連接的 AWS端都是subnet中的第一個可用的 IPv6 地址，接下來才是我們使用的。

另一個需要考慮的因素是local和remote IPv6 網路CIDR 範圍。這些可以是::/0 或特定的prefix。此配置定義 IPsec 第 2 階段SA(Security Association)。如果我們指定prefix，請務必配置我們的customer gateway設備。

PS:
即使指定 /126，控制台也會將 IPv6 tunnel CIDR 顯示為 /128。雖然始終配置 IPv4 地址，但此範圍內位置我們會看不到流量，因為指定的 SA 設置只允許協商 IPv6 SA。

Customer gateway configuration

對於customer gateway的設備特定配置，AWS 建議我們查閱設備廠商的文件，了解如何設置 IPv6 VPN。 IPv6 S2S VPN 存在 IPv4 中沒有顯示的獨立於每個設備廠商的細微差別。

AWS 提供IPsec 配置檔的下載，但目前僅涵蓋 IPv4 配置。某些設置和配置參數與 IP 協議版本無關。但是，與tunnel addressing、第 2 階段 SA 協商和peering配置相關的設置確實有所不同。

使用 AWS templates時，務必省略 IPv4 ，並將其替換為 IPv6 。

指定local和remote CIDR 時，確保將 VPN 設備配置為協商 IPsec 第 2 階段 SA 以匹配 AWS 。 如果我們想在 VPN 上使用 BGP 而不是靜態路由，並使用LOCAL REMOTE CIDR 範圍來確定第 2 階段 SA 的範圍，則 P2P IP 必須包含在 CIDR block中。 因此，只有在 VPN 兩側都使用 fd00::/8 時才可以界定 SA 範圍，並且如果使用non-unique local addressing，則必須將 SA 協商為 ::/0。

當使用 AWS 產生的tunnel IP 或指定 BGP 的 /128 CIDR 範圍設立時，預設情況下peering將失敗。原因是 /128 與 IPv4 中的 /32 一樣，是host route。我們需要定義一條指向tunnel AWS 端的靜態路由來建立 BGP peering。

設計IPv6的DNS

DNS的核心概念與IPv4相比沒有變化。從OSI L3的角度來看，DNS 只是另一個應用程序，因此，憑藉 OSI/ISO 模型提供的抽象，與所選的網路層協議無關。

無論 IP 版本如何，DNS 和 IP Layer之間都存在深層連結。 DNS 規範已經調整併導入了一種附加類型用在 IPv6 。在 IPv6 中，相當於 IPv4 “A” record的是 AAAA record。這意味著可以使用 IPv4 作為網路協議來連接到 DNS 服務器並解析 IPv6 (AAAA) record。

PTR records

PTR record將 IP 地址轉換為域名。 IPv6 地址在域 IP6.ARPA 下反向對應。 IPv6 反向對應使用由點分隔的sequence of nibbles，suffix為“.IP6.ARPA”（如RFC 3596 中定義）。例如，與地址2001:db8:1234:1a00:1:2:3:4 對應的反向查找域名將是4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.a.1.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa

Alias records

Amazon Route 53 支援 alias record。 Route 53 alias record在內部對應到alias target（例如 AWS 資源）的 DNS 名稱。 Route 53 監控與alias target的 DNS 名稱關聯的 IP 地址，以進行擴展運作和軟體更新。來自 Route 53 name server的authoritative response包含 A record（對於 IPv4 地址）或 AAAA 記錄（對於 IPv6 地址）以及alias target的 IP 地址。

Host的DNS resolution

除了外部配置之外，Host的networking stack在運行時解析 DNS record。當配置為Dual-stack時，大多數OS預設會選 IPv6。換句話說，當對 FQDN 的查詢同時返回 A 和 AAAA 記錄時，OS更願意使用 AAAA 記錄並建立到目標的 IPv6 連接。所以如果我們的服務或應用程式還在使用IPv4，就有必要調整Ipv4的優先順序。

Route 53 DNS records

如大家所知，AWS Route 53是AWS提供的DNS 服務。Route 53 提供了兩個案例功能：

對外(Internet)的DNS
從Resolver和authoritative name server的角度來看VPC 內的 DNS 功能

對外的Public IPv6 DNS resolution

對於可外部查詢的 DNS，我們可以使用具有 A 和 AAAA record的 Route 53 public hosted zones。 Route 53 health checks 會檢查IPv4 和 IPv6 均存在Name server，這意味著想要解析 Route 53 public hosted zones上託管的 FQDN 的clients可以直接執行此操作。

VPC內的DNS resolution

VPC 內的Route 53 Resolver，它提供解析 DNS 名稱的功能。該Resolver可通過 169.254.169.253 或 VPC_CIDR_NETWORK + 2（對於 IPv4）以及 fd00:ec2::253（對於基於 Nitro 的 IPv6 hosts）進行存取。

PS:
預設情況下，VPC 的 DHCP option set會將這些 VPC Route 53 DNS resolvers指定給 DHCP client。但是，如果我們不想使用 AWS 提供的 DNS 功能，我們可以更改 DHCP option set以將客client指向自託管或第三方 DNS 解析器。

Private DNS resolution

Route 53 可配置為一個或多個zone的authoritative name server。可以通過建立Private Hosted Zones並將其與一個或多個 VPC 關聯來啟用此功能。 Route 53 支援建立 AAAA records，以便它可用於將 FQDN 解析為 IPv6 地址。

DNS64與NAT64

在 VPC 中運行的IPv6-only 工作負載只能發送和接收 IPv6 網路流量。如果沒有 DNS64，對IPv4-only 服務的 DNS 查詢將回應 IPv4 address，並且IPv6-only client無法與其通訊。要彌合此差距，我們可以為subnet啟用 DNS64，並將其應用於該subnet內的所有 AWS 資源。使用 DNS64，Route 53 解析程序會查找我們查詢的服務的 DNS 記錄並執行以下操作之一：

如果DNS records包含 IPv6 地址，它會直接回應IPv6 address。
如果 DNS records中沒有與目標相關的 IPv6 address，Route 53 Resolver會通過在 RFC 6052 (64:ff9b::/96) 中定義的 /96 prefix 加到 IPv4 address的前面來合成一個IPv6 address。 IPv6-only client將網路流量發送到合成的 IPv6 address。然後，我們需要將此流量路由到 NAT gateway，NAT gateway對流量執行必要的轉換，以允許subnet中的 IPv6 client存取該subnet外的 IPv4 資源。

DNS64 是subnet-level的設定，我們可以使用在AWS CLI 或 VPC console的modify-subnet-attribute在 IPv6-only subnet上啟用或禁用該設定。 DNS64 與內建於 VPC NAT gateway服務中的 NAT64 結合使用。

NAT64 使 VPC 中的 IPv6-only cleint能夠與同一 VPC（不同subnet中）、地端機房或網際網路中的IPv4-only 服務進行連結。 NAT64 自動在我們現有的 NAT gateway或新的NAT gateway上使用，該功能我們無法啟用或禁用。啟用 DNS64 並且IPv6-only服務通過 NAT gateway將網路流量發送到合成的 IPv6 address後，會發生以下情況：

NAT gateway從 64:ff9b::/96 prefix識別出原始目的地是 IPv4，並通過轉換以下內容將 IPv6 流量轉換為 IPv4：
1.Source IPv6 具有自己的Private IPv4，由Internet Gateway轉換為Elastic IP。
2.通過去除 64:ff9b::/96 prefix將目標 IPv6 轉換為 IPv4。
NAT Gateway通過 Internet gateway、VPC peering、virtual private gateway或transit gateway將轉換後的 IPv4 流量發送到目的地，並啟動連接。
IPv4-only 的主機回應 IPv4 流量。連接建立後，NAT gateway接受來自外部主機的IPv4流量。
回應的IPv4 流量傳送到NAT gateway，NAT gateway接收流量並通過將其IP（目標IP）替換為主機的IPv6 地址並將back64:ff9b::/96 prefix加到source IPv4 來對流量進行去NAT。然後流量沿著local route流向主機。

NAT gateway使 VPC subnet中的IPv6-only 工作負載能夠與subnet外任何位置的IPv4-only進行通訊。

IPv6的安全與監控考量

Network-level access control

VPC 具有兩種網路存取控制機制，無論使用IPv4 或 IPv6，這些機制都可用：

elastic network interface level的Security Group
subnet-level的network ACLs

Security Group(SG) — 這是Instance的stateful virtual firewall。每個elastic network interface必須至少有一個與其關聯的SG。由於SG預設拒絕所有inbound流量，因此在操作 IPv6 時需要建立額外的 IPv6 inbound規則。

Network ACLs — 這與SG在幾個方面有所不同：

它們用在VPC subnet而不是單一的elastic network interface
他們是stateless
他們可以添加明確的 DENY rule
對於inbound和outbound，它們預設是 ALLOW ANY

由於最後一點，我們無需更新預設的 ACL 即可使用 IPv6 。

VPC Flow Logs

VPC flow logs是一項功能，使我們能夠擷取有關進出 VPC 中網路介面的 IPv6 流量的資訊。 IPv6 流量的 VPC flow logs的作業方式與 IPv4 相同，我們可以在 VPC level、subnet level或network interface level建立flow logs。如果我們在 VPC 或subnet level建立 VPC flow logs，則該 VPC 或subnet中的每個network interfacew都會受到監控。

Flow logs記錄可以使用預設格式或自定義格式。使用自定義格式，您可以指定 IPv6 flow logs記錄中包含的fields以及順序。

以下是使用默認格式的 IPv6 流量的flow logs記錄範例。這是允許從 2406:da1c:491:7402:60ee:a99b:749c:c248 到 2406:da1c:491:7402:4427:239a:8656:4f3a 的 ICMP ping 流量的預設格式擷取的範例（如下表所示）。

PS:
如果network interface具有多個 IPv6 address並且流量發送到secondary private IPv6 address，並且我們僅使用預設格式 dstaddr field，VPC flow logs將顯示primary private IPv6 address。

要擷取原始目標 IPv6 address，我們可以使用帶有 pkt-dstaddr field的自定義flow logs格式。它同樣適用於 pkt-srcaddr field。有關其他flow logs注意事項，請參閱Flow log limitations。Flow log資料可以儲存到CloudWatch Logs 或 S3。

VPC Traffic Mirroring

VPC traffic mirroring是flow logs的輔助功能，它複製整個流量包，包括來自 EC2 instance的指定elastic network interface的流量。 traffic mirroring複製EC2 instance的network interface中所有inbound/outbound IPv4/IPv6流量。我們可以將複製流量的發送到另一個 EC2 instance的network interface，或具有 UDP listening的Network Load Balancer。

複製的流量通過來源VPC IPv4路由表發送至目的地。需要注意的是，所有複製的流量都封裝在 IPv4 流量包中。 traffic mirroring同時mirrors IPv4 和 IPv6 流量。無需進行特殊配置即可為 IPv6 流量啟用traffic mirroring，無論traffic mirroring來源和目標位於同一 VPC 中，還是位於通過 VPC peering或 Transit Gateway 的不同 VPC 中（IPv4路由是通的）。

AWS WAF

AWS WAF 讓我們監控轉發到 CloudFront distribution、API Gateway REST API、Application Load Balancer 或 AppSync GraphQL API 的 HTTP(S) request。借由 AWS WAF，與受保護資源關聯的服務可以根據指定的條件（例如發出請求的 IPv4/IPv6 address）以請求的內容或 HTTP 403 狀態代碼進行回應。

Web ACL

我們可以使用 Web ACL 中的規則來allow或deny基於條件的 Web requests，其中包括發出請求的 IP address或地址範圍。 IP set match statement根據一組 IP 地址和地址範圍檢查 Web request的 IP 地址。使用此選項可根據request來源的 IP 地址（IPv4 或 IPv6）allow或deny Web request。 AWS WAF IP sets支援除 0.0.0.0/0 和 ::/0 之外的所有 IPv4 和 IPv6 CIDR 範圍。

AWS Shield

AWS Shield Standard 與AWS Shield Advanced提供針對 DDoS 攻擊的保護。 DDoS 攻擊可以阻止合法用戶訪問服務，並可能因流量過大而導致系統崩潰。所有 AWS Shield偵測和緩解措施均適用於 IPv4 和 IPv6，不會對服務的效能、可擴展性或可用性產生任何影響。

AWS Network Firewall

AWS Network Firewall 是適用 VPC的stateful、託管網路防火牆以及IDS/IPS服務。借由此功能，我們可以啟用 AWS Network Firewall endpoints來過濾Dual-stack subnets中的 IPv4 和 IPv6 流量。因此，我們可以過濾進出網際網路、地端網絡或 VPC 中任何endpoint的 IPv4 和 IPv6 流量。

AWS System Manager

AWS Systems Manager 管理的資源必須具有到 Systems Manager endpoint的 IPv4 連接。例如，要使用 Systems Manager Session Manager連接到 EC2 instance，該instance必須是Dual stack，並且必須具有到網際網路或 AWS PrivateLink VPC endpoint的 IPv4 連接。同樣，地端資源也必須處於Dual stack網路模式。

Dual-stack的網路擴展設計

ELB(Elastic Load Balancing)

ELB 自動將inbound流量分配到一個或多個AZ中的多個目標，例如 EC2 instance、容器和 IP address。它支援以下類型的負載均衡器：ALB、NLB和Classic Load Balancers。

PS:
ALB 和NLB 是專門構建的load balancers，用來取代了Classic Load Balancers。

ALB/NLB都可以用在For internet或 LAN。我們可以將 IPv6 CIDR block與 VPC 關聯，並選擇是for internet 或for LAN。要支援IPv6，我們要選“Dual stack”IP address type。在Dual stack IP address type中，LB的DNS名稱同時提供IPv4和IPv6地址，並分別建立A和AAAArecord。

ALB/NLB可以同時具有 IPv4 或 IPv6 target。配置target group時，不能混合使用 IPv4 和 IPv6 。需要注意，對於 IPv6 target，只支持 IP-type target，並且 IPv6 地址需要來自 VPC IPv6 space。我們不能來自peered VPC、地端或可通過 AWS Transit Gateway 存取的 IPv6 地址。

ALB 支援HTTP 和 HTTPS listener for IPv6。 NLB只在 TCP 和 TLS listener支援 IPv6。

ELB IPv6 support:

當我們在NLB上啟用Dual stack模式並具有 IPv4 target時，NLB會執行 IPv6 到 IPv4 的轉換，因此不會保留source IP。但是，NLB會將 IPv6 source IP加到proxy protocol (PPv2) header並將其發送到target。在這種情況下，target需要解析 PPv2 header以取得client的實際source IP。

對於具有 IPv6 target的NLB，為與具有 IPv6 target的Dual stack LB的 IPv6 連接啟用來源 IP 的保留。 client IP 對從 IPv6 轉換為 IPv4 或 IPv4 轉換為 IPv6 的流量保留不受影響。此類流量的來源 IP 始終是NLB的private IP 。下表總結了 NLB client用於目標連接的協議（IPv4 或 IPv6），以及目標具有的基於client IP 保留的client IP 可見性：

Global Accelerator

該服務已支援IPv6。藉由Dual stack Accelerator，我們可以將 IPv6 與 IPv4 流量一起路由至Dual stack ALB endpoint。除了兩個static IPv4 之外，還可以取得兩個static IPv6 。我們在新建新的accelerator時可以選擇Dual stack，也可以使用標準 AWS 工具（包括 AWS Management Console, AWS SDK或AWS CLI）將現有的IPv4-only accelerator變更為Dual stack。變更時，accelerator的 IPv4 運作不會發生變化。除了使用現有 Global Accelerator CloudWatch metrics監控 IPv4 流量外，也可以監控 IPv6 流量。

CloudFront

當使用者通過 IPv6 向 CloudFront 發出 HTTP/HTTPS request時，CloudFront 會自動對應網路狀況將使用者流量路由到效能最佳的 AWS 邊緣站點，以提供緩存或動態內容。該邊緣位置通過 IPv6 回應使用者。無論cleint使用 IPv4 還是 IPv6，都會收到相同的內容以及相同的安全性、可用性、效能和可擴展性。

CloudFront 使用 IPv4-only 與origin server通訊，目前不支援 IPv6 origin server。這適用於 CloudFront distribution的所有類型的來源，包括 Amazon S3 buckets、AWS Elemental MediaStore 容器、AWS Elemental MediaPackage channel和custom origins。

以下是 IPv6 中 HTTP request生命週期的request流程：

IPv6 ivewer（例如瀏覽器）存取我們的網站，並通過 IPv6 使用 FQDN :d111111abcdef8.cloudfront.net 從 CloudFront distribution request object（例如image file）。
DNS 查詢首先到達recursive resolver。此解析程序在 Route 53 中查詢 d111111abcdef8.cloudfront.net 的 AAAA record，因為 Route 53 是 cloudfront.net domain的authoritative name server。
Route 53 name servers可通過 IPv4 或 IPv6 存取。 DNS 解析 AAAA 查詢並將request路由到能夠最好服務該request的 CloudFront POP。 CloudFront 自動判斷網路狀況將使用者的流量路由到效能最佳的 AWS POP。
Viewer連接到相應的 CloudFront POP。
在 POP 中，CloudFront 檢查其緩存中是否有請求的內容。如果image file位於緩存中，CloudFront 將它們返回給viewer。如果檔案不在緩存中，CloudFront 會將request與我們的distribution中的設置進行比較，並通過 IPv4 將 HTTP request轉發到image file的origin server。
origin server將檔案請求回應給edge。
一旦first byte從origin到達，CloudFront 就開始將檔案回應給viewer。 CloudFront 還會根據cache header檔案加到edge的緩存中。

進階的Dual Stack與 IPv6-only的網路設計

Transit Gateway Connect attachment

Transit Gateway Connect 使用GRE將SD-WA network virtual appliances整合到 Transit Gateway 中，簡化了各分區辦公室的網路連接。對於通過 GRE tunnels的動態路由交換，Transit Gateway Connect 支援以下 BGP 模式：

eBGP
iBGP
MP-BGP

MP-BGP 是 BGP 的延伸，使 BGP 能夠承載多種網路層協議的路由資訊。 BGP 可以承載的流量類型稱為address families，MP-BGP 的優點是能夠通過一個peering連路由多個address families。這也意味著我們可以在現有連接上加上 IPv6 設定。

IPv6的集中式 internet outbound traffic

集中式outbound traffic是 IPv4 的一種普遍模式。可以使用兩種不同的方法來實現類似的模式：

使用稱為 IPv6-to-IPv6 Network Prefix Translation（NPTv6 或 NAT66）技術的 Transparent proxy。
在OS或Application設定中使用Explicit forward proxy configured。

第一種模式需要使用 Transit Gateway 和基於 EC2 的路由器設備來執行 NAT66 功能。下圖顯示了使用基於 Linux 的 NAT66 insatnce的進階設定。來自client的流量遵循到 Transit Gateway 的預設路由，從 Transit Gateway 轉發到集中式outgoing traffic VPC。

一旦進入outbound trafficVPC，它就會被轉發到 NAT66 instance，NAT66 會將流量包的來源 IP 轉換為其自己的 IP。為了提高安全性，NAT66 instance可以提供防火牆功能。為了實現高可用性，我們可以加入多個AZ，或使用 Transit Gateway Connect 連接路由設備。

PS:
如果我們需要集中式的traffic inspection，則可以採用集中式outbound traffic。通過只有outbound traffic的internet gateway，AWS 可以很容易實現distributed outbound traffic。然而，如果有outbound traffic inspection需求，並且無法在每個 VPC 中進行檢查，則可以使用集中式模式。

第二種模式需要一組可以在集中式outbound traffic VPC 中配置的explicit proxies。 Squid proxy是一種常用的open-source proxy解決方案。在配置forward proxy並更新OS或Application設定後，我們將能夠連接到 Internet 上的 IPv6 資源。

TGW 與 IPv6 結合使用來解決 IPv4 address overlap問題

TGW可以連接到具有overlap IP address CIDR 的 VPC。這是因為除了配置路由之外，TGW 不受 VPC 中使用的地址空間的影響。雖然可以將 TGW 連接到具有overlap IP address CIDR 的 VPC，但不可能存在衝突的路由。但是，由於 IPv6 prefix是globally unique的，因此它可以在具有overlap IP CIDR 的 VPC 中的主機之間提供連接。

EKS IPv6 clusters

為了避免 IPv4 地址耗盡、大規模減少延遲並簡化路由配置，解決方案是使用 IPv6 address space。在EKS cluster上使用IPv6會有一些優勢：

可以在一個主機或subnet上運行更多 Pod，而無需擔心耗盡 VPC 中所有可用 IPv4 的風險。
它可以去除NAT可能造成的延遲，允許與在地端、AWS 或Internet上運行的其他 IPv6 服務。
它減輕了維護複雜路由的配置。

此外，Pod etworking經過配置，以便 Pod 可以與cluster外部IPv4-based 的應用程式進行通訊。