Кратко
- Сетевая фаза PPP и состояние IPV6CP
Openedнеобходимы для IPv6, но сами по себе не доказывают существование пригодного глобального адреса. - Отказ от DAD глобального адреса заменяет проверку двумя предпосылками топологии; их нужно подтверждать отдельно от согласования IPV6CP.
После сбоя остаётся неполный журнал: IPV6CP открылся, но адрес и маршрут не сохранились. Команда пытается восстановить событие по последней зелёной строке и обнаруживает, что она описывает лишь один переход.
RFC 5072 требует, чтобы PPP вошёл в фазу сетевого протокола, а IPV6CP достиг Opened до обмена пакетами IPv6. Это точная граница допуска. Она не сообщает, был ли сформирован глобальный unicast-адрес, прошёл ли он проверку, появился ли маршрут и ответил ли удалённый узел.
В документе определён один параметр IPV6CP — 64-битный Interface-Identifier. Configure-Request несёт ровно один экземпляр. Различные ненулевые значения получают Ack; совпадающие вызывают Nak с другим предложением; два нуля завершают согласование через Reject. Гарантия ограничена различием двух концов этой PPP-линии.
Если допустимый идентификатор согласовать не удалось, RFC не разрешает подставить значение по умолчанию. Восстановление не определено, а ручная настройка названа лишь одним подходом. Поэтому автоматически выбранное системой значение должно иметь собственную запись о происхождении.
Согласованный идентификатор участвует в создании локального link-local-адреса. Для глобального адреса текст предупреждает: нельзя предполагать, что идентификатор тот же. Узел может породить один или несколько иных. Значит, протокол IPV6CP не восстанавливает фактический глобальный адрес.
Отсюда следует различие в Duplicate Address Detection. Для link-local на уже различённых концах DAD избыточен. Для глобального адреса он может быть избыточен только при одновременном выполнении двух условий.
Префикс из Router Advertisement должен быть эксклюзивным для этой PPP-линии. Завершающий маршрутизатор не должен сам создавать глобальный адрес из объявленного префикса. Лишь тогда RFC 5072 рекомендует администратору установить DupAddrDetectTransmits в ноль.
Ноль означает не успешную проверку, а отсутствие проверки. Доверие переносится на систему выдачи префиксов и конфигурацию маршрутизатора. Повторное использование префикса или новый адрес на маршрутизаторе разрушает основание исключения, хотя старый Configure-Ack остаётся неизменным.
RFC 4862 задаёт общий порядок: DAD проводится до назначения unicast-адреса независимо от SLAAC, DHCPv6 или ручного способа, кроме перечисленных исключений. Он же определяет ноль передач как отключённый DAD. Следовательно, альтернативное доказательство должно быть наблюдаемым.
Глобальный адрес появляется разными путями. При stateless-настройке узел соединяет префикс Router Advertisement с идентификатором. При stateful-настройке адрес предоставляет сервер вроде DHCPv6. Объявленный префикс, выданный адрес, запись интерфейса, маршрут и успешный пакет — отдельные этапы.
Рекомендации для идентификатора позднее изменились. RFC 8064 формально обновил RFC 5072, рекомендовал непрозрачную схему RFC 7217 для стабильных SLAAC-адресов и отказ от внедрения постоянного канального адреса. Но наличие обновления не подтверждает реализацию на конкретном устройстве.
Состояние Opened также не заменяет аутентификацию. RFC 5072 отдельно перечисляет фильтрацию доступа, аутентификацию и шифрование и отмечает риск повтора для метода с MD5. Успешный IPv6-контроль не решает автоматически вопрос личности или полномочий узла.
Для расследования нужны: LCP и сетевая фаза; результат аутентификации и авторизации; полный обмен IPV6CP; оба идентификатора и способы их создания; link-local; способ получения глобального адреса, префикс и сроки; DAD либо доказательства двух условий; установленный адрес и маршрут; источник наблюдаемого пакета; ответ; итог приложения.
Это операционная рекомендация, а не добавленное требование стандарта. Она следует разделению слоёв реальности Heng Lu: намерение, состояние протокола, конфигурация, сетевое наблюдение и деловой вывод соединяются доказательствами, а не цветом одной строки.
Sources
- RFC 5072 — IPv6 поверх PPP
- RFC 5072 — канонический текст
- Запись RFC Editor для RFC 5072
- Поиск исправлений RFC 5072
- Запись RFC 5072 в IETF Datatracker
- История RFC 5072 в IETF Datatracker
- RFC 1661 — протокол точка-точка
- RFC 2472 — заменённая спецификация IPv6 поверх PPP
- RFC 4291 — архитектура адресации IPv6
- RFC 4861 — обнаружение соседей IPv6
- RFC 4862 — автоматическая настройка IPv6
- RFC 7217 — семантически непрозрачные идентификаторы
- RFC 8064 — рекомендация для стабильных идентификаторов
- RFC 8200 — IPv6
- IANA — назначения полей PPP
- Heng Lu — приоритет работающего кода
- Heng Lu — минимальная начальная спецификация
- Heng Lu — слои реальности
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
