Ką derasi IPv6CP ir kam vis dar reikia prefikso
Link-local adresas PPP sąsajoje yra sąrankos žingsnis, o ne IPv6 prieiga. Atskirkite identifikatorių mainus nuo prefiksų, maršrutų ir kliento integracijos.
IPv6 pakyla PPP sąsajoje, atsiranda link-local adresas, ir pakeitimas paskelbiamas baigtu. Tada niekas nemarsrutizuojama, nėra visuotinio adreso, o bandymas į viešą paskirtį nepavyksta, nors sąsaja vis dar atrodo sukonfigūruota. Ryšys pakilo; tinklas niekada. Atlikite keturis patikrinimus žemiau iš eilės ir sustokite ties tuo, kuris paaiškina skirtumą.
Ką link-local adresas iš tikrųjų įrodo
IPv6CP pakelia IPv6 PPP ryšyje ir derasi dėl sąsajos identifikatoriaus kiekvienai pusei. Tas identifikatorius sukuria link-local adresą, kurio pakanka kalbėtis su partneriu per ryšį ir nepakanka pasiekti ką nors kita. Adresas įrodo, kad ryšys paruoštas IPv6, ir neįrodo nieko apie tinklą už partnerio. Skaityti jį kaip prieigos adresą yra klaida, nuo kurios prasideda dauguma šių tyrimų.
Keturi klausimai žemiau atskiria, ką nusprendžia ryšio sluoksnis, nuo to, ką turi pateikti paslauga. Atsakykite į juos iš eilės, nes į vėlesnį klausimą negalima atsakyti, kol ankstesnis dar atviras.
| 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 |
Iš kur turi ateiti prefiksas
Visuotiniam adresui reikia prefikso iš kažkur: maršrutizatoriaus skelbimo, deleguoto prefikso, DHCPv6 arba statinės konfigūracijos. IPv6CP neneša nė vieno, ir joks laukimas ryšyje jo nesukurs. RFC 5072 priskiria IPv6CP sąrankos žingsniui, kuris vyksta prieš kitiems IPv6 protokolams pradedant veikti ryšyje, ir tai yra visa jo apimtis: paruošti ryšį, o ne numeruoti tinklą. Pateikite prefiksą ir sąsaja pradės perduoti srautą, o ne tik egzistuoti.
Maršrutizatoriaus skelbimai yra įprastas atsakymas vietiniame tinkle ir mažiau patikimas taško į tašką tunelyje, nes klientas turi ir siųsti užklausas, ir priimti atsakymą. Kai kurie tunelio klientai nedaro nė vieno. Patikrinkite, ką klientas pasirengęs priimti, prieš nuspręsdami, kad serveris turi tai siųsti.
Tas pats prefiksas turi būti pasiekiamas ir iš kito galo. Klientas, turintis visuotinį adresą, bet neturintis grįžimo kelio, yra sukonfigūruotas, o ne prijungtas.
Maršrutai yra atskiras pažadas
Net ir turint adresą, klientas turi žinoti, kurios paskirties vietos priklauso tuneliui, o serveriui reikia grįžimo kelio toms paskirtims. Tai du sprendimai, priimti dviejose vietose. Tunelis, perduodantis visą IPv6 srautą, turi turėti numatytąjį maršrutą kliente ir grįžimo maršrutą serveryje; padalintas tunelis reikalauja, kad abi pusės sutartų dėl to paties prefiksų sąrašo. Kai jos nesutaria, srautas išeina ir niekada negrįžta.
Užrašykite sąrašą prieš ką nors konfigūruodami. Jei planas sako, kad per tunelį eina tik įmonės prefiksas, klientas neturėtų turėti numatytojo IPv6 maršruto, o serveris neturėtų jo skelbti.
Likusį lemia kliento integracija
Kai kurie tunelio klientai IPv6 konfigūruoja aiškiai. Pavyzdžiui, Apple Network Extension paima adresą, prefiksą ir maršrutų rinkinį tuneliui, todėl jį naudojanti programa nelaukia Ethernet stiliaus skelbimo. Kiti pasikliauja per ryšį ateinančiais maršrutizatoriaus skelbimais. Abu modeliai yra teisėti ir reikalauja skirtingo serverio elgesio, todėl netinkamas pasirinkimas sukuria klientą, kuris amžinai laukia pranešimo, kurio niekas nesiunčia. Nustatykite modelį prieš keisdami serverį.
Senas sąsajos pavadinimas, pavyzdžiui, ppp0, neįrodo nieko apie šiandien veikiančią krūvą. Šiuolaikinis klientas gali naudoti paketų tunelio API vietoj PPP sąsajos, o prielaida, kad jis elgiasi kaip istorinis ryšys, yra būdas sugadinti veikiantį dizainą. Klauskite kliento versijos ir tiekimo metodo, o ne sąsajos pavadinimo.
Parašykite planą, kurio klientui reikia
Išsamus aprašymas apima tris dalykus: kokį adresą turi klientas, kokias paskirtis turi perduoti tunelis ir kaip tinklas siunčia atsakymus atgal. Link-local adresas neatsako į nė vieną jų, o priimtas skelbimas atsako tik į vieno dalį. Tikrinkite kiekvieną punktą atskirai, o ne priimkite žalią indikatorių. Tada užrašykite, kuris mechanizmas pateikė kiekvieną atsakymą, nes šis įrašas paverčia kitą IPv6 ataskaitą dviejų minučių patikrinimu.
Laikykite įrašą kartu su paslaugos dokumentacija ir atnaujinkite jį, kai pasikeičia klientas. Planas, kuris buvo teisingas PPP klientui, gali būti neteisingas paketų tunelio klientui toje pačioje paslaugoje. Keturi klausimai lieka tie patys; juda tik atsakymai.