Resumen

  • La revisión 28 precisa cómo observar y retirar reglas de correspondencia; la regla predeterminada ya aparecía en la revisión 27.
  • Tras retirar una regla específica para nuevas conversiones, una regla 0.0.0.0/0: Pref6(PE) configurada puede captar el tráfico restante; si no existe, se prevé descarte y señalización ICMP o ICMPv6.
  • Ninguna salida predeterminada debe anunciarse al otro lado de una frontera administrativa sin acuerdo bilateral explícito, y su ruta IPv4 no puede devolver el paquete al mismo mecanismo.

Tres actos distintos en una emergencia

El marco examinado por el grupo v6ops permite transportar tráfico IPv4 residual sobre una red subyacente solo IPv6. La conversión ocurre en los bordes y las correspondencias de direcciones permiten atravesar dominios cooperantes sin mantener estado por flujo en una pasarela situada en la trayectoria. Su ámbito es limitado: un operador o varios operadores que coordinan sus sistemas autónomos. No es una solución para el Internet abierto.

Los acuerdos bilaterales previos, la coordinación de prefijos, el filtrado ICMP común y la confianza en los puntos de entrada son condiciones que deben existir antes del uso; el borrador no las firma ni las verifica por los participantes.

Cuando se retira una regla específica, el primer acto es impedir que se emplee para nuevas conversiones. La revisión 28 recomienda hacerlo de inmediato, aunque permite un margen configurable de unos segundos para paquetes que ya estaban en tránsito. El segundo acto es elegir qué sucede después. Una regla predeterminada configurada puede hacerse cargo de los destinos IPv4 que ya no tengan una correspondencia más precisa. Sin ella, el texto indica que se descarte el paquete y se emita el error ICMP correspondiente.

El tercer acto aparece si la nueva salida pertenece a otro ámbito administrativo: confirmar que ese operador aceptó exactamente ese tráfico y que puede reenviarlo correctamente.

Confundir los tres actos permite contar una historia cómoda: «se retiró la regla y el servicio no se interrumpió». Esa frase omite quién absorbió el tráfico, bajo qué límite y con qué ruta final. Incluso dentro de un acuerdo de cooperación, un permiso para ciertos bloques no equivale a un mandato para todo el resto de IPv4. La continuidad puede ser una mejora; también puede ser una transferencia silenciosa de carga y riesgo.

El valor y el peligro de la regla comodín

La regla 0.0.0.0/0: Pref6(PE) da una salida cuando no hay correspondencia específica. Puede evitar una pérdida inmediata, pero concentrar tráfico en una salida subóptima, saturar capacidad o convertir la salida en objetivo de secuestro. Es importante no convertir esta mecánica en una noticia falsa: la revisión 27 ya la describía y advertía de riesgos. La revisión 28 vuelve más explícitos la gestión de la base de reglas, el comportamiento ante la retirada y el requisito de que el tráfico no forme bucles.

La distribución de reglas, según el borrador, debe conservar campos como el tipo de conversión, permitir limitar alcance y filtrar, autenticar el origen y rechazar asociaciones no autorizadas entre bloques IPv4 y prefijos de correspondencia. Las extensiones concretas de protocolo quedan fuera de este marco. Por tanto, no existe aquí una autoridad técnica universal capaz de convertir la recepción de un anuncio en una prueba de consentimiento bilateral. Si una regla cruza la frontera, la sección 9.4 exige un acuerdo explícito. Cada parte debe poder reconocer el alcance que aceptó.

Una ruta que se muerde la cola

Después de la conversión de salida, el paquete IPv4 recuperado no lleva una marca que diga «ya atravesé este marco». Si la mejor ruta IPv4 de la salida predeterminada apunta a otro punto de borde que participa en él, el paquete puede volver a convertirse y repetir el trayecto. El TTL o límite de saltos acaba limitando la duración de la vuelta, pero no impide que se haya elegido una ruta incorrecta ni el consumo repetido de recursos.

De ahí el requisito operativo: la salida predeterminada necesita una visión completa de encaminamiento IPv4 para el tráfico que atrae y no debe resolverlo hacia una ruta que reingrese en la red subyacente. También debe observarse y limitarse la regla comodín, con controles de acceso y velocidad apropiados. Antes de aceptar el reenvío habría que comprobar, para los destinos afectados, la mejor ruta real después de recuperar IPv4. Luego habría que contrastar los contadores por regla y los errores con la trayectoria esperada.

Un paquete entregado no demuestra por sí mismo la autorización; un paquete con TTL agotado no constituye prevención del bucle.

Un registro de cambio que ambas partes puedan reconocer

La revisión 28 recomienda versión o sello temporal de la regla, resúmenes de coherencia de la base MR-DB, avisos de cambio, contadores de reenvío por regla y acceso de gestión. Son medios de observación, no una afirmación de que ya estén desplegados en redes concretas.

Daniel Kade propone como análisis editorial un registro bilateral acotado: bloque y versión retirados, momento a partir del cual no sirven a nuevas conversiones, tratamiento del tráfico en vuelo, estado de las tablas restantes, salida de reserva, alcance aceptado por cada operador, resultado de la comprobación IPv4 y de no reingreso, contadores, errores, responsables y condición de reversión. Ni el registro ni sus campos son un artefacto normativo del IETF.

La ventaja de ese registro no es fabricar un acuerdo desde un solo lado, sino hacer comprobables dos consentimientos y una ruta. El operador de entrada sabe qué desvió; el de salida, qué recibió y adónde puede entregarlo. Ambos pueden delimitar cuándo deja de ser válido el reenvío. La posibilidad de observar tráfico no sustituye una firma, y una firma sin vista de encaminamiento tampoco evita un bucle.

El Datatracker mostraba la revisión 28 como Internet-Draft activo del grupo v6ops, destinado a un documento informativo y todavía bajo seguimiento del director de área en la IESG, con objeciones DISCUSS pendientes. No es un RFC aprobado, un protocolo de distribución terminado ni un informe de incidente real. Precisamente por eso conviene leer su frontera con rigor: una propuesta técnica puede formular condiciones, pero no otorgar por sí sola el poder de enrutar a través de otro operador.

Fuentes