Wat IPv6CP onderhandelt, en wat nog steeds een prefix nodig heeft
Een link-local adres op de PPP-interface is een configuratiestap, geen IPv6-toegang. Scheid de uitwisseling van identifiers van prefixen, routes en clientintegratie.
IPv6 komt op de PPP-interface omhoog, er verschijnt een link-local adres, en de wijziging wordt als klaar verklaard. Dan wordt er niets gerouteerd, er bestaat geen globaal adres, en een test naar een openbare bestemming mislukt terwijl de interface er nog steeds geconfigureerd uitziet. De verbinding kwam omhoog; het netwerk nooit. Werk de vier controles hieronder op volgorde af en stop bij degene die de kloof verklaart.
Wat een link-local adres werkelijk bewijst
IPv6CP brengt IPv6 op de PPP-verbinding omhoog en onderhandelt een interface-identificatie voor elke kant. Die identificatie levert een link-local adres op, dat genoeg is om met de peer over de verbinding te praten en niet genoeg om iets anders te bereiken. Het adres bewijst dat de verbinding klaar is voor IPv6, en het bewijst niets over het netwerk achter de peer. Het als toegangsadres lezen is de fout waarmee de meeste van deze onderzoeken beginnen.
De vier vragen hieronder scheiden wat de verbindingslaag beslist van wat de dienst moet leveren. Beantwoord ze op volgorde, want een latere vraag kan niet worden beantwoord zolang een eerdere nog openstaat.
| 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 |
Waar het prefix vandaan moet komen
Een globaal adres heeft een prefix van ergens nodig: een routeraankondiging, een gedelegeerd prefix, DHCPv6 of statische configuratie. IPv6CP draagt er geen, en geen enkele hoeveelheid wachten op de verbinding levert er een op. RFC 5072 plaatst IPv6CP als de configuratiestap die loopt voordat andere IPv6-protocollen op de verbinding werken, en dat is de hele reikwijdte: de verbinding voorbereiden, niet het netwerk nummeren. Lever het prefix en de interface begint verkeer te dragen in plaats van alleen te bestaan.
Routeraankondigingen zijn het gebruikelijke antwoord op een LAN en een minder betrouwbaar antwoord op een punt-naar-punt-tunnel, omdat de client zowel verzoeken moet sturen als het antwoord moet accepteren. Sommige tunnelclients doen geen van beide. Controleer wat de client bereid is te accepteren voordat je besluit dat de server het moet sturen.
Hetzelfde prefix moet vanaf de andere kant bereikbaar zijn. Een client die een globaal adres heeft maar geen terugweg, is geconfigureerd, niet verbonden.
Routes zijn een aparte belofte
Zelfs met een adres moet de client weten welke bestemmingen bij de tunnel horen, en de server heeft een terugweg nodig voor die bestemmingen. Dat zijn twee beslissingen op twee plaatsen. Een tunnel die al het IPv6-verkeer draagt, heeft een standaardroute op de client en een terugroute op de server nodig; een gesplitste tunnel vereist dat beide kanten het eens worden over dezelfde prefixlijst. Als ze het oneens zijn, vertrekt het verkeer en komt het nooit terug.
Schrijf de lijst op voordat je iets configureert. Als het plan zegt dat alleen het bedrijfsprefix door de tunnel gaat, hoort de client geen standaard-IPv6-route te hebben, en hoort de server er geen aan te kondigen.
Clientintegratie beslist de rest
Sommige tunnelclients configureren IPv6 expliciet. Apples Network Extension neemt bijvoorbeeld een adres, een prefix en een set routes voor de tunnel, zodat een toepassing die het gebruikt niet wacht op een aankondiging in Ethernet-stijl. Andere vertrouwen op routeraankondigingen die over de verbinding binnenkomen. Beide modellen zijn legitiem en vragen ander servergedrag, dus de verkeerde keuze levert een client op die voor altijd wacht op een bericht dat niemand stuurt. Identificeer het model voordat je de server wijzigt.
Een oude interfacenaam zoals ppp0 bewijst niets over de stack die vandaag draait. Een moderne client kan een pakkettunnel-API gebruiken in plaats van een PPP-interface, en aannemen dat hij zich als een historische verbinding gedraagt is hoe een werkend ontwerp wordt gebroken. Vraag naar de clientversie en de inrichtingsmethode, niet naar de interfacenaam.
Schrijf het plan dat de client nodig heeft
Een volledige beschrijving dekt drie dingen: welk adres de client heeft, welke bestemmingen de tunnel moet dragen en hoe het netwerk antwoorden terugstuurt. Een link-local adres beantwoordt geen van alle, en een geaccepteerde aankondiging beantwoordt slechts een deel van één. Controleer elk punt afzonderlijk in plaats van een groene indicator te accepteren. Noteer daarna welk mechanisme elk antwoord leverde, want die registratie maakt het volgende IPv6-rapport tot een controle van twee minuten.
Bewaar de registratie bij de servicedocumentatie en werk hem bij wanneer de client verandert. Een plan dat juist was voor een PPP-client kan onjuist zijn voor een pakkettunnelclient op dezelfde dienst. De vier vragen blijven hetzelfde; alleen de antwoorden verschuiven.