Resumen

  • El prefijo IPv6 site-local FEC0::/10 daba direcciones internas sin un prefijo global, pero la dirección no indicaba a qué sitio pertenecía.
  • RFC 4193 sustituyó esa dependencia de los límites del sitio por prefijos generados localmente con una alta probabilidad de ser únicos, y dejó el encaminamiento en manos de cada red.

Análisis

La otra mitad de la dirección estaba en el equipo

Una aplicación guardaba FEC0::1234:5678:9ABC e intentaba conectarse. En un equipo con varias conexiones o que se desplazaba entre redes, esa cadena hexadecimal podía no bastar: había que indicar el sitio con un identificador de zona como %1. En otra instancia del equipo, el mismo sitio podía ser %2. La dirección parecía portable; la mitad que faltaba dependía del estado local del equipo.

Ese era el trato incómodo de las direcciones unicast site-local de IPv6. RFC 3513, publicado en abril de 2003, definió FEC0::/10 para usarse dentro de un sitio sin un prefijo global. Le seguían un identificador de subred de 54 bits y otro de interfaz de 64 bits. Los routers no debían reenviar esos paquetes fuera del sitio. Una red podía usar IPv6 internamente sin obtener antes un bloque encaminable en todo Internet.

La dirección no identificaba el sitio que la hacía local. FEC0::1 podía existir a la vez en dos sitios. RFC 3879, de septiembre de 2004, explica las consecuencias: las aplicaciones tenían que gestionar un identificador adicional; una dirección literal no podía recordarse como destino independiente del equipo ni obtenerse sin más de DNS; y el software que transmitía direcciones IP podía llevar la ambigüedad al otro lado de la frontera.

La palabra «sitio» debía resolver demasiadas cosas a la vez. Una red corporativa, un campus, una ubicación geográfica, un dominio de encaminamiento, una zona de cortafuegos y una frontera administrativa pueden tener límites distintos. RFC 3879 enumera fronteras de seguridad, alcance, encaminamiento, calidad de servicio, administración y financiación. Una DMZ podía quedar dentro para un propósito y fuera para otro. El paquete tenía una dirección; la organización, varios mapas.

Los routers heredaron la misma discusión. Si un destino site-local idéntico significaba cosas diferentes según la interfaz por la que llegaba el paquete, un router conectado a varios sitios necesitaba rutas específicas para cada sitio y un manejo especial de las tablas de reenvío. Los túneles y las tablas virtualizadas podían asumir ese trabajo, pero no convertían «sitio» en una unidad universal.

La ventaja era real: direcciones internas sin prefijo global y una frontera que los routers podían filtrar. En 2003, el grupo de trabajo de IPv6 se inclinó por buscar un reemplazo. RFC 3879 habla de un acuerdo en marzo y su confirmación en julio, aunque aclara que el consenso estaba lejos de ser unánime. El RFC de septiembre de 2004 retiró FEC0::/10, pero permitió que las implementaciones y redes existentes siguieran usándolo hasta que se normalizara un sustituto. El prefijo no podía reasignarse sin una futura decisión de estándares de la IETF.

RFC 4193 ofreció el reemplazo en octubre de 2005. Las direcciones IPv6 locales únicas usan FC00::/7; para los prefijos asignados localmente, se genera de forma seudoaleatoria un identificador global de 40 bits, seguido por un identificador de subred de 16 bits y uno de interfaz de 64. «Global» describe la unicidad buscada para el prefijo, no una promesa de acceso a Internet. RFC 4193 habla de una alta probabilidad de unicidad, no de certeza. Estas direcciones sirven para comunicaciones locales, pueden encaminarse entre un conjunto limitado de sitios y no se esperan en el encaminamiento global de Internet.

El cambio importa cuando se unen redes. Es poco probable que colisionen prefijos ULA generados por separado, por lo que una fusión o interconexión privada a menudo puede evitar renumerar las interfaces. Aun así, hacen falta rutas explícitas entre los sitios. La dirección ya no debe codificar una definición universal de «sitio»; la red local decide por dónde pasan sus rutas y filtros.

En febrero de 2006, RFC 4291 incorporó el retiro a la arquitectura de direccionamiento de IPv6: las nuevas implementaciones no deben conservar el comportamiento especial de FEC0::/10. Los RFC explican el cambio de diseño, pero no cuántos sistemas aún usan el prefijo. Esa prevalencia exige mediciones actuales de equipos, routers o tráfico.

Fuentes