Resumen

  • El cambio normativo descansó en una pareja: los routers deben admitir /127 en enlaces inter-router punto a punto y deben desactivar el anycast Subnet-Router para ese prefijo.
  • La máscara configura un espacio de dos direcciones, pero no demuestra que el medio tenga solo dos routers, que no haya hosts ni que ambos extremos cumplan la conducta requerida.

El segundo MUST explica el primero

Leer únicamente la primera obligación de RFC 6164 produce una conclusión demasiado cómoda. Sí: los routers deben soportar prefijos /127 en enlaces punto a punto entre routers. Pero la frase siguiente ordena desactivar el anycast Subnet-Router para ese prefijo. Las dos instrucciones forman una sola pieza de ingeniería.

La razón está en RFC 3627. Con dos direcciones disponibles, el primer router podía recibir la dirección terminada en uno y, además, reclamar la terminada en cero como dirección anycast del subred. El segundo router tenía previsto usar ese cero como dirección unicast. La detección de direcciones duplicadas podía impedir la configuración. La semántica colectiva y la identidad individual habían ocupado el mismo valor.

El documento de 2003 reconocía que aquel anycast parecía poco útil en un enlace de dos routers. También señalaba que el fallo no se había visto a gran escala, quizá porque muchas implementaciones no ejecutaban la función. Esa falta de uniformidad era parte del problema: una práctica podía funcionar durante años y romperse al sustituir un extremo por otro más fiel a la arquitectura.

Por eso la historia no se resume en “antes estaba mal, después estuvo bien”. RFC 6164 acepta que el análisis anterior era correcto. Lo que hace es eliminar el mecanismo conflictivo dentro de un ámbito controlado y, a cambio, ordenar soporte explícito. El primer MUST habilita; el segundo desambigua.

El ámbito es una condición de validez

El texto de 2011 define el enlace con cuidado. Debe conectar exactamente dos routers y ningún host. Puede ser Ethernet, pero solo si está configurado para uso punto a punto. No cubre una conexión entre router y host, un segmento mixto ni la dirección link-local. Presupone direcciones específicas para tareas como monitorización, DNS inverso, traceroute, gestión o sesiones EBGP.

Ese inventario es el verdadero contrato. El número 127 solo comprime la parte de dirección. No certifica cuántos participantes puede admitir un servicio Ethernet, quién comparte un túnel ni si una plataforma virtual permite adjuntar otro extremo. Tampoco dice qué versión ejecuta cada router.

La norma conserva límites dentro del bloque padre. Si varios /127 salen de un /64, no deberían asignarse como unicast los valores cuyos 64 bits inferiores son todos cero. También deben evitarse los 128 valores superiores reservados para anycast de subred. Haber desactivado una función en un enlace no libera todos los identificadores reservados alrededor de él.

El contrato, por tanto, tiene dimensiones de topología, implementación y asignación. Un sistema de gestión que guarda solo el prefijo conserva una de tres.

El atacante no necesitaba ocupar una dirección

En un /64 Ethernet con Neighbor Discovery, la ausencia puede consumir recursos. Un paquete dirigido a una dirección sin vecino hace que el router cree una entrada INCOMPLETE, emita una Neighbor Solicitation y mantenga temporizadores. Un atacante puede repetirlo sobre una cantidad inmensa de destinos que nunca responderán.

RFC 6164 cuantifica el espacio: después de restar los dos routers y el anycast Subnet-Router quedan 2^64 - 3 direcciones sin asignar. La limitación de solicitudes y la recolección del caché ayudan, pero no garantizan que una sesión BGP legítima vuelva a levantarse mientras el ataque presiona la resolución de vecinos. El /127 cierra ese conjunto dentro del prefijo local al asignar sus dos valores a los extremos.

La otra amenaza es el rebote. En medios punto a punto que no usan Neighbor Discovery, una ruta on-link más amplia puede hacer que un paquete para una dirección vacía viaje de un router al otro y vuelva. RFC 4443 prohíbe reenviarlo por el mismo enlace y recomienda un ICMPv6 Destination Unreachable. RFC 6164 observa que ese control vive en la ruta de reenvío y que una longitud exacta elimina el destino sobrante, incluida la exposición a comportamientos antiguos.

La escasez de direcciones fue un beneficio secundario. El cambio principal fue reducir trabajo involuntario y hacer más estrecha la superficie del enlace. La práctica operativa no ganó la discusión por mayoría; aportó un perfil que podía retirar el anycast problemático y resolver fallos más costosos.

Historic dirige al lector, no borra el expediente

RFC 6547 movió RFC 3627 al estado Historic en 2012. También dejó claro que la guía Standards Track de RFC 6164 debe prevalecer cuando ambos textos chocan. Ese enlace de estado evita que un lector ocasional siga la advertencia anterior como si nada hubiera ocurrido.

Pero el cambio no niega el caso de Duplicate Address Detection. No elimina la observación sobre implementaciones heterogéneas. No borra el erratum que corrige el nombre de una referencia ICMPv6. Cambia la autoridad prescriptiva para el presente, mientras conserva el expediente que explica por qué hizo falta la pareja de obligaciones nueva.

Una arquitectura documental sana permite precisamente eso. Los hechos históricos permanecen consultables. La regla vigente señala su ámbito. Ningún comité necesita declarar falso todo el pasado para admitir que un conjunto de participantes adoptó otra compatibilidad.

La cadena de evidencia después de la norma

Antes de aprobar /127, el operador necesita probar el medio: dos routers, ningún host y ausencia de capacidad multipunto no controlada. Necesita probar ambos extremos: soporte, supresión del anycast, Neighbor Discovery e ICMPv6 según corresponda. Necesita validar el plan padre para no caer en valores reservados.

Después vienen pruebas distintas. Una vecindad confirma un intercambio de control. Una ruta instalada confirma una decisión local. Un paquete observado confirma un resultado concreto. Ninguna de ellas convierte automáticamente las demás en verdaderas, y ninguna dura para siempre después de un cambio de software o topología.

Esta separación impide que la documentación se convierta en autoridad imaginaria. El RFC autoriza una opción dentro de un conjunto. El inventario registra intención. La telemetría y las pruebas muestran qué está ejecutándose. La aceptación profesional exige que las tres capas coincidan.

La reversión bien diseñada

El valor del episodio no es que la IETF haya cambiado de opinión. Es que el cambio puede expresarse como una transición comprobable: preservar el diagnóstico, restringir el dominio, retirar la semántica que chocaba, atender nuevos riesgos y enlazar formalmente los documentos.

Sustituir “nunca /127” por “siempre /127” destruiría ese trabajo. El perfil de RFC 6164 es pequeño por diseño. Su fuerza procede de que cada condición puede observarse y cada incumplimiento puede activar un retorno.

La autoridad correcta no está en la máscara ni en el número del documento. Está en la correspondencia entre la regla publicada y el enlace que realmente funciona.

Fuentes