Vad IPv6CP förhandlar om och vad som fortfarande behöver ett prefix
En link-local-adress på PPP-gränssnittet är ett konfigurationssteg, inte IPv6-åtkomst. Separera identifierarutbytet från prefix, rutter och klientintegration.
IPv6 kommer upp på PPP-gränssnittet, en link-local-adress dyker upp, och ändringen förklaras klar. Sedan routas ingenting, det finns ingen global adress, och ett test mot en offentlig destination misslyckas medan gränssnittet fortfarande ser konfigurerat ut. Länken kom upp; nätverket aldrig. Gå igenom de fyra kontrollerna nedan i ordning och stanna vid den som förklarar gapet.
Vad en link-local-adress egentligen bevisar
IPv6CP får upp IPv6 på PPP-länken och förhandlar en gränssnittsidentifierare för varje sida. Den identifieraren ger en link-local-adress, som räcker för att tala med motparten över länken och inte räcker för att nå något annat. Adressen bevisar att länken är klar för IPv6, och den bevisar ingenting om nätverket bakom motparten. Att läsa den som en åtkomstadress är felet som de flesta av dessa utredningar börjar med.
De fyra frågorna nedan skiljer det som länklagret avgör från det som tjänsten måste leverera. Svara på dem i ordning, eftersom en senare fråga inte kan besvaras medan en tidigare fortfarande är öppen.
| 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 |
Varifrån prefixet måste komma
En global adress behöver ett prefix från någonstans: ett routermeddelande, ett delegerat prefix, DHCPv6 eller statisk konfiguration. IPv6CP bär inget, och ingen mängd väntan på länken producerar ett. RFC 5072 placerar IPv6CP som konfigurationssteget som körs innan andra IPv6-protokoll verkar på länken, och det är hela dess omfattning: att förbereda länken, inte att numrera nätverket. Leverera prefixet och gränssnittet börjar bära trafik i stället för att bara existera.
Routermeddelanden är det vanliga svaret på ett LAN och ett mindre tillförlitligt på en punkt-till-punkt-tunnel, eftersom klienten måste både skicka förfrågningar och acceptera svaret. Vissa tunnelklienter gör inget av dem. Kontrollera vad klienten är villig att acceptera innan du bestämmer att servern ska skicka det.
Samma prefix måste vara nåbart från andra änden. En klient som har en global adress men ingen returväg är konfigurerad, inte ansluten.
Rutter är ett separat löfte
Även med en adress måste klienten veta vilka destinationer som hör till tunneln, och servern behöver en returväg för dessa destinationer. Det är två beslut fattade på två ställen. En tunnel som bär all IPv6-trafik behöver en standardrutt på klienten och en returrutt på servern; en delad tunnel kräver att båda sidor enas om samma prefixlista. När de inte är eniga lämnar trafiken och kommer aldrig tillbaka.
Skriv ner listan innan du konfigurerar något. Om planen säger att bara företagsprefixet går genom tunneln bör klienten inte ha någon standard-IPv6-rutt, och servern bör inte annonsera någon.
Klientintegration avgör resten
Vissa tunnelklienter konfigurerar IPv6 explicit. Apples Network Extension tar till exempel en adress, ett prefix och en uppsättning rutter för tunneln, så en applikation som använder den väntar inte på ett meddelande i Ethernet-stil. Andra förlitar sig på routermeddelanden som kommer in över länken. Båda modellerna är legitima och kräver olika serverbeteende, så fel val ger en klient som väntar i evighet på ett meddelande som ingen skickar. Identifiera modellen innan du ändrar servern.
Ett gammalt gränssnittsnamn som ppp0 bevisar ingenting om den stack som körs i dag. En modern klient kan använda ett pakettunnel-API i stället för ett PPP-gränssnitt, och att anta att den beter sig som en historisk anslutning är hur en fungerande design går sönder. Fråga efter klientversionen och etableringsmetoden, inte gränssnittsnamnet.
Skriv planen som klienten behöver
En fullständig beskrivning täcker tre saker: vilken adress klienten har, vilka destinationer tunneln ska bära och hur nätverket skickar tillbaka svar. En link-local-adress besvarar ingen av dem, och ett accepterat meddelande besvarar bara en del av en. Kontrollera varje punkt för sig i stället för att acceptera en grön indikator. Anteckna sedan vilken mekanism som levererade varje svar, eftersom den anteckningen gör nästa IPv6-rapport till en kontroll på två minuter.
Förvara anteckningen tillsammans med tjänstedokumentationen och uppdatera den när klienten ändras. En plan som var rätt för en PPP-klient kan vara fel för en pakettunnelklient på samma tjänst. De fyra frågorna förblir desamma; bara svaren flyttar sig.