IPv6 Zones trong URL thực sự là một sai lầm

IPv6 là một giao thức mạng đầy thú vị nhưng cũng chứa đựng những điểm kỳ quặc khiến các lập trình viên phải đau đầu. Một trong những khía cạnh khó chịu nhất chính là cách xử lý IPv6 zones (phạm vi) bên trong các URL, một thiết kế mà nhiều người cho rằng là một sai lầm.

Vấn đề về địa chỉ Link-local

Điểm kỳ lạ nhất của tiêu chuẩn IPv6 nằm ở việc mọi giao diện mạng đều sở hữu địa chỉ link-local trong dải fe80::/10. Nếu một máy chủ có hai card mạng, cả hai đều sẽ có địa chỉ bắt đầu bằng fe80::. Vậy, khi bạn gửi một gói tin đến fe80::4, hệ thống làm thế nào để biết gói tin đó nên đi qua card mạng nào?

Câu trả lời nằm ở việc sử dụng IPv6 scopes hoặc zones. Định dạng chính xác của phần zone này phụ thuộc vào hệ điều hành: trên Linux, đó là tên giao diện mạng (ví dụ: eth0), còn trên Windows, đó là ID của giao diện. Điều này cho phép bảng định tuyến (routing table) của kernel biết cách xử lý xung đột địa chỉ.

Trên máy tính của tôi, địa chỉ này sẽ được biểu diễn như sau:

fe80::4%eth0

Trong đó, eth0 là tên thiết bị ethernet.

Rắc rối với cú pháp URL

Thông thường, khi tạo một bind host host:port, người ta dùng dấu hai chấm để phân tách. Tuy nhiên, IPv6 cũng dùng dấu hai chấm để phân tách các nhóm hex. Để tránh nhầm lẫn, địa chỉ IPv6 trong URL thường được đặt trong dấu ngoặc vuông. Ví dụ, fe80::4 trên cổng 80 sẽ là:

[fe80::4]:80

Và khi thêm zone vào, nó trông như thế này:

[fe80::4%eth0]:80

Vấn đề phát sinh khi chúng ta kết hợp điều này với quy tắc mã hóa URL. Về mặt lý thuyết, một zone sẽ là một phần của hostname. Bạn có thể nghĩ URL sẽ là:

http://[fe80::4%eth0]:80

Tuy nhiên, nếu bạn thử phân tích chuỗi này bằng ngôn ngữ lập trình Go, bạn sẽ gặp lỗi ngay lập tức.

Cái bẫy của Percent-encoding

Lỗi xảy ra vì URL không thể biểu diễn trực tiếp tất cả các giá trị Unicode. Các ký tự không phù hợp với ngữ pháp của URL phải được percent-encoded (mã hóa phần trăm). Dấu % chính là ký tự đặc biệt dùng để báo hiệu việc mã hóa này (ví dụ %20 cho dấu cách).

Do đó, khi trình phân tích URL gặp %eth0, nó cố gắng giải mã nó như một chuỗi thoát (escape sequence) và thất bại vì et không phải là một mã hex hợp lệ.

Để khắc phục, bạn phải mã hóa chính ký tự % trong zone ID thành %25. URL đúng chuẩn sẽ trở thành:

http://[fe80::4%25eth0]:80

Mặc dù RFC 6874 quy định rõ ràng rằng đây là cách làm đúng đắn (IPv6addrz = IPv6address "%25" ZoneID), nhưng thực tế này gây ra trải nghiệm người dùng (UX) cực kỳ tệ cho một trường hợp ngoại lệ.

Không chỉ là vấn đề của Go

Sự phiền toái này không giới hạn ở Go hay thư viện net/url. Nhiều framework và thư viện phổ biến khác như Nginx hay Python Requests cũng gặp phải vấn đề tương tự khi xử lý IPv6 zones. Thậm chí, các trình duyệt web hiện tại cũng không hỗ trợ đầy đủ tính năng này vì nó phá vỡ khái niệm "origin" – một nền tảng quan trọng trong bảo mật web.

Trong tương lai, có thể sẽ có giải pháp tốt hơn thông qua các bản nháp RFC mới. Nhưng cho đến lúc đó, việc phải nhớ mã hóa kép % thành %25 là một gánh nặng nhỏ nhưng đủ gây ức chế cho bất kỳ ai làm việc với mạng và lập trình hệ thống.

Tóm lại, đôi khi những thiết kế tiêu chuẩn phức tạp khiến chúng ta tự hỏi liệu máy tính có thực sự là một ý tưởng hay không.