Што договара 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 клиент може да биде погрешен за клиент на пакетен тунел на истата услуга. Четирите прашања остануваат исти; се поместуваат само одговорите.