Resumen

  • RFC 6666 asigna 100::/64 como bloque IPv6 exclusivo para descarte. Puede distribuirse dentro de un sistema autónomo y resolverse hacia interfaces nulas, pero no debe anunciarse a AS de terceros ni aceptarse desde ellos.
  • El bloque no es la ruta de la víctima, la comunidad BLACKHOLE ni un comprobante de entrega. La prueba une autorización, aceptación, resolución recursiva, FIB, contadores de descarte, contención exterior y retirada.
  • Nick Hilliard y David Freedman firmaron conjuntamente el RFC informativo. Su aporte fue aclarar la operación: un nombre globalmente inequívoco para una acción local, no un servicio global ni una orden de despliegue.

El control dijo «aceptado» antes que la red

Un servicio IPv6 recibe una avalancha. Un operador autorizado inyecta por iBGP un /128 para la dirección atacada, usa una dirección de 100::/64 como siguiente salto y ve que todos los bordes aceptan la ruta. La automatización cierra el ticket: blackhole activo.

Falta el resultado. En tres bordes, la recursión encuentra una ruta estática a la interfaz nula y los paquetes mueren. En otro falta esa ruta y el objeto BGP nunca se convierte en una entrada de reenvío. En un quinto, un filtro de exportación defectuoso deja salir el propio prefijo de descarte. Un solo estado de control oculta tres desenlaces.

No es un incidente real. Es una prueba mental para separar lo que RFC 6666 coordina de lo que una implementación debe demostrar.

Una dirección global para una decisión local

El blackholing de destino cambia el siguiente salto del host o prefijo atacado para eliminar el tráfico antes de que ocupe enlaces y equipos internos. En IPv4 se recurrió durante años a direcciones privadas que los routers de borde ya enviaban a una interfaz nula. La práctica era eficaz, pero tomaba prestado un espacio con otra función. Usar direcciones de documentación mezclaba todavía más el ejemplo con el control productivo.

RFC 6666 pidió por eso un bloque IPv6 propio. IANA registra 100::/64, escritura normalizada de 0100::/64, como Discard-Only Address Block. No está asignado a una parte final. El registro vigente lo marca como válido en los campos de origen y destino y como reenviable, pero no alcanzable globalmente.

La aparente tensión describe el diseño. Un router debe poder transportar la dirección y resolverla dentro del dominio. Un tercero no debe considerarla un destino de Internet. El bloque se comporta como un identificador unicast donde la maquinaria de rutas lo necesita y como una frontera donde empieza eBGP.

Ese es el papel limitado del registro. IANA fija el significado; no instala la ruta nula, no decide qué cliente puede apagar qué dirección, no descarta el paquete y no asume el coste de los usuarios legítimos desconectados. La coordinación no sustituye a la operación.

Tres mecanismos, tres recibos

RTBH de destino sacrifica la dirección atacada para proteger el resto. RTBH de origen usa estado de rutas y uRPF para rechazar paquetes cuya fuente debería resolverse por el camino de descarte. Tienen autoridades, daños y métricas diferentes. La activación de uno no prueba la del otro.

Una interfaz nula tampoco es un sinkhole. La primera elimina; el segundo desvía hacia un sistema de observación y puede devolver tráfico seleccionado a su ruta normal. La palabra «blackhole» no debe ocultar si hubo captura, retención, análisis o posibilidad de seguir hacia el destino.

Y 100::/64 no es la comunidad BLACKHOLE de RFC 7999. El bloque ofrece un siguiente salto recursivo estable dentro del AS. La comunidad es una señal consultiva adherida al prefijo de la víctima. Cada operador decide si la honra, y entre dos redes debe existir acuerdo y validación de que el vecino está autorizado a anunciar el prefijo. Sin política explícita, el equipo no debería descartar por haber visto la comunidad.

Por eso, recibir una comunidad demuestra recepción de intención, no acción en el plano de datos. Un AS también puede usar el bloque de descarte internamente sin pedir a un vecino que interprete BLACKHOLE. Una herramienta cruza relaciones; la otra ordena la recursión local.

La ruta correcta existe dentro y no existe fuera

RFC 6666 permite distribuir parte o todo 100::/64 dentro del AS y apuntarlo a una interfaz nula en algunos o todos sus routers IPv6. «Algunos» deja una decisión real: descartar solo en los ingresos conocidos o mantener una resolución homogénea en más puntos. La topología y el objetivo definen la respuesta.

En el límite con terceros, el signo cambia. El prefijo y sus subredes no deben exportarse ni aceptarse, y el tráfico dirigido a ellos no debe pasar entre AS. Una fuga puede atraer volúmenes hacia una red que ya está bajo ataque y agravar el daño.

La salud, por tanto, es asimétrica: presencia interna suficiente y ausencia externa completa. Un indicador único de «ruta presente» no puede representar ambas obligaciones.

Seis comprobantes enlazados

El primero es la autoridad: quién aprobó, qué prefijo exacto, qué alcance, por qué, desde cuándo y hasta cuándo. Evita que un cliente apague espacio ajeno o que una alarma vieja produzca una ruta indefinida.

El segundo es la aceptación de control: ruta desencadenante, comunidad, siguiente salto, routers receptores y decisión de política. Longitud, origen, RPKI o atributos inválidos pueden impedir la activación. La aceptación sigue siendo solo un evento de RIB.

El tercero es la FIB. Cada borde previsto debe mostrar que el prefijo víctima resuelve mediante 100::/64 a la interfaz de descarte. Una ruta visible en el controlador o reflector puede perder la selección, fallar al resolver o no ser programada en hardware.

El cuarto observa paquetes. Los contadores de descarte y sondas limpias sitúan el resultado en un borde y un momento. Cero puede significar que no llegó tráfico, que el borde era otro, que falló la telemetría o que no existió la acción.

El quinto prueba contención con Adj-RIB-Out, filtros y políticas. La ausencia en un colector público no equivale a ausencia universal; las vistas locales de exportación son decisivas.

El sexto prueba recuperación: retirada del disparador, limpieza de la FIB, retorno de la ruta ordinaria y caducidad de la aprobación. Un contador acumulado pertenece al pasado; no describe el estado actual.

Descartar también destruye servicio legítimo

El blackholing de destino reduce el impacto sobre la red al hacer inalcanzable la dirección atacada para todos. Ese es el intercambio, no un defecto oculto. Elegir el prefijo víctima más estrecho limita el daño colateral, aunque nunca lo convierte en disponibilidad.

La revisión posterior debe preguntar qué se preservó. ¿Bajó la saturación del enlace compartido? ¿Siguieron vivos los servicios vecinos? ¿La carga se movió a otra dirección? ¿Una regla de origen amplió el corte? Una gráfica descendente no basta cuando el instrumento genera descenso destruyendo tráfico.

Hilliard aporta precisión, no propiedad

El perfil IETF de Nick Hilliard enumera seis RFC. RFC 6666 fue escrito con David Freedman, revisado por la comunidad y publicado como Informational. No es una norma personal ni una orden universal.

Su lección duradera es que un control productivo merece un espacio de nombres propio y una frontera visible. 100::/64 evita que la operación tome prestado un prefijo de documentación y permite reconocer un propósito común. La misma claridad exige impedir que ese propósito local se convierta en una ruta global.

El registro hace legible la intención. La autoridad del operador, la FIB y los paquetes establecen el resultado.

Fuentes