Resumen

  • Un borrador individual del 21 de julio introduce la Specific Local Address Table, SLAT. Cada cliente del servidor de rutas puede ver un alias IPv4 diferente para el siguiente salto de un mismo miembro físico.
  • El servidor reescribe NEXT_HOP según la columna del destinatario antiguo; el proxy ARP/ND del intercambio debe resolver ese alias hacia el miembro correcto. El anuncio BGP y la entrega del paquete dependen de la misma libreta de direcciones.
  • RFC 7947 exige normalmente que el servidor de rutas no toque NEXT_HOP. La propuesta establece una excepción; los pares bilaterales que no pasan por el servidor necesitan la tabla publicada o su propia traducción.

Dos redes reciben el mismo prefijo IPv4 desde un servidor de rutas. Una entiende un siguiente salto IPv6; la otra solo puede instalar uno IPv4. El destino final del tráfico no ha cambiado: sigue siendo la red que originó el anuncio. Lo que cambia es el nombre local que cada receptora usa para encontrarla en la LAN. El diseño anterior podía dar a cada miembro una IPv4 pública. El nuevo pone un alias privado o local en la vista de cada cliente.

RFC 8950 permite llevar un prefijo IPv4 con siguiente salto IPv6 tras negociar la capacidad correspondiente. El router antiguo no adquiere esa capacidad porque el resto del intercambio haya migrado. El borrador de traducción distingue clientes Legacy, que requieren IPv4; Supporting, que manejan ambas opciones; y Unnumbered, que usan siguiente salto IPv6 y carecen del IPv4. La incompatibilidad llega al servidor de rutas, que debe decidir qué dirección ve cada uno.

La base empieza con una identidad física: una MAC fija, una IPv6 local al enlace y una IPv6 global por miembro, únicas en el intercambio. Esas ternas forman la Local Address Table. Para cada cliente Legacy o Supporting, el operador acuerda un prefijo IPv4 local específico y añade una columna de direcciones para todos los miembros: la SLAT. En la tabla ilustrativa del borrador, la misma máquina puede ser 10.0.0.10 para un cliente y 192.0.2.10 para otro. Ninguna columna crea un segundo vecino físico; crea una segunda forma de nombrarlo.

El servidor debe aplicar esa regla en ambos sentidos. Al recibir una ruta IPv4 con NEXT_HOP IPv4, lo cambia a la IPv6 del emisor registrada en SLAT. Al enviarla a un receptor Legacy, sustituye el campo por el alias IPv4 del emisor en la columna de ese receptor. Para Unnumbered no debe reescribirlo; para Supporting, el borrador recomienda conservarlo. Si el siguiente salto no corresponde a ningún miembro registrado, el servidor no debe difundir la ruta. El libro de direcciones deja de ser inventario pasivo: habilita o detiene anuncios.

También gobierna la búsqueda de vecinos sobre la LAN. El punto de intercambio observa ARP y Neighbor Discovery, responde las consultas con la columna SLAT que toca y, en el modelo propuesto, impide que esas consultas circulen directamente entre clientes. Una ruta puede figurar correctamente en BGP mientras el proxy responde con una MAC equivocada para su alias. La prueba que falta en cualquier instalación concreta es una secuencia común de anuncio recibido, fila SLAT, respuesta ARP/ND, FIB del receptor y paquete entregado, repetida tras cambiar una dirección del miembro.

La propuesta modifica una norma de conducta conocida. La sección 2.2.1 de RFC 7947 obliga al servidor a transmitir NEXT_HOP intacto porque no transporta los paquetes. El nuevo texto aparta expresamente esa regla para su traducción. En el diseño SLAT el servidor sigue fuera del camino de datos, pero custodia el nombre que permite al receptor hallar al par real. El proxy debe consultar la misma verdad. Los autores recomiendan una fuente única para las asignaciones y comprobaciones periódicas de que las distintas formas del siguiente salto terminan en el mismo miembro.

La transición puede ser gradual. Primero llega la observación ARP/ND. Después se despliega un servidor nuevo, capaz de tratar IPv6 como siguiente salto de rutas IPv4, junto al tradicional. Las columnas SLAT pueden comenzar copiando las IPv4 públicas actuales y cambiar a prefijos locales cuando la reserva se estreche. Durante ese período mixto hay dos vistas operativas: mantener un rollback exige conservar las dos y probar dónde lleva cada una.

El acuerdo bilateral escapa al traductor central. Cuando dos miembros intercambian rutas directamente, el borrador pide publicar una SLAT actualizada para que traduzcan por su cuenta. También propone que el looking glass enseñe el valor IPv4 original, el siguiente salto IPv6 real y el alias de salida para un cliente elegido. Esa triple vista evita tratar una dirección local como si fuera la identidad universal del par. Otra variante introduce una máquina proxy que sí reenvía tráfico entre dos dominios; su riesgo pertenece a esa arquitectura, no al servidor SLAT que solo reescribe anuncios.

La escasez de IPv4 se resuelve aquí con una obligación nueva, no con un truco de sintaxis. El intercambio puede ahorrar direcciones públicas si mantiene sincronizados el anuncio por destinatario y la respuesta de vecino. Los paquetes decidirán si la libreta estaba al día.

Borrador Route Server Next Hop Translation, revisión 02 · RFC 7947 · RFC 8950 · RFC 9161