Tag: ipv6

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 是沒支援的啊，這功能補的好晚...

RIPE 的 IPv4 位置發完了

RIPE 在上個禮拜宣佈 IPv4 address 發完了：「[ripe-list] The RIPE NCC has run out of IPv4 Addresses」。

但這不代表不能申請，只是會進到「IPv4 Waiting List」這個列表裡面等待，各種原因取回的會發個這些申請者。

在台灣應該還是沒什麼感覺，因為固網 ISP 手上其實都拿一堆 IP 屯著，讓動態 IP 的架構輪著用，而行動網路上也可以看到不少 ISP 使用 Carrier-grade NAT 之類的架構在跑，最差也還可以拿 Private IP 硬上，暫時也不是太缺...

IPv6 的部份的確有愈來愈好，但還是常常可以看到 IPv4 的 routing 比較好，IPv6 有時候會繞到歐美再回亞洲...

話說起來，應該做看看 IPv6 上的 SmokePing 了，這樣才能比較 IPv4 與 IPv6 的 routing...

家裡電腦裝 Ubuntu 18.04

上個禮拜四家裡的桌機開不了機，找了一天發現是系統的 SSD 掛掉了，就買了張 M.2 SSD，然後計畫順便把本來的 Ubuntu 16.04 升級到 Ubuntu 18.04，但 Ubuntu 18.04 把預設的界面從 Unity 換成 GNOME (然後披上 Unity 的皮)，加上前陣子系統從 Intel 平台換到 AMD，整個狀況變得超混亂之後，就變成一連串踩地雷的過程...

最一開始是 UEFI + LUKS 的安裝問題，本來想裝到 M.2 SSD 上面，但 Ubuntu 18.04 的 grub-install 就是硬寫到 /dev/sda 不能改：「“Unable to install GRUB in /dev/sda” when installing GRUB」，照著這篇的 workaround 用還是不行，最後放棄，直接生一顆 SATA SSD 接到 SATA Port 1，把 M.2 當作資料碟。

硬體相關的問題：

軟體相關的問題：

  • 目前不支援從 GUI 設定 PPPoE 的網路 (沃槽)，幾種方式裡面我推薦用 pppoeconf 設定會比較好，然後可以改 /etc/ppp/options 加上 IPv6 的設定。
  • 本來想裝 gnome-shell-extension-system-monitor 觀察系統狀態，但會造成系統超級卡，關掉後就變成普通的卡 (後來就找到 Intel I211-AT 的那個問題了)。

現在至少是堪用的程度了，接下來就是不斷的補各種設定...