- Trong các mạng ban đầu xoay quanh kết nối điểm-điểm, hầu như không cần hệ thống địa chỉ, nhưng khi mạng bus lan rộng để giảm chi phí, độ phức tạp như địa chỉ MAC, bridging và ARP dần chồng chất
- Khi Ethernet kết hợp với IP, việc chuyển tiếp tới next hop đòi hỏi gán địa chỉ MAC và broadcast ARP, và gánh nặng này phình to đáng kể trong các mạng liên kết quy mô lớn và wifi
- Ý tưởng IPv6 phản ánh kỳ vọng về một thế giới đơn giản hơn, nơi loại bỏ bus vật lý và layer 2 internetwork, đồng thời bỏ cả broadcast, ARP, DHCP và địa chỉ MAC
- Nhưng trong môi trường triển khai thực tế, IPv4 và framing cũ vẫn tồn tại, nên các di sản như neighbor discovery, DHCP, NAT và layer 2 bridging cũng tiếp tục được giữ lại
- Để duy trì kết nối khi di chuyển, người ta vẫn tiếp tục dùng layer 2 bridging và tunneling tập trung thay vì định tuyến Internet, còn các phương án như QUIC được nhắc tới như đường vòng cho roaming
Mạng bus đã trở thành nguyên nhân làm hỏng mọi thứ
- Trong môi trường chuyển mạch kênh ban đầu của mạng điện thoại và đường thuê riêng, chỉ có kết nối điểm-điểm, nên không cần hệ thống địa chỉ; các bit được đưa vào một đầu sẽ xuất hiện ở đầu kia sau một khoảng thời gian cố định
- Ngay cả sau khi TDM và chuyển mạch kênh ảo được đưa vào, từ góc nhìn người dùng vẫn chỉ là đầu vào bên này nối tới đầu ra bên kia, nên ở giai đoạn đó vẫn chưa cần địa chỉ
- Khi các máy tính có nhiều giao diện bắt đầu chuyển bit giữa các đường truyền, địa chỉ IP, subnet và routing mới xuất hiện, nhưng trên các liên kết điểm-điểm vẫn chưa cần địa chỉ MAC
- Để giảm chi phí kết nối trong cùng một site, mạng bus nối nhiều thiết bị vào một sợi dây xuất hiện, và song song với họ Internet, mỗi loại lại hình thành hệ layer 2 riêng của mình
- arcnet, một LAN đời đầu, yêu cầu cấu hình thủ công địa chỉ layer 2 8 bit bằng jumper hoặc công tắc DIP; trùng địa chỉ có thể gây sự cố nghiêm trọng, nhưng do mạng nhỏ nên sự bất tiện này còn hạn chế
- Ethernet giải quyết vấn đề trùng lặp bằng cách đưa vào địa chỉ MAC 48 bit, gần như duy nhất và được gán từ khâu sản xuất
- Các công nghệ LAN như IPX và Netware hoạt động tốt trong một mạng bus đơn mà gần như không cần cấu hình địa chỉ, và được mô tả như một thời kỳ đẹp đẽ, vận hành đáng tin cậy
- Các mạng doanh nghiệp lớn và đại học phải liên kết nhiều bus với nhau vì nút thắt cổ chai của một bus 10 Mbps duy nhất, nhưng thay vì chọn IP khi đó còn non nớt, họ mở rộng bằng bridging và switching dựa trên địa chỉ Ethernet
- Vì địa chỉ Ethernet được cấp tuần tự từ nhà máy nên không có cấu trúc phân cấp; bảng bridging vì vậy không thể gom nhóm hiệu quả như bảng định tuyến IP hiện đại xử lý theo subnet
- Để bridging hiệu quả, cần nhớ mỗi địa chỉ MAC đang nằm trên bus nào
- Để tránh cấu hình thủ công, hệ thống phải học tự động và kéo theo nhiều tương tác phức tạp
- Các mạng bridge phức tạp được nối với nhau bằng những cơ chế như spanning tree, kéo theo broadcast flood, đường đi không tối ưu và khả năng debug rất thấp
- Các bridge trung gian trong Ethernet thường không có khái niệm địa chỉ riêng, nên không thể tạo công cụ kiểu traceroute; bridging thực tế gần như là một kiến trúc không thể debug
- Dù vậy, nhờ tối ưu hóa phần cứng, bridging chạy rất nhanh, gần tốc độ đường truyền Ethernet, và đó là lợi thế lớn ở thời điểm đó
Internet chạy trên bus
- Từ mô hình nối từng máy tính riêng lẻ bằng các liên kết điểm-điểm đường dài, dần dần xuất hiện nhu cầu kết nối toàn bộ LAN, khiến việc nối các LAN với nhau qua khoảng cách xa trở nên cần thiết
- Bridging đường dài đơn thuần không khả thi vì vấn đề kiểm soát nghẽn; Ethernet bridging chỉ hoạt động khi mọi liên kết có tốc độ gần tương đương hoặc hầu như không có nghẽn
- Nối trực tiếp bằng bridging giữa Ethernet 10 Mbps và liên kết điểm-điểm 0.128 Mbps là vô vọng, còn cơ chế tìm đường dựa trên flooding thì quá lãng phí trên các liên kết chậm
- Định tuyến không tối ưu còn chấp nhận được trong môi trường cục bộ, nhưng trên các liên kết đường dài chậm và đắt thì trở thành thảm họa, nên không thể mở rộng
- Cụm vấn đề này vốn đã là lĩnh vực mà Internet xử lý, và nếu nối các bus LAN bằng công nghệ Internet thì cấu trúc sẽ tốt hơn nhiều
- Vì vậy, các định dạng frame để chở gói Internet trên LAN như Ethernet và arcnet đã được thiết kế, và từ đây vấn đề bắt đầu
- Nếu trong một segment Ethernet có nhiều router IP, ta phải phân biệt router nào sẽ nhận và chuyển tiếp gói, và chỉ địa chỉ IP đích cuối cùng là không đủ để biểu diễn lựa chọn đó
- Do đó, cần giữ đích cuối trong header IP, còn router next hop thực tế thì được chỉ định bằng địa chỉ MAC trong frame Ethernet
- Thông tin con người thực sự muốn biểu đạt là
gửi tới IP đích 10.1.1.1 qua MAC của router 11:22:33:44:55:66, nhưng hệ điều hành lại xử lý nó dưới dạng như đi qua IP router 192.168.1.1
- Để tạo ra lớp trừu tượng đó, hệ điều hành trước hết phải tìm địa chỉ Ethernet của IP router, và ARP được thêm vào như một bước trung gian
- ARP hoạt động bằng cách gửi broadcast tới toàn bộ Ethernet cục bộ để tìm thiết bị sở hữu một IP cụ thể; nếu có bridge, broadcast Ethernet này phải được chuyển tiếp qua mọi giao diện
- Trong các Ethernet liên kết quy mô lớn, broadcast quá mức trở thành một trong những cơn ác mộng lớn nhất, đặc biệt nghiêm trọng với wifi
- Về sau, bridge và switch bắt đầu thêm các mẹo đặc biệt để thu hẹp phạm vi truyền ARP; một số thiết bị, nhất là access point wifi, thậm chí còn tạo phản hồi ARP giả, nhưng tất cả đều chỉ là các kỹ xảo kỹ thuật
Chết bởi di sản
- Theo thời gian, các giao thức không phải IP trên Ethernet gần như biến mất, và mạng ổn định thành một cấu trúc gồm layer 2 kiểu bus trên đường truyền vật lý, bridge nối các bus đó, rồi router layer 3 đặt phía trên
- Khi việc cấu hình IP thủ công trở nên mệt mỏi, nhu cầu cấu hình tự động xuất hiện; nhưng thiết bị lúc này đã được xuất xưởng kèm địa chỉ Ethernet, còn địa chỉ IPv4 32 bit thì không đủ để gán vĩnh viễn duy nhất từ khâu sản xuất
- Nếu cấp phát địa chỉ IP theo kiểu tuần tự đơn giản thì lại quay về cấu trúc phi phân cấp như Ethernet, nên đó không phải lời giải phù hợp
- Vì vậy bootp và DHCP ra đời, và giống như ARP, chúng trở thành những giao thức cần được đối xử đặc biệt
- DHCP phải được một node chưa có địa chỉ IP gửi đi trước, nên buộc phải điền vào một header IP gần như vô nghĩa nhưng đúng định dạng RFC; máy chủ DHCP cũng phải tự điền phần này bằng raw socket thay vì dùng lớp IP trong kernel
- Cuối cùng, bootp và DHCP cũng cần biết địa chỉ Ethernet để cấp phát địa chỉ IP, nên chúng thực hiện vai trò gần như ngược với ARP
- Bài viết cũng nhắc rằng RARP làm việc tương tự theo cách đơn giản hơn, nhưng hầu như không bàn sâu ở đây
- Kết quả là Ethernet và IP ngày càng bị ràng buộc chặt tới mức ngày nay gần như không thể tách rời
- Bảng định tuyến IP trông như đang chỉ định router bằng địa chỉ IP, nhưng thực chất là chỉ định gián tiếp địa chỉ MAC; ARP đi qua bridge, còn DHCP trông giống gói IP nhưng thực chất lại gần với một giao thức Ethernet hơn
- Đồng thời, cả bridging lẫn routing đều trở nên phức tạp hơn; bridging phần lớn thuộc phạm vi IEEE và phần cứng, còn routing phần lớn thuộc IETF và phần mềm, mỗi bên gần như hành xử như thể bên kia không tồn tại
- Quản trị viên mạng lựa chọn giữa bridging và routing tùy theo yêu cầu tốc độ cũng như mức độ ngại cấu hình máy chủ DHCP; họ cố dùng bridging nhiều nhất có thể và chỉ dùng routing khi thật sự cần
- Sự phức tạp của bridging cuối cùng dẫn tới SDN, nơi quyết định layer 2 được kéo lên tầng trên và quản lý tập trung bằng giao thức chạy trên IP
- SDN vẫn tốt hơn việc để switch và bridge tự vận hành theo cách riêng, nhưng bài viết chỉ ra rằng điều này hơi trớ trêu, vì chính IP vốn đã là một mạng được định nghĩa bằng phần mềm để xử lý các mạng quá lớn
- IPv4 ban đầu khó tăng tốc bằng phần cứng và trên thực tế cũng chưa được tăng tốc đủ tốt; cấu hình DHCP lại rất phiền phức, nên các quản trị viên dần học cách bridge những phạm vi ngày càng lớn
- Các trung tâm dữ liệu lớn ngày nay được mô tả là vận hành gần như một mạng bus ảo khổng lồ dựa trên SDN, và trong nhiều trường hợp gói tin không thực sự được định tuyến
Giờ hãy tạm quên câu chuyện phía trên
- Khi IETF bắt đầu thiết kế IPv6 vào đầu những năm 1990, đã có rất nhiều hỗn loạn diễn ra, nhưng thiết kế vẫn tiến hành với giả định rằng có thể tránh được thảm họa sắp tới
- Một thay đổi cốt lõi trong quá trình đó là thực tế mạng bus vật lý gần như đã bị ngừng sử dụng
- Ethernet không còn là bus thật mà chỉ giả vờ là bus; khi tốc độ tăng tới mức không thể duy trì CSMA/CD, nó lại quay về topology hình sao
- Mô hình kéo cáp riêng từ từng trạm về switch trung tâm trở nên phổ biến, khiến tường, trần và sàn nhà đầy những bó cáp Ethernet lớn và đắt đỏ
- Ngay cả wifi, thứ trông như môi trường vô tuyến chia sẻ — tức bus tối thượng — trên thực tế cũng hầu như luôn hoạt động ở infrastructure mode để mô phỏng một topology hình sao khổng lồ
- Ngay cả hai trạm wifi kết nối cùng một access point cũng không giao tiếp trực tiếp; chúng gửi gói có chứa địa chỉ MAC của nút kia tới access point, rồi access point phát lại gói đó
- Khi node X gửi tới node Internet Z, qua router IP Y và access point wifi A, thì Z là đích IP, Y là đích Ethernet, còn A là đối tượng truyền vô tuyến thực tế, khiến các tầng địa chỉ chồng lấn đầy phức tạp
- Để làm được điều đó, 802.11 cung cấp 3-address mode để mang đồng thời đích Ethernet thực và đích Ethernet trung gian
- Đi kèm là các bit
to-AP và from-AP để chỉ hướng station→AP hoặc AP→station; khi cả hai bit đều đúng, nó còn có thể biểu diễn chế độ chuyển tiếp giữa các AP
- Nếu A là repeater và phải tiếp tục gửi sang trạm gốc B, thì chủ thể phát/thu trên sóng và nguồn/đích Ethernet đều khác nhau, nên cần 4-address mode
- 802.11s mesh thậm chí còn có tới 6-address mode, và bài viết nói rằng tới đó thì tác giả đã bỏ cuộc không cố hiểu nữa
Thế giới nơi IPv6 là một thiết kế tốt
- IETF khi suy nghĩ về IPv6 đã nhìn vào sự hỗn loạn đã có và cả sự hỗn loạn lớn hơn sắp tới, rồi tưởng tượng ra một thế giới mới vứt bỏ di sản cũ
- Giả định của thế giới đó là loại bỏ mạng bus vật lý, loại bỏ layer 2 internetwork, loại bỏ broadcast, loại bỏ địa chỉ MAC, loại bỏ ARP và DHCP, dùng header IP đơn giản có thể tăng tốc bằng phần cứng, giải quyết tình trạng cạn địa chỉ, và loại bỏ cấu hình IP thủ công ở mọi nơi trừ lõi mạng
- Nếu layer 2 luôn là điểm-điểm thì sẽ không có đối tượng nào để gửi broadcast, nên có thể thay bằng multicast; và vì bên gửi, bên nhận đã hiển nhiên nên địa chỉ MAC cũng trở nên không cần thiết
- Nếu địa chỉ MAC biến mất thì cũng không còn cần ánh xạ giữa IP và MAC, nên ARP và DHCP cũng có thể biến mất; đồng thời không gian địa chỉ đủ lớn để lại có thể định tuyến các subnet lớn
- Trong thế giới đó, wifi repeater, wifi access point, Ethernet switch và cả SDN đều sẽ hoạt động như router IPv6
- Khi ấy, ARP storm, IGMP snooping bridge và bridging loop sẽ biến mất, còn mọi vấn đề định tuyến đều có thể lần theo bằng traceroute
- Có thể loại bỏ 12 byte địa chỉ MAC nguồn/đích trong mỗi gói Ethernet và 18 byte thông tin địa chỉ trong mỗi gói wifi; vì vậy dù IPv6 dùng địa chỉ lớn hơn IPv4 thêm 24 byte, nếu tính cả việc bỏ header Ethernet thì phần overhead tăng thực tế chỉ còn 12 byte
- Bài viết cho rằng kỳ vọng một ngày nào đó có thể loại bỏ chính địa chỉ Ethernet đã giúp biện minh cho lựa chọn chiều dài địa chỉ IPv6 vốn bị xem là quá lớn
- Nhưng thiết kế đẹp đẽ đó đã không trở thành hiện thực trong thế giới thực
Khúc cầu hồn cho một giấc mơ
- Câu nói của một đồng nghiệp rằng “các tầng chỉ được thêm vào chứ không bao giờ bị gỡ bỏ” được đưa ra như kết luận tổng thể
- Ưu điểm của IPv6 chỉ có ý nghĩa nếu có thể bỏ toàn bộ di sản cũ và bắt đầu lại, nhưng trên thực tế điều đó gần như bất khả thi
- Ngay cả khi tỷ lệ phổ cập IPv6 đạt 99%, chừng nào IPv4 chưa biến mất hoàn toàn thì địa chỉ Ethernet và địa chỉ wifi cũng chưa thể biến mất; và miễn còn duy trì chuẩn framing IEEE 802.3 và 802.11 thì việc tiết kiệm số byte đó cũng không xảy ra
- Vì vậy IPv6 cuối cùng vẫn cần neighbor discovery còn phức tạp hơn ARP, và dù mạng bus đã biến mất, các mô phỏng kiểu broadcast vẫn phải tiếp tục để thực hiện hành vi giống ARP
- Trong gia đình, người ta vẫn phải vận hành máy chủ DHCP cục bộ để hỗ trợ các bóng đèn IPv4 cũ; và để bóng đèn đó chạm được Internet thì NAT cũng vẫn cần tồn tại
- Tệ hơn nữa, bài viết đánh giá rằng nhóm IPv6 đã bỏ lại bài toán mobile IP mà không giải quyết, khiến thứ bridging layer 2 khủng khiếp vẫn tiếp tục cần thiết
- Theo cách hiểu của tác giả, kế hoạch khi đó là triển khai IPv6 trước trong vài năm, rồi sau khi IPv4 và địa chỉ MAC biến mất sẽ giải quyết mobile IP dễ hơn
- Thời ấy, người ta cho rằng hầu như không có trường hợp dùng máy tính khi đang di chuyển, nên chỉ hình dung một cách khá gượng gạo cảnh mang máy qua lại giữa các cổng Ethernet mà vẫn giữ phiên ftp
Mobile IP, ứng dụng sát thủ
- Sau đó lịch sử lại cho thấy việc mang theo máy tính — tức điện thoại — và di chuyển giữa nhiều access point không dây đã trở thành chuyện thường ngày
- Trên LTE, kiểu di chuyển này phần lớn hoạt động; trên wifi thì đôi khi hoạt động, nhưng bí mật nằm không phải ở định tuyến Internet mà ở layer 2 bridging
- Định tuyến Internet hoàn toàn không xử lý được tính di động; nếu di chuyển trong mạng IP và địa chỉ IP đổi, mọi kết nối đang mở đều bị đứt
- Wifi doanh nghiệp bridge toàn bộ LAN ở layer 2 để máy chủ DHCP trung tâm luôn cấp cùng một địa chỉ IP bất kể bạn gắn vào access point nào, và kết nối được duy trì chỉ với vài giây hỗn loạn trong lúc bridge tái cấu hình
- Wifi gia đình với nhiều extender hoặc repeater cũng dùng cùng cách làm đó
- Ngược lại, nếu đi bộ ngoài đường và lần lượt dùng các mạng wifi khác nhau của từng cửa hàng, bạn sẽ nhận IP mới mỗi lần, và mọi kết nối đều bị cắt mỗi lần như vậy
- LTE còn đi xa hơn: bạn có thể di chuyển nhiều dặm giữa các trạm gốc mà vẫn giữ nguyên cùng một địa chỉ IP; bài viết cũng nhắc rằng mạng di động thường dùng địa chỉ IPv6
- Cách làm là tunnel lưu lượng về một điểm trung tâm rồi bridge nó, cùng với rất nhiều firewall, như một LAN layer 2 ảo khổng lồ duy nhất; cái giá phải trả là độ phức tạp khổng lồ và độ trễ tăng thêm tới mức đáng xấu hổ
- Các nhà mạng muốn sửa điều này, nhưng bài viết cho rằng gần như không thể
Cách để mobile IP thực sự hoạt động 1
- Câu trả lời cho việc vì sao mobile IP không hoạt động đúng được dẫn tới kết luận rằng định nghĩa nổi tiếng của 4-tuple dùng để nhận diện phiên là sai ngay từ đầu
- Phiên TCP và UDP được nhận diện bằng
(source ip, source port, destination ip, destination port), mà cấu trúc này lại băng ngang layer 3 và layer 4, nên rất dễ vỡ khi địa chỉ IP thay đổi
- Bài viết cho rằng nếu việc nhận diện phiên chỉ dựa trên dữ liệu layer 4 thì mobile IP đã có thể hoạt động hoàn hảo
- Ví dụ, khi X:1111 giao tiếp với Y:80, nếu X đổi địa chỉ sang Q thì gói trở thành
(Q,1111,Y,80); Y sẽ không còn nhận ra đó là phiên cũ và sẽ loại bỏ nó, còn gói trả về (Y,80,X,1111) cũng không thể tới X nữa
- Một phương án thay thế được nêu ra là mở rộng số hiệu cổng từ 16 bit hiện nay thành một giá trị băm duy nhất dài khoảng 128 hoặc 256 bit, và nhận diện socket bằng một thẻ không phụ thuộc địa chỉ IP
- Trong trường hợp đó, gói vẫn mang thông tin địa chỉ layer 3
(X,Y) để định tuyến, nhưng khi nhận, kernel không dùng thông tin layer 3 để nhận diện socket mà chỉ dùng uuid
- Cổng đích 80 chỉ còn cần để phân biệt dịch vụ mong muốn khi bắt đầu một phiên mới; sau đó nó có thể bị bỏ qua hoặc lược đi
- Kernel của Y sẽ cache rằng các gói phiên
(uuid) gần đây đến từ X; sau khi X chuyển sang Q và gửi tiếp với thẻ (uuid,80) giống cũ, Y có thể ghép nó vào đúng phiên và cập nhật đích phản hồi từ X sang Q
- Cách này giữ được kết nối, nhưng cần thêm biện pháp để ngăn kẻ mạo danh chiếm đoạt kết nối
- Tuy nhiên UDP và TCP không hoạt động như vậy, và việc thay đổi chúng bây giờ được mô tả là kiểu dự án từng tưởng dễ như đổi IPv4 sang IPv6, nhưng hàng chục năm sau vẫn chưa xong nổi quá một nửa
QUIC và khả năng đi đường vòng
- Ở phía tích cực hơn, bài viết cho rằng một lần vi phạm tầng nữa có thể mở ra giải pháp đường vòng
- Nếu bỏ TCP cũ kỹ và dùng QUIC chạy trên UDP, ta có thể không dùng 4-tuple của UDP làm định danh kết nối
- Nếu cổng UDP là cổng cho một mobility layer đặc biệt, phần bên trong có thể được giải mã tiếp thành các gói nội bộ mang thẻ uuid thích hợp rồi ánh xạ chúng vào đúng phiên và socket
- Bài viết nói rằng giao thức QUIC thử nghiệm ít nhất trên lý thuyết đã có định dạng gói phù hợp với kiểu kiến trúc này
- Vì cơ chế mã hóa và xác thực gói không trạng thái của QUIC vốn đã cần một định danh phiên hoặc khóa riêng, nên có thể bổ sung hỗ trợ roaming trong suốt với tương đối ít công sức
- Nếu làm được vậy, chỉ cần loại bỏ nốt UDP và TCP còn lại khỏi Internet, thì lần này layer 2 bridging sẽ thực sự không còn cần thiết, và broadcast, địa chỉ MAC, SDN lẫn DHCP cũng có thể bị loại bỏ
- Bài viết khép lại bằng cụm từ khôi phục sự thanh nhã của Internet
Chỉnh sửa bổ sung
-
Chỉnh sửa 2017-08-16
- Ý tưởng trước đó về mobile IP không chỉ giới hạn ở IPv6
- Đã sửa lại rằng nó cũng có thể hoạt động trong môi trường IPv4 và NAT, thậm chí roaming qua nhiều lớp NAT
-
Chỉnh sửa 2017-08-15
- Một ví dụ đơn giản nhất để ngăn chiếm đoạt kết nối là trao đổi kiểu SYN-ACK-SYNACK ở thời điểm khởi đầu TCP
- Nếu Y tin ngay gói đầu tiên từ host mới Q, thì kẻ tấn công ở bất cứ đâu trên Internet cũng có thể dễ dàng chiếm kết nối X→Y
- Nếu Y gửi cookie và Q phải nhận, xử lý rồi gửi lại cho Y, thì ít nhất kẻ tấn công phải ở mức man-in-the-middle mới có thể tấn công được
- Với các giao thức mã hóa như QUIC, bắt tay này cũng có thể được bảo vệ bằng khóa phiên
-
Chỉnh sửa 2017-10-24
- Ngoài QUIC còn có các ứng viên giao thức thay thế TCP hỗ trợ roaming kiểu này, và MinimaLT được nêu làm ví dụ
- Bài viết nói đã từng nghe rằng MinimaLT là giao thức đầu tiên giải quyết bài toán roaming một cách thanh nhã, và giải pháp được chấp nhận trong tương lai có thể sẽ mô phỏng cấu trúc đó
-
Chỉnh sửa 2020-07-09
- Chỉ có ghi chú rằng tác giả đã đăng thêm suy nghĩ về di trú và khả năng tương tác IPv4/IPv6 ở một bài khác, không có giải thích bổ sung nào trong nội dung bài này
1 bình luận
Ý kiến trên Hacker News
Theo quan điểm của tôi, IPv6 dù không hẳn là đỉnh cao của thiết kế giao thức hoàn hảo, nhưng các phương án thay thế mà mọi người đưa ra rồi cuối cùng cũng hội tụ về dạng khá giống IPv6. Nếu ai cũng liên tục không làm ra được thứ gì tốt hơn, thì rốt cuộc điều đó có nghĩa là IPv6 là một thiết kế khá ổn
Nếu gom lại các cuộc thảo luận Hacker News trước đây thì có thể thấy chủ đề này cứ lặp đi lặp lại theo chu kỳ vài năm, như thread năm 2017, thread năm 2019, thread năm 2020, thread năm 2023
Tôi không thích việc bài này nhìn ARP quá tiêu cực. Nhờ ARP mà có thể làm IP networking trong LAN mà không cần router, và default gateway cũng có thể được xem như một trường hợp đặc biệt của giao tiếp IP LAN thông thường. Dù vậy, phần giải thích lịch sử networking thì thật sự rất xuất sắc, và tôi vẫn đang đọc tiếp phần IPv6
Tôi hơi bối rối không rõ chính xác bài này đang muốn nói gì. Có phải ý là các thiết bị mạng của tôi tự gán địa chỉ IPv6 dựa trên địa chỉ MAC, và đó là cốt lõi của stateless IPv6 không? Theo tôi biết, IPv6 cũng ra đời để giải quyết sự cạn kiệt IPv4 và các vấn đề của NAT. Nhưng Xbox của tôi lại nói mạng kém nếu không có IPv6, điều này cũng mang cảm giác khá thiên về Bắc Mỹ
Tôi ngày càng cảm thấy việc IPv6 có cả SLAAC lẫn DHCPv6 là một sai lầm lớn. Bản thân SLAAC thì rất tốt, nhưng có hai cơ chế cấu hình thì quá dễ gây rối. Việc Android không hỗ trợ DHCPv6 càng làm mọi thứ khó hiểu hơn. Tôi đoán SLAAC là sản phẩm của thời kỳ máy tính đắt đỏ và DHCP server là một thiết bị riêng. Nhưng giờ máy tính đã rẻ và hầu hết router đều có thể chạy DHCP, nên bối cảnh đã khác. Nếu DHCPv6 mặc định đi theo hướng cấp phát địa chỉ dựa trên MAC thì có lẽ cấu hình đã đơn giản hơn, còn tự động cấu hình trong link-local vẫn có thể được giữ nguyên
Tôi thấy bài này rất thú vị, nhưng có một chỗ tôi không hiểu lắm. Tác giả nói rằng ngay cả trên WiFi giờ cũng không còn dùng CSMA/CD, vậy thực tế nó vận hành thế nào? Tác giả giải thích rằng ngay cả hai trạm WiFi cùng kết nối vào một access point cũng không giao tiếp trực tiếp với nhau. Nếu vậy thì đến một thời điểm nào đó, mỗi trạm vẫn phải phân biệt được tín hiệu mà nó nghe thấy là của chính nó, của trạm khác gửi lên AP, hay của AP gửi tới trạm khác. Nếu thế thì chẳng phải vẫn cần một cơ chế tương tự, chỉ là tên khác đi thôi sao?
Trước đây IPv6 từng có vẻ như là bước tiếp theo không thể tránh khỏi, nhưng nhìn tình trạng hụt hơi như hiện nay thì tôi lại nghĩ liệu vấn đề mà nó định giải quyết từ đầu có thật sự quan trọng đến thế không. Từ góc nhìn người dùng thực tế thì dù sao người ta vẫn xoay xở để có đủ địa chỉ IPv4 và Internet vẫn tiếp tục chạy, nên tôi tự hỏi liệu IPv6 có thật sự cần thiết hay không. Không biết kết luận này có sai không