Кратко

  • RFC 3542 отделил постоянные опции IPv6, хранящиеся в сокете, от вспомогательных данных одной конкретной отправки. Такие данные переопределяют только постоянную опцию с тем же именем; остальные продолжают действовать.
  • У этого правила есть границы: данные нулевой длины могут отключить одну опцию на одну дейтаграмму, уже поставленные в очередь пакеты могут не содержать запрошенных позднее метаданных, а вызовы отправки TCP не соответствуют отдельным переданным сегментам один к одному.

Представим долговременный UDP-сокет диагностического приложения. Программа выбрала интерфейс выхода и задала параметры IPv6, которые должны применяться к каждой дейтаграмме. Для одного исключительного сообщения нужен другой маршрут. Если реализация считает вспомогательные данные этой отправки заменой всего набора постоянных настроек, пакет, возможно, пойдёт по нужному пути, но одновременно потеряет параметры, которые никто не собирался менять.

RFC 3542, опубликованный в мае 2003 года под названием Advanced Sockets Application Program Interface (API) for IPv6, прямо определил эту границу. Это информационный документ, а не стандарт сетевого протокола, задающий формат пакета на проводе. Он описывает интерфейс между приложением и ядром: какие запросы программа может сделать IPv6-стеку, но не то, что сеть обязательно передаст. Успешный вызов интерфейса сам по себе не доказывает, что пакет был отправлен, дошёл до адресата или обеспечил результат приложения.

Причину изменения показывает сравнение с заменённым документом RFC 2292. В прежней модели постоянные опции задавались как единая группа, и вспомогательные данные конкретного сообщения могли заменить эту группу целиком. RFC 3542 разделил больше параметров и сделал отдельные опции адресуемыми независимо. Когда состояние стало состоять из отдельных элементов, и область переопределения должна была стать такой же узкой: заменяется только опция с совпадающим типом.

Это не просто вопрос стиля программирования: правило задаёт радиус действия исключения. Если сокет хранит независимые параметры интерфейса, класса трафика и обработки расширений заголовков, данные маршрутизации для одного сообщения не получают права стирать два других решения. Ядро объединяет постоянное состояние с узким исключением при построении дейтаграммы. Но результат такой сборки — ещё не наблюдение реально отправленного пакета.

Правило позволяет также запросить конкретное отсутствие. Приложение может установить постоянную опцию IPV6_HOPOPTS, а для одной отправки передать вспомогательные данные того же типа нулевой длины. Тогда в этой дейтаграмме не будет заголовка Hop-by-Hop Options. Ноль не означает «забыть все настройки»: он однократно отключает названную опцию. Если приложение не изменит состояние отдельно, следующая дейтаграмма снова унаследует постоянное значение.

При приёме возникает другая, временная проблема. Приложение включает опции IPV6_RECVxxx, после чего recvmsg() может возвращать доступные сведения о пакете в виде вспомогательных объектов. Отсутствие ожидаемого объекта может означать, что информации в пакете не было. Но RFC 3542 предупреждает и о другом случае: дейтаграммы, уже находившиеся в очереди до включения опции приёма, могут не содержать новых метаданных. Пробел может описывать содержимое пакета или момент начала наблюдения; одного факта отсутствия недостаточно, чтобы восстановить картину на проводе.

TCP обозначает предел аналогии с дейтаграммой. RFC 3542 не определяет такую же вспомогательную настройку для каждого вызова отправки TCP, поскольку вызов приложения не соответствует ровно одному передаваемому сегменту. Повторный сегмент может использовать прежние или новые постоянные опции; документ не обещает границу сообщения там, где TCP не может её сохранить. Некоторые необязательные сведения о приёме TCP тоже оставлены неопределёнными, и RFC предостерегает от их использования в решениях контроля доступа.

Историческим примерам нужна временная маркировка. RFC 3542 включает пример Routing Header Type 0 из эпохи RFC 2460. Сегодня базовой спецификацией IPv6 является RFC 8200. Пример старого документа показывает возможности API того времени, но не является современной рекомендацией по маршрутизации.

Историческое значение RFC 3542 — в сужении исключения: вместо замены всей группы в RFC 2292 он оставил переопределение только одноимённой опции. Чтобы доказать работу системы, нужно раздельно фиксировать состояние сокета до вызова, вспомогательные данные конкретного сообщения, наблюдённую дейтаграмму и последующий результат. Успешный sendmsg() подтверждает, что интерфейс принял намерение; он не доказывает, что пакет прошёл ожидаемым маршрутом.

Источники