IPv6CP не туралы келіседі және неге әлі префикс керек
PPP интерфейсіндегі link-local мекенжай — конфигурация қадамы, IPv6 қатынасы емес. Идентификаторлар алмасуын префикстерден, маршруттардан және клиент интеграциясынан бөліңіз.
IPv6 PPP интерфейсінде көтеріледі, link-local мекенжай пайда болады және өзгеріс аяқталды деп жарияланады. Содан кейін ештеңе маршрутталмайды, ғаламдық мекенжай жоқ, ал интерфейс әлі конфигурацияланған болып көрінгенмен, қоғамдық межеге тест сәтсіз аяқталады. Байланыс көтерілді; желі ешқашан көтерілмеді. Төмендегі төрт тексеруді ретімен орындаңыз және айырмашылықты түсіндіретін тексеруде тоқтаңыз.
link-local мекенжай шын мәнінде нені дәлелдейді
IPv6CP PPP байланысында IPv6-ны көтереді және әр жақ үшін интерфейс идентификаторын келіседі. Сол идентификатор 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-ны айқын конфигурациялайды. Мысалы, Apple-дың Network Extension туннель үшін мекенжай, префикс және маршруттар жиынтығын алады, сондықтан оны пайдаланатын қолданба Ethernet стиліндегі хабарламаны күтпейді. Басқалары байланыс арқылы келетін маршрутизатор хабарламаларына сүйенеді. Екі модель де заңды және түрлі серверлік мінез-құлықты қажет етеді, сондықтан қатесін таңдау ешкім жібермейтін хабарламаны мәңгі күтетін клиент жасайды. Серверді өзгерту алдында модельді анықтаңыз.
ppp0 сияқты ескі интерфейс атауы бүгін жұмыс істеп тұрған стек туралы ештеңе дәлелдемейді. Қазіргі клиент PPP интерфейсінің орнына пакеттік туннель API-ін пайдалануы мүмкін, ал оның тарихи қосылым сияқты әрекет етеді деп болжау — жұмыстағы дизайнды бұзудың жолы. Интерфейс атауын емес, клиент нұсқасын және жеткізу әдісін сұраңыз.
Клиентке қажет жоспарды жазыңыз
Толық сипаттама үш нәрсені қамтиды: клиенттің қандай мекенжайы бар, туннель қандай межелерді тасымалдауы керек және желі жауаптарды қалай қайтарады. link-local мекенжай олардың ешқайсысына жауап бермейді, ал қабылданған хабарлама тек біреуінің бір бөлігіне жауап береді. Жасыл индикаторды қабылдаудың орнына әр тармақты бөлек тексеріңіз. Содан кейін қай механизм әр жауапты бергенін жазыңыз, өйткені бұл жазба келесі IPv6 есебін екі минуттық тексеріске айналдырады.
Жазбаны қызмет құжаттамасымен бірге ұстаңыз және клиент өзгергенде жаңартыңыз. PPP клиенті үшін дұрыс болған жоспар сол қызметтегі пакеттік туннель клиенті үшін қате болуы мүмкін. Төрт сұрақ өзгеріссіз қалады; тек жауаптар жылжиды.