Qué negocia IPv6CP y qué sigue necesitando un prefijo
Una dirección link-local en la interfaz PPP es un paso de configuración, no acceso IPv6. Separe el intercambio de identificadores de los prefijos, las rutas y la integración del cliente.
IPv6 sube en la interfaz PPP, aparece una dirección link-local y el cambio se declara terminado. Después no se enruta nada, no existe una dirección global y una prueba hacia un destino público falla mientras la interfaz sigue pareciendo configurada. El enlace subió; la red nunca. Recorra las cuatro comprobaciones siguientes en orden y deténgase en la que explique la diferencia.
Qué demuestra realmente una dirección link-local
IPv6CP sube IPv6 en el enlace PPP y negocia un identificador de interfaz para cada lado. Ese identificador produce una dirección link-local, que basta para hablar con el par a través del enlace y no basta para alcanzar nada más. La dirección demuestra que el enlace está listo para IPv6 y no demuestra nada sobre la red detrás del par. Leerla como una dirección de acceso es el error con el que empiezan la mayoría de estas investigaciones.
Las cuatro preguntas siguientes separan lo que resuelve la capa de enlace de lo que debe aportar el servicio. Respóndalas en orden, porque a una pregunta posterior no se puede responder mientras una anterior siga abierta.
| 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 dónde tiene que venir el prefijo
Una dirección global necesita un prefijo de algún sitio: un anuncio de router, un prefijo delegado, DHCPv6 o configuración estática. IPv6CP no transporta ninguno, y ninguna espera en el enlace producirá uno. RFC 5072 sitúa IPv6CP como el paso de configuración que se ejecuta antes de que otros protocolos IPv6 funcionen en el enlace, y ese es todo su alcance: preparar el enlace, no numerar la red. Proporcione el prefijo y la interfaz empieza a transportar tráfico en lugar de solo existir.
Los anuncios de router son la respuesta habitual en una LAN y una menos fiable en un túnel punto a punto, porque el cliente tiene que enviar solicitudes y aceptar la respuesta a la vez. Algunos clientes de túnel no hacen ni una cosa ni la otra. Compruebe qué está dispuesto a aceptar el cliente antes de decidir que el servidor debe enviarlo.
El mismo prefijo tiene que ser alcanzable desde el otro extremo. Un cliente que tiene una dirección global pero ningún camino de vuelta está configurado, no conectado.
Las rutas son una promesa aparte
Incluso con una dirección, el cliente necesita saber qué destinos pertenecen al túnel, y el servidor necesita un camino de vuelta para esos destinos. Son dos decisiones tomadas en dos lugares. Un túnel que transporta todo el tráfico IPv6 necesita una ruta por defecto en el cliente y una ruta de vuelta en el servidor; un túnel dividido necesita que ambos lados acuerden la misma lista de prefijos. Cuando no coinciden, el tráfico sale y no vuelve nunca.
Escriba la lista antes de configurar nada. Si el plan dice que solo el prefijo corporativo pasa por el túnel, el cliente no debería tener una ruta IPv6 por defecto, y el servidor no debería anunciar ninguna.
La integración del cliente decide el resto
Algunos clientes de túnel configuran IPv6 de forma explícita. Network Extension de Apple, por ejemplo, toma una dirección, un prefijo y un conjunto de rutas para el túnel, así que una aplicación que lo usa no espera un anuncio al estilo Ethernet. Otros dependen de que lleguen anuncios de router por el enlace. Ambos modelos son legítimos y necesitan un comportamiento distinto del servidor, así que elegir el equivocado produce un cliente que espera para siempre un mensaje que nadie envía. Identifique el modelo antes de cambiar el servidor.
Un nombre de interfaz antiguo como ppp0 no demuestra nada sobre la pila que se ejecuta hoy. Un cliente actual puede usar una API de túnel de paquetes en lugar de una interfaz PPP, y suponer que se comporta como una conexión histórica es como se rompe un diseño que funciona. Pregunte por la versión del cliente y el método de aprovisionamiento, no por el nombre de la interfaz.
Escriba el plan que necesita el cliente
Una descripción completa cubre tres cosas: qué dirección tiene el cliente, qué destinos debe transportar el túnel y cómo envía la red las respuestas de vuelta. Una dirección link-local no responde a ninguna de ellas, y un anuncio aceptado responde solo a una parte de una. Compruebe cada elemento por separado en lugar de aceptar un indicador verde. Después anote qué mecanismo aportó cada respuesta, porque ese registro convierte el siguiente informe sobre IPv6 en una comprobación de dos minutos.
Guarde el registro con la documentación del servicio y actualícelo cuando cambie el cliente. Un plan que era correcto para un cliente PPP puede ser erróneo para un cliente de túnel de paquetes en el mismo servicio. Las cuatro preguntas siguen siendo las mismas; solo se mueven las respuestas.