Resumen

  • IPv6 multihoming no queda resuelto al asignar dos prefijos: la fuente, el primer salto y el resolutor deben pertenecer a un contexto compatible.
  • La prueba operativa debe conservar las tres decisiones de una misma tentativa sin convertir una configuración recibida o un éxito aislado en garantía general.

El síntoma suele llegar demasiado tarde. La consulta DNS respondió. El sistema escogió una dirección de origen válida. Había un router por defecto alcanzable. Después, silencio. La lista de piezas parece completa porque cada subsistema muestra una marca verde. El fallo está en la unión: la respuesta procedía del VPN, el origen de un proveedor fijo y el primer salto de un enlace móvil.

Ese tipo de combinación ocupa el centro de la RFC 7157, IPv6 Multihoming without Network Address Translation. Se publicó en marzo de 2014 como RFC informativa, tras revisión y consenso del IETF. O. Troan figura como editor, junto con David Miles, Satoru Matsushima, Takashi Okimoto y Dan Wing. La ficha oficial de Ole Trøan documenta esa participación. No autoriza a atribuirle la invención individual del modelo, la operación de redes ajenas ni la autoría de especificaciones posteriores.

La observación decisiva es que NAPT no sólo cambia direcciones. En una instalación IPv4 típica, el equipo de borde también resuelve qué dirección exterior usar, por cuál siguiente salto enviar y, a veces, qué servicio DNS consultar. Para el host interior, una dirección privada y una puerta resumen un conjunto más amplio de decisiones. La concentración reduce lo que el extremo necesita saber, pero también oculta quién decidió cada cosa.

Un sitio pequeño con IPv6 puede recibir un prefijo de cada proveedor. Un portátil conserva a la vez Wi‑Fi, telefonía y un túnel corporativo. Cada conexión aporta direcciones, routers y resolutores. La transparencia extremo a extremo evita que toda comunicación dependa de una traducción invisible, pero no crea por sí sola la política que enlaza esos parámetros.

RFC 7157 formula tres problemas. Primero, qué dirección de origen corresponde al destino. Segundo, qué primer salto acepta y transporta ese origen. Tercero, qué resolutor conoce el espacio de nombres pertinente. La selección debe ser coherente antes del primer paquete, en especial porque los proveedores suelen aplicar filtros de ingreso: una fuente asignada por A puede ser descartada si el paquete sale por B.

La dirección configurada es sólo una candidata. RFC 6724 define algoritmos por defecto para elegir fuentes y destinos y permite una tabla de políticas administrativas. En un entorno con varios prefijos, esa tabla puede no resolver de forma determinista la fuente adecuada para cada proveedor. RFC 7078 ofrece una opción DHCPv6 para distribuir información de política. Conviene no exagerar el recibo: el mensaje prueba qué configuración llegó, no que el host la instaló, que seguía vigente ni que gobernó una tentativa concreta.

El primer salto tiene su propia decisión. Dos Router Advertisements pueden dejar dos routers válidos. Elegir cualquiera puede enviar una fuente legítima por un borde que no la acepta. RFC 8028, publicada después en Standards Track, fija una secuencia para hosts con varios prefijos: primero se elige la fuente y luego se busca un router que haya anunciado ese prefijo. Sus autores son Fred Baker y Brian Carpenter. El agradecimiento a Ole Troan por texto importante acredita colaboración, no transfiere la autoría.

El DNS añade una dimensión que no cabe en la tabla de rutas. Un nombre interno puede existir únicamente dentro del VPN. Dos resolutores pueden devolver respuestas distintas según el origen. Preguntar a todos y aceptar el primero puede producir una dirección válida pero inútil desde la salida elegida. RFC 7157 contempla política basada en el espacio de nombres y remite a RFC 6731 para distribuir selección de DNS mediante DHCPv6. El resultado debe conservar la identidad del contexto que lo produjo.

No hay un único propietario de la cadena. La aplicación plantea un nombre y una intención. La política DNS elige un contexto y obtiene destinos. El host escoge la fuente. La lógica de red decide la puerta. El proveedor acepta o descarta. El servidor responde o no. Un panel que sólo guarda el último resultado convierte un problema de coordinación en una disputa entre equipos con evidencias incomparables.

Tampoco existe un eslogan fiel para las alternativas. RFC 7157 propone evitar NAT y NPTv6 cuando sea posible para conservar la transparencia extremo a extremo. En la misma conclusión admite que NPTv6 puede ser necesario como solución intermedia y considera adecuadas las vías basadas en DHCPv6 para los problemas analizados. RFC 6296 define traducción stateless de prefijos. Ninguno de esos textos demuestra que una opción sea correcta para todas las redes.

La arquitectura de dominios de provisión desarrolló después una forma de mantener juntas las configuraciones relacionadas. RFC 7556 denomina PvD al conjunto coherente de prefijos fuente, servidores DNS, sufijos, puerta por defecto y otros parámetros. Su modelo intenta evitar que un nodo mezcle, por accidente, piezas de dominios distintos. RFC 8801 añade identificadores PvD basados en FQDN dentro de anuncios de router y datos JSON opcionales. Un identificador mejora la asociación; no certifica alcance, confianza ni éxito.

Por eso el objeto auditable debe ser una tentativa. Un mismo identificador enlaza el nombre pedido, el PvD y resolutor usados, la respuesta y su TTL, el destino elegido, las fuentes candidatas, la fuente seleccionada, la versión de política, los routers disponibles, el primer salto, los prefijos anunciados, el vecino, el filtro, los reintentos y la observación remota. Los tiempos monotónicos preservan el orden aunque cambie el reloj civil.

Las fronteras importan. Tener una dirección no demuestra haberla elegido. Elegirla no prueba aceptación aguas arriba. Recibir un anuncio no prueba que el router haya reenviado. Obtener DNS no prueba entrega. Incluso una respuesta de aplicación demuestra sólo que una combinación funcionó durante ese intento. Esa modestia no debilita la operación; impide fabricar certeza donde sólo hay registros parciales.

Leída así, la labor editorial de Trøan aporta una pregunta duradera: cuando desaparece la caja que centralizaba tres políticas, ¿puede la red mostrar cómo las vuelve a unir? La transparencia exige decisiones visibles, no ausencia de decisiones.

Fuentes