Què negocia IPv6CP i què encara necessita un prefix
Una adreça link-local a la interfície PPP és un pas de configuració, no accés IPv6. Separeu l'intercanvi d'identificadors dels prefixos, les rutes i la integració del client.
IPv6 s'aixeca a la interfície PPP, apareix una adreça link-local i es declara el canvi acabat. Llavors no hi ha encaminament, no existeix cap adreça global i una prova cap a una destinació pública falla mentre la interfície encara sembla configurada. L'enllaç s'ha aixecat; la xarxa mai no ho ha fet. Feu les quatre comprovacions següents per ordre i atureu-vos a la que expliqui la diferència.
Què demostra realment una adreça link-local
IPv6CP aixeca IPv6 a l'enllaç PPP i negocia un identificador d'interfície per a cada costat. Aquest identificador produeix una adreça link-local, que és suficient per parlar amb el par a través de l'enllaç i no suficient per arribar a res més. L'adreça demostra que l'enllaç està preparat per a IPv6 i no demostra res sobre la xarxa que hi ha darrere del par. Llegir-la com una adreça d'accés és l'error amb què comencen la majoria d'aquestes investigacions.
Les quatre preguntes següents separen què resol la capa d'enllaç de què ha de proporcionar el servei. Responeu-les per ordre, perquè a una pregunta posterior no es pot respondre mentre una d'anterior continua oberta.
| 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 |
D'on ha de venir el prefix
Una adreça global necessita un prefix d'algun lloc: un anunci de router, un prefix delegat, DHCPv6 o configuració estàtica. IPv6CP no en porta cap, i cap espera a l'enllaç no en produirà. RFC 5072 situa IPv6CP com el pas de configuració que s'executa abans que altres protocols IPv6 funcionin a l'enllaç, i aquest és tot el seu abast: preparar l'enllaç, no numerar la xarxa. Proporcioneu el prefix i la interfície comença a portar trànsit en lloc de només existir.
Els anuncis de router són la resposta habitual en una LAN i una de menys fiable en un túnel punt a punt, perquè el client ha d'enviar sol·licituds i acceptar la resposta alhora. Alguns clients de túnel no fan ni una cosa ni l'altra. Comproveu què està disposat a acceptar el client abans de decidir que el servidor ho ha d'enviar.
El mateix prefix ha de ser abastable des de l'altre extrem. Un client que té una adreça global però cap camí de tornada està configurat, no connectat.
Les rutes són una promesa a part
Fins i tot amb una adreça, el client ha de saber quines destinacions pertanyen al túnel, i el servidor necessita un camí de tornada per a aquestes destinacions. Són dues decisions preses en dos llocs. Un túnel que porta tot el trànsit IPv6 necessita una ruta per defecte al client i una ruta de tornada al servidor; un túnel dividit necessita que els dos costats acordin la mateixa llista de prefixos. Quan no hi estan d'acord, el trànsit surt i no torna mai.
Escriviu la llista abans de configurar res. Si el pla diu que només el prefix corporatiu passa pel túnel, el client no ha de tenir una ruta IPv6 per defecte, i el servidor no n'ha d'anunciar cap.
La integració del client decideix la resta
Alguns clients de túnel configuren IPv6 explícitament. El Network Extension d'Apple, per exemple, pren una adreça, un prefix i un conjunt de rutes per al túnel, de manera que una aplicació que el fa servir no espera un anunci a l'estil Ethernet. D'altres depenen que arribin anuncis de router per l'enllaç. Els dos models són legítims i necessiten un comportament diferent del servidor, així que triar el model equivocat produeix un client que espera per sempre un missatge que ningú no envia. Identifiqueu el model abans de canviar el servidor.
Un nom d'interfície antic com ppp0 no demostra res sobre la pila que funciona avui. Un client actual pot usar una API de túnel de paquets en lloc d'una interfície PPP, i suposar que es comporta com una connexió històrica és com es trenca un disseny que funcionava. Demaneu la versió del client i el mètode de proveïment, no el nom de la interfície.
Escriviu el pla que el client necessita
Una descripció completa cobreix tres coses: quina adreça té el client, quines destinacions ha de portar el túnel i com la xarxa envia les respostes de tornada. Una adreça link-local no respon a cap d'aquestes, i un anunci acceptat només respon a una part d'una. Comproveu cada element per separat en lloc d'acceptar un indicador verd. Després anoteu quin mecanisme ha proporcionat cada resposta, perquè aquest registre converteix el següent informe sobre IPv6 en una comprovació de dos minuts.
Mantingueu el registre amb la documentació del servei i actualitzeu-lo quan canviï el client. Un pla que era correcte per a un client PPP pot ser equivocat per a un client de túnel de paquets al mateix servei. Les quatre preguntes continuen sent les mateixes; només es mouen les respostes.