22/04/2026
IPv8 : 8.8.8.8.8.8.8.8
# IPv8: Đề xuất "viết lại" Internet, gói IPv4 vào trong 64-bit
*Một bản Internet-Draft được nộp lên IETF vào 14/04/2026 đang gây tranh cãi dữ dội. Nó hứa hẹn giải quyết cùng lúc cả chuyện cạn IPv4, bảng routing toàn cầu phình to, lẫn sự phân mảnh của management plane - nhưng cũng đặt ra những câu hỏi rất lớn về quyền riêng tư.*
https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
# # Bối cảnh: vì sao lại có IPv8?
Sau 25 năm kể từ khi IPv6 được chuẩn hoá, phần lớn lưu lượng internet toàn cầu **vẫn chạy trên IPv4**. Dual-stack mệt mỏi, NAT chồng NAT, IPv6 adoption ì ạch ở nhiều quốc gia. Bảng BGP toàn cầu đã vượt 1 triệu prefix và tiếp tục phình to mỗi năm. Management plane thì phân mảnh - DHCP một nơi, DNS một nơi, AAA một nơi, SIEM một nơi, NTP một nơi.
Vào ngày 14 tháng 4 năm 2026, **Jamie Thain** của One Limited (một công ty đặt tại Bermuda) nộp lên IETF bản Internet-Draft mang tên `draft-thain-ipv8-00`, đề xuất một cách tiếp cận hoàn toàn khác: thay vì chạy song song một giao thức mới, hãy **mở rộng IPv4 thành 64-bit** và đóng gói toàn bộ management plane vào một nền tảng duy nhất gọi là Zone Server.
Đây không phải là sản phẩm của một Working Group trong IETF. Đây là **individual submission** - tức một cá nhân (hoặc một công ty) tự đề xuất, chưa qua quy trình đồng thuận nào của IETF.
---
# # Địa chỉ 64-bit: r.r.r.r.n.n.n.n
Địa chỉ IPv8 dài 64 bit, được chia làm hai phần 32-bit:
```
r.r.r.r . n.n.n.n
│ │
│ └── Host address (32 bit, giống hệt IPv4)
└── Routing prefix = ASN của tổ chức sở hữu (32 bit)
```
Logic này tạo ra một hệ quả rất thú vị: **IPv4 là một tập con thực sự của IPv8**. Khi routing prefix `r.r.r.r = 0.0.0.0`, địa chỉ đó được xử lý y hệt IPv4 thông thường. Nói cách khác, mọi thiết bị IPv4 hiện tại đã và đang sử dụng địa chỉ IPv8 hợp lệ mà không cần biết điều đó.
Đây chính là khác biệt lớn nhất so với IPv6. Thay vì bắt cả thế giới "chạy song song hai protocol" (dual-stack), IPv8 đóng gói IPv4 vào trong mình. Không có "flag day", không có migration bắt buộc ở bất kỳ tầng nào, không cần thay socket API.
# # # Hệ quả về không gian địa chỉ
Mỗi tổ chức sở hữu ASN sẽ nhận được **4.294.967.296 địa chỉ host** (toàn bộ không gian IPv4 cho riêng mình). Với khoảng 100.000 ASN hoạt động trên internet, tổng không gian là đủ dùng ở mức không tưởng cho tương lai thấy được.
# # # Hệ quả về routing table toàn cầu
Đây là phần "ảo diệu" nhất về mặt kỹ thuật. Vì mỗi ASN chỉ quảng bá **một prefix duy nhất** (chính là ASN của nó), bảng BGP8 toàn cầu **bị giới hạn về cấu trúc ở mức một entry cho mỗi ASN** - thay vì phình to theo số prefix như hiện nay. Deaggregation và prefix hijacking bị vô hiệu hoá ở tầng kiến trúc.
---
# # Cấu trúc header: bảo thủ có chủ đích
Header IPv8 không "đập đi xây lại" như IPv6. Nó giữ nguyên toàn bộ các field của IPv4, chỉ thay field địa chỉ 32-bit bằng field 64-bit:
- `Version = 8` (4 bit)
- IHL, Type of Service, Total Length, Identification, Flags, Fragment Offset, TTL, Protocol, Checksum - **giống hệt IPv4**
- Source/Destination ASN Prefix: 32 bit × 2 (mới)
- Source/Destination Host Address: 32 bit × 2 (mới)
Header chỉ lớn hơn IPv4 đúng **8 octet**. Chi phí triển khai stack được giữ ở mức rất thấp so với sự đột phá của IPv6.
---
# # Zone Server: trái tim của IPv8
Đây mới là phần gây bão nhất. IPv8 không chỉ là một giao thức lớp 3 - nó là cả **một hệ quản trị mạng**. Zone Server là nền tảng active/active gộp chung mọi dịch vụ management vào một chỗ:
| Dịch vụ truyền thống | Trong IPv8 |
|---|---|
| DHCP | **DHCP8** - một lease response trả về tất cả mọi thứ thiết bị cần |
| DNS | **DNS8** - có A8 record cho 64-bit |
| RADIUS/TACACS+/AD | **OAuth8** - cache JWT local |
| Syslog/SIEM | **NetLog8** - telemetry chuẩn hoá |
| NTP | **NTP8** |
| ACL | **ACL8** |
| WHOIS | **WHOIS8** - trở thành critical infrastructure |
| NAT64/464XLAT | **XLATE8** |
Ý tưởng: thay vì mua, cấu hình, vận hành một chục sản phẩm khác nhau từ mười vendor khác nhau, bạn triển khai một Zone Server là xong. Mỗi thiết bị khi cắm vào mạng sẽ nhận được một lease chứa toàn bộ cấu hình - địa chỉ, DNS, NTP, OAuth endpoint, ACL policy, logging endpoint.
---
# # Validation bắt buộc ở egress
Đây là điểm mà dân networking chia làm hai phe rõ rệt. IPv8 quy định rằng **mọi packet đi ra internet đều phải được validate tại egress**:
1. Thiết bị phải **auth bằng OAuth2 JWT** trước khi gửi packet đầu tiên. Không có JWT hợp lệ = không có packet nào đi ra. Anonymous IP-level connection **không còn tồn tại**.
2. Mỗi kết nối ra ngoài phải đi kèm **một DNS8 lookup hợp lệ**. Không có hardcode IP.
3. Destination ASN phải được **WHOIS8 verify là đang active**. Không có rogue routing.
4. Nếu một trong ba điều kiện trên không thoả, connection bị **terminate ngay tại border router**.
Tác dụng kỹ thuật: malware C2 cắm hardcode IP bị chặn ở tầng protocol. Bogon filter không cần maintain thủ công. BGP hijack bị vô hiệu hoá vì route không install được nếu WHOIS8 không validate.
**Tác dụng phụ** (tuỳ góc nhìn): Tor bị chặn. VPN không qua DNS bị chặn. Bất kỳ protocol nào không bắt đầu bằng một DNS lookup đều không chạy được. Dân giấu tung tích trên mạng gần như không còn đường.
---
# # Tranh cãi: đây là đột phá hay là giám sát toàn diện?
Cộng đồng networking phản ứng rất mạnh với draft này. Các luận điểm chính:
**Ủng hộ:**
- Giải quyết cùng lúc nhiều vấn đề mà IPv6 không đụng tới (management plane, BGP table size, security built-in).
- Backward compatible thật sự - không cần flag day.
- Header extension tối thiểu, chi phí implement thấp.
- Cloud provider sẽ thích ý tưởng mỗi VPC có prefix riêng (127.x.x.x zone) để tránh RFC1918 collision.
**Phản đối:**
- Mô hình "mọi packet phải qua Zone Server validate" biến internet thành một mạng có giám sát toàn diện. Anonymity ở tầng IP biến mất.
- Mandatory NetLog8 logging nghĩa là **mọi traffic đều được ghi lại theo chuẩn**. Đây là giấc mơ của các chính phủ độc tài.
- Một ISP ở Bermuda tự viết ra cả một bộ giao thức (IPv8, BGP8, OSPF8, DHCP8, DNS8, WHOIS8, NetLog8, WiFi8, Update8, Zone Server, RINE...) không qua bất kỳ quy trình đồng thuận nào của IETF - đây là cờ đỏ về mặt quy trình chuẩn hoá.
- Một số nhận xét trên Hacker News và LowEndTalk cho rằng toàn bộ bản draft có dấu hiệu được viết bằng LLM trong một thời gian rất ngắn.
- IPv6 đã có sẵn cơ chế `::ffff:a.b.c.d` để biểu diễn IPv4 trong không gian IPv6. Nếu chỉ cần backward compatibility thì IPv6 đã có rồi - lý do thật sự khiến IPv6 không được adoption không phải là technical.
---
# # Khả năng được áp dụng trong thực tế
Thẳng thắn mà nói: **gần bằng không**.
Lý do:
1. **Quy trình IETF**: IPv6 được hình thành qua so sánh nhiều proposal cạnh tranh trong một WG chính thức, rồi đồng thuận chọn một dẫn xuất của SIPP. IPv8 chỉ là individual submission, chưa có WG nào được thành lập.
2. **Momentum**: IPv4 vẫn chạy, IPv6 đã có hạ tầng 25 năm. Để chuyển sang một giao thức thứ ba - dù là "siêu tập" của IPv4 - cần một cú hích kinh tế hoặc chính trị mà hiện chưa thấy đâu.
3. **Phản kháng chính trị**: Những nước bảo vệ quyền riêng tư sẽ chặn bất kỳ nỗ lực nào chuẩn hoá một giao thức mà mọi packet đều được WHOIS-validate và log lại.
4. **Số lượng spec phụ thuộc**: Bản thân `draft-thain-ipv8-00` kéo theo hơn chục draft companion (routing-protocols, rine, zoneserver, whois8, netlog8, support8, mib, wifi8, update8). Để làm cho IPv8 thật sự chạy được cần hiện thực hoá toàn bộ chuỗi này.
Internet-Draft sẽ hết hạn vào **16/10/2026**, sau đó hoặc được update, extend, hoặc lặng lẽ biến mất. Hiện đã có phiên bản `-01` và `-02`, cho thấy tác giả đang tiếp tục refine. Một implementation tham chiếu bằng Zig cũng đã xuất hiện trên GitHub, nhưng phạm vi còn rất hạn chế.
---
# # Điểm đáng học từ IPv8
Kể cả nếu IPv8 không bao giờ trở thành chuẩn, cách đặt vấn đề của nó rất đáng suy ngẫm cho bất kỳ ai làm kiến trúc mạng:
- **IPv6 thất bại ở tầng kinh tế, không phải tầng kỹ thuật.** Bài học: một giao thức tương thích ngược thật sự sẽ đi xa hơn một giao thức "đúng về mặt kỹ thuật" nhưng yêu cầu dual-stack.
- **Management plane phân mảnh là gánh nặng vận hành lớn nhất của mạng doanh nghiệp ngày nay.** Bạn có thể đã cảm nhận điều này khi cấu hình FortiGate, vì phải phối hợp nhiều hệ thống rời rạc chỉ để nói cho một thiết bị biết nó là ai, ở đâu, được làm gì, và log về đâu.
- **Security-by-default ở tầng IP là con dao hai lưỡi.** Nó bảo vệ người dùng khỏi malware nhưng cũng cắt đứt khả năng thoát khỏi kiểm duyệt.
Dù bản draft này cuối cùng có đi đến đâu, nó cũng đặt ra một câu hỏi quan trọng mà cộng đồng networking sẽ phải trả lời trong thập kỷ tới: **liệu internet có nên tiếp tục là "dumb pipe" trung lập, hay nó cần tiến hoá thành một mạng có quản lý?**
---
*Tham khảo: [draft-thain-ipv8-00 trên IETF Datatracker](https://datatracker.ietf.org/doc/draft-thain-ipv8/), thảo luận trên Hacker News, LowEndTalk, The Network DNA, và lilting.ch.*