Hva IPv6CP forhandler om, og hva som fortsatt trenger et prefiks
En link-local-adresse på PPP-grensesnittet er et oppsettstrinn, ikke IPv6-tilgang. Skill identifikatorutvekslingen fra prefikser, ruter og klientintegrasjon.
IPv6 kommer opp på PPP-grensesnittet, en link-local-adresse dukker opp, og endringen erklæres ferdig. Så rutes ingenting, det finnes ingen global adresse, og en test mot en offentlig destinasjon feiler mens grensesnittet fortsatt ser konfigurert ut. Lenken kom opp; nettverket gjorde det aldri. Gå gjennom de fire kontrollene nedenfor i rekkefølge og stopp ved den som forklarer gapet.
Hva en link-local-adresse egentlig beviser
IPv6CP bringer IPv6 opp på PPP-lenken og forhandler en grensesnittidentifikator for hver side. Den identifikatoren gir en link-local-adresse, som er nok til å snakke med motparten over lenken og ikke nok til å nå noe annet. Adressen beviser at lenken er klar for IPv6, og den beviser ingenting om nettverket bak motparten. Å lese den som en tilgangsadresse er feilen som starter de fleste av disse undersøkelsene.
De fire spørsmålene nedenfor skiller det lenkelaget avgjør fra det tjenesten må levere. Svar på dem i rekkefølge, fordi et senere spørsmål ikke kan besvares mens et tidligere fortsatt er åpent.
| 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 |
Hvor prefikset må komme fra
En global adresse trenger et prefiks fra et sted: en ruterannonse, et delegert prefiks, DHCPv6 eller statisk konfigurasjon. IPv6CP bærer ikke et, og ingen mengde venting på lenken vil produsere ett. RFC 5072 plasserer IPv6CP som oppsettstrinnet som kjører før andre IPv6-protokoller virker på lenken, og det er hele omfanget: å forberede lenken, ikke å nummerere nettverket. Lever prefikset, og grensesnittet begynner å bære trafikk i stedet for bare å eksistere.
Ruterannonser er det vanlige svaret på et LAN og et mindre pålitelig et på en punkt-til-punkt-tunnel, fordi klienten må både sende forespørsler og godta svaret. Noen tunnelklienter gjør ingen av delene. Sjekk hva klienten er villig til å godta før du bestemmer at serveren skal sende det.
Det samme prefikset må være nåbart fra den andre enden. En klient som har en global adresse, men ingen returvei, er konfigurert, ikke tilkoblet.
Ruter er et separat løfte
Selv med en adresse må klienten vite hvilke destinasjoner som hører til tunnelen, og serveren trenger en returvei for disse destinasjonene. Det er to beslutninger tatt på to steder. En tunnel som bærer all IPv6-trafikk trenger en standardrute på klienten og en returrute på serveren; en delt tunnel krever at begge sider blir enige om samme prefiksliste. Når de ikke er enige, forlater trafikken og kommer aldri tilbake.
Skriv ned listen før du konfigurerer noe. Hvis planen sier at bare bedriftsprefikset går gjennom tunnelen, bør klienten ikke ha en standard IPv6-rute, og serveren bør ikke annonsere en.
Klientintegrasjon avgjør resten
Noen tunnelklienter konfigurerer IPv6 eksplisitt. Apples Network Extension tar for eksempel en adresse, et prefiks og et sett med ruter for tunnelen, så en applikasjon som bruker den ikke venter på en Ethernet-lignende annonse. Andre er avhengige av ruterannonser som kommer over lenken. Begge modellene er legitime og krever ulik serveratferd, så det gale valget gir en klient som venter evig på en melding ingen sender. Identifiser modellen før du endrer serveren.
Et gammelt grensesnittnavn som ppp0 beviser ingenting om stakken som kjører i dag. En moderne klient kan bruke et pakketunnel-API i stedet for et PPP-grensesnitt, og å anta at den oppfører seg som en historisk forbindelse er måten en fungerende design blir ødelagt. Spør etter klientversjonen og klargjøringsmetoden, ikke grensesnittnavnet.
Skriv planen klienten trenger
En fullstendig beskrivelse dekker tre ting: hvilken adresse klienten har, hvilke destinasjoner tunnelen skal bære, og hvordan nettverket sender svar tilbake. En link-local-adresse besvarer ingen av dem, og en godtatt annonse besvarer bare en del av én. Kontroller hvert punkt for seg i stedet for å godta en grønn indikator. Noter deretter hvilken mekanisme som leverte hvert svar, fordi den registreringen gjør den neste IPv6-rapporten til en kontroll på to minutter.
Hold registreringen sammen med tjenestedokumentasjonen, og oppdater den når klienten endres. En plan som var riktig for en PPP-klient, kan være gal for en pakketunnelklient på samme tjeneste. De fire spørsmålene forblir de samme; bare svarene flytter seg.