Ce negociază IPv6CP și ce mai are nevoie de un prefix
O adresă link-local pe interfața PPP este un pas de configurare, nu acces IPv6. Separați schimbul de identificatori de prefixe, rute și integrarea clientului.
IPv6 urcă pe interfața PPP, apare o adresă link-local, iar modificarea este declarată terminată. Apoi nimic nu este rutat, nu există adresă globală, iar un test către o destinație publică eșuează în timp ce interfața încă pare configurată. Legătura a urcat; rețeaua niciodată. Parcurgeți cele patru verificări de mai jos în ordine și opriți-vă la cea care explică diferența.
Ce demonstrează de fapt o adresă link-local
IPv6CP ridică IPv6 pe legătura PPP și negociază un identificator de interfață pentru fiecare parte. Acel identificator produce o adresă link-local, care este suficientă pentru a vorbi cu partenerul prin legătură și nu este suficientă pentru a ajunge la orice altceva. Adresa demonstrează că legătura este pregătită pentru IPv6 și nu demonstrează nimic despre rețeaua din spatele partenerului. Citirea ei ca adresă de acces este greșeala cu care încep majoritatea acestor investigații.
Cele patru întrebări de mai jos separă ce rezolvă stratul de legătură de ce trebuie să furnizeze serviciul. Răspundeți în ordine, pentru că la o întrebare ulterioară nu se poate răspunde cât timp una anterioară rămâne deschisă.
| 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 |
De unde trebuie să vină prefixul
O adresă globală are nevoie de un prefix de undeva: un anunț de router, un prefix delegat, DHCPv6 sau configurație statică. IPv6CP nu transportă niciunul, iar nicio așteptare pe legătură nu va produce unul. RFC 5072 plasează IPv6CP ca pasul de configurare care rulează înainte ca alte protocoale IPv6 să funcționeze pe legătură, și acesta este întregul său domeniu: pregătirea legăturii, nu numerotarea rețelei. Furnizați prefixul și interfața începe să transporte trafic în loc să existe doar.
Anunțurile de router sunt răspunsul obișnuit într-o rețea locală și unul mai puțin fiabil într-un tunel punct la punct, pentru că clientul trebuie atât să trimită solicitări, cât și să accepte răspunsul. Unii clienți de tunel nu fac nici una. Verificați ce este dispus clientul să accepte înainte de a decide că serverul trebuie să trimită asta.
Același prefix trebuie să fie accesibil și de la celălalt capăt. Un client care are o adresă globală, dar nu are cale de întoarcere, este configurat, nu conectat.
Rutele sunt o promisiune separată
Chiar și cu o adresă, clientul trebuie să știe ce destinații aparțin tunelului, iar serverul are nevoie de o cale de întoarcere pentru acele destinații. Sunt două decizii luate în două locuri. Un tunel care transportă tot traficul IPv6 are nevoie de o rută implicită pe client și de o rută de întoarcere pe server; un tunel divizat cere ca ambele părți să cadă de acord asupra aceleiași liste de prefixe. Când nu sunt de acord, traficul pleacă și nu se mai întoarce.
Scrieți lista înainte de a configura ceva. Dacă planul spune că doar prefixul corporativ trece prin tunel, clientul nu ar trebui să aibă o rută IPv6 implicită, iar serverul nu ar trebui să anunțe una.
Integrarea clientului decide restul
Unii clienți de tunel configurează IPv6 explicit. De exemplu, Network Extension de la Apple preia o adresă, un prefix și un set de rute pentru tunel, astfel încât o aplicație care îl folosește nu așteaptă un anunț în stil Ethernet. Alții depind de anunțuri de router care sosesc prin legătură. Ambele modele sunt legitime și necesită un comportament diferit al serverului, așa că alegerea greșită produce un client care așteaptă veșnic un mesaj pe care nimeni nu îl trimite. Identificați modelul înainte de a schimba serverul.
Un nume vechi de interfață precum ppp0 nu demonstrează nimic despre stiva care rulează astăzi. Un client modern poate folosi un API de tunel de pachete în locul unei interfețe PPP, iar presupunerea că se comportă ca o conexiune istorică este felul în care se rupe un proiect care funcționează. Întrebați despre versiunea clientului și metoda de furnizare, nu despre numele interfeței.
Scrieți planul de care are nevoie clientul
O descriere completă acoperă trei lucruri: ce adresă are clientul, ce destinații trebuie să transporte tunelul și cum trimite rețeaua răspunsurile înapoi. O adresă link-local nu răspunde la niciuna, iar un anunț acceptat răspunde doar la o parte a unuia. Verificați fiecare element separat în loc să acceptați un indicator verde. Apoi notați ce mecanism a furnizat fiecare răspuns, pentru că acea evidență transformă următorul raport IPv6 într-o verificare de două minute.
Păstrați evidența împreună cu documentația serviciului și actualizați-o când clientul se schimbă. Un plan care era corect pentru un client PPP poate fi greșit pentru un client de tunel de pachete pe același serviciu. Cele patru întrebări rămân aceleași; doar răspunsurile se mută.