Кратко

  • RFC 1888 сначала советовал спроектировать нативный план IPv6 и лишь затем описывал четыре необязательных механизма совместимости с NSAP.
  • Обратимость не устраняла различия: OSI Area могла включать несколько каналов, разные префиксы не агрегировались, а идентичность хоста не превращалась в адрес конкретного интерфейса.
  • RFC 4048 отделил предположительно неиспользованные механизмы от двух ошибок обратного отображения; RFC 4548 исправил лишь узкую функцию пространства ICP.

Пересмотр начался не с одной причины

RFC 4048 в 2005 году сообщил: насколько было известно IETF, отображения NSAP внутри IPv6 никогда серьёзно не использовались и не поддерживались реализациями IPv6. Это атрибутированная оценка в пределах институционального знания, а не перепись всех частных экспериментов. Она обосновывала перевод RFC 1888 в Historic и возврат прежнего IPv6-префикса в Reserved.

Однако направление IPv6-внутри-NSAPA недавно вызвало интерес, в том числе возможным применением в ATM. Здесь нашлись две конкретные ошибки раздела 6. ICP — шестнадцатибитное поле из двух октетов, а не один третий октет. Четыре десятичные цифры IDI кодируются двумя октетами BCD, а не произвольным двоичным числом.

Чтобы понять, почему выводы различались, надо вернуться к RFC 1888. Документ вышел в августе 1996 года как Experimental, а не как Internet Standard. Ещё до формул он рекомендовал владельцам запланированных или внедрённых OSI NSAP создать нативный план IPv6 и осмысленно перенести локальную топологию.

Адресная иерархия не совпадала с физической

RFC называл три ограничения. В OSI/IS-IS одна Area могла охватывать несколько физических каналов, тогда как подсеть IPv6 предполагала один канал. Копирование номера Area в номер подсети сохраняло обозначение, но не доказывало соседство на последнем участке.

Для глобального масштаба требовался общий агрегируемый префикс. Обычные IPv6-адреса и ограниченные NSAPA-отображения не получали его автоматически. Алгоритм мог без потерь восстановить каждый исходный адрес и одновременно увеличить число объявляемых маршрутов.

Кроме того, несколько NSAP могли идентифицировать конечную OSI-систему целиком, поверх её интерфейсов. IPv6 назначает адреса интерфейсам. Преобразование идентификатора хоста не выбирало доступный интерфейс. Перенос ES-IS, IS-IS и их инфраструктуры оставался вне области RFC; контрольная плоскость не следовала за байтами.

Четыре механизма оставляли разные пробелы

Первый помещал ограниченную ICD- или DCC-NSAPA в шестнадцать октетов IPv6 с началом 0x02. Внутри подмножества он был алгоритмическим и обратимым, но мог давать неэффективную маршрутизацию. Для Area с несколькими физическими подсетями требовался дополнительный механизм.

Второй начинался с 0x03 и обрезал NSAPA. Оставшаяся иерархия вела к Area, но полная цель должна была прийти в NSAPA destination option либо внутри инкапсулированного CLNP-пакета. Получатель локально выбирал: переслать, декапсулировать или отбросить. Автоматическое обнаружение последнего участка не определялось; статическая таблица или будущий аналог ES-IS были только вариантами.

Разрыв портил и диагностику. Обычная автоконфигурация не работала без изменений, полную NSAPA нельзя было просто поместить в IPv6 routing header, а ICMP-ошибка на обрезанный адрес источника могла не добраться до настоящего отправителя. Механизм терял не только доставку, но и квитанцию о причине сбоя.

Третий вариант сохранял обычный IPv6 и передавал полную NSAPA источника или назначения в option. Узлы, не использующие функцию, не обязаны были её реализовывать. Наличие поля подтверждало отправку данных, но не поддержку или действие получателя.

Четвёртый помещал IPv6 внутрь двадцатиоктетной NSAPA под IANA AFI 35 и ICP 0. Рекурсивное вложение запрещалось из-за аномалий и петель, связанных с RFC 1326. RFC 1629 даёт контекст NSAP для ATM, а RFC 3513 — более поздней архитектуры IPv6; ни один не доказывает эксплуатацию RFC 1888.

Исправление части не вернуло целое

RFC 4548 в 2006 году заменил только раздел 6. Под AFI 35 десятичный ICP 0 обозначает формат IPv6, ICP 1 — IPv4. Значения 2–9999 требуют определённого и опубликованного формата и IETF consensus. Текущий реестр IANA OSI NSAPA Numbers хранит эти значения, но строка реестра не свидетельствует о парсере, включённой функции, маршруте или трафике.

Информационные страницы RFC Editor для RFC 1888, RFC 4048 и RFC 4548 фиксируют статус и частичную замену. RFC 4548 не возродил ограниченные и обрезанные NSAP-в-IPv6 отображения. Он сохранил корректную узкую регистрацию, не отменяя исторический статус окружающего эксперимента.

Так возникает лестница доказательств: план в документе, обратимый алгоритм, допустимый синтаксис, регистрация кода, парсер, включение, маршрут, последний участок, решение получателя, результат приложения и независимое наблюдение использования. Каждая ступень требует собственной квитанции.