Tag: ipv6

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.

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

Route 53 支援 DNS64，以及 NAT Gateway 支援 NAT64

AWS 宣佈了一套機制，讓 IPv6-only 的機器可以連到 IPv4-only 的服務：「Let Your IPv6-only Workloads Connect to IPv4 Services」。

首先是 DNS64，針對只有 IPv4-only 的 A record 自動加上 AAAA record (如果已經有 AAAA record 的則不變)，這邊提到的 64:ff9b::/96 是來自 DNS64 標準內的規範：

The DNS resolver first checks if the record contains an IPv6 address (AAAA record). If it does, the IPv6 address is returned. The IPv6 host can connect to the service using just IPv6. When the record only contains an IPv4 address, the Route 53 resolver synthesizes an IPv6 address by prepending the well-known 64:ff9b::/96 prefix to the IPv4 address.

再來就是 NAT Gateway 可以把 64:ff9b::/96 透過 NAT64 轉到 IPv4 network 上：

You may configure subnet routing to send all packets starting with 64:ff9b::/96 to the NAT gateway. The NAT gateway recognizes the IPv6 address prefix, extracts the IPv4 address from it, and initiates an IPv4 connection to the destination. As usual, the source IPv4 address is the IPv4 address of the NAT gateway itself.

由於有些 protocol 會帶 IP address 資訊，所以不能保證 NAT64 一定會動，但大多數的情況應該是可以解決，至少提供了 IPv6-only server 連到 IPv4-only network 上的方法...

Amazon VPC 支援純 IPv6 的網段了

Amazon VPC 支援純 IPv6 的網段了：「Amazon Virtual Private Cloud (VPC) customers can now create IPv6-only subnets and EC2 instances」。

先前機器都還是要設一個 IPv4 位置，所以網段都必須有 IPv4 network space，這次推出使得機器可以跑在 IPv6-only network 上了，不過 Linux 裡面應該還是會有個 lo 與 127.0.0.1...

短時間應該用不到，不過可以先玩看看感覺一下...

把 Whoogle 改跑在 Raspberry Pi 上面

本來是把 Whoogle 跑在固定 IP 的機器上面，後來發現一下就被擋了，改用 Tor 跑也沒用 (exit node 的 IP reputation 應該更差)，花了些時間搬到 Raspberry Pi 上面跑，改用浮動 IP 來跑。

首先是 Docker 跑不起來的問題，這主要是 Raspberry Pi 第一代的 CPU 指令集似乎跟主流的 armhf 不同？不確定... 但最後是直接上 pipx 解決。

跑起來以後發現 IPv6 的 reputation 也很差，幾乎是一定會被擋 (在『繞過 Web 上「防機器人」機制的資料』這篇有提到)，所以乾脆把整台機器的 IPv6 network 都關掉，強迫讓他走 IPv4 network，然後再定時重新撥 PPPoE 去換 IP...

不過目前是跑在 Raspberry Pi 第一代上面，速度真的好慢... 看之後有沒有機會換另外的板子 :o

AWS 的 VPC 內可以用 IPv6 的 Metadata Service、Time Service 與 DNS Server 了

在「IPv6 endpoints are now available for the Amazon EC2 Instance Metadata Service, Amazon Time Sync Service, and Amazon VPC DNS Server」這邊看到的，AWS 把一些基礎服務補上了 IPv6 interface：

The Amazon EC2 Instance Metadata Service, Amazon Time Sync Service, and Amazon VPC DNS server can now be accessed over IPv6 endpoints by instances built on the Nitro System.

Metadata Service 的部份在「Use IMDSv2」這邊可以看到，在 IPv4 的時候是 169.254.169.254，在 IPv6 時則是 fd00:ec2::254：

The examples in this section use the IPv4 address of the instance metadata service: 169.254.169.254. If you are retrieving instance metadata for EC2 instances over the IPv6 address, ensure that you enable and use the IPv6 address instead: fd00:ec2::254. The IPv6 address of the instance metadata service is compatible with IMDSv2 commands. The IPv6 address is only accessible on Instances built on the Nitro System.

Time Service 的部份可以在「Set the time for your Linux instance」這邊翻到，可以看到 fd00:ec2::123 這個位置：

The Amazon Time Sync Service is available through NTP at the 169.254.169.123 IPv4 address or the fd00:ec2::123 IPv6 address for any instance running in a VPC. The IPv6 address is only accessible on Instances built on the Nitro System.

DNS 的部份則是在「DNS support for your VPC」這邊翻，可以看到 fd00:ec2::253 這個 IPv6 address 的 DNS 服務：

If this attribute is true, queries to the Amazon provided DNS server at the 169.254.169.253 IPv4 address (or the reserved IP address at the base of the VPC IPv4 network range plus two) and the fd00:ec2::253 IPv6 address will succeed. The IPv6 address is only accessible on EC2 instances built on the Nitro System.

算是又補齊了一些基礎建設...

另外 EC2 剛好這三個字都在十六進位表示法的範圍內，就拿來當 IPv6 address 也是讓人好記很多。

另外結尾故意用 ::254、::123、::253 (要注意這是十六進位) 也讓人好記很多，而不是 ::fe 這類 hex。

Ubuntu 環境 PPPoE 遇到拿的到 IPv6 address 但是卻不通的問題

在 Ubuntu 的環境裡透過 PPPoE 上拿 IPv6 address 不是什麼大問題，搜一下大概都可以找到，在 /etc/ppp/options 的最後面加上這串就可以了 (或是在 /etc/ppp/peers/ 裡面的檔案對特定的設定加)：

+ipv6 ipv6cp-use-ipaddr

不過我遇到的問題是，ppp0 雖然拿到了 IPv6 address (從 ip addr 或是 ifconfig 可以看到)，但 mtr -6 www.google.com 確不通。

找問題時發現 netstat -6rn 有兩筆 IPv6 default gateway，刪掉 enp3s0 的那筆馬上就通了，所以是跟 routing 有關的問題，在本地端收到了 default routing，優先權還比 ppp0 拿到的還高。

因為這台主機是跑 Netplan，所以就用 Netplan 的方式強制關掉本地端的 Router Advertisement (RA)：

network:
    version: 2
    renderer: networkd
    ethernets:
        enp3s0:
            accept-ra: false

最後重開機確認後就通了...

EC2 API 支援 IPv6，以及 Lightsail 支援 IPv6...

看到 AWS 丟出了兩個有點「有趣」的消息：「Amazon EC2 API now supports Internet Protocol Version 6 (IPv6)」、「Amazon Lightsail now supports IPv6」。

先是 EC2 的 API 支援 IPv6 的消息，但也不是全部都支援了 (亞洲區只有印度有支援，新加坡、日本、南韓與香港都沒在上面)：

Usage of Amazon EC2’s new dual-stack endpoints are available at no additional charge. The new endpoints are generally available in US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Asia Pacific (Mumbai) and South America (São Paulo).

不過畢竟也不是直接面向使用者的部份，不算太意外就是了... 但另外聽到 Lightsail 支援 IPv6 的消息就比較意外了：

Amazon Lightsail now supports Internet Protocol version 6 (IPv6) on Lightsail resources like instances, containers, load balancers and CDN. With this launch, Lightsail resources operate in dual-stack mode, accepting both IPv4 and IPv6 client connections. This helps unlock application scenarios where some end user clients are IPv6 only.

本來以為 EC2 與 CloudFront 有的東西在 Lightsail 上都會有，原來 IPv6 是沒支援的啊，這功能補的好晚...