Кратко

  • Редакция 02 проекта v6ops от 28 октября устанавливает порядок выбора источника ICMPv4-ответа при непереводимом внешнем IPv6-источнике ошибки: если доступен публичный IPv4, его следует использовать; в ином случае нужно использовать 192.0.0.8. Редакция 01 не содержала столь явного первого шага.
  • Транслятору рекомендуется приложить объект Node Identification с исходным IPv6-адресом. Для Packet Too Big это возможно лишь после перевода в ICMPv4; объект можно опустить, но ошибку всё равно следует доставить. IANA регистрирует 192.0.0.8/32 как фиктивный IPv4-адрес.

Поле источника не равно личности отправителя

У ошибки сети есть содержание: пункт назначения недоступен, время истекло или пакет слишком велик. Когда IPv4-соединение проходит через участок только с IPv6, промежуточный узел может сообщить об этом по ICMPv6. Его внешний IPv6-источник может не совпадать с префиксом трансляции и не иметь статического или динамического соответствия. В исходное поле будущего ICMPv4 этот адрес не записать. Если у устройства перевода нет собственного публичного IPv4, нельзя просто отправить ответ от его публичного имени.

Раздел 4.1 нового проекта сначала спрашивает, есть ли в распоряжении транслятора публичный IPv4-адрес или пул. Если есть, его рекомендуется использовать в русле RFC 6791. Если нет, фиктивный 192.0.0.8 становится обязательным. Прежняя редакция обобщённо рекомендовала фиктивный номер для непереводимого источника. Новая версия прямо разделяет два типа установки: с публичным адресом для исходящих ошибок и без него. У второго типа всё равно остаётся способ послать нужное сообщение.

Реестр IANA называет этот /32 «IPv4 dummy address». В таблице допустимо его использование как источника; как назначение он недействителен, не пересылается и не объявлен глобально достижимым. Значит, 192.0.0.8 на экране трассировки — метка выбора транслятора, а не адрес конкретного узла IPv6, породившего ошибку. Рисовать по нему реальный промежуточный маршрутизатор — удобная картинка с неверной подписью.

Подлинный IPv6-источник предлагается поместить в объект Node Identification, в подполе IP Address. Если объект добавлен, исходный адрес должен в нём присутствовать, а контрольная сумма заголовка расширения должна быть обновлена. Если источник переводится обычным способом, проект запрещает использовать фиктивный адрес и добавлять это расширение. Резервный маршрут существует для конкретного отсутствия соответствия, а не для любого ICMP-сообщения.

Есть ещё одно условие видимости. Средства вроде traceroute должны уметь разобрать и показать Node Identification. Иначе пакет содержит исходный IPv6-адрес, а оператор видит только 192.0.0.8. Отправка данных устройством и показ данных программой — разные этапы. Проверка только заголовка IPv4 ничего не скажет о втором этапе.

Packet Too Big заставляет разделить пользу и атрибуцию

Сообщение Packet Too Big помогает отправителю выбрать размер пакета для пути. Расширение, которое сохранило бы имя узла, нельзя присоединить к ICMPv6 PTB до перевода. Транслятор сначала создаёт ICMPv4-ошибку и затем может добавить объект идентификации. Проект разрешает в этом случае вообще не добавлять объект, но рекомендует всё равно перевести ошибку с фиктивным источником и не отбрасывать её.

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

Прежде чем выбирать адрес ответа, устройство должно понять, что ошибка относится именно к ранее переведённому IPv4-трафику, а не к обычному IPv6-обмену. Выделенный IPv6-адрес или /64 для трансляции облегчают задачу. Если один и тот же адрес применяется обоими потоками, может потребоваться состояние или разбор заголовка пакета, вызвавшего ошибку. Запись в реестре IANA не заменяет эту операционную классификацию.

Datatracker показывает рабочий Internet-Draft группы v6ops, отправленный в IESG и находящийся на оценке AD. В случае утверждения он изменил бы RFC 6791 и RFC 7915. Новой заявки в IANA нет; готовой записи о развёрнутом оборудовании в тексте тоже нет. Прежние статьи о Node Identification разбирали общее раскрытие личности узла и незнакомый AFI. Здесь решается более узкий вопрос: от какого IPv4-адреса вернуть ошибку, когда исходная IPv6-личность не переводится и публичного адреса у транслятора нет.

Источники