Что согласует IPv6CP и чему всё ещё нужен префикс
Link-local адрес на интерфейсе PPP — это шаг настройки, а не доступ к IPv6. Отделите обмен идентификаторами от префиксов, маршрутов и интеграции клиента.
IPv6 поднимается на интерфейсе PPP, появляется link-local адрес, и изменение объявляют завершённым. Затем ничего не маршрутизируется, глобального адреса нет, а проверка до публичного назначения не проходит, хотя интерфейс всё ещё выглядит настроенным. Канал поднялся; сеть никогда. Выполните четыре проверки ниже по порядку и остановитесь на той, которая объясняет разрыв.
Что на самом деле доказывает link-local адрес
IPv6CP поднимает IPv6 на канале PPP и согласует идентификатор интерфейса для каждой стороны. Этот идентификатор порождает link-local адрес, которого достаточно для связи с партнёром по каналу и недостаточно для доступа к чему-либо ещё. Адрес доказывает, что канал готов к IPv6, и ничего не доказывает о сети за партнёром. Читать его как адрес доступа — та ошибка, с которой начинается большинство таких разборов.
Четыре вопроса ниже разделяют то, что решает канальный уровень, и то, что должна предоставить служба. Отвечайте по порядку, потому что на более поздний вопрос нельзя ответить, пока открыт предыдущий.
| Question | Answered by | What it does not settle |
|---|---|---|
| Is IPv6 up on the link? | IPv6CP: interface identifiers, then link-local addresses | Any address reachable beyond the peer |
| Where does a global prefix come from? | Router advertisement, delegated prefix, DHCPv6 or static configuration | IPv6CP carries no prefix of its own |
| Who owns the routes? | The client's tunnel configuration and the server's return path | A link-local address implies no route at all |
| How does this client get configured? | Explicit tunnel settings or router advertisements, depending on the client | The standard does not choose for the implementation |
Откуда должен взяться префикс
Глобальному адресу нужен префикс откуда-то: объявление маршрутизатора, делегированный префикс, DHCPv6 или статическая конфигурация. IPv6CP не несёт ни одного, и никакое ожидание на канале его не создаст. RFC 5072 ставит IPv6CP как шаг настройки, который выполняется до того, как другие протоколы IPv6 начнут работать на канале, и это весь его охват: подготовить канал, а не пронумеровать сеть. Предоставьте префикс, и интерфейс начнёт нести трафик, а не просто существовать.
Объявления маршрутизатора — обычный ответ в локальной сети и менее надёжный в туннеле «точка-точка», потому что клиент должен и отправлять запросы, и принимать ответ. Некоторые туннельные клиенты не делают ни того, ни другого. Проверьте, что клиент готов принять, прежде чем решать, что сервер должен это отправить.
Тот же префикс должен быть достижим и с другого конца. Клиент, у которого есть глобальный адрес, но нет обратного пути, настроен, но не подключён.
Маршруты — отдельное обещание
Даже с адресом клиент должен знать, какие назначения относятся к туннелю, а серверу нужен обратный путь для этих назначений. Это два решения, принятые в двух местах. Туннелю, несущему весь трафик IPv6, нужен маршрут по умолчанию на клиенте и обратный маршрут на сервере; разделённому туннелю нужно, чтобы обе стороны договорились об одном списке префиксов. Когда они не совпадают, трафик уходит и никогда не возвращается.
Запишите список, прежде чем что-либо настраивать. Если план говорит, что через туннель идёт только корпоративный префикс, у клиента не должно быть маршрута IPv6 по умолчанию, и сервер не должен его объявлять.
Остальное решает интеграция клиента
Некоторые туннельные клиенты настраивают IPv6 явно. Например, Network Extension от Apple принимает адрес, префикс и набор маршрутов для туннеля, поэтому приложение, которое его использует, не ждёт объявления в стиле Ethernet. Другие полагаются на объявления маршрутизатора, приходящие по каналу. Обе модели законны и требуют разного поведения сервера, поэтому неверный выбор даёт клиента, который вечно ждёт сообщения, которого никто не отправляет. Определите модель, прежде чем менять сервер.
Старое имя интерфейса вроде ppp0 ничего не доказывает о стеке, который работает сегодня. Современный клиент может использовать API пакетного туннеля вместо интерфейса PPP, и предположение, что он ведёт себя как историческое соединение, — это способ сломать работающую схему. Спрашивайте версию клиента и способ предоставления, а не имя интерфейса.
Напишите план, который нужен клиенту
Полное описание охватывает три вещи: какой адрес есть у клиента, какие назначения должен нести туннель и как сеть отправляет ответы обратно. Link-local адрес не отвечает ни на один из них, а принятое объявление отвечает лишь на часть одного. Проверяйте каждый пункт отдельно, вместо того чтобы принимать зелёный индикатор. Затем запишите, какой механизм предоставил каждый ответ, потому что эта запись превращает следующий отчёт об IPv6 в проверку на две минуты.
Храните запись вместе с документацией службы и обновляйте её при изменении клиента. План, верный для клиента PPP, может быть неверным для клиента пакетного туннеля на той же службе. Четыре вопроса остаются теми же; меняются только ответы.