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