Какво договаря IPv6CP и какво все още изисква префикс
Локалният адрес на връзката на PPP интерфейса е стъпка при настройката, а не достъп до IPv6. Разделете обмена на идентификатори от префиксите, маршрутите и интеграцията на клиента.
IPv6 се вдига на PPP интерфейса, появява се локален адрес на връзката и промяната се обявява за завършена. После нищо не се маршрутизира, глобален адрес няма, а тест към публична дестинация се проваля, докато интерфейсът все още изглежда конфигуриран. Връзката се вдигна; мрежата така и не се вдигна. Изпълнете четирите проверки по-долу по ред и спрете на тази, която обяснява разликата.
Какво всъщност доказва локалният адрес на връзката
IPv6CP вдига IPv6 на PPP връзката и договаря идентификатор на интерфейса за всяка страна. Този идентификатор създава локален адрес на връзката, който е достатъчен, за да се говори с партньора по връзката, и недостатъчен, за да се достигне нещо друго. Адресът доказва, че връзката е готова за 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 интерфейс и допускането, че се държи като историческа връзка, е начинът да се счупи работещ дизайн. Питайте за версията на клиента и метода на осигуряване, не за името на интерфейса.
Напишете плана, който клиентът има нужда
Пълното описание покрива три неща: кой адрес държи клиентът, кои дестинации трябва да носи тунелът и как мрежата изпраща отговорите обратно. Локалният адрес на връзката не отговаря на нито едно от тях, а приета обява отговаря само на част от едно. Проверявайте всеки пункт отделно, вместо да приемате зелен индикатор. После запишете кой механизъм е доставил всеки отговор, защото този запис превръща следващия доклад за IPv6 в проверка от две минути.
Пазете записа с документацията на услугата и го обновявайте, когато клиентът се промени. План, който е бил правилен за PPP клиент, може да е грешен за клиент на пакетен тунел в същата услуга. Четирите въпроса остават същите; местят се само отговорите.