Кратко

  • RFC 3493 позволял сокету AF_INET6 общаться с узлами IPv4 через IPv4-mapped IPv6-адреса. IPV6_V6ONLY ограничивал его IPv6, но RFC задавал выключенное состояние по умолчанию.
  • Поэтому семейство сокета и успешный wildcard bind не доказывали семейство входящего узла или наличие отдельного владельца IPv4-порта. Эффективное значение опции, каждый bind и принятые соединения были разными квитанциями.

Контейнерная схема может обещать два независимых входа. Один процесс подписан IPv6, второй IPv4, оба используют одинаковый порт. Если AF_INET6-процесс запускается первым и его wildcard socket двухстековый, ядро может отдать ему обе семьи. Второй контейнер существует, но его listener не возник.

RFC 3493 обеспечивал совместимость с помощью IPv4-mapped IPv6-адресов. 32 бита IPv4 помещались в младшую часть 128-битной структуры под фиксированным префиксом ::ffff:. Приложение могло соединиться с IPv4-узлом через AF_INET6; при приеме ядро возвращало его в sockaddr_in6. Макрос IN6_IS_ADDR_V4MAPPED() позволял распознать представление.

Представление не является доказательством маршрута. Оно не превращает удаленный узел в нативный IPv6, не описывает промежуточную сеть и не подтверждает одинаковую политику доступа. Оно фиксирует лишь способ передачи адреса между ядром и программой.

Раздел 5.3 определил IPV6_V6ONLY. Включенная булева опция оставляла сокету AF_INET6 только IPv6-коммуникацию. RFC указывал, что по умолчанию она выключена. При таком историческом контракте один wildcard listener мог принять нативный IPv6 и IPv4, показанный как mapped address.

Пример RFC связан с владением ресурсом: включение опции позволяет двум версиям сервера использовать один номер порта, одной для IPv6, другой для IPv4. Значит, опция определяет, занимает ли один bind одну или две семьи и остается ли место для второго сокета. Порядок запуска становится частью фактической архитектуры.

Список процессов этого не доказывает. Оба могут числиться запущенными, хотя один bind завершился ошибкой. Список сокетов тоже обманывает, если AF_INET6 читают как IPv6-only. Нужны семейство, считанное значение IPV6_V6ONLY, адрес, namespace, порт, код возврата и наблюдаемые классы узлов.

Есть важная оговорка. Опция не влияет на mapped addresses, входящие как корректная IPv6-коммуникация через SIIT. RFC 6052 и RFC 6145 описывают встроенные адреса и трансляцию пакетов, отличные от локального представления IPv4-пира в dual-stack socket. По внешнему виду нельзя определить место преобразования.

Разрешение имени находится еще раньше. getaddrinfo() возвращает кандидаты по семье и flags. RFC 6724 задает выбор, RFC 8305 рассматривает IPv6 и IPv4 как конкурирующие пути. Наличие кандидата не подтверждает bind, достижимость, авторизацию или завершение услуги.

Выключенный default — исторический факт 2003 года. RFC 3493 имеет статус Informational, заменил RFC 2553 и указывает на другой официальный стандарт API. Современные ядра, runtime и платформы могут отличаться. Их поведение следует измерять, а не выводить из старого текста.

Устойчивая модель состоит из отдельных доказательств: объявленная семья, эффективная опция, граница bind, владелец порта, форма peer, решение приложения и результат услуги. Без них ярлык «IPv6 listener» может скрывать вход IPv4 или отсутствующий IPv4 listener.

Источники