Che cosa negozia IPv6CP e che cosa ha ancora bisogno di un prefisso
Un indirizzo link-local sull'interfaccia PPP è un passo di configurazione, non un accesso IPv6. Separate lo scambio di identificatori dai prefissi, dalle rotte e dall'integrazione del client.
IPv6 sale sull'interfaccia PPP, compare un indirizzo link-local e la modifica viene dichiarata completata. Poi non viene instradato nulla, non esiste un indirizzo globale e un test verso una destinazione pubblica fallisce mentre l'interfaccia sembra ancora configurata. Il collegamento è salito; la rete mai. Eseguite i quattro controlli qui sotto in ordine e fermatevi su quello che spiega la differenza.
Che cosa dimostra davvero un indirizzo link-local
IPv6CP attiva IPv6 sul collegamento PPP e negozia un identificatore di interfaccia per ciascun lato. Quell'identificatore produce un indirizzo link-local, che basta per parlare con il peer attraverso il collegamento e non basta per raggiungere qualsiasi altra cosa. L'indirizzo dimostra che il collegamento è pronto per IPv6 e non dimostra nulla sulla rete dietro il peer. Leggerlo come indirizzo di accesso è l'errore con cui iniziano la maggior parte di queste indagini.
Le quattro domande qui sotto separano ciò che risolve il livello di collegamento da ciò che il servizio deve fornire. Rispondete in ordine, perché a una domanda successiva non si può rispondere finché una precedente resta aperta.
| 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 |
Da dove deve venire il prefisso
Un indirizzo globale ha bisogno di un prefisso da qualche parte: un annuncio del router, un prefisso delegato, DHCPv6 o una configurazione statica. IPv6CP non ne trasporta alcuno, e nessuna attesa sul collegamento ne produrrà uno. RFC 5072 colloca IPv6CP come il passo di configurazione che viene eseguito prima che altri protocolli IPv6 operino sul collegamento, e questo è tutto il suo ambito: preparare il collegamento, non numerare la rete. Fornite il prefisso e l'interfaccia inizia a trasportare traffico invece di esistere soltanto.
Gli annunci del router sono la risposta comune su una LAN e una meno affidabile su un tunnel punto a punto, perché il client deve sia inviare sollecitazioni sia accettare la risposta. Alcuni client di tunnel non fanno né l'una né l'altra. Verificate che cosa il client è disposto ad accettare prima di decidere che il server debba inviarlo.
Lo stesso prefisso deve essere raggiungibile dall'altro capo. Un client che ha un indirizzo globale ma nessun percorso di ritorno è configurato, non connesso.
Le rotte sono una promessa separata
Anche con un indirizzo, il client deve sapere quali destinazioni appartengono al tunnel, e il server ha bisogno di un percorso di ritorno per quelle destinazioni. Sono due decisioni prese in due luoghi. Un tunnel che trasporta tutto il traffico IPv6 ha bisogno di una rotta predefinita sul client e di una rotta di ritorno sul server; un tunnel diviso richiede che entrambi i lati concordino lo stesso elenco di prefissi. Quando non sono d'accordo, il traffico esce e non torna mai.
Scrivete l'elenco prima di configurare qualsiasi cosa. Se il piano dice che solo il prefisso aziendale passa attraverso il tunnel, il client non dovrebbe avere una rotta IPv6 predefinita, e il server non dovrebbe annunciarne una.
L'integrazione del client decide il resto
Alcuni client di tunnel configurano IPv6 in modo esplicito. Network Extension di Apple, per esempio, prende un indirizzo, un prefisso e un insieme di rotte per il tunnel, così un'applicazione che lo usa non attende un annuncio in stile Ethernet. Altri dipendono dagli annunci del router che arrivano sul collegamento. Entrambi i modelli sono legittimi e richiedono un comportamento del server diverso, quindi scegliere quello sbagliato produce un client che attende per sempre un messaggio che nessuno invia. Identificate il modello prima di cambiare il server.
Un vecchio nome di interfaccia come ppp0 non dimostra nulla sullo stack in esecuzione oggi. Un client attuale può usare un'API di tunnel a pacchetti invece di un'interfaccia PPP, e supporre che si comporti come una connessione storica è il modo in cui si rompe un progetto che funziona. Chiedete la versione del client e il metodo di provisioning, non il nome dell'interfaccia.
Scrivete il piano di cui il client ha bisogno
Una descrizione completa copre tre cose: quale indirizzo possiede il client, quali destinazioni il tunnel deve trasportare e come la rete invia le risposte. Un indirizzo link-local non risponde a nessuna di esse, e un annuncio accettato risponde solo a una parte di una. Controllate ogni voce separatamente invece di accettare un indicatore verde. Poi annotate quale meccanismo ha fornito ogni risposta, perché quel registro trasforma il prossimo rapporto IPv6 in un controllo di due minuti.
Conservate il registro con la documentazione del servizio e aggiornatelo quando il client cambia. Un piano che era corretto per un client PPP può essere sbagliato per un client di tunnel a pacchetti sullo stesso servizio. Le quattro domande restano le stesse; si muovono solo le risposte.