Hvad IPv6CP forhandler om, og hvad der stadig kræver et præfiks
En link-local-adresse på PPP-interfacet er et opsætningstrin, ikke IPv6-adgang. Adskil identifikatorudvekslingen fra præfikser, ruter og klientintegration.
IPv6 kommer op på PPP-interfacet, en link-local-adresse vises, og ændringen erklæres færdig. Så ruter intet, der findes ingen global adresse, og en test mod en offentlig destination fejler, mens interfacet stadig ser konfigureret ud. Linket kom op; netværket gjorde aldrig. Gå de fire kontroller nedenfor igennem i rækkefølge, og stop ved den, der forklarer hullet.
Hvad en link-local-adresse egentlig beviser
IPv6CP bringer IPv6 op på PPP-linket og forhandler en interface-identifikator for hver side. Den identifikator giver en link-local-adresse, som er nok til at tale med peer'en over linket og ikke nok til at nå noget andet. Adressen beviser, at linket er klar til IPv6, og den beviser intet om netværket bag peer'en. At læse den som en adgangsadresse er den fejl, der starter de fleste af disse undersøgelser.
De fire spørgsmål nedenfor adskiller det, linklaget afgør, fra det, tjenesten skal levere. Besvar dem i rækkefølge, fordi et senere spørgsmål ikke kan besvares, mens et tidligere stadig er åbent.
| 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 præfikset skal komme fra
En global adresse har brug for et præfiks et eller andet sted fra: en routerannonce, et delegeret præfiks, DHCPv6 eller statisk konfiguration. IPv6CP bærer ikke et, og ingen mængde venten på linket vil frembringe et. RFC 5072 placerer IPv6CP som det opsætningstrin, der kører, før andre IPv6-protokoller virker på linket, og det er hele dens omfang: at forberede linket, ikke at nummerere netværket. Lever præfikset, og interfacet begynder at bære trafik i stedet for blot at eksistere.
Routerannoncer er det almindelige svar på et LAN og et mindre pålideligt et på en punkt-til-punkt-tunnel, fordi klienten både skal sende forespørgsler og acceptere svaret. Nogle tunnelklienter gør ingen af delene. Tjek, hvad klienten er villig til at acceptere, før du beslutter, at serveren skal sende det.
Det samme præfiks skal være nåbart fra den anden ende. En klient, der har en global adresse, men ingen returvej, er konfigureret, ikke forbundet.
Ruter er et separat løfte
Selv med en adresse skal klienten vide, hvilke destinationer der hører til tunnelen, og serveren har brug for en returvej for disse destinationer. Det er to beslutninger truffet to steder. En tunnel, der bærer al IPv6-trafik, har brug for en standardrute på klienten og en rute tilbage på serveren; en delt tunnel kræver, at begge sider bliver enige om den samme præfiksliste. Når de er uenige, forlader trafikken og vender aldrig tilbage.
Skriv listen ned, før du konfigurerer noget. Hvis planen siger, at kun virksomhedspræfikset går gennem tunnelen, bør klienten ikke have en standard-IPv6-rute, og serveren bør ikke annoncere en.
Klientintegration afgør resten
Nogle tunnelklienter konfigurerer IPv6 eksplicit. Apples Network Extension tager for eksempel en adresse, et præfiks og et sæt ruter til tunnelen, så en applikation, der bruger den, ikke venter på en Ethernet-lignende annonce. Andre er afhængige af routerannoncer, der ankommer over linket. Begge modeller er legitime og kræver forskellig serveradfærd, så det forkerte valg giver en klient, der venter evigt på en besked, ingen sender. Identificer modellen, før du ændrer serveren.
Et gammelt interface-navn som ppp0 beviser intet om den stak, der kører i dag. En nutidig klient kan bruge en pakketunnel-API i stedet for et PPP-interface, og at antage, at den opfører sig som en historisk forbindelse, er måden, hvorpå et fungerende design bliver ødelagt. Spørg efter klientversionen og klargøringsmetoden, ikke interface-navnet.
Skriv den plan, klienten har brug for
En fuldstændig beskrivelse dækker tre ting: hvilken adresse klienten har, hvilke destinationer tunnelen skal bære, og hvordan netværket sender svar tilbage. En link-local-adresse besvarer ingen af dem, og en accepteret annonce besvarer kun en del af en. Kontroller hvert punkt for sig i stedet for at acceptere en grøn indikator. Notér derefter, hvilken mekanisme der leverede hvert svar, fordi den registrering gør den næste IPv6-rapport til et tjek på to minutter.
Hold registreringen sammen med servicedokumentationen, og opdater den, når klienten ændres. En plan, der var rigtig for en PPP-klient, kan være forkert for en pakketunnelklient på samme tjeneste. De fire spørgsmål forbliver de samme; kun svarene flytter sig.