Que negocia IPv6CP e que aínda necesita un prefixo
Un enderezo link-local na interface PPP é un paso de configuración, non acceso IPv6. Separe o intercambio de identificadores dos prefixos, as rutas e a integración do cliente.
IPv6 sobe na interface PPP, aparece un enderezo link-local e o cambio declárase rematado. Despois non se encamiña nada, non existe un enderezo global e unha proba cara a un destino público falla mentres a interface segue parecendo configurada. A ligazón subiu; a rede nunca. Percorra as catro comprobacións seguintes en orde e detéñase na que explique a diferenza.
Que demostra realmente un enderezo link-local
IPv6CP sobe IPv6 na ligazón PPP e negocia un identificador de interface para cada lado. Ese identificador produce un enderezo link-local, que abonda para falar co par a través da ligazón e non abonda para chegar a nada máis. O enderezo demostra que a ligazón está lista para IPv6 e non demostra nada sobre a rede detrás do par. Leelo como un enderezo de acceso é o erro co que comezan a maioría destas investigacións.
As catro preguntas seguintes separan o que resolve a capa de ligazón do que debe fornecer o servizo. Respóndallas en orde, porque a unha pregunta posterior non se pode responder mentres unha anterior siga aberta.
| 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 onde ten que vir o prefixo
Un enderezo global necesita un prefixo de algún sitio: un anuncio de router, un prefixo delegado, DHCPv6 ou configuración estática. IPv6CP non transporta ningún, e ningunha espera na ligazón producirá un. RFC 5072 sitúa IPv6CP como o paso de configuración que se executa antes de que outros protocolos IPv6 funcionen na ligazón, e ese é todo o seu alcance: preparar a ligazón, non numerar a rede. Proporcione o prefixo e a interface comeza a transportar tráfico en lugar de só existir.
Os anuncios de router son a resposta habitual nunha LAN e unha menos fiable nun túnel punto a punto, porque o cliente ten que enviar solicitudes e aceptar a resposta á vez. Algúns clientes de túnel non fan nin unha cousa nin a outra. Comprobe que está disposto a aceptar o cliente antes de decidir que o servidor debe envialo.
O mesmo prefixo ten que ser alcanzable desde o outro extremo. Un cliente que ten un enderezo global pero ningún camiño de volta está configurado, non conectado.
As rutas son unha promesa á parte
Incluso cun enderezo, o cliente necesita saber que destinos pertencen ao túnel, e o servidor necesita un camiño de volta para eses destinos. Son dúas decisións tomadas en dous lugares. Un túnel que transporta todo o tráfico IPv6 necesita unha ruta por defecto no cliente e unha ruta de volta no servidor; un túnel dividido necesita que ambos os dous lados acorden a mesma lista de prefixos. Cando non coinciden, o tráfico sae e non volve nunca.
Escriba a lista antes de configurar nada. Se o plan di que só o prefixo corporativo pasa polo túnel, o cliente non debería ter unha ruta IPv6 por defecto, e o servidor non debería anunciar ningunha.
A integración do cliente decide o resto
Algúns clientes de túnel configuran IPv6 de forma explícita. Network Extension de Apple, por exemplo, toma un enderezo, un prefixo e un conxunto de rutas para o túnel, así que unha aplicación que o usa non espera un anuncio ao estilo Ethernet. Outros dependen de que cheguen anuncios de router pola ligazón. Ambos os modelos son lexítimos e necesitan un comportamento distinto do servidor, así que escoller o equivocado produce un cliente que espera para sempre unha mensaxe que ninguén envía. Identifique o modelo antes de cambiar o servidor.
Un nome de interface antigo como ppp0 non demostra nada sobre a pila que se executa hoxe. Un cliente actual pode usar unha API de túnel de paquetes en lugar dunha interface PPP, e supor que se comporta como unha conexión histórica é como se rompe un deseño que funciona. Pregunte pola versión do cliente e o método de aprovisionamento, non polo nome da interface.
Escriba o plan que necesita o cliente
Unha descrición completa cobre tres cousas: que enderezo ten o cliente, que destinos debe transportar o túnel e como envía a rede as respostas de volta. Un enderezo link-local non responde a ningunha delas, e un anuncio aceptado responde só a unha parte dunha. Comprobe cada elemento por separado en lugar de aceptar un indicador verde. Despois anote que mecanismo forneceu cada resposta, porque ese rexistro converte o seguinte informe sobre IPv6 nunha comprobación de dous minutos.
Garde o rexistro coa documentación do servizo e actualíceo cando cambie o cliente. Un plan que era correcto para un cliente PPP pode ser erróneo para un cliente de túnel de paquetes no mesmo servizo. As catro preguntas seguen sendo as mesmas; só se moven as respostas.