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.

本來以為 EC2CloudFront 有的東西在 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 的那個問題了)。

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

Google Hangouts 將會使用固定 IP 位置

Google 宣佈 Hangouts 將會使用固定 IP 位置,讓系統管理員更方便管理:「Dedicated Hangouts Meet IP addresses」。

We’re adding a range of official, fixed IP addresses to be used exclusively for classic Hangouts and Hangouts Meet in G Suite domains.

目前看到的資訊是:

IPv4: 74.125.250.0/24
IPv6: 2001:4860:4864:5::0/64

然後文章裡的說明是二月 14 日會變更:

Hangouts Meet and classic Hangouts will stop using the old IP address on February 14, 2019.

管理者可以調整關於這段 IP 的流量,通常是調高優先權?不過要調低也是可以...

台灣各 ISP 的 IPv6 使用情況

看到 zmx 提到:

所以 TWNIC 有弄了「Taiwan IPv6」這個網站頁面出來... 所以就 IPv6 使用率來說,中華不管是在固網還是在行動都是最早投入轉移,使用率也是最高的。

其他家行動的部份可以看出來都有在做,只是比率差異而已,但固網的部份扣掉中華後根本是 0%,雖然說其他固網的量偏小...

Vultr 推出 $3.5/m 的方案

Twitter 上看到 Vultr 推出了 USD$3.5/month 的方案:

這規格與價錢明顯就是對 Amazon Lightsail 的新方案反應...

最早的時候 Vultr 提供了 USD$2.5/month 的類似方案,但後來限制到只有紐約與邁阿密有,最近則是限制到只有 IPv6 address 沒有 IPv4 address (會需要靠 Cloudflare 這類服務幫忙 proxy),而且限制只能開兩台。

這次推出的方案跟 USD$2.5/month 的規格一樣,不過是有 IPv4 address,所以多了 USD$1/month。

Vultr 又開放 USD$2.5/month 的機器了,限制 IPv6 only...

今天被提到說 Vultr 開放 USD$2.5/month 的機器又開放了,但是限制 IPv6 only:

對於網站來說,可以在前面擋個 Cloudflare 之類的服務當作 IPv4 proxy 來解,應該是還不錯...

Facebook 觀察 IPv6 的使用情況

Facebook 是在六年前啟用了 IPv6 服務,然後分析了現在各地區 IPv6 使用的情況:「How IPv6 deployment is growing in U.S. and other countries」,另外提供了統計系統的資料給大家查 (不過看起來只有二月以後的?):「Facebook IPv6」。

然後被提到台灣區的成長在這幾個月很快速,主要原因是中華電信的導入:

We are also seeing countries and regions with less mature internet infrastructure start to transition to IPv6. Although overall deployment is still low, recent growth in some places has been exponential. Taiwan, for example, has gone from less than 1 percent in February 2018 to more than 10 percent as of May 28, 2018. Taiwan's rapid growth directly corresponds to recent IPv6 initiatives by Chunghwa, Taiwan's largest ISP.

先前在 Twitter 上有提到中華在 www.ipv6.hinet.net 網站上的跑馬燈有公告關於 IPv6 的導入,所以到這個月月底,使用比率應該都還會有明顯的提昇:

因為 Windows 7 以上的系統直接 PPPoE 的應該都會拿到 IPv6 address,但如果是 IP 分享器的就不一定支援了,不然應該會更高...

另外行動網路的部份也陸陸續續在轉移了,像我的 blog 上可以看到有 emome-ip6.hinet.net 的訪客,而且 Google 搜尋也可以看到一些資訊了:「"emome-ip6.hinet.net" - Google 搜尋」。

Cloudflare 推出 Spectrum:65535 個 TCP Port 都可以轉的 Proxy...

Cloudflare 推出了 Spectrum,文章標題提到的 65533 應該是指 80 & 443 以外其他的 port:「Introducing Spectrum: Extending Cloudflare To 65,533 More Ports」。

然後因為 TCP proxy 不像 HTTP proxy 與 WebSocket proxy 可以靠 Host header 資訊判斷,在 TCP proxy 需要獨占 IP address 使用 (i.e. 一個 IP address 只能給一個客戶用),而因為 IPv4 address 不夠的關係,這個功能只開放給 Enterprise 客戶用:

Today we are introducing Spectrum, which brings Cloudflare’s security and acceleration to the whole spectrum of TCP ports and protocols for our Enterprise customers.

雖然現在限定在 Enterprise 客戶,但 Cloudflare 還是希望看看有沒有其他想法,目前提出來的選項包括了開放 IPv6 address 給所有人用,或是變成獨立付費項目:

Why just Enterprise? While HTTP can use the Host header to identify services, TCP relies on each service having a unique IP address in order to identify it. Since IPv4 addresses are endangered, it’s quite expensive for us to delegate an IP per application and we needed to limit use. We’re actively thinking about ways to bring Spectrum to everyone. One idea is to offer IPv6-only Spectrum to non-Enterprise customers. Another idea is let anyone use Spectrum but pay for the IPv4 address. We’re not sure yet, but if you prefer one to the other, feel free to comment and let us know.

類似的產品應該是 clean pipe 類的服務,但一般 clean pipe 是透過 routing 重導清洗流量,而非像 Cloudflare 這樣設計... 不知道後續會有什麼樣的變化。

PChome 修正了問題,以及 RFC 4074 的說明

早些時候測試發現 PChome 已經修正了之前提到的問題:「PChome 24h 連線會慢的原因...」、「PChome 24h 連線會慢的原因... (續篇)」,這邊除了整理一下以外,也要修正之前文章裡的錯誤。

在 RFC 4074 (Common Misbehavior Against DNS Queries for IPv6 Addresses) 裡面提到了當你只有 IPv4 address 時,DNS server 要怎麼回應的問題。

在「3. Expected Behavior」說明了正確的作法,當只有 A RR 沒有 AAAA RR 的時候,應該要傳回 NOERROR,而 answer section 裡面不要放東西:

Suppose that an authoritative server has an A RR but has no AAAA RR for a host name. Then, the server should return a response to a query for an AAAA RR of the name with the response code (RCODE) being 0 (indicating no error) and with an empty answer section (see Sections 4.3.2 and 6.2.4 of [1]). Such a response indicates that there is at least one RR of a different type than AAAA for the queried name, and the stub resolver can then look for A RRs.

在「4.2. Return "Name Error"」裡提到,如果傳回 NXDOMAIN (3),表示查詢的這個名稱完全沒有 RR,而不僅僅限於 AAAA record,這就是我犯的錯誤 (在前面的文章建議傳回 NXDOMAIN):

This type of server returns a response with RCODE 3 ("Name Error") to a query for an AAAA RR, indicating that it does not have any RRs of any type for the queried name.

With this response, the stub resolver may immediately give up and never fall back. Even if the resolver retries with a query for an A RR, the negative response for the name has been cached in the caching server, and the caching server will simply return the negative response. As a result, the stub resolver considers this to be a fatal error in name resolution.

Several examples of this behavior are known to the authors. As of this writing, all have been fixed.

PChome 這次的修正回應了正確的值 (而不是我提到的 NXDOMAIN):

$ dig shopping.gs1.pchome.com.tw aaaa @ns1.gs1.pchome.com.tw

; <<>> DiG 9.9.5-3ubuntu0.16-Ubuntu <<>> shopping.gs1.pchome.com.tw aaaa @ns1.gs1.pchome.com.tw
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<<<- opcode: QUERY, status: NOERROR, id: 40767
;; flags: qr aa rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;shopping.gs1.pchome.com.tw.    IN      AAAA

;; AUTHORITY SECTION:
gs1.pchome.com.tw.      5       IN      SOA     ns1.gs1.pchome.com.tw. root.dns.pchome.com.tw. 20171123 3600 3 3600 5

;; Query time: 16 msec
;; SERVER: 210.242.216.91#53(210.242.216.91)
;; WHEN: Fri Nov 24 01:44:52 CST 2017
;; MSG SIZE  rcvd: 134

另外 RFC 也有一些其他的文件可以參考,像是 RFC 2308 (Negative Caching of DNS Queries (DNS NCACHE))、RFC 4697 (Observed DNS Resolution Misbehavior) 以及 RFC 8020 (NXDOMAIN: There Really Is Nothing Underneath),這些文件描述了蠻多常見的問題以及正確的處理方法,讀完對於現在愈來愈複雜的 DNS 架構有不少幫助。