GRAND: Vá lỗ hổng gói tin IPv6 đầu tiên bằng Neighbour Discovery chủ động

IPv6 Neighbour Discovery tồn tại một điểm bất đối xứng tinh tế: máy chủ biết cách liên lạc với router trước khi router biết cách liên lạc ngược lại với máy chủ. GRAND ra đời để sửa chữa sự bất đối xứng này bằng cách để máy chủ chủ động quảng bá địa chỉ của mình — và cơ chế đó vừa được hiện thực hóa trên FreeBSD.

Vấn đề của gói tin IPv6 đầu tiên

Hãy hình dung một thiết bị vừa tham gia mạng IPv6, nhận Router Advertisement, cấu hình một địa chỉ IPv6 mới và bắt đầu giao tiếp với Internet ngay lập tức.

Từ góc nhìn của máy chủ, mọi thứ đã sẵn sàng. Nó biết địa chỉ link-layer của router mặc định nên có thể gửi gói tin ra Internet ngay.

Nhưng từ góc nhìn của router, tình hình có thể khác hoàn toàn. Router có thể chưa biết cách để tiếp cận địa chỉ IPv6 global vừa được cấu hình của máy chủ.

Điều này tạo ra một bất đối xứng trong IPv6 Neighbour Discovery: máy chủ đã có thể tiếp cận router, trong khi router phải thực hiện Neighbour Discovery trước khi có thể chuyển tiếp lưu lượng trở lại máy chủ.

Khi máy chủ gửi gói tin đến một đích ngoài link, router chặng đầu nhận và chuyển tiếp bình thường. Nhưng khi đích từ xa phản hồi, gói tin quay về router với máy chủ là đích đến. Nếu router chưa có mục Neighbour Cache cho địa chỉ đó, nó buộc phải phân giải địa chỉ link-layer của máy chủ trước khi chuyển tiếp.

Hệ quả là Neighbour Discovery nằm ngay trên đường tới hạn của gói tin phản hồi đầu tiên — các gói đầu của kết nối có thể bị tăng độ trễ hoặc thậm chí bị mất trong khi quá trình phân giải địa chỉ đang diễn ra.

Điều đáng chú ý là máy chủ đã nắm trong tay mọi thông tin mà router cần. Nó biết mình sở hữu địa chỉ IPv6 đó và biết địa chỉ link-layer tương ứng. Chỉ có router là chưa học được điều này.

Vì sao Neighbour Discovery lại gây ra độ trễ?

Trong tình huống này, IPv6 Neighbour Discovery mang tính thụ động. Khi một nút cần liên lạc với neighbour mà nó không có mục Neighbour Cache khả dụng, nó bắt đầu phân giải địa chỉ bằng cách gửi Neighbour Solicitation và chờ Neighbour Advertisement.

Cơ chế này hoạt động tốt với các neighbour đã thiết lập. Vấn đề chỉ xuất hiện trong giai đoạn chuyển tiếp từ "địa chỉ vừa trở nên khả dụng" sang "phần còn lại của mạng biết cách tiếp cận nó". Đây chính là khoảng trống mà GRAND nhắm tới.

GRAND: Chuyển Neighbour Discovery từ thụ động sang chủ động

Gratuitous Neighbour Discovery đảo ngược hướng dòng thông tin. Thay vì chờ router khám phá máy chủ khi gói tin đầu tiên đến, máy chủ chủ động thông báo địa chỉ IPv6 và địa chỉ link-layer của mình thông qua một Neighbour Advertisement không được yêu cầu.

Router sau đó có thể học thông tin này trước khi cần chuyển tiếp lưu lượng về phía máy chủ. Đây là ý tưởng trung tâm của RFC 9131.

Tuy nhiên, hiện thực hóa GRAND không đơn thuần là gửi một Neighbour Advertisement không yêu cầu mỗi khi địa chỉ xuất hiện. GRAND tương tác với nhiều quy tắc Neighbour Discovery hiện hữu, bao gồm xử lý nhiều địa chỉ, địa chỉ anycast và proxy, thời điểm gửi, và Duplicate Address Detection.

Xây dựng GRAND trên nền RFC 4861

Một phần quan trọng khi hiện thực GRAND là hiểu rằng Neighbour Advertisement không yêu cầu đã có vai trò xác định trong Neighbour Discovery.

Quy tắc 7.2.6 của RFC 4861 quy định hành vi cho các Neighbour Advertisement không yêu cầu, bao gồm các trường hợp như thay đổi địa chỉ link-layer của một nút. Quy tắc này cũng giới hạn số lượng quảng cáo mà một nút có thể gửi cho nhiều địa chỉ, đồng thời khuyến nghị giãn cách các quảng cáo để tránh tắc nghẽn không cần thiết.

Các quy tắc 7.2.7 và 7.2.8 của RFC 4861 bao quát trường hợp đặc biệt của Neighbour Advertisement anycast và proxy. Trong những tình huống này, nhiều nút có thể cùng phản hồi một Neighbour Solicitation. Nếu tất cả đều truyền ngay lập tức, mục đích của chúng sẽ trở nên vô hiệu.

Để giải quyết, RFC 4861 quy định một độ trễ ngẫu nhiên trước khi gửi Neighbour Advertisement anycast hoặc proxy. Điều này cho nhiều nút phản hồi tiềm năng cơ hội tránh truyền đồng thời.

Các quy tắc thời điểm này là phần quan trọng trong thiết kế tổng thể của Neighbour Discovery: đưa thông tin có sẵn nhanh là hữu ích, nhưng làm điều đó mà không tạo ra bão multicast cũng quan trọng không kém.

Hiện thực mới bổ sung các hành vi này như phần của công việc GRAND, thay vì dựa vào hạ tầng queueing và delayed-NA có sẵn.

GRAND và Neighbour Advertisement bị trễ

Một phần ít rõ ràng của GRAND là việc lập lịch các Neighbour Advertisement. Đây cũng là nơi tác giả quyết định hiện thực các phần còn thiếu của RFC 4861.

Hiện thực cũ chưa cung cấp cơ chế queueing và truyền trễ cần thiết cho các hành vi này. Hiện thực GRAND đòi hỏi bổ sung hạ tầng đó rồi dùng nó để lập lịch các Neighbour Advertisement không yêu cầu.

Trong GRAND, một địa chỉ vừa được cấu hình có thể dẫn đến một Neighbour Advertisement không yêu cầu, nhưng hiện thực phải cân nhắc có bao nhiêu địa chỉ đang được quảng bá và khi nào mỗi quảng cáo nên được truyền đi. Trong IPv6, một interface có thể có hàng trăm địa chỉ cùng lúc.

Gửi tất cả quảng cáo ngay lập tức có thể tạo ra một đợt bùng nổ không cần thiết — ví dụ, một datacentre sau khi khôi phục điện khiến nhiều máy chủ khởi động cùng lúc. Vì vậy, hiện thực bổ sung hành vi quảng cáo trễ theo mô tả của RFC 4861 7.2.6 và hành vi phản hồi ngẫu nhiên theo 7.2.7 và 7.2.8.

Điều này đặc biệt liên quan với địa chỉ anycast và proxy, nơi nhiều hơn một nút có thể phản hồi. Mục tiêu không chỉ là giảm thiểu thời gian trước khi quảng cáo được gửi, mà là cân bằng giữa khám phá neighbour nhanh và lượng lưu lượng multicast mà quá trình đó tạo ra.

RFC 9131 thực sự thay đổi điều gì?

RFC 9131 xây dựng trên các cơ chế Neighbour Discovery để giải quyết vấn đề gói tin đầu tiên.

Máy chủ gửi một Neighbour Advertisement không yêu cầu khi một địa chỉ IPv6 mới trở nên khả dụng. Quảng cáo này chứa thông tin mà router chặng đầu cần để xây dựng một mục neighbour.

Tuy nhiên, còn một nửa quan trọng thứ hai của cơ chế. Theo hành vi RFC 4861 gốc, việc nhận một Neighbour Advertisement không yêu cầu không nhất thiết có nghĩa rằng router không có mục Neighbour Cache sẽ tạo một mục mới.

RFC 9131 thay đổi hành vi này: router nhận một Neighbour Advertisement không yêu cầu hợp lệ cho một địa chỉ mà nó chưa có mục Neighbour Cache có thể tạo một mục mới từ thông tin được cung cấp. Mục này được tạo ở trạng thái STALE — chi tiết khiến GRAND hữu ích cho vấn đề gói tin đầu tiên.

Vì sao STALE là chìa khóa?

Thoạt nhìn, đưa một neighbour vừa học vào trạng thái STALE có vẻ phản trực giác. Tại sao không đánh dấu REACHABLE?

Sự phân biệt rất quan trọng. GRAND cho router biết máy chủ đang tuyên bố sở hữu địa chỉ IPv6 và cung cấp địa chỉ link-layer. Nó không nhất thiết chứng minh neighbour hiện đang có thể tiếp cận theo nghĩa được Neighbour Unreachability Detection sử dụng.

STALE cho phép router dùng thông tin đã học mà không cần một thao tác phân giải địa chỉ multicast mới. Router sau đó có thể xác minh khả năng tiếp cận bằng các cơ chế Neighbour Discovery thông thường. Điều này có nghĩa GRAND loại bỏ phân giải địa chỉ khỏi đường tới hạn của gói tin đầu tiên mà không tuyên bố neighbour đã được xác minh vĩnh viễn là có thể tiếp cận.

Hiện thực GRAND trong FreeBSD

Hiện thực GRAND trong FreeBSD đòi hỏi nhiều hơn việc chỉ thêm code để truyền một Neighbour Advertisement không yêu cầu.

Hiện thực IPv6 Neighbour Discovery sẵn có trước đó đã cung cấp state machine, xử lý vòng đời địa chỉ, Duplicate Address Detection và quản lý Neighbour Cache. Tuy nhiên, nó chưa cung cấp hạ tầng queueing và delayed-Neighbour-Advertisement cần cho GRAND và các hành vi RFC 4861 liên quan.

Hiện thực GRAND bổ sung hạ tầng đó. Nó cũng hiện thực hành vi quảng cáo trễ và ngẫu nhiên theo quy tắc 7.2.7 và 7.2.8 của RFC 4861, bao gồm xử lý thời điểm quảng cáo để nhiều địa chỉ, địa chỉ anycast và quảng cáo liên quan proxy không tạo ra các đợt bùng nổ lưu lượng Neighbour Discovery không cần thiết.

Hiện thực kết hợp nhiều phần hành vi Neighbour Discovery:

• Chủ động quảng bá địa chỉ IPv6 vừa trở nên khả dụng
• Xử lý thay đổi địa chỉ link-layer
• Bổ sung queueing cho Neighbour Advertisement
• Trì hoãn nhiều quảng cáo không yêu cầu
• Áp dụng ngẫu nhiên hóa phù hợp cho phản hồi anycast và proxy
• Tích hợp cơ chế lập lịch mới với trạng thái và xử lý timer ND hiện hữu

Kết quả không phải một "hệ thống con GRAND" riêng biệt, mà là một phần mở rộng của hiện thực Neighbour Discovery hiện hữu với hỗ trợ queueing và lập lịch truyền mới.

Xử lý thay đổi địa chỉ link-layer

GRAND cũng kết nối tự nhiên với một trong những ứng dụng sẵn có của Neighbour Advertisement không yêu cầu.

Quy tắc 7.2.6 của RFC 4861 định nghĩa quảng cáo không yêu cầu cho các tình huống như thay đổi địa chỉ link-layer. Nếu địa chỉ link-layer của một interface thay đổi trong khi địa chỉ IPv6 vẫn được cấu hình, các nút khác có thể vẫn có thông tin cache tham chiếu địa chỉ link-layer cũ.

Hiện thực có thể chủ động quảng bá ánh xạ mới thay vì chờ Neighbour Discovery thông thường phát hiện thay đổi. Điều này có nghĩa công việc GRAND bao quát hai tình huống liên quan chặt chẽ:

• Một địa chỉ IPv6 trở nên khả dụng
• Ánh xạ link-layer cho một địa chỉ IPv6 hiện hữu thay đổi

Trong cả hai trường hợp, mục tiêu đều giống nhau: đưa thông tin đến các neighbour trước khi chúng buộc phải khám phá một cách thụ động.

Bài học khi tích hợp vào FreeBSD

Hiện thực cũng làm nổi bật một khác biệt quan trọng giữa việc hiện thực giao thức trên giấy và tích hợp nó vào một network stack hiện hữu.

RFC mô tả hành vi giao thức mong muốn, nhưng kernel trước đó không có đủ mọi cơ chế cần thiết để hiện thực nó. Cụ thể, GRAND đòi hỏi hỗ trợ queueing và truyền trễ mới cho Neighbour Advertisement.

Thêm GRAND do đó đồng nghĩa giới thiệu những cơ chế đó và đảm bảo chúng tương tác đúng với vòng đời địa chỉ, DAD, quản lý Neighbour Cache và xử lý trạng thái Neighbour Discovery hiện hữu.

Đặc biệt, các quảng cáo do GRAND tạo ra có ngữ nghĩa khác với các Neighbour Advertisement khác. Điều này đòi hỏi thay đổi cách quảng cáo được xếp hàng, kết hợp, trì hoãn và cuối cùng là truyền đi.

Các yêu cầu về thời điểm cũng khiến hiện thực thú vị hơn việc chỉ tạo gói tin ngay lập tức. Hiện thực cần tránh tạo các đợt bùng nổ không cần thiết trong khi vẫn đưa thông tin có sẵn đủ sớm để giải quyết vấn đề gói tin đầu tiên. Đây là lúc các chi tiết trong quy tắc 7.2.6–7.2.8 của RFC 4861 trở nên quan trọng trong thực tế — chúng không chỉ là chi tiết giao thức lịch sử mà cung cấp các quy tắc cần thiết để Neighbour Discovery chủ động hành xử tốt trên mạng thực.

Vì sao điều này quan trọng với triển khai IPv6 thực tế?

Neighbour Discovery thường vô hình khi mọi thứ hoạt động đúng — và chính điều đó khiến các vấn đề như thế này dễ bị bỏ qua. Giao thức thường đủ nhanh đến mức người dùng không bao giờ nghĩ về nó. Nhưng Neighbour Discovery có thể nằm ngay trên đường chuyển tiếp, nghĩa là hành vi của nó có thể ảnh hưởng đến gói tin đầu tiên của một kết nối.

Điều này ngày càng liên quan khi các máy chủ IPv6 cấu hình và gỡ bỏ địa chỉ một cách động. Địa chỉ privacy, prefix thay đổi, thiết bị di động, máy ảo, container và các môi trường khác đều có thể khiến địa chỉ xuất hiện và biến mất trong suốt vòng đời của một interface.

GRAND cho phép mạng học về một địa chỉ mới ngay khi địa chỉ đó trở nên khả dụng, thay vì chờ lưu lượng buộc quá trình khám phá phải xảy ra. Đồng thời, các cơ chế thời điểm kế thừa từ thiết kế Neighbour Discovery giúp đảm bảo các quảng cáo chủ động không tự trở thành nguồn lưu lượng multicast không cần thiết.

GRAND và RFC 9898

GRAND không chỉ là một tối ưu hóa thú vị được mô tả trong một RFC. RFC 9898 — Neighbour Discovery Considerations in IPv6 Deployments — xác định rõ GRAND là cơ chế giải quyết độ trễ chuyển tiếp của router gây ra bởi dạng Neighbour Discovery này.

Điều này quan trọng vì nó đặt vấn đề vào bối cảnh triển khai IPv6 thực tế thay vì coi đó là một vấn đề giao thức mang tính lý thuyết.

Lưu ý từ tác giả: bài viết gốc có sử dụng công cụ AI để hỗ trợ soạn thảo và ngôn ngữ. Công việc kỹ thuật, phân tích và kết luận là của chính tác giả.