Kva IPv6CP forhandlar om, og kva som framleis treng eit prefiks
Ei link-local-adresse på PPP-grensesnittet er eit oppsettsteg, ikkje IPv6-tilgang. Skil identifikatorutvekslinga frå prefiks, ruter og klientintegrasjon.
IPv6 kjem opp på PPP-grensesnittet, ei link-local-adresse dukkar opp, og endringa blir erklært ferdig. Så blir ingenting ruta, det finst inga global adresse, og ein test mot ein offentleg destinasjon feilar medan grensesnittet framleis ser konfigurert ut. Lenka kom opp; nettverket gjorde det aldri. Gå gjennom dei fire kontrollane nedanfor i rekkjefølgje og stopp ved den som forklarer gapet.
Kva ei link-local-adresse eigentleg beviser
IPv6CP bringer IPv6 opp på PPP-lenka og forhandlar ein grensesnittidentifikator for kvar side. Den identifikatoren gir ei link-local-adresse, som er nok til å snakke med motparten over lenka og ikkje nok til å nå noko anna. Adressa beviser at lenka er klar for IPv6, og ho beviser ingenting om nettverket bak motparten. Å lese ho som ei tilgangsadresse er feilen som startar dei fleste av desse undersøkingane.
Dei fire spørsmåla nedanfor skil det lenkjelaget avgjer frå det tenesta må levere. Svar på dei i rekkjefølgje, fordi eit seinare spørsmål ikkje kan svarast på medan eit tidlegare framleis er ope.
| 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 |
Kvar prefikset må kome frå
Ei global adresse treng eit prefiks frå ein stad: ei ruterannonse, eit delegert prefiks, DHCPv6 eller statisk konfigurasjon. IPv6CP ber ikkje eit, og inga mengd venting på lenka vil produsere eitt. RFC 5072 plasserer IPv6CP som oppsettsteget som køyrer før andre IPv6-protokollar verkar på lenka, og det er heile omfanget: å førebu lenka, ikkje å nummerere nettverket. Lever prefikset, og grensesnittet byrjar å bera trafikk i staden for berre å eksistere.
Ruterannonsar er det vanlege svaret på eit LAN og eit mindre påliteleg eit på ein punkt-til-punkt-tunnel, fordi klienten må både sende førespurnader og godta svaret. Nokre tunnelklientar gjer ingen av delane. Sjekk kva klienten er villig til å godta før du bestemmer at tenaren skal sende det.
Det same prefikset må vere nåbart frå den andre enden. Ein klient som har ei global adresse, men ingen returveg, er konfigurert, ikkje tilkopla.
Ruter er eit separat løfte
Sjølv med ei adresse må klienten vite kva destinasjonar som høyrer til tunnelen, og tenaren treng ein returveg for desse destinasjonane. Det er to avgjerder tekne på to stader. Ein tunnel som ber all IPv6-trafikk treng ei standardrute på klienten og ei returrute på tenaren; ein delt tunnel krev at begge sider blir samde om same prefiksliste. Når dei ikkje er samde, forlèt trafikken og kjem aldri tilbake.
Skriv ned lista før du konfigurerer noko. Viss planen seier at berre bedriftsprefikset går gjennom tunnelen, bør klienten ikkje ha ei standard IPv6-rute, og tenaren bør ikkje annonsere ei.
Klientintegrasjon avgjer resten
Nokre tunnelklientar konfigurerer IPv6 eksplisitt. Apples Network Extension tar til dømes ei adresse, eit prefiks og eit sett med ruter for tunnelen, så ein applikasjon som brukar han ventar ikkje på ei Ethernet-liknande annonse. Andre er avhengige av ruterannonsar som kjem over lenka. Begge modellane er legitime og krev ulik tenaråtferd, så det gale valet gir ein klient som ventar evig på ei melding ingen sender. Identifiser modellen før du endrar tenaren.
Eit gammalt grensesnittnamn som ppp0 beviser ingenting om stakken som køyrer i dag. Ein moderne klient kan bruke eit pakketunnel-API i staden for eit PPP-grensesnitt, og å anta at han oppfører seg som ei historisk tilkopling er måten ein fungerande design blir øydelagd. Spør etter klientversjonen og klargjeringsmetoden, ikkje grensesnittnamnet.
Skriv planen klienten treng
Ei fullstendig skildring dekkjer tre ting: kva adresse klienten har, kva destinasjonar tunnelen skal bera, og korleis nettverket sender svar tilbake. Eit link-local-adresse svarar ikkje på nokon av dei, og ein godteken annonse svarar berre på ein del av éin. Kontroller kvart punkt for seg i staden for å godta ein grøn indikator. Noter deretter kva mekanisme som leverte kvart svar, fordi den registreringa gjer den neste IPv6-rapporten til ein kontroll på to minutt.
Hald registreringa saman med tenestedokumentasjonen, og oppdater ho når klienten blir endra. Ein plan som var riktig for ein PPP-klient, kan vere gal for ein pakketunnelklient på same teneste. Dei fire spørsmåla blir dei same; berre svara flyttar seg.