Tag: ipv6

AWS 的 VPC 可以設定 Private IPv6 address 了

AWS 的 VPC 以前都只能設定 public IPv6 address，現在總算是可以設定 private IPv6 address 了：「AWS announces private IPv6 addressing for VPCs and subnets」，另外一篇講的比較詳細：「Understanding IPv6 addressing on AWS and designing a scalable addressing plan」。

IPv6 address 的熟悉度沒有 IPv4 address 高... 看起來 AWS 所提到的 private 包括了 GUA 與 ULA：

Private IPv6 addresses on AWS can include ULA, which are intended for local communication, and private GUA, which could be globally routable according to protocol definition.

GUA 好像是就是拿 public ip 區段用 (反正 IPv6 區段夠大)？反而是 ULA 這邊用的 fd00::/8 跟以前 IPv4 的 private range 剛好相對應，比較好理解...

合併 GitHub Actions 的 IP address

在 GitHub 官方文件「About GitHub's IP addresses」中，是有提到 https://api.github.com/meta 這組 API endpoint，可以取得當下的 GitHub Actions 所使用的連外 IP address，不過如果你實際掃下來後會發現量相當大，以現在的情況來說，IPv4 address 有 3708 筆，IPv6 address 則有 801 筆：

$ cat github-actions-ipv4.txt | wc
   3708    3708   58233
$ cat github-actions-ipv6.txt | wc
    801     801   17522

實際去看的時候會看到一些吐血的，像是這包 /31 的：

13.105.49.0/31
13.105.49.2/31
13.105.49.4/31
13.105.49.6/31
13.105.49.8/31
13.105.49.10/31
13.105.49.12/31
13.105.49.14/31
13.105.49.16/31

這包還真的就整整 128 筆，你就不能輸出個 13.105.49.0/24 嗎...

用 ChatGPT 問了要怎麼解決，被提示有 netmask 這個工具可以用，不需要另外自己編譯，可以直接用 apt 裝起來然後倒進去讓他跑就好，整包搭配 jq 與 HTTPie 處理掉 (換 curl 基本上也沒問題)：

netmask --cidr -- $(http https://api.github.com/meta | jq -r '.actions[]')

Update：看到資安的朋友按讚突然想到，這邊用了 $() 把資料丟到 command line 包裝，可能會有安全上的顧慮，請自己斟酌...

不過整包 (IPv4 + IPv6) 還是有 3187 行，但總是有個方法可以整理起來用，不用自己刻一堆程式處理...

測 IPv4 NAT VPS，以及架設 HTTPS Proxy

因為 AWS 開始收 Public IPv4 address 費用的關係 (而且頗貴，參考「AWS 將開始收取 IPv4 的 Public IP 費用」)，我把其中一台主機改成只有 IPv6 address 後遇到不少問題 (在「把 AWS 上的 EC2 instance 改成 IPv6-only」這邊)。

由於有 proxy 的需求，剛好找機會玩一下 IPv4 NAT VPS... 這種 VPS 最基本的大概就是會給一個 IPv4 address 上 non-standard port 當作 SSH port，讓你可以連進去管理；另外通常會給 port forwarding 的功能，而且是固定不能換的，讓你可以開一些 port 出來用。

我的用途是 IPv6 address 的 proxy，所以要找有給固定的 IPv6 address 的，另外希望跑在日本，這樣其他用途也比較方便。

過年期間翻了一下找到 NAT VPS，有 256MB 跑個 proxy 類的應用應該還 OK，實際上是 256MB RAM + 64MB swap 的 OpenVZ 類環境，kernel 有到 5.2.0 還算堪用，上面可以選 Ubuntu 22.04 安裝。

費用的部分 US$7/year 還行，網路上是有看到 128MB RAM 的 機器，但這樣連裝東西都綁手綁腳的，太容易 OOM。

(剛拿到機器的時候還試著裝 Percona Server for MySQL，結果就 OOM 跑不完 setup 的流程，看起來得自己改設定混過去，但只是想確認 256MB RAM + 64MB swap 可以弄到什麼程度，就反安裝了...)

在上面把想測的東西測試完後，實際的 proxy 設定比較簡單... 先設定一個只有 IPv6 address 的 domain 申請 Let's Encrypt 的 SSL certificate，然後掛給 Squid 用。

然後在 IPv6-only 的機器上用 curl -v --proxy https://username:password@proxy-jp.example.com:12345/ https://home.gslin.org/robots.txt 確認沒問題後就可以把服務都掛過去。

有些服務會吃環境變數 HTTP_PROXY 與 HTTPS_PROXY，有些是在設定檔內設定，基本上都是照著文件設就可以了。

我遇到的 application & library 都可以吃 HTTPS Proxy 協定，就沒什麼大問題... 如果有遇到不行的，也可以考慮在 Squid 裡面直接放行特定的 IPv6 address。

把 AWS 上的 EC2 instance 改成 IPv6-only

因為「AWS 將開始收取 IPv4 的 Public IP 費用」的關係，先試著把其中一台 EC2 instance 改成 IPv6-only，結果遇到不少問題...

首先是對外服務的部分，本來想用 CloudFront 擋在前面，但 CloudFront 到現在還是不支援 IPv6-only origin：「CloudFront support for IPv6 origins」，所以這邊的選擇變成是 Cloudflare。

第二個是 AWS 自家的 API 還是有些沒有 IPv6 address，像是取得 AWS 擁有的 IP pool 的 https://ip-ranges.amazonaws.com/ip-ranges.json (本來是要取得 CloudFront 的區段，用在 nginx 的設定裡)。

另外就是周邊的問題，很多服務都沒有 IPv6 address，像是 api.slack.com：

各種 proxy 與 NAT 架構還是必要的措施...

捷克政府宣布 2032/06/06 政府網站將停用 IPv4 服務

看到「Czech republic sets IPv4 end date (konecipv4.cz)」這篇，捷克政府公告了政府網站將在 2032/06/06 停用 IPv4 服務：「Czech republic sets IPv4 end date」。

On 17 January 2024, the Government of the Czech Republic approved the material "Restarting the implementation of DNSSEC and IPv6 technologies in the state administration". On the basis of this decision, the Czech state administration will stop providing its services over IPv4 on 6 June 2032. Thus, the Czech Republic knows its IPv4 shutdown date.

剛好昨天在試著將手上 AWS 的 EC2 instance 拔掉 IPv4 address (因為 2024/02/01 開始收費，參考先前寫的「AWS 將開始收取 IPv4 的 Public IP 費用」)，結果還是遇到相依服務還沒有上 IPv6 endpoint 的問題，如果要轉移的話得開 DNS64 與 NAT64，但因為目前就只有兩台小機器在 AWS 上，在上面租 NAT64 或是自己架 NAT64 的費用反而比付 IPv4 address 的費用還貴，就先暫時丟著了。

我這邊遇到的問題是 api.slack.com 目前只有 IPv4 address，這邊因為是走 HTTPS，也許可以靠其他在有 IPv6 address 的 VPS 上的 proxy server 解決 (我剛好有租一些 VPS instance)，這幾天再來看看怎麼弄...

AWS 的 VPC 開放自訂 IPv6 CIDR 了，但還是有 4 的倍數的限制...

AWS 的公告，VPC 裡的 IPv6 可以自訂 CIDR 了：「VPCs and subnets now support more sizes for IPv6 CIDRs」。

不過還是有限制，首先是 VPC 的大小必須是 /44 到 /60 中 4 的倍數，也就是只有 /44、/48、/52、/56 以及 /60 這五個可以用，而 subnet 也有類似的限制，但從 /44 到 /64，所以剛好就是多了 /64 可以用：

Amazon VPC allows customers to create VPCs and subnets of different sizes using IPv6 CIDRs. With this capability, customers can now create VPCs in sizes between /44 and /60, and subnets in sizes between /44 and /64, in increments of /4.

先前的限制是 VPC 只能給 /56 以及 subnet 只能給 /64 的搭配，是個「可以動」但總是覺得「...」的設計：

Before today, AWS supported one standard IPv6 CIDR block size of /56 for VPC and /64 for subnet, whereas IPv4 CIDR block size were flexible for both VPCs and subnets.

不過我實際在 ap-northeast-1 上測試，發現如果是 AWS 發的 IPv6 address，固定就是 /56 的大小，然後 subnet 在選擇的時候可以選 /56、/60 與 /64。

這邊提到 VPC 可以選擇大小，應該是其他方式帶進來的 IPv6 address？

另外這次的 /4 的遞增限制，我猜是 AWS 裡面 SDN 上面的限制？IPv4 的 CIDR 有 33 個大小 (/0 到 /32)，IPv6 上面如果也處理 33 個的話，反過來設計剛好是 /4 遞增的 workaround？

不過話說回來，我記得前陣子 AWS 公佈要收 Public IPv4 address 的費用時 (參考「AWS 將開始收取 IPv4 的 Public IP 費用」)，Hacker News 上有人抱怨還是有很多 AWS 的服務是 IPv4 only，在純 IPv6 network 上面是不太會動的；把這些服務的 IPv6 endpoint 生出來應該要趕快放到 roadmap 上...

IPv6 Excuse Bingo (IPv6 理由伯賓果？)

在「AWS IPv4 Estate Now Worth $4.5B (toonk.io)」這邊的討論意外的看到「IPv6 Excuse Bingo」這個網站...

這個 bingo 是動態的，每次 reload 都會有不同的版本出來，理由超多...

不過實際用 IPv6 network 後會發現各種鳥問題真的多，之前 (到現在) 最經典的就是 HE 跟 Cogent 的 IPv6 network 因為錢的問題談不攏而不通的問題，在維基百科上面就有提到從 2009 年開始就不通了：

There is a long-running dispute between the provider Cogent Communications and Hurricane Electric. Cogent has been refusing to peer settlement-free with Hurricane Electric since 2009.

所以夠大的服務如果要弄 IPv6 都得注意到這點，像是 CDN 或是 GeoIP-based load balancer 就不能把 Cogent 的用戶導到 HE 的位置上面，反之亦然。

不過話說 AWS 手上有 128M 個 IPv4 address，整個 IPv4 address 的空間也才 4.29B，也就是說光 AWS 手上就有大約 3% 的 IPv4 address 空間，如果扣掉不可用的區段的話就更高了...

Amazon SES 寄到 Gmail 受到阻擋的情況

我自己沒遇過，但是 Hacker News 上看到有人有遇到，所以記錄起來：「Tell HN: Gmail rate limiting emails from AWS SES」。

Amazon SES 預設是共用 IP pool，所以遇到這種情況不算太意外，但應該是暫時性的，不過發問的作者有提到後來的解法是花 US$25/mo 使用 Dedicated IP 解決 IP reputation 的問題 (在 id=37177533 這邊)：

Thanks you all for comments. I have made a decision to subscribed to dedicated IPs (credits: @slau).

The differentiating factor between our current AWS SES plan and the competitors (mentioned in the comments) is having a dedicated IP. With our current volume, none of the competitors are anyway near AWS SES costs. So, moving to a dedicated IPs thats cost 25$ extra not only solves our issue, but also no change in code/infrastructure.

記得以前另外一個教訓是，寄信還是儘量用 IPv4 address 去寄，因為 IPv6 address 的 reputation 得養頗久... 不過這個也是很久前的事情了。

6to4 在 2015 年就 deprecated 了...

找資料才發現 RFC 7526 廢掉 6to4 了：「Deprecating the Anycast Prefix for 6to4 Relay Routers」。

看起來像是無法解決的技術問題：

While this makes the forward path more controlled, it does not guarantee a functional reverse path.

去程的部份比較沒問題，但回程的部份就不一定會動。

不過目前看起來 HE 的 192.88.99.1 還有在運作，真的用 6to4 連 IPv6 network 的人至少還有機會動，等之後 IPv6 更普及應該會慢慢退場...

AWS Global Accelerator 支援 IPv6

AWS 的 Anycast 服務 AWS Global Accelerator 宣佈支援 IPv6：「New for AWS Global Accelerator – Internet Protocol Version 6 (IPv6) Support」。

算是補功能，不過這個功能只對於「純 IPv6 環境」的使用者端有用 (沒有 DNS64 + NAT64 的轉換)，目前商轉給一般使用者用的 IPv6 環境應該都還是有掛 DNS64 + NAT64 才對...

另外使用這個功能會需要 VPC 有 IPv6 能力：

To test this new feature, I need a dual-stack application with an ALB entry point. The application must be deployed in Amazon Virtual Private Cloud (Amazon VPC) and support IPv6 traffic.

然後 IPv4 會進到 IPv4 的服務裡，IPv6 則會進到 IPv6 的服務裡：

Protocol translation is not supported, neither IPv4 to IPv6 nor IPv6 to IPv4. For example, Global Accelerator will not allow me to configure a dual-stack accelerator with an IPv4-only ALB endpoint. Also, for IPv6 ALB endpoints, client IP preservation must be enabled.

短時間還用不太到，但之後應該有機會...