Що узгоджує 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, може бути хибним для клієнта пакетного тунелю на тій самій службі. Чотири питання залишаються тими самими; змінюються лише відповіді.