Кратко

  • RFC 1877 добавил четыре параметра IPCP для основных и запасных адресов DNS и NBNS; четыре нулевых октета явно просили соседа вернуть предложение в Configure-Nak.
  • Nak не принимал и не исправлял запрос. Клиент должен был отправить новый Configure-Request с предложенным значением и получить соответствующий Ack.
  • Согласованный адрес не доказывал состояние Opened, достижимость, ответ, авторитетность данных или использование приложением. Для каждого шага требовалась отдельная запись.

Полезная информация приходила в возражении

После дозвона компьютер мог передавать IP-пакеты, но не знать, куда послать вопрос о доменном имени. RFC 1877, опубликованный в декабре 1995 года как Informational, расширил IPCP. Адреса служб имён стали частью уже существующего согласования IP поверх PPP, а не отдельным протоколом обнаружения.

Документ назначил тип 129 основному DNS, 130 основному NBNS, 131 запасному DNS и 132 запасному NBNS. Формат у всех одинаков: тип, длина шесть и четырёхоктетный IPv4-адрес. Современный реестр номеров PPP IANA по-прежнему связывает эти номера с RFC 1877. Это свидетельство назначения, а не сегодняшнего использования.

Сам исходный текст требует оговорки. В описании поля раздела 1.3 есть одинокая фраза об основном сервере NBNS, хотя заголовок раздела, схема и назначение типа 131 согласованно указывают на запасной DNS. Это противоречие ограничивает точность документа; оно не позволяет превращать случайную фразу в семантику протокола.

Не знающий адреса клиент отправлял четыре нуля. Значение прямо означало просьбу предоставить сведения в Configure-Nak. Можно было намеренно указать и другой неприемлемый адрес. Сосед отвергал его и возвращал тот, который считал допустимым.

Так отказ сохранял распределение полномочий. Удалённая сторона говорила, что готова принять. Локальная сторона ещё решала, повторять ли запрос. Автоматическое применение значения из Nak превратило бы совет в чужую команду.

Согласие находилось не в Nak, а в следующем Request

RFC 1877 повторил формат и поведение параметра IP-Address из RFC 1332. Configure-Request формулирует желаемую конфигурацию. Configure-Nak отклоняет значения и предлагает допустимые. Configure-Reject без изменений возвращает неизвестный или не подлежащий согласованию параметр. Configure-Ack принимает текущий запрос без исправления.

Пусть клиент отправил тип 129 со значением 0.0.0.0, а сосед вернул 192.0.2.53 в Nak. Захват доказывает получение, понимание параметра и предложение адреса. Он не доказывает установку. Клиент должен отправить новый Request с 192.0.2.53. Только Ack, относящийся к этому запросу, фиксирует согласие в данной попытке.

Идентификатор и порядок пакетов входят в доказательство. Старый Nak может опоздать, Ack — повториться, а новый Request — уже содержать другое значение. Если оставить лишь итоговую строку DNS, исчезнут автор предложения, принявшая сторона и срок действия решения.

RFC 1661 помещает IPCP после нескольких границ. Сначала готов физический канал, затем LCP устанавливает линию, при необходимости заканчивается аутентификация, и только потом начинается фаза сетевых протоколов. Каждый NCP открывается отдельно. Подтверждение одного параметра DNS не означает, что IPCP достиг Opened и IP-трафик уже допустим.

Одинаковый формат не делал DNS и NBNS одной системой

RFC 1034 и RFC 1035 описывают DNS с резолверами, серверами и распределённой властью над именами. RFC 1001 и RFC 1002 задают службу имён NetBIOS поверх TCP/UDP. Одинаковая оболочка IPCP упрощала реализацию, но не объединяла запросы, данные и доверие.

Основной и запасной адреса согласовывались независимо. Если были оба, RFC советовал сначала обращаться к основному. Здесь «основной» задавал порядок выбора локальным PPP-клиентом. Он не утверждал, что сервер хранит главную копию зоны DNS. Одинаковое слово в разных слоях не переносит полномочия.

Результат мог быть частичным: основной DNS без запасного, DNS без NBNS, параметры из разных раундов. Общей атомарной фиксации четырёх адресов не существовало. По умолчанию каждый адрес отсутствовал. Пропуск не означал неограниченный или неявно унаследованный сервер.

Топология могла опровергнуть полезность правильного значения

RFC 1877 предлагал не включать параметры в список рекомендуемых IPCP. Их полезность зависела от топологии удалённой сети и приложения локальной стороны. Корректный и согласованный адрес мог оказаться вне установленного маршрута. Сервер мог отвечать на DNS, когда программе нужен NBNS. Полученный ответ мог не пройти локальную проверку.

После Ack лестница продолжается: IPCP Opened, интерфейс и маршрут, отправленный пакет, достигнутый сервер, сопоставленные запрос и ответ, оценка авторитетности или целостности, выбор приложением и видимый результат. Статус соединения не может заменить эти наблюдения.

RFC 1877 не был стандартом Internet и не обсуждал безопасность. Первое не доказывает обязательность или повсеместное внедрение. Второе не является гарантией: согласование не аутентифицировало соседа, предложенный сервер или последующие ответы.

Историческая сила механизма — в узкой задаче. Он позволял запросить координату, получить предложение и явно согласовать значение. Работу службы по этому адресу должна была доказать уже действующая сеть.