Động lực để thêm cờ IPV6_V6ONLY là gì?

Question

Trong mạng IPv6, cờ IPV6_V6ONLY được sử dụng để đảm bảo rằng một socket sẽ chỉ sử dụng IPv6, và đặc biệt là ánh xạ IPv4 đến IPv6 sẽ không được sử dụng cho ổ cắm đó. Trên nhiều hệ điều hành, IPV6_V6ONLY không được đặt theo mặc định, nhưng trên một số hệ điều hành (ví dụ: Windows 7), nó được đặt theo mặc định.

Câu hỏi của tôi là: Động lực để giới thiệu cờ này là gì? Có điều gì đó về bản đồ IPv4-to-IPv6 đã gây ra vấn đề, và do đó mọi người cần một cách để vô hiệu hóa nó? Dường như với tôi rằng nếu ai đó không muốn sử dụng ánh xạ IPv4 đến IPv6, họ có thể không chỉ định địa chỉ IPv6 được ánh xạ IPv4. Tôi đang thiếu gì ở đây?

Answer 1

Tôi không biết tại sao nó sẽ là mặc định; nhưng đó là loại cờ mà tôi sẽ luôn đặt rõ ràng, bất kể mặc định là gì.

Tại sao nó tồn tại ở nơi đầu tiên, tôi đoán rằng nó cho phép bạn giữ các máy chủ IPv4 hiện có và chỉ chạy các máy chủ mới trên cùng một cổng nhưng chỉ cho kết nối IPv6. Hoặc có thể máy chủ mới có thể chỉ đơn giản là proxy cho khách hàng cũ, làm cho chức năng IPv6 dễ dàng và không đau để thêm vào các dịch vụ cũ.

Answer 2

Hãy tưởng tượng giao thức bao gồm trong cuộc hội thoại địa chỉ mạng, ví dụ: kênh dữ liệu cho FTP. Khi sử dụng IPv6, bạn sẽ gửi địa chỉ IPv6, nếu người nhận xảy ra là địa chỉ được ánh xạ IPv4, nó sẽ không có cách nào để kết nối với địa chỉ đó.

Answer 3

Lý do thường được đề cập nhất là đối với trường hợp máy chủ có một số dạng ACL (Danh sách điều khiển truy cập). Ví dụ: hãy tưởng tượng một máy chủ có các quy tắc như:

Allow 192.0.2.4 
Deny all 

Nó chạy trên IPv4. Bây giờ, ai đó chạy nó trên một máy tính với IPv6 và, tùy thuộc vào một số tham số, yêu cầu IPv4 được chấp nhận trên ổ cắm IPv6, ánh xạ là :: 192.0.2.4 và sau đó không còn phù hợp với ACL đầu tiên nữa. Đột nhiên, truy cập sẽ bị từ chối.

Đang rõ ràng trong ứng dụng của bạn (sử dụng IPV6_V6ONLY) sẽ giải quyết được sự cố, bất kể hệ điều hành mặc định là gì.

Answer 4

Không phải tất cả các nền tảng hỗ trợ IPv6 đều hỗ trợ ổ cắm kép, vì vậy câu hỏi sẽ trở thành cách các ứng dụng cần tối đa hóa khả năng tương thích IPv6 hoặc biết dualstack được hỗ trợ hoặc ràng buộc tách biệt khi không? Câu trả lời phổ quát duy nhất là IPV6_V6ONLY. Một ứng dụng bỏ qua IPV6_V6ONLY hoặc được viết trước khi ngăn xếp IP có khả năng dualstack tồn tại có thể tìm thấy ràng buộc tách biệt với V4 không thành công trong môi trường dualstack vì socket dualstack IPv6 liên kết với IPv4 ngăn chặn ràng buộc socket IPv4. Ứng dụng này cũng có thể không mong đợi IPv4 qua IPv6 do các vấn đề về địa chỉ hoặc mức độ giải quyết hoặc các điều khiển truy cập IP.

Tình huống tương tự hoặc nhiều khả năng nhất có thể nhắc MS và cộng đồng mặc định là 1 thậm chí tho RFC3493 tuyên bố 0 là mặc định. 1 về mặt lý thuyết tối đa hóa khả năng tương thích ngược. Cụ thể Windows XP/2003 không hỗ trợ ổ cắm dualstack.

Cũng không thiếu các ứng dụng mà không cần phải vượt qua thông tin lớp thấp hơn để hoạt động chính xác và tùy chọn này có thể khá hữu ích cho việc lập kế hoạch chiến lược tương thích IPv4/IPv6 phù hợp nhất với yêu cầu và mã nguồn hiện tại.

Answer 5

Có nhiều cách hợp lý để sử dụng các địa chỉ IPv4 có thể được sử dụng để phá vỡ hệ thống cấu hình kém hoặc ngăn xếp xấu hoặc thậm chí trong hệ thống được cấu hình tốt. Nhà phát triển có thể muốn sử dụng cờ này để làm cho ứng dụng của họ an toàn hơn bằng cách không sử dụng phần này của API.

Xem: http://ipv6samurais.com/ipv6samurais/openbsd-audit/draft-cmetz-v6ops-v4mapped-api-harmful-01.txt

Answer 6

Đối với Linux, khi viết một dịch vụ mà lắng nghe trên cả hai khe IPv4 và IPv6 trên cổng dịch vụ cùng, ví dụ port 2001, bạn PHẢI gọi setsockopt (s, SOL_IPV6, IPV6_V6ONLY, & một, sizeof (một)); trên ổ cắm IPv6. Nếu không, thao tác bind() cho ổ cắm IPv4 không thành công với "Địa chỉ đã được sử dụng".

Answer 7

Có một ví dụ rất phổ biến khi tính hai mặt của hành vi là một vấn đề. Cuộc gọi tiêu chuẩn getaddrinfo() với cờ AI_PASSIVE cung cấp khả năng chuyển thông số tên nodename và trả về danh sách địa chỉ để nghe. Giá trị đặc biệt dưới dạng một chuỗi NULL được chấp nhận cho nodename và ngụ ý lắng nghe các địa chỉ đại diện.

Trên một số hệ thống 0.0.0.0 và :: được trả lại theo thứ tự này. Khi ổ cắm ngăn xếp kép được bật theo mặc định và bạn không đặt ổ cắm IPV6_V6ONLY, máy chủ kết nối với 0.0.0.0 và sau đó không kết nối với ngăn xếp kép :: và do đó (1) chỉ hoạt động trên IPv4 và (2) báo cáo lỗi.

Tôi sẽ xem xét đơn đặt hàng sai vì IPv6 được mong đợi sẽ được ưu tiên hơn. Nhưng ngay cả khi bạn lần đầu tiên thử hai ngăn xếp :: và sau đó chỉ IPv2-0.0.0.0, máy chủ vẫn báo cáo lỗi cho cuộc gọi thứ hai.

Cá nhân tôi xem xét toàn bộ ý tưởng của một ngăn xếp ngăn xếp kép là một sai lầm. Trong dự án của tôi, tôi thà luôn đặt rõ ràng IPV6_V6ONLY để tránh điều đó. Một số người dường như đã coi đó là một ý tưởng hay nhưng trong trường hợp đó, tôi có thể sẽ xóa một cách rõ ràng IPV6_V6ONLY và dịch NULL trực tiếp đến 0.0.0.0 bỏ qua cơ chế getaddrinfo().