Кратко

  • RFC 4620 дал диагностическим средствам IPv6 прямой способ спросить узел о выбранных именах или адресах, в том числе в сети без DNS и глобальной маршрутизации.
  • Узел мог отказаться от ответа. Полученные сведения оставались локальным самоотчётом, а не подтверждённой идентичностью или авторитетной записью.

Анализ

Автоматически настроенный IPv6-адрес может работать, но оператору всё равно трудно понять, какому устройству он принадлежит. При подключении канала или поиске неисправности локальная сеть может не иметь DNS, а адрес канала связи не обязан присутствовать в публичной зоне. Запросить у доступного узла имя или другие адреса, которые он связывает с собой, иногда полезно для диагностики.

В августе 2006 года Майкл Кроуфорд и Брайан Хаберман описали такую возможность в RFC 4620. Документ имел статус Experimental и ограничивал применение диагностикой, отладкой и управлением сетью. Он прямо оставлял DNS авторитетным источником имён и адресов в глобальном Интернете. Иными словами, запрос Node Information не создавал ещё один глобальный каталог: он помогал исследовать канал, где DNS или глобальная маршрутизация недоступны.

Сообщения передавались через ICMPv6: тип 139 для запроса, тип 140 для ответа. Запрос указывал узел-получатель и предмет вопроса; адреса могли различаться. Определённые Qtype включали запрос без данных, имя узла, адреса IPv6 и адреса IPv4. Флаги адресного запроса позволяли выбрать области адресов и запросить все адреса либо ограниченный набор. Диагностическая программа могла спросить активный узел о том, что он сообщает, не предполагая, что ответ полностью перечисляет все интерфейсы.

Отказ был предусмотренным результатом. Код ответа различал успех, отказ и неизвестный тип запроса. Даже успешный ответ мог не содержать данных. Поэтому отсутствие ответа, отказ, неподдерживаемый тип и пустой результат имеют разный смысл; ни один из них сам по себе не доказывает отсутствие узла. Перед обработкой запроса отвечающий узел проверял, принадлежит ли адрес назначения его unicast- или anycast-адресам либо локальной multicast-группе, к которой он присоединился. Локальная политика могла отбросить запрос.

64-битное значение nonce копировалось из запроса в ответ, чтобы сопоставить сообщения и затруднить слепую подделку. Авторы оговорили ограничение: наблюдатель, способный перехватить обмен, может обойти эту защиту. Для подлинности связи предлагался IPsec, а для решений, связанных с безопасностью, требовалась отдельная аутентификация.

Раскрытие также ограничивалось. Настройка по умолчанию должна была отклонять запросы с глобальных адресов источника; документ рекомендовал ограничивать частоту ответов и управлять выдачей временных IPv6-адресов для защиты приватности. IANA по-прежнему регистрирует типы 139 и 140, но регистрация номера не означает, что произвольный хост ответит. RFC 4620 приводил ping6 в KAME, USAGI и других реализациях IPv6 как пример диагностики. Документация Nmap и сейчас описывает скрипт обнаружения, использующий эти запросы. Это свидетельствует о возможностях инструментов, но не об их распространённости в сетях.

Историческое значение RFC 4620 было ограниченным и ясным: самоотчёт узла стал доступен диагностике, но право на отказ и слабая доказательная сила ответа остались видимыми. Такой ответ не подтверждал, кто управляет устройством, кому принадлежит имя или какая организация за ним стоит. Он не заменял авторитетный реестр активов.

Источники