Кратко

  • PPP сначала должен был перейти в фазу сетевых протоколов, а IPv6CP — в Opened; управляющие пакеты имели значение 0x8057, а допущенные пакеты IPv6 — 0x0057.
  • Разные Interface-Token различали две стороны этой линии. Они не аутентифицировали участника и не доказывали глобальную уникальность, владение адресом, достижимость или получение.

Особенно показателен случай нулевого запроса. В RFC 2023 сторона могла ответить на нулевой Interface-Token ненулевым предложением в Configure-Ack. RFC 2472 позже заменила этот ответ на Configure-Nak. Исправление восстановило смысл квитанций: Ack принимает запрос, Nak предлагает иной результат.

До IPv6 стояло два шлюза состояния

По RFC 1661 протокол LCP устанавливал, настраивал и проверял канал данных. Затем могла проходить аутентификация. Только после этого PPP входил в фазу сетевых протоколов, где отдельный NCP настраивал каждый сетевой протокол.

RFC 2023 назвала NCP для IPv6 протоколом IPv6CP. Его сообщения обозначались полем PPP 8057 и не могли обмениваться раньше сетевой фазы. Пакеты IPv6 имели значение 0057 и ждали состояния IPv6CP Opened.

Поэтому LCP Opened не означал готовность IPv6. Сетевая фаза разрешала переговоры, но не завершала их. IPv6CP Opened снимал запрет на класс пакетов, но не создавал маршрут и не свидетельствовал об отправке.

Уникальность возникала из сравнения

Опция Interface-Token имела тип 1, длину 6 октетов и 32-битное значение. Каждая сторона сначала выбирала пробный маркер. RFC советовала брать несколько источников различий; одного канального адреса могло не хватить. При отсутствии хорошего источника ноль позволял попросить предложение у другой стороны.

Получатель сравнивал удалённое значение с собственным последним Configure-Request. Разные ненулевые значения можно было подтвердить. Равные ненулевые значения означали коллизию и требовали Configure-Nak с новым предложением. Два нуля завершали автоматические переговоры через Configure-Reject; значения по умолчанию не было.

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

Ответы подтверждали разные факты

Configure-Ack ненулевого маркера подтверждал конкретный запрос в одном направлении. Он не завершал встречное направление и не устанавливал личность участника. RFC 2023 не рассматривала вопросы безопасности; Interface-Token не был учётными данными.

Configure-Nak фиксировал несогласие и возможную замену. Он не доказывал, что новый запрос был отправлен, принят или применён. Configure-Reject удалял опцию из последующих запросов. Он мог означать отсутствие поддержки либо неразрешимый случай ноль против нуля, но не успешную ручную настройку.

Выражение «уникален в канале PPP» само задавало предел. Маркеры различали две стороны одной сессии, а не занимали место во всемирном пространстве имён. Они не были постоянным именем устройства, человека, организации или абонента и не давали права собственности на сформированный адрес.

Возможность приёма ещё не означала передачу

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

RFC 2472 заменила 32-битный маркер 64-битным Interface-Identifier и исправила нулевой ответ. Затем RFC 5072 заменила RFC 2472. Нынешний реестр IANA сохраняет 0057 и 8057, но ссылается для IPv6CP на RFC 5072, а старое значение сжатия 004f помечает историческим. Значит, RFC 2023 — историческая стадия, а не современная инструкция.

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

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

Источники