Tag: ipv4

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 上的方法...

AWS 增加 CloudFront 的 AWS-managed prefix list 讓管理者使用

看到 AWS 公告提供 CloudFront 的 origin subnet 資訊 (AWS-managed prefix list) 讓管理者可以用：「Amazon VPC now supports an AWS-managed prefix list for Amazon CloudFront」。

以往會自己去「AWS IP address ranges」這邊提供的 JSON 檔案定時撈出來再丟到 managed prefix list 裡面，這次的功能等於是 AWS 自己管理這個 prefix list 讓管理者使用。

馬上想的到的用途就是 HTTP/HTTPS port 了，只開放給 CloudFront 的伺服器存取：

Starting today, you can use the AWS managed prefix list for Amazon CloudFront to limit the inbound HTTP/HTTPS traffic to your origins from only the IP addresses that belong to CloudFront’s origin-facing servers. CloudFront keeps the managed prefix list up-to-date with the IP addresses of CloudFront’s origin-facing servers, so you no longer have to maintain a prefix list yourself.

要注意的是這不應該當作唯一的 ACL 手段，因為其他人也可以建立 CloudFront distribution 來穿透打進你的 origin server。

另外有個比較特別的地方，這個 prefix list 的權重很重，使用他會算 55 條 rule 的量，在 security group 內很容易撞到 60 條的限制，在 route table 裡面則是直接撞到 50 條的限制；不過這兩個限制都可以跟 AWS 申請調昇：

The Amazon CloudFront managed prefix list weight is unique in how it affects Amazon VPC quotas:

  • It counts as 55 rules in a security group. The default quota is 60 rules, leaving room for only 5 additional rules in a security group. You can request a quota increase for this quota.
  • It counts as 55 routes in a route table. The default quota is 50 routes, so you must request a quota increase before you can add the prefix list to a route table.

如果 HTTP 一條，HTTPS 也一條，那就會算 110 rules 了，有暴力的感覺...

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

Vultr 可以帶自己的 IP 位置使用

Twitter 上看到 Vultr 可以帶自己的 IP 使用：

翻了一下發現是 2015 年就提供的功能：「Announce IP Space on the Cloud with Vultr」，而旁邊的 Linode 與 DigitalOcean 似乎都沒翻到...

在文件「Configuring BGP on Vultr」這邊可以看到需要先驗證 IP 是你的，算是業界常見的作法，跟當初申請 AWS 的 Direct Connect 類似的作法。

AWS 昨天公告了 84 個 /16 的 IPv4 位置

在 Hacker News 首頁上看到 AWS 昨天公告了 84 個 /16 (IPv4)：「AWS adds an extra 5.5M IPv4 addresses (github.com/seligman)」。

這使得 AWS 在整個可用的 IPv4 network 佔的空間從 1.61045% 上升到了 1.75915%，不確定這 84 個 /16 花了多少錢買...

另外看到國外 ISP 的一些作法，發 CGNAT 的 IPv4 位置，以及實際的 IPv6 位置，這樣對於有支援 IPv6 的應用就可以反連回去：

When I lived in Ireland I only got a public IPv6, my IPv4 was behind CG-NAT. The nerd in me wasn't a fan of that on paper, but in reality I didn't have any issues with it.

家裡的第四台還是 IPv4 only 啊 (至少不是 CGNAT，之前被換到 CGNAT 時有去幹繳過)，要連 IPv6 資源目前還是只能透過 6to4 去摸，看起來是連到香港的 HE，速度普普通通...

HiNet 開始提供 2G/1G 的線路

HiNet 開始提供 2G/1G 的線路了，但在企業上網的「HiNet企業上網促銷網站」這邊還沒看到 2G/1G 的方案，反倒是在一般家用的「HiNet光世代 2G/1G HiLight極速方案 | 中華電信網路門市 CHT.com.tw」這邊可以看到了，不過有些地方得注意。

首先是「家用型」(NTD$3,069/month) 是有限制流量的：

2G/1G家用型(非固定制)僅供自然人以個人證號提出申請。如連續3日每日訊務量(上下行加總)皆超過200GB，本公司得於通知後，於其後連續2日調整服務速率上限為100Mbps/40Mbps(Best Effort)，調整速率期滿後恢復申辦速率。

如果想要將頻寬灌好灌滿的話，得裝「進階型」(NTD$5,299/month)，另外一個問題是「家用型」不支援 PPPoE 固定 IP 服務 (i.e. 非固固)：

2G/1G進階型(非固定制)得自行上網申請非固定制之固定IP，換言之有動態IP 16個或固定IP 1個+動態IP 15個此二種型態供客戶選擇，前述非固定制之固定IP，本公司有權於下列情況發生者，重新配發新的固定IP取代原本之固定IP。

目前的 1G/600M 是可以申請一個非固固的，這樣誘因又少了些。

另外看了一下目前 1G/600M 的優惠價是 NTD$2,399/month，所以意思是，租兩條頻寬還比較多 (2G/1.2G)，還比較便宜 (NTD$4,798/month)，而且有兩個固定 IP？

Ptt 上的「Re: [情報] 中華電信將推2G/1G光世代上網新服務，每月最低3069元起」這篇裡面也有不少討論，看起來這個方案有得吵了 XD

IPv4 的價錢

在 Hacker News 首頁上看到「IPv4 pricing (hetzner.com)」這篇，裡面的連結「IPv4 pricing」是 Hetzner 這個 hosting 通知 IPv4 將在八月漲價的資料...

可以看到「/24 IP subnet (254 usable IPs)」這組的價錢從「€ 215.13 / € 0 setup」漲到「€ 435.20 / € 4864.00 setup」，看起來是趁機漲了不少 setup fee 來綁使用者。

Hacker News 的討論裡面有提到 e-mail 的應用上還是得用 IPv4，至少 Microsoft 還是不愛 IPv6：

I remember while trying to figure out why Microsoft was blocking emails that IPv6 SMTP source addresses had a much higher risk of being blocked despite having done all the required stuff like PTR, SPF, DKIM. Microsoft's form to submit delisting an IP address does not even accept an IPv6 address: https://sender.office.com/

Stuff like this really hinders adoption.

hmmm，e-mail 的確是痛點 (尤其是 reputation 問題)，但其他大多數的應用好像還好？