Thế giới nơi IPv6 từng là một thiết kế tuyệt vời (2017)
(apenwarr.ca)- Trong các mạng ban đầu chủ yếu dựa trên kết nối điểm-điểm, hầu như không cần một hệ thống địa chỉ, nhưng khi mạng bus lan rộng để tiết kiệm chi phí, độ phức tạp như địa chỉ MAC, bridging và ARP bắt đầu tích tụ
- Khi Ethernet và IP được kết hợp, việc chuyển tiếp tới next hop đòi hỏi định địa chỉ MAC và broadcast ARP, và gánh nặng này phình to đặc biệt trong các mạng liên kết quy mô lớn và wifi
- Ý tưởng về IPv6 phản ánh kỳ vọng vào một thế giới đơn giản hơn: loại bỏ bus vật lý và layer 2 internetwork, đồng thời bỏ luôn broadcast, ARP, DHCP và địa chỉ MAC
- Tuy nhiên trong môi trường triển khai thực tế, IPv4 và framing cũ vẫn tiếp tục tồn tại, kéo theo cả các di sản như neighbor discovery, DHCP, NAT và layer 2 bridging
- Để 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ì Internet routing, còn các lựa chọn như QUIC được nhắc tới như một đường vòng cho roaming
Mạng bus đã làm hỏng mọi thứ như thế nào
- Trong môi trường chuyển mạch kênh ban đầu của mạng điện thoại và các đường thuê riêng, chỉ tồn tại 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 bên kia sau một khoảng thời gian nhất đị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 là dạng đầu vào một phía nối với đầu ra phía kia, và ở giai đoạn này vẫn chưa cần địa chỉ
- Khi các máy tính có nhiều giao diện chuyển tiếp bit giữa các đường truyền, địa chỉ IP, subnet và routing xuất hiện, nhưng trên các liên kết điểm-điểm thì vẫn chưa cần địa chỉ MAC
- Để giảm chi phí kết nối trong phạm vi cục bộ, mạng bus gắn nhiều thiết bị lên cùng một sợi dây đã ra đời, và song song với họ Internet, mỗi bên lại hình thành các hệ layer 2 riêng
- LAN đời đầu là arcnet yêu cầu cấu hình thủ công địa chỉ layer 2 8-bit bằng jumper hoặc DIP switch; trùng địa chỉ có thể gây sự cố nghiêm trọng, nhưng vì mạng còn nhỏ nên bất tiện này vẫn trong mức chịu được
- Ethernet đưa ra địa chỉ MAC 48-bit, giải quyết vấn đề trùng lặp bằng cách gán địa chỉ gần như duy nhất ngay từ giai đoạn 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à không cần cấu hình địa chỉ, và được mô tả là một giai đoạn đẹp đẽ, đáng tin cậy
- Các mạng doanh nghiệp lớn và trường đại học phải liên kết nhiều bus do nút thắt của một bus 10 Mbps duy nhất, nhưng thay vì IP khi đó còn chưa trưởng thành, họ chọn 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ại nhà máy nên không có tính phân cấp; bảng bridging không thể gom nhóm hiệu quả như bảng routing IP hiện đại xử lý đường đi theo đơn vị subnet
- Để bridging hiệu quả, cần nhớ mỗi địa chỉ MAC nằm trên bus nào
- Để tránh cấu hình thủ công điều này, cần cơ chế học tự động và 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 kém
- Các bridge trung gian không có khái niệm địa chỉ như trên Ethernet thông thường nên không thể tạo công cụ kiểu traceroute; trên thực tế bridging gần như là cấu trúc không thể debug nổi
- Dù vậy, nhờ tối ưu hóa phần cứng, bridging chạy rất nhanh, gần với wire speed của Ethernet, và đó từng là ưu điểm lớn vào thời điểm ấy
Internet chạy trên bus
- Từ cấu trúc kết nối từng máy tính bằng các liên kết điểm-điểm đường dài, nhu cầu dần chuyển sang kết nối cả LAN, khiến việc liên kết đường dài giữa các LAN trở nên cần thiết
- Bridging đường dài đơn giản không khả thi vì vấn đề điều khiển tắc nghẽn; bridging Ethernet chỉ hoạt động khi mọi liên kết có tốc độ tương tự hoặc gần như không có nghẽn mạng
- 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 việc tìm đường dựa trên flooding lại quá lãng phí trên đường truyền chậm
- Routing không tối ưu có thể còn chịu đượ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ì là chí mạng, nên không thể mở rộng
- Đây vốn là nhóm vấn đề mà Internet đã xử lý từ trước, và việc nối các bus LAN bằng công nghệ Internet có thể cho ra cấu trúc tốt hơn nhiều
- Vì thế các định dạng frame để chở gói Internet trên LAN như Ethernet và arcnet được thiết kế, và đây là điểm mọi rắc rối bắt đầu
- Khi có nhiều IP router trong cùng một segment Ethernet, cần phân biệt router nào sẽ nhận và chuyển tiếp gói; chỉ địa chỉ IP đích cuối cùng là không đủ để biểu diễn lựa chọn này
- Do đó cần giữ đích cuối trong IP header, còn next hop router thực tế thì chỉ định bằng địa chỉ MAC của frame Ethernet
- Thông tin thực mà con người muốn diễn đạt là
gửi tới IP đích 10.1.1.1 qua MAC 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 tiên 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 broadcast ra toàn bộ Ethernet cục bộ để tìm chủ sở hữu của một IP cụ thể; nếu có bridge thì vì đó là broadcast Ethernet, nó phải được chuyển ra mọi giao diện
- Trên các Ethernet liên kết 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 trên wifi
- Về sau bridge và switch bắt đầu thêm các thủ thuật đặc biệt để giảm phạm vi chuyển tiếp ARP; một số thiết bị, nhất là access point wifi, còn tạo cả phản hồi ARP giả, nhưng tất cả đều gần như những cú hack kỹ thuật
Chết vì 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 được cố định thành một cấu trúc gồm layer 2 kiểu bus trên dây vật lý, các bridge nối những bus đó lại, và router layer 3 đặt ở phía trên
- Khi việc cấu hình IP thủ công trở nên quá mệt mỏi, nhu cầu tự động cấu hình xuất hiện; nhưng thiết bị thì đã xuất xưởng kèm địa chỉ Ethernet, còn địa chỉ IPv4 32-bit lại không đủ để gán duy nhất vĩnh viễn ngay từ giai đoạn sản xuất
- Nếu chỉ cấp IP tuần tự đơn giản thì lại quay về cấu trúc phi phân cấp kiểu Ethernet, nên đó không phải lời giải phù hợp
- Vì vậy bootp và DHCP xuất hiện, và giống như ARP, chúng trở thành những giao thức cần được đối xử đặc biệt
- Vì DHCP phải được gửi đi trước khi node có địa chỉ IP, nó buộc phải nhồi vào một IP header về thực chất là vô nghĩa nhưng đúng theo RFC; DHCP server cũng phải tự điền trực tiếp phần này bằng raw socket thay vì dùng IP stack trong kernel
- bootp và DHCP rốt cuộc vẫn cần biết địa chỉ Ethernet để cấp địa chỉ IP, nên chúng gần như đóng vai trò ngược của ARP
- Dù RARP làm cùng việc đó đơn giản hơn, bài viết nói rằng ở đây gần như không bàn đến nó
- Kết quả là Ethernet và IP ngày càng bị trói chặt vào nhau, đến mức ngày nay gần như không thể tách rời
- Bảng routing IP trông như đang chỉ định router bằng địa chỉ IP, nhưng thực tế là đang gián tiếp chỉ định địa chỉ MAC; ARP thì đi qua bridge, còn DHCP tuy trông như gói IP nhưng về bản chất lại gần với một giao thức Ethernet hơn
- Đồng thời cả bridging và routing đều trở nên phức tạp hơn; bridging chủ yếu thuộc thế giới IEEE và phần cứng, còn routing chủ yếu thuộc IETF và phần mềm, và hai bên xử lý như thể phía kia không tồn tại
- Nhà vận hành mạng chọn giữa bridging và routing tùy theo nhu cầu tốc độ và mức độ ngại cấu hình DHCP server, thường cố dùng bridging nhiều nhất có thể và chỉ routing khi thật sự cần
- Độ phức tạp của bridging cuối cùng dẫn tới SDN, nơi các quyết định layer 2 được kéo lên tầng cao hơn để quản lý tập trung bằng giao thức chạy trên IP
- SDN tốt hơn việc switch và bridge tự vận hành hỗn loạn, nhưng tác giả chỉ ra rằng điều đó cũng có phần trớ trêu, vì IP vốn dĩ đã là một mạng được định nghĩa bằng phần mềm dùng để xử lý một hệ thống đã phình to vượt tầm
- IPv4 ban đầu khó tăng tốc bằng phần cứng và trên thực tế cũng không được tăng tốc đủ tốt; cấu hình DHCP thì rất phiền phức, nên nhà vận hành ngày càng học cách bridging những miền lớn hơn nữa
- Các data center lớn ngày nay được mô tả như mạng bus ảo khổng lồ dựa trên SDN, và trong nhiều trường hợp gần như không thật sự routing gói tin
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 thập niên 1990, rất nhiều hỗn loạn đã xảy ra, nhưng việc thiết kế vẫn dựa trên giả định rằng có thể tránh được thảm họa đang tới
- Một thay đổi cốt lõi khi đó là việc dùng mạng bus vật lý trên thực tế đã gần như chấm dứt
- Ethernet không còn là bus thực nữa mà chỉ giả vờ là bus; khi tốc độ tăng đến mức không thể duy trì CSMA/CD, nó lại quay về topo hình sao
- Mô hình kéo cáp riêng từ từng trạm tới switch trung tâm trở nên phổ biến, khiến tường, trần và sàn đầy những bó cáp Ethernet lớn và đắt đỏ
- Ngay cả wifi, trông như môi trường vô tuyến chia sẻ là dạng bus tối hậu, trên thực tế cũng gần như luôn mô phỏng một topo sao khổng lồ bằng infrastructure mode
- Ngay cả hai trạm wifi nối vào cùng một access point cũng không giao tiếp trực tiếp; chúng gửi gói có địa chỉ MAC của đối phương tới access point, rồi access point phát lại
- Nếu node X gửi tới Internet node Z qua IP router Y và wifi access point 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ế, tạo ra nhiều tầng địa chỉ chồng chéo phức tạp
- Để làm được điều này, 802.11 cung cấp 3-address mode để chứa cả đích Ethernet thực và đích Ethernet trung gian
- Nó còn có các bit
to-AP,from-APđể biểu thị chiều trạm→AP và AP→trạm; nếu cả hai bit cùng đúng thì còn có thể biểu diễn hoạt động chuyển tiếp giữa các AP - Nếu A là repeater và phải gửi tiếp tới trạm gốc B, thì chủ thể gửi/nhận thật trên không trung cùng với Ethernet source/destination đều khác nhau, nên cần đến 4-address mode
- 802.11s mesh thậm chí có tới 6-address mode, và tác giả viết rằng đến mức đó thì đành bỏ cuộc không cố hiểu thêm 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 mớ hỗn loạn đã xảy ra và sẽ còn nghiêm trọng hơn, rồi tưởng tượng ra một thế giới mới bỏ lại toàn 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, có một IP header đơn giản có thể tăng tốc bằng phần cứng, giải quyết cạn kiệt địa chỉ, và loại bỏ cấu hình IP thủ công ở mọi nơi trừ phần lõi
- Nếu layer 2 luôn là điểm-điểm thì không còn đối tượng để gửi broadcast, nên có thể thay bằng multicast; và vì đối tác gửi/nhận đã hiển nhiên, địa chỉ MAC cũng trở nên không cần thiết
- Khi địa chỉ MAC biến mất thì cũng không còn nhu cầu ánh xạ giữa IP và MAC, do đó ARP và DHCP cũng có thể biến mất; đồng thời sẽ có đủ không gian địa chỉ để lại có thể dùng routing theo subnet lớn
- Trong thế giới ấy, wifi repeater, wifi access point, Ethernet switch và cả SDN đều sẽ hoạt động như IPv6 router
- Khi đó ARP storm, bridge có IGMP snooping, và bridging loop sẽ biến mất, còn mọi vấn đề routing đều có thể lần theo bằng traceroute
- Mỗi gói Ethernet có thể bỏ 12 byte địa chỉ MAC nguồn/đích, mỗi gói wifi có thể bỏ 18 byte thông tin địa chỉ; vì vậy dù IPv6 dùng địa chỉ lớn hơn IPv4 24 byte, nếu bỏ được Ethernet header thì phần overhead tăng thêm thực chất chỉ còn 12 byte
- Bài viết cho rằng kỳ vọng một ngày nào đó loại bỏ được chính địa chỉ Ethernet đã giúp biện minh cho quyết định chọn độ dài địa chỉ IPv6 lớn đến vậy
- Nhưng thiết kế đẹp đẽ này đã không thành hiện thực trong thế giới thật
Khúc tưởng niệm cho một giấc mơ
- Câu nói của một đồng nghiệp rằng "các lớp chỉ được thêm vào chứ không bị loại bỏ" được đưa ra như kết luận chung
- Các ưu điểm của IPv6 chỉ có ý nghĩa khi có thể vứt bỏ di sản cũ và khởi động lại, nhưng trên thực tế điều đó gần như bất khả thi
- Dù tỷ lệ phổ cập IPv6 có đạt 99%, chừng nào IPv4 chưa biến mất hoàn toàn thì địa chỉ Ethernet và wifi cũng không thể biến mất; và chừng nào vẫn giữ các chuẩn framing IEEE 802.3 và 802.11 thì khoản tiết kiệm byte đó cũng không thể đạt được
- 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 thì các mô phỏng kiểu broadcast cho hành vi kiểu ARP vẫn tiếp tục là cần thiết
- Trong gia đình, người ta vẫn phải chạy DHCP server cục bộ để các bóng đèn IPv4 đời cũ hoạt động, và nếu muốn những bóng đèn đó chạm tới Internet thì NAT cũng vẫn phải tồn tại
- Tệ hơn nữa là nhóm IPv6 đã không giải quyết được bài toán mobile IP, và kết quả là kiểu layer 2 bridging kinh khủng vẫn tiếp tục cần thiết
- Theo bài viết, khi ấy có lẽ người ta dự định triển khai IPv6 trước trong vài năm, rồi sau khi IPv4 và địa chỉ MAC biến mất thì sẽ giải quyết mobile IP dễ dàng hơn
- Ở thời điểm đó, người ta còn cho rằng gần như không có trường hợp dùng máy tính khi đang di chuyển; hình dung xa nhất chỉ là một cảnh hơi gượng ép kiểu cắm/rút giữa các cổng Ethernet mà vẫn muốn giữ phiên ftp
Mobile IP như một killer app
- Về sau lịch sử lại cho thấy trường hợp dùng mang theo máy tính, tức điện thoại, 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, việc di chuyển này hầu như hoạt động; trên wifi thì đôi khi hoạt động, nhưng bí quyết không nằm ở Internet routing mà ở layer 2 bridging
- Internet routing hoàn toàn không xử lý được tính di động; nếu bạn di chuyển trong mạng IP làm địa chỉ IP thay đổi thì mọi kết nối đang mở đều bị đứt
- Wifi doanh nghiệp giải quyết bằng cách bridge toàn bộ LAN ở layer 2, để DHCP server trung tâm luôn cấp cùng một địa chỉ IP dù thiết bị gắn vào access point nào, và chỉ chấp nhận vài giây hỗn loạn khi bridge tái cấu hình
- Wifi gia đình có nhiều extender hoặc repeater cũng dùng cùng cách đó
- Ngược lại, nếu đang đi bộ và băng qua nhiều mạng wifi khác nhau như wifi công cộng của từng cửa hàng, bạn sẽ nhận IP mới ở mỗi mạng, và mọi kết nối đều bị cắt mỗi lần như vậy
- LTE thì còn làm mạnh tay hơn, giữ nguyên cùng một địa chỉ IP ngay cả khi di chuyển nhiều dặm giữa các trạm gốc, và bài viết 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 rất nhiều firewall thành một LAN layer 2 ảo siêu lớn, đổi lại là độ phức tạp khổng lồ và độ trễ bổ sung đáng xấu hổ
- Các nhà mạng muốn sửa điều này như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 về 4-tuple dùng để nhận diện session là sai ngay từ đầu
- Session TCP và UDP được nhận diện bằng
(source ip, source port, destination ip, destination port), cấu trúc này cắt ngang layer 3 và layer 4 nên rất mong manh trước thay đổi địa chỉ IP - Bài viết cho rằng nếu việc nhận diện session 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 rồi X đổi địa chỉ thành Q, gói sẽ thành
(Q,1111,Y,80), khiến Y không nhận ra đó là session cũ và loại bỏ; các gói Y trả về theo(Y,80,X,1111)cũng không còn đến được X nữa - Phương án thay thế được nêu 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 khoảng 128 hoặc 256 bit, và nhận diện socket bằng một thẻ không phụ thuộc vào địa chỉ IP
- Khi đó gói tin ở layer 3 vẫn mang thông tin địa chỉ
(X,Y)để routing, nhưng kernel khi nhận sẽ không dùng thông tin layer 3 để xác định socket mà chỉ dùng uuid - Đích port 80 chỉ còn cần để phân biệt dịch vụ mong muốn khi khởi tạo session mới, sau đó có thể bỏ qua hoặc lược bỏ
- Kernel của Y sẽ cache rằng gói của session
(uuid)gần đây đến từ X; sau khi X chuyển sang Q và tiếp tục gửi với thẻ(uuid,80)giống cũ, Y có thể ghép nó vào session đó và cập nhật đích phản hồi từ X sang Q - Cách này giúp giữ kết nối, nhưng bài viết lưu ý rằng cần thêm biện pháp để ngăn kẻ giả mạo chiếm đoạt kết nối
- Tuy nhiên UDP và TCP không hoạt động theo cách đó, và việc thay đổi nó vào lúc này được đánh giá là kiểu dự án từng trông dễ như chuyển IPv4 sang IPv6, nhưng nhiều thập kỷ sau vẫn chưa xong nổi một nửa
QUIC và một khả năng đi đường vòng
- Về mặt tích cực, một giải pháp vòng vo khác lại được gợi ra thông qua một lần phá vỡ phân lớp nữa
- Nếu bỏ TCP cũ và dùng QUIC chạy trên UDP, có thể tránh việc dùng chính 4-tuple của UDP làm định danh kết nối
- Nếu UDP port là một mobility layer đặc biệt, phần payload bên trong có thể được giải mã tiếp như các gói nội bộ gắn uuid thích hợp, rồi ghép vào đúng session 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 cấu trúc như vậy
- Vì QUIC vốn đã cần định danh session hoặc khóa duy nhất cho mã hóa và xác thực gói không trạng thái, nên có kỳ vọng rằng chỉ với lượng công việc tương đối nhỏ, nó có thể hỗ trợ roaming trong suốt
- Khi đó nếu chỉ cần loại bỏ nốt UDP và TCP khỏi Internet, lần này có lẽ thật sự sẽ không còn cần layer 2 bridging nữa, và broadcast, địa chỉ MAC, SDN lẫn DHCP cũng có thể bị loại bỏ
- Bài viết kết lại bằng câu khôi phục sự thanh lịch của Internet
Các chỉnh sửa bổ sung
-
Chỉnh sửa 2017-08-16
- Ý tưởng mobile IP nêu trước đó không chỉ giới hạn ở IPv6
- Bài viết 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 tương tự tại thời điểm khởi tạo 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 cướp kết nối X→Y
- Nếu Y gửi cookie và Q 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 trung gian chứ không còn là một tác nhân bên ngoài đơn giản nữa
- Khi dùng các giao thức mã hóa như QUIC, cái bắt tay đó 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 như một ví dụ
- Bài viết nói rằng MinimaLT là giao thức đầu tiên mà tác giả biết đã giải quyết bài toán roaming một cách thanh lịch, và gợi ý rằng các lời giải tương lai có thể sẽ mô phỏng cấu trúc này
-
Chỉnh sửa 2020-07-09
- Chỉ có nhắc rằng tác giả đã đăng thêm một bài khác về suy nghĩ liên quan tới migration và khả năng tương tác giữa IPv4/IPv6, không có giải thích bổ sung trong thân bài
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