Resumen

  • La revisión 02 del borrador v6ops, de 28 de octubre, ordena las fuentes para errores ICMPv6 cuya IPv6 externa no puede traducirse: usar una IPv4 pública disponible cuando la haya; si no, usar obligatoriamente 192.0.0.8. La revisión 01 no establecía esa prioridad explícita.
  • El traductor debería añadir un objeto Node Identification con la IPv6 original. En Packet Too Big puede omitirlo, porque la extensión se incorpora después de traducir a ICMPv4; aun así, debería entregar el error. IANA registra 192.0.0.8/32 como dirección ficticia, sin alcance global como destino.

La fuente de la respuesta no siempre es la fuente del problema

Cuando tráfico IPv4 pasa por una red solo IPv6, un equipo intermedio puede devolver un error ICMPv6. Puede avisar que el destino es inalcanzable, que se agotó el tiempo o que el paquete es demasiado grande. Si la dirección IPv6 externa del error no pertenece al prefijo de traducción y no tiene entrada estática ni con estado, el traductor no puede escribirla en el campo de fuente IPv4 de la respuesta. La ausencia de una dirección adecuada no elimina el hecho que el error intenta comunicar.

La nueva sección 4.1 separa dos condiciones que antes aparecían mezcladas. Si el traductor posee una dirección IPv4 pública o un conjunto de ellas, debería emplearla siguiendo la ruta de RFC 6791. Si carece de ella, debe usar 192.0.0.8. El texto anterior recomendaba la dirección ficticia para el caso de fuente intraducible sin formular claramente la preferencia por una dirección pública disponible. El cambio reconoce una diferencia económica y operativa concreta: algunos traductores en redes IPv6 no disponen de una IPv4 pública solo para firmar visualmente sus errores.

La tabla oficial de IANA identifica el /32 como «IPv4 dummy address», asignada por RFC 7600. Sus columnas permiten uso como fuente, pero no como destino válido, reenviable o globalmente alcanzable. En una herramienta de diagnóstico ese valor puede aparecer como fuente de la respuesta traducida. Su nombre en el registro describe una función, no un nodo físico en la ruta. Dibujar un salto llamado 192.0.0.8 como si fuese el router que originó el error sería tomar el sustituto administrativo por el testigo.

El borrador propone que el traductor añada un objeto Node Identification con un subobjeto IP que contenga la IPv6 original. Si añade el objeto, esa dirección es obligatoria y la suma de comprobación de la cabecera de extensión debe actualizarse. Si la fuente IPv6 se puede traducir de forma ordinaria, el texto prohíbe tanto la fuente ficticia como esa extensión. La bifurcación no depende del aspecto de la pantalla: depende de si existe una correspondencia real para la dirección externa.

El error de tamaño obliga a aceptar una atribución incompleta

Packet Too Big muestra la incomodidad del diseño. La extensión ICMP no puede agregarse al mensaje ICMPv6 Packet Too Big antes de traducirlo. El objeto de identificación debe entrar después, ya en el mensaje ICMPv4. La revisión 02 permite que una implementación omita el objeto en ese caso; le recomienda conservar la traducción del error con la dirección ficticia y no descartarlo. Perder el aviso de tamaño por no tener IPv4 pública sería un mal negocio para el emisor que necesita ajustar sus paquetes.

La contrapartida es clara. El cliente IPv4 puede recibir una señal válida de tamaño y, al mismo tiempo, ver solo el marcador de respaldo como dirección aparente. La entrega del error y la identificación de su origen son dos pruebas distintas. El borrador no promete que una extensión opcional aparezca en cada caso ni que todo programa de traceroute sepa leerla.

Antes de actuar, el traductor también debe distinguir errores causados por paquetes IPv4 que él convirtió de tráfico IPv6 nativo que no requiere esta operación. Una dirección o un /64 dedicado a la traducción facilita el juicio. Si la misma IPv6 cumple ambas funciones, el borrador señala que puede ser necesario mantener estado o inspeccionar la cabecera del paquete que provocó el error. La clasificación no brota del número 192.0.0.8: es trabajo del operador y de su implementación.

El apartado operativo añade una dependencia menos visible: las herramientas deben interpretar y mostrar Node Identification para que la dirección IPv6 original ayude a investigar. Una extensión puede estar en la captura y faltar en la interfaz. Los artículos anteriores sobre este objeto trataron su política de divulgación y el caso de AFI desconocido. Este borrador tiene otra tesis: la elección de fuente de un traductor IPv6/IPv4 sin dirección pública. El Datatracker lo presenta como propuesta del grupo v6ops en evaluación del IESG, destinada a actualizar RFC 6791 y RFC 7915 si se aprueba. Falta una traza de implementación que muestre ambas ramas en funcionamiento.

Fuentes