Un mundo en el que IPv6 fue un gran diseño (2017)
(apenwarr.ca)- En las primeras redes, centradas en conexiones punto a punto, casi no se necesitaba un esquema de direcciones, pero la expansión de las redes en bus para reducir costos fue acumulando complejidad como direcciones MAC, bridging y ARP
- A medida que Ethernet e IP se combinaron, se hizo necesario el direccionamiento MAC y las difusiones ARP para reenviar al siguiente salto, y esa carga se amplificó mucho en grandes redes interconectadas y en wifi
- La idea de IPv6 reflejaba la expectativa de un mundo más simple que abandonara el bus físico y las internetworks de capa 2, y eliminara incluso broadcast, ARP, DHCP y direcciones MAC
- Pero en los entornos de despliegue reales, IPv4 y el framing heredado siguieron presentes, y con ellos también se conservaron legados como neighbor discovery, DHCP, NAT y el bridging de capa 2
- Para mantener la conexión durante el movimiento, se sigue usando bridging de capa 2 y tunelización central en lugar del enrutamiento de Internet, mientras que alternativas como QUIC se mencionan como una ruta indirecta para el roaming
El momento en que las redes en bus lo arruinaron todo
- En los primeros entornos de conmutación de circuitos y líneas dedicadas de la red telefónica solo existían conexiones punto a punto, así que no hacía falta un esquema de direcciones, y la estructura consistía en que los bits introducidos por un lado salían por el otro tras cierto tiempo
- Incluso tras la adopción de TDM y de la conmutación por circuitos virtuales, desde la perspectiva del usuario seguía siendo una forma en la que una entrada de un lado se conectaba con una salida del otro, y en esta etapa tampoco había necesidad de direcciones
- Cuando computadoras con varias interfaces empezaron a transferir bits entre líneas, aparecieron las direcciones IP, las subredes y el enrutamiento, pero en enlaces punto a punto seguían sin hacer falta direcciones MAC
- Para reducir el costo de conectar sitios locales surgieron las redes en bus, que conectaban varios dispositivos a un mismo cable, y además de la familia Internet nacieron distintos esquemas propios de capa 2
- En una LAN temprana como arcnet había que configurar manualmente direcciones de capa 2 de 8 bits con jumpers o interruptores DIP, y aunque los duplicados provocaban fallas graves, la red era pequeña y la molestia era limitada
- Ethernet resolvió el problema de los duplicados introduciendo direcciones MAC de 48 bits, asignadas de forma casi única durante la fabricación
- Tecnologías LAN como IPX y Netware funcionaban bien dentro de una sola red en bus sin necesidad de configurar direcciones, y se describen como una época en la que todo funcionaba de manera hermosa y confiable
- Las grandes redes corporativas y universitarias tuvieron que interconectar varios buses por el cuello de botella de un solo bus de 10 Mbps, pero en vez de apostar por IP, que aún no maduraba, eligieron bridging y switching basados en direcciones Ethernet como camino de expansión
- Como las direcciones Ethernet se asignaban secuencialmente en fábrica y no tenían jerarquía, las tablas de bridging no podían agregarse de manera eficiente como las tablas modernas de enrutamiento IP que manejan rutas por subred
- Para hacer bridging de forma eficiente había que recordar en qué bus estaba cada dirección MAC
- Para evitar configurarlo manualmente, hicieron falta aprendizaje automático e interacciones complejas
- Las redes de bridges complejas se sostuvieron con mecanismos como spanning tree, acompañados de inundaciones de broadcast, rutas no óptimas y poca capacidad de depuración
- Los bridges intermedios no tenían un concepto de dirección en el Ethernet normal, así que no se podían crear herramientas tipo traceroute, y el bridging era en la práctica una estructura casi imposible de depurar
- Aun así, gracias a la optimización por hardware, el bridging funcionaba muy rápido, cerca de la velocidad de línea de Ethernet, y eso era una gran ventaja en ese momento
Internet funcionando sobre un bus
- Desde una estructura que conectaba computadoras individuales por enlaces punto a punto de larga distancia, poco a poco surgió la necesidad de conectar LAN completas, lo que obligó a enlazar LAN entre sí a larga distancia
- Un bridge de larga distancia simple no era viable por problemas de control de congestión, y el bridging de Ethernet solo funcionaba bajo la suposición de velocidades de enlace parecidas o casi sin congestión
- Unir por bridging un Ethernet de 10 Mbps con un enlace punto a punto de 0.128 Mbps no tenía esperanza, y la búsqueda de rutas basada en flooding era demasiado derrochadora sobre enlaces lentos
- El enrutamiento no óptimo, tolerable en entornos locales, se volvía fatal en enlaces lentos y caros de larga distancia, por lo que no escalaba
- Ese conjunto de problemas ya era territorio que Internet venía resolviendo, y conectar buses LAN con tecnología Internet podía dar una estructura mucho mejor
- Por eso se diseñaron formatos de frame para transportar paquetes de Internet sobre LAN como Ethernet y arcnet, y ahí fue donde empezaron los problemas
- Si había varios routers IP en un segmento Ethernet, había que distinguir cuál de ellos debía recibir y reenviar un paquete, y la IP de destino final no bastaba para expresar esa elección
- Por eso fue necesario mantener el destino final en el encabezado IP y especificar el siguiente router real mediante la dirección MAC del frame Ethernet
- La información real que uno quiere expresar es
enviar a la IP de destino 10.1.1.1 mediante la MAC del router 11:22:33:44:55:66, pero el sistema operativo terminó manejándolo como algo del tipovía la IP del router 192.168.1.1 - Para hacer posible esa abstracción, el sistema operativo primero tenía que encontrar la dirección Ethernet de la IP del router, y como paso intermedio se añadió ARP
- ARP funciona enviando un broadcast a todo el Ethernet local para encontrar al propietario de una IP concreta, y si había bridges, ese broadcast Ethernet debía reenviarse por todas las interfaces
- En grandes redes Ethernet interconectadas, el exceso de broadcasts se convirtió en una de las peores pesadillas, y fue aún más grave en wifi
- Más adelante, los bridges y switches empezaron a incorporar hacks especiales para reducir el alcance de ARP, y algunos equipos, en especial puntos de acceso wifi, incluso generaban respuestas ARP falsas, pero todo eso era poco más que un hack técnico
Muerte por legado
- Con el tiempo, los protocolos no IP sobre Ethernet casi desaparecieron, y la red quedó fijada en una estructura de buses de capa 2 sobre líneas de capa física, bridges que conectaban esos buses y routers de capa 3 encima de todo eso
- A medida que crecía el cansancio con la configuración manual de IP, surgió la demanda de configuración automática, pero los dispositivos ya salían de fábrica con direcciones Ethernet y las direcciones IPv4 de 32 bits no alcanzaban para asignaciones permanentes y únicas durante la fabricación
- Asignar direcciones IP de forma secuencial solo habría devuelto el problema a una estructura no jerárquica como Ethernet, así que no era una buena solución
- Por eso aparecieron bootp y DHCP, que se convirtieron en protocolos que también necesitaban trato especial, igual que ARP
- Como DHCP debe ser transmitido primero por un nodo que aún no tiene dirección IP, hubo que rellenar encabezados IP esencialmente sin sentido con el formato definido por RFC, y el servidor DHCP tuvo que construirlos directamente con raw sockets en vez de usar la capa IP del kernel
- Como bootp y DHCP necesitan conocer la dirección Ethernet para poder asignar una dirección IP, terminaron cumpliendo un papel casi inverso al de ARP
- Se menciona que RARP hacía lo mismo de forma más simple, pero que aquí casi no se tratará
- Como resultado, Ethernet e IP se fueron entrelazando cada vez más hasta volverse hoy casi inseparables
- Las tablas de enrutamiento IP aparentan señalar routers por dirección IP, pero en realidad están señalando indirectamente direcciones MAC; ARP atraviesa bridges, y DHCP parece un paquete IP pero en el fondo se parece más a un protocolo de Ethernet
- Al mismo tiempo, tanto el bridging como el enrutamiento se volvieron más complejos, y el bridging quedó mayormente del lado de IEEE y el hardware, mientras que el enrutamiento quedó del lado de IETF y el software, tratándose mutuamente como si el otro no existiera
- Los operadores de red elegían entre bridging y enrutamiento según necesidades de velocidad y su aversión a configurar servidores DHCP, usando todo el bridging posible y recurriendo al enrutamiento solo cuando hacía falta
- La complejidad del bridging acabó elevando las decisiones de capa 2 a capas superiores y gestionándolas de forma centralizada con protocolos sobre IP, lo que llevó a SDN
- SDN era mejor que dejar que switches y bridges se comportaran cada uno por su lado, pero se señala que tiene algo de absurdo fundamental, porque IP ya era en sí una red definida por software para manejar redes que se habían vuelto demasiado grandes
- Al principio, IPv4 era difícil de acelerar por hardware y en la práctica tampoco consiguió suficiente aceleración por hardware, mientras que configurar DHCP era muy engorroso, así que los operadores aprendieron a hacer bridging sobre dominios cada vez más grandes
- Hoy se describe a los grandes centros de datos como si fueran prácticamente gigantescas redes virtuales en bus basadas en SDN, donde muchas veces los paquetes no se enrutan de verdad
Ahora olvidemos por un momento todo lo anterior
- Cuando la IETF imaginó IPv6 a comienzos de los años 90, gran parte del caos ya estaba en marcha, pero el diseño avanzó bajo la suposición de que aún podía evitarse la catástrofe que venía
- En ese proceso, un cambio clave fue que el uso de redes físicas en bus ya casi se había abandonado
- Ethernet ya no era un bus real, sino algo que solo fingía serlo, y cuando el aumento de velocidad hizo imposible mantener CSMA/CD, volvió de hecho a una topología en estrella
- Se generalizó una estructura en la que cada estación tiraba un cable individual hasta un switch central, y paredes, techos y pisos quedaron llenos de grandes y caros haces de cables Ethernet
- Incluso wifi, que parece el bus definitivo por ser un medio inalámbrico compartido, en realidad casi siempre imita una gran topología en estrella mediante infrastructure mode
- Incluso dos estaciones wifi conectadas al mismo punto de acceso no se comunican directamente: envían paquetes al punto de acceso con la MAC del nodo contrario, y el punto de acceso los vuelve a transmitir
- Si el nodo X envía al nodo de Internet Z, pasando por el router IP Y y el punto de acceso wifi A, entonces Z es el destino IP, Y es el destino Ethernet y A es el verdadero par de transmisión inalámbrica, lo que superpone de forma compleja varias capas de direccionamiento
- Para eso, 802.11 ofrece 3-address mode, que puede contener a la vez el destino Ethernet real y el destino Ethernet intermedio
- Además existen bits
to-APyfrom-APpara indicar la dirección estación→AP y AP→estación, y si ambos son verdaderos a la vez, también se puede representar el funcionamiento como repetidor entre APs - Si A es un repetidor y debe reenviar de nuevo a la estación base B, entonces el emisor y receptor reales por aire y el origen y destino Ethernet también son distintos, por lo que hace falta 4-address mode
- 802.11s mesh llega incluso hasta un modo de 6 direcciones, y el texto dice que a esa altura ya dejó de intentar entenderlo
El mundo en el que IPv6 era un buen diseño
- La IETF que estaba pensando en IPv6, viendo tanto el caos ya existente como el aún mayor que se acercaba, imaginó un mundo nuevo que abandonara el legado existente
- Ese mundo asumía la eliminación de las redes físicas en bus, la eliminación de internetworks de capa 2, la eliminación del broadcast, de las direcciones MAC, de ARP y DHCP, un encabezado IP simple acelerable por hardware, suficiente espacio de direcciones y la eliminación de la configuración manual de IP fuera del core
- Si la capa 2 siempre fuera punto a punto, no habría ni siquiera un conjunto de destinatarios al que enviar broadcast, así que se podría sustituir por multicast, y como el par de envío y recepción sería obvio, tampoco harían falta direcciones MAC
- Si desaparecían las direcciones MAC, ya no haría falta mapear entre IP y MAC, así que también podrían desaparecer ARP y DHCP, y además habría suficiente espacio de direcciones como para volver a usar enrutamiento con subredes grandes
- En ese mundo, se plantea la idea de que los repetidores wifi, puntos de acceso wifi, switches Ethernet e incluso SDN habrían funcionado todos como routers IPv6
- Entonces desaparecerían las tormentas ARP, los IGMP snooping bridge y los bridging loop, y todos los problemas de enrutamiento podrían rastrearse con traceroute
- Al eliminar 12 bytes de MAC de origen y destino en cada paquete Ethernet y 18 bytes de información de dirección en cada paquete wifi, se calcula que aunque IPv6 use direcciones 24 bytes más grandes que IPv4, al quitar el encabezado Ethernet la sobrecarga adicional real sería de solo 12 bytes
- Se dice que esta expectativa de poder eliminar algún día las propias direcciones Ethernet ayudó a justificar la elección de una longitud de dirección IPv6 excesivamente grande
- Sin embargo, este hermoso diseño no llegó a hacerse realidad en el mundo real
Réquiem por un sueño
- La frase de un compañero de trabajo, “las capas solo se agregan, nunca se eliminan”, se presenta como la conclusión general
- Las ventajas de IPv6 solo podían sostenerse si era posible abandonar el legado existente y empezar de nuevo, pero en la práctica eso fue casi imposible
- Aunque la adopción de IPv6 llegara al 99%, mientras IPv4 no desaparezca por completo tampoco desaparecerán las direcciones Ethernet ni las de wifi, y mientras se mantengan los estándares de framing IEEE 802.3 y 802.11, tampoco se logrará ese ahorro de bytes
- Por eso, IPv6 terminó necesitando neighbor discovery, más complejo que ARP, y aunque las redes en bus hayan desaparecido, sigue haciendo falta una simulación parecida al broadcast para comportamientos tipo ARP
- En casa, hay que seguir operando un servidor DHCP local para que funcione una bombilla IPv4 antigua, y si esa bombilla quiere llegar a Internet, también sigue haciendo falta NAT
- Peor aún, se evalúa que el equipo de IPv6 dejó sin resolver el problema de mobile IP, y como resultado siguió siendo necesario el horrible bridging de capa 2
- Según el texto, la idea en ese momento era desplegar primero IPv6 en unos pocos años y luego, una vez desaparecidos IPv4 y las direcciones MAC, resolver mobile IP con más facilidad
- En aquella época se pensaba que casi no había casos de uso de computadoras en movimiento, y solo podían imaginarse escenas torpes como seguir una sesión de ftp mientras uno cambiaba de puerto Ethernet
Mobile IP como killer app
- Más tarde, el uso de computadoras que uno lleva consigo, es decir, teléfonos, moviéndose entre varios puntos de acceso inalámbricos, se volvió algo cotidiano
- En LTE este movimiento suele funcionar y en wifi a veces también, pero se señala que el secreto no está en el enrutamiento de Internet sino en el bridging de capa 2
- El enrutamiento de Internet no maneja la movilidad en absoluto: si uno se mueve dentro de una red IP y cambia su dirección IP, todas las conexiones abiertas se rompen
- El wifi empresarial hace bridging de toda la LAN a nivel de capa 2 para que un servidor DHCP central entregue la misma dirección IP sin importar a qué punto de acceso se conecte el equipo, manteniendo así la conexión a costa de unos segundos de caos mientras se reconfiguran los bridges
- El wifi doméstico con varios extensores o repetidores usa el mismo método
- En cambio, cuando uno cruza redes wifi distintas, como al caminar por la calle y pasar por redes públicas de distintas tiendas, recibe una nueva dirección IP cada vez y con eso se cortan todas las conexiones
- LTE va aún más lejos y permite mantener la misma dirección IP incluso al moverse varios kilómetros entre estaciones base, y se menciona que las redes móviles suelen usar direcciones IPv6
- El método consiste en tunelizar el tráfico hacia un punto central y luego hacer bridging, junto con muchos firewalls, como si todo fuera una sola LAN virtual gigantesca de capa 2, a costa de una enorme complejidad y una latencia adicional vergonzosa
- Se dice que las operadoras quieren arreglar esto, pero que es casi imposible
Cómo hacer que mobile IP funcione de verdad 1
- La explicación de por qué mobile IP no funciona bien lleva a la conclusión de que la famosa definición de 4-tuple usada para identificar sesiones está mal planteada
- Las sesiones TCP y UDP se identifican como
(source ip, source port, destination ip, destination port), y esa estructura cruza la capa 3 y la capa 4, volviéndose frágil ante cambios de dirección IP - Se sostiene que si la identificación de sesiones dependiera solo de datos de capa 4, mobile IP funcionaría perfectamente
- Como ejemplo, si X:1111 se comunica con Y:80 y X cambia su dirección a Q, el paquete pasa a ser
(Q,1111,Y,80), de modo que Y no lo reconoce como parte de la sesión existente y lo descarta; además, los paquetes de respuesta(Y,80,X,1111)ya no pueden llegar a X - Como alternativa, se propone ampliar los números de puerto, en lugar de 16 bits, a algo como valores hash únicos de 128 o 256 bits, e identificar sockets con etiquetas independientes de la dirección IP
- En ese caso, los paquetes seguirían incluyendo la información de direcciones
(X,Y)en la capa 3 para enrutar, pero el kernel no usaría la información de capa 3 al recibirlos para identificar el socket, sino solo el uuid - El puerto de destino 80 solo haría falta para distinguir qué servicio se quiere al iniciar una sesión nueva, y después podría ignorarse u omitirse
- El kernel de Y almacenaría en caché que el paquete de sesión
(uuid)llegó recientemente desde X, y cuando X se mueva a Q y llegue con la misma etiqueta(uuid,80), podría asociarlo a la sesión correspondiente y actualizar el destino de respuesta de X a Q - Eso mantendría la conexión, aunque se añade la advertencia de que haría falta un cuidado extra para evitar el secuestro de conexión por un suplantador
- Pero UDP y TCP no funcionan así, y cambiarlo ahora se evalúa como una clase de proyecto que parecía tan fácil como cambiar IPv4 por IPv6, pero que décadas después sigue sin estar ni a la mitad
QUIC y una posibilidad de rodeo
- En el lado positivo, se plantea una solución indirecta mediante otra violación de capas
- Si se abandona TCP viejo y se usa QUIC sobre UDP, se hace posible no usar el 4-tuple de UDP como identificador de conexión
- Si el puerto UDP fuera un puerto especial para una capa de movilidad, se podría volver a interpretar su contenido como paquetes internos con una etiqueta uuid adecuada y asociarlos a la sesión y socket correctos
- Se dice que el protocolo experimental QUIC ya tiene, al menos en teoría, un formato de paquetes adecuado para algo así
- Como el cifrado y la autenticación stateless que usa QUIC ya requieren de por sí identificadores o claves de sesión únicas, se plantea que con relativamente poco trabajo podría habilitarse un roaming transparente
- Si eso ocurriera, solo quedaría eliminar de Internet el resto de UDP y TCP, y esta vez sí dejaría de ser necesario el bridging de capa 2, junto con broadcast, direcciones MAC, SDN y DHCP
- El texto cierra con una frase sobre restaurar la elegancia de Internet
Correcciones complementarias
-
Corrección del 2017-08-16
- La idea anterior sobre mobile IP no se limita a IPv6
- Se corrigió indicando que también podría funcionar en IPv4 y con NAT, e incluso en roaming a través de varios NAT
-
Corrección del 2017-08-15
- Como forma de evitar el secuestro de conexión, se presenta como ejemplo más simple un intercambio similar a SYN-ACK-SYNACK al inicio de TCP
- Si Y confía de inmediato en el primer paquete del nuevo host Q, a un atacante en cualquier parte de Internet le resultaría fácil secuestrar la conexión X→Y
- Si Y envía una cookie y Q la recibe, la procesa y la devuelve a Y, entonces al menos el ataque ya requeriría un hombre en el medio, y no solo un atacante externo simple
- En protocolos cifrados como QUIC, también sería posible proteger ese handshake con la clave de sesión
-
Corrección del 2017-10-24
- Además de QUIC, se mencionan otros posibles protocolos sustitutos de TCP con soporte de roaming, y se da MinimaLT como ejemplo
- Se indica que se ha oído que MinimaLT fue el primer protocolo en resolver el problema del roaming de forma elegante, y que es posible que futuras soluciones adopten una estructura parecida
-
Corrección del 2020-07-09
- Solo se menciona que publicó en otro texto algunas ideas adicionales sobre migración e interoperabilidad IPv4/IPv6, sin añadir más explicación dentro del cuerpo
1 comentarios
Opiniones de Hacker News
Desde mi punto de vista, IPv6 no es la cúspide de un diseño de protocolo perfecto, pero las alternativas supuestamente mejores que propone la gente terminan convergiendo en algo muy parecido a IPv6. Si nadie logra crear de forma consistente algo mejor que esto, entonces IPv6 al final significa un diseño bastante bueno.
Si uno reúne discusiones antiguas de Hacker News, este tema se sigue repitiendo cada pocos años, como en el hilo de 2017, el hilo de 2019, el hilo de 2020 y el hilo de 2023.
No me gusta que este artículo vea a ARP de forma tan negativa. Gracias a ARP, el networking IP dentro de una LAN es posible incluso sin router, y la puerta de enlace predeterminada puede tratarse como un caso especial de la misma comunicación IP típica en LAN. Eso sí, la explicación de la historia del networking es realmente excelente, y todavía sigo leyendo la parte de IPv6.
Estoy un poco confundido sobre qué intenta decir exactamente este artículo. ¿Está diciendo que mis equipos de red obtienen por sí solos direcciones IPv6 basadas en su dirección MAC, y que ese es el núcleo de stateless IPv6? Según entiendo, IPv6 también surgió para resolver el agotamiento de IPv4 y los problemas de NAT. Pero mi Xbox dice que la red es mala si no hay IPv6, y eso también se siente como una perspectiva bastante centrada en Norteamérica.
Cada vez siento más que haber dejado tanto SLAAC como DHCPv6 en IPv6 fue un gran error. SLAAC en sí es excelente, pero tener dos mecanismos de configuración es demasiado confuso. El hecho de que Android no soporte DHCPv6 también aumenta la confusión. Mi suposición es que SLAAC es producto de una época en la que las computadoras eran caras y el servidor DHCP era un equipo aparte. Pero hoy las computadoras son baratas y la mayoría de los routers pueden ejecutar DHCP, así que la situación es distinta. Si DHCPv6 hubiera ido por el camino de asignar direcciones basadas en MAC por defecto, creo que la configuración habría sido más simple, y la autoconfiguración en enlace local también se habría mantenido.
Este artículo me pareció muy interesante, pero hay un punto que no termino de entender. El autor dice que en WiFi ya no se usa CSMA/CD, entonces me pregunto cómo funciona realmente. También explica que incluso dos estaciones WiFi conectadas al mismo punto de acceso no se comunican directamente entre sí. Si es así, en algún momento cada estación tiene que poder distinguir si la señal que oye es para ella, si es otra estación enviando algo al AP o si es el AP enviándole algo a otra estación. Entonces me pregunto si no sigue siendo necesario algún mecanismo parecido, aunque tenga otro nombre.
Antes IPv6 parecía el siguiente paso inevitable, pero viendo lo poco de impulso que tiene ahora, me hace pensar si el problema que intentaba resolver realmente no era tan importante desde el inicio. Desde la perspectiva del usuario real, al final parecía que de alguna manera siempre se conseguían suficientes direcciones IPv4 para que Internet siguiera funcionando, así que uno se pregunta si de verdad hacía falta IPv6. Me gustaría saber si esa conclusión está equivocada.