Resumen

  • RFC 8950 permite anunciar alcance IPv4 y VPN-IPv4 con un next hop IPv6. La capability 5 expresa soporte para una terna exacta de AFI de NLRI, SAFI de NLRI y AFI de next hop; no habilita por sí sola la familia ni demuestra que el next hop sea alcanzable.
  • El receptor deduce el tipo del next hop a partir de la longitud. Un route reflector debe conservar el encoding recibido y no puede distribuir la NLRI a un cliente que no anunció capacidad para procesarlo.
  • Una migración defendible prueba por separado los OPEN, MP_REACH_NLRI, policy de importación, recursión IPv6, ruta elegida, FIB, adyacencia o túnel y tráfico IPv4 real. Una sesión verde es solo el primer peldaño.

A la 1:40, un sitio de agregación traslada su transporte a un único underlay IPv6. Los clientes y sus prefijos continúan en IPv4. El objetivo es retirar del core la duplicación de direcciones, IGP y procedimientos de fallo, no convertir los servicios.

Dos route reflectors y casi todos sus clientes soportan el mecanismo. Un equipo nuevo anuncia IPv4 unicast y Extended Next Hop Encoding. Otro, más antiguo, anuncia únicamente la familia. Ambas sesiones llegan a Established.

El equipo nuevo recibe y selecciona las rutas IPv4, pero su resolver busca el next hop IPv6 en una VRF de gestión y termina en una interfaz ajena al servicio. El equipo antiguo no recibe esas rutas: el reflector no está autorizado a reescribir el next hop IPv6 como IPv4 para acomodarlo. Los paneles de sesión y de tabla pueden estar verdes mientras el servicio está partido.

Destino y next hop son afirmaciones distintas

La NLRI dice qué destinos son alcanzables. El next hop dice hacia qué dirección debe resolver y reenviar el receptor para usar ese alcance. Que ambas direcciones pertenezcan habitualmente a la misma familia no las convierte en un solo objeto.

MP-BGP hace visible la separación. MP_REACH_NLRI contiene AFI, SAFI, longitud del next hop, sus bytes y la NLRI. RFC 4760 define el contenedor. Las definiciones IPv4 anteriores solo preveían next hops IPv4, lo que impedía describir un servicio IPv4 a través de un core IPv6 de forma general.

RFC 8950 amplía la combinación permitida. AFI 1 sigue significando NLRI IPv4; para ciertas SAFI, el AFI del next hop puede ser 2. No traduce la dirección del cliente ni elimina la obligación IPv4. Separa la familia del destino de la familia del ancla de transporte.

La adopción sigue siendo local. Un operador puede activarla en un dominio, un conjunto de peers o una familia de servicio. Quien no adopta permanece en otro conjunto de compatibilidad, no en estado inválido. El estándar ofrece una regla común mínima; no un gobierno de migración.

También debe evitarse la exageración económica. Un core IPv6-only puede reducir estado duplicado, pero no borra clientes, contratos, valor de direcciones, soporte o riesgo IPv4. El nombre de una capa no describe todo el producto.

La capability promete una terna, no el servicio

Extended Next Hop Encoding usa el código 5. Su value consta de ternas de seis octetos: dos para NLRI AFI, dos para NLRI SAFI y dos para next-hop AFI. RFC 8950 usa AFI 1, SAFI 1, 2, 4, 128 o 129 y next-hop AFI 2.

El detalle no es decorativo. Soporte para IPv4 unicast no demuestra soporte para labeled unicast, multicast o VPN-IPv4. Releases y plataformas pueden cubrir subconjuntos distintos. Un campo único supported=true destruye la precisión operativa.

La capability 5 tampoco permite el AFI/SAFI. La capability Multiprotocol determina por separado si la familia se intercambia. El código 5 solo declara qué encoding de next hop entiende un peer para una familia ya admitida.

Por eso la evidencia de OPEN tiene dos controles: ¿se negoció la familia MP-BGP? ¿El receptor anunció la terna exacta? Una sesión puede quedar Established sin cualquiera de ellos. El sender solo puede usar next hop IPv6 tras comprobar el segundo.

Esta regla breve encarna el Minimum Initial Specification de Heng Lu. Los peers comparten un código y una validación determinista; cada borde conserva la decisión de adopción. La ausencia de soporte produce compatibilidad limitada, no autoridad central ni castigo.

La longitud asigna el tipo

Para AFI 1 y SAFI 1, 2 o 4, un next hop IPv6 mide 16 o 32 octetos. Dieciséis codifican una dirección; treinta y dos pueden incluir una global seguida de una link-local según RFC 2545.

Para VPN-IPv4 con SAFI 128 o 129, el formato mide 24 o 48 octetos e incluye un Route Distinguisher de ocho octetos en cero. RFC 8950 ajustó el encoding VPN de RFC 5549 a las implementaciones interoperables desplegadas y corrigió una errata conocida.

El receptor debe usar esa longitud, dentro de lo permitido por AFI/SAFI, para saber a qué protocolo pertenece el next hop. No es metadato de pantalla. Un pipeline que convierte todo en una cadena sin tipo pierde la base de una auditoría posterior.

Global y link-local tampoco tienen la misma autoridad. Una global puede resolverse en una tabla; una link-local solo es única junto a interfaz y enlace. fe80::1 sin peer, interfaz y VRF no identifica un next hop completo.

Esto importa en eBGP unnumbered. El transporte y la capability pueden estar correctos mientras el FIB carece de la adyacencia con scope de interfaz. Un reinicio o reemplazo puede conservar el texto de la dirección y cambiar el contexto que le daba validez.

En VPN, el RD cero del campo next hop no elimina el RD de servicio ni los route targets de la ruta. Encoding del next hop e identidad VPN son objetos separados.

El reflector no es un traductor

Si un route reflector conserva un next hop, debe conservar su encoding. Si un cliente no lo soporta, la NLRI no puede llegarle. Sustituir IPv6 por IPv4 no sería una mejora de formato, sino una nueva decisión: otro punto de recursión, otro camino y otro dominio de fallo.

Una sola actualización puede revelar una limitación en todo el client set. Si cualquier cliente origina un encoding que otros deben recibir, todos los destinatarios relevantes necesitan compatibilidad. El reflector puede actuar correctamente y aun así dejar una tabla desigual.

La ausencia resultante es engañosa. El cliente antiguo continúa Established y recibe rutas IPv4 de encoding clásico. El reflector conserva la ruta nueva. Un contador solo muestra diferencia; no explica que la declaración del propio cliente impidió la distribución.

La prueba une, en el mismo epoch, UPDATE de origen, ruta aceptada por el reflector, OPEN del cliente destino y Adj-RIB-Out hacia él. El motivo debe ser encoding no soportado, no un genérico prefijo ausente.

next-hop-self, route servers y confederaciones cambian la frontera y necesitan ensayos propios. Un rewrite puede ser legítimo, pero entonces es una acción local con propietario y evidencia, no reflexión transparente.

La recursión convierte sintaxis en operación

Tras aceptar el UPDATE, el receptor busca el next hop IPv6 en una tabla o VRF, sigue la recursión, enlaza adyacencia o túnel y entrega el resultado al FIB.

Todo puede fallar por separado: next hop fuera del IGP, route solo en global mientras el proceso consulta una VRF, recursión incompleta, Neighbor Discovery fallido, label/SID ausente, MTU insuficiente después de encapsular o line card retrasada.

La escalera de evidencia es:

  1. familia MP-BGP anunciada;
  2. terna exacta de extended next hop;
  3. MP_REACH_NLRI esperado en el wire;
  4. tipo interpretado correctamente;
  5. import policy aceptó la ruta;
  6. decision process la eligió;
  7. next hop resuelto en el contexto previsto;
  8. FIB programó el destino IPv4 hacia la adyacencia o túnel;
  9. paquetes IPv4 fueron y volvieron.

Ningún peldaño prueba el siguiente. “BGP tiene la ruta” es insuficiente. Un dashboard puede reunir estados, pero debe preservar qué observación autorizó cada transición.

El rollback exige la misma precisión. Volver a next hop IPv4 puede requerir restaurar underlay, next-hop-self, capabilities antiguas y anuncios en orden. Quitar el código 5 sin recuperar el resolver anterior no es reversión.

La política de seguridad gana una superficie IPv6

RFC 8950 no autentica las rutas. Una sesión protegida puede llevar un anuncio no autorizado. RPKI origin validation estudia el origin AS del prefijo IPv4, no la seguridad ni la resolución del next hop IPv6.

Herramientas que solo inventarían next hops IPv4 para rutas IPv4 perderán el nuevo objeto. RFC 8950 advierte que el next hop IPv6 puede facilitar desvío a través de infraestructura IPv6, con riesgo de hijacking o denial of service. También requiere considerar el caso poco común de una dirección IPv4-mapped IPv6.

No hace falta rechazar toda ruta entre familias. Hace falta una autorización más rica: peers permitidos, familias, scopes IPv6, tablas, túneles y servicios IPv4 que pueden depender de ellos.

Transport authentication, GTSM, prefix policy, RPKI, autorización del next hop, seguridad underlay y validación con paquetes conservan funciones distintas. Correlacionarlas mejora la decisión; fusionarlas inventa certeza.

El canary cruza ambas familias

Antes de activar, seleccionar un prefijo IPv4 limitado y un next hop IPv6 previsto. Guardar ruta, FIB, trayectoria de paquetes, peer, contexto de resolver y ternas esperadas en cada speaker.

En un nuevo session epoch, capturar los OPEN de ambos lados y comprobar por separado Multiprotocol y código 5. Después validar el UPDATE: AFI 1, SAFI correcta, longitud 16/32 o 24/48, bytes IPv6 exactos y NLRI sin cambios.

Con reflector, probar conservación del next hop y soporte de cada cliente. En cada receptor, guardar pre-policy, post-policy, ruta elegida, lookup recursivo, tabla, adyacencia/túnel y FIB.

Enviar tráfico IPv4 representativo con source, destination, dirección, retorno, tamaño y epoch. Un ping no representa encapsulación o MTU. Finalmente retirar el canary y verificar limpieza en Adj-RIB-Out, RIB, recursión y FIB.

Que la configuración anterior exista en Git no prueba que el camino anterior todavía funcione. La reversión existe cuando vuelve a transportar paquetes bajo el estado actual.

El RFC define lenguaje común; los vendors implementan; los operadores eligen; la red en ejecución decide. El destino no se vuelve IPv6 por cruzar un core IPv6. El número visto en OPEN no es autoridad de forwarding. La ruta solo adquiere credibilidad cuando tipo, policy, recursión, hardware y paquetes coinciden.