Un mundo donde IPv6 fue un gran diseño (2017)

• En las primeras redes centradas en conexiones punto a punto, casi no hacía falta un esquema de direcciones, pero con la expansión de las redes en bus para reducir costos se fue acumulando complejidad como direcciones MAC, bridging y ARP
• Cuando Ethernet e IP se combinaron, hicieron falta direccionamiento MAC y broadcasts ARP para el reenvío al siguiente salto, y esa carga se amplificó mucho en grandes redes interconectadas y en wifi
• La visión de IPv6 reflejaba la expectativa de un mundo más simple que abandonara el bus físico y la internetwork de capa 2, eliminando incluso broadcast, ARP, DHCP y direcciones MAC
• Pero en los entornos reales de despliegue, IPv4 y el framing existente siguieron ahí, y con ellos también continuaron legados como neighbor discovery, DHCP, NAT y el bridging de capa 2
• Para mantener conexiones durante la movilidad, se sigue usando bridging de capa 2 y tunelización central en lugar del routing de Internet, y se menciona a alternativas como QUIC como una posible ruta de escape para el roaming

---

La red en bus fue lo que arruinó todo

• En los primeros entornos de conmutación de circuitos telefónicos y líneas dedicadas solo existían conexiones punto a punto, así que no hacía falta un esquema de direcciones; los bits que entraban por un lado salían por el otro tras cierto tiempo
• Incluso después de la introducción de TDM y la conmutación por circuitos virtuales, desde la perspectiva del usuario seguía siendo una entrada en un extremo conectada con una salida en el otro, y en esa etapa tampoco había necesidad de direcciones
• Cuando aparecieron computadoras con varias interfaces que reenviaban bits entre líneas surgieron las direcciones IP, las subredes y el routing, pero en enlaces punto a punto seguían sin hacer falta direcciones MAC
• Para reducir el costo de conectar sitios locales aparecieron las redes en bus, donde varios dispositivos se conectaban a un solo cable, y además de la familia Internet surgieron 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 si se duplicaban causaban fallas graves, aunque el problema era limitado porque las redes eran pequeñas
• Ethernet introdujo direcciones MAC de 48 bits y resolvió el problema de duplicación al asignar direcciones casi únicas desde la fabricación
• Tecnologías LAN como IPX y Netware funcionaban bien dentro de una sola red en bus sin configuración de direcciones, y se las describe como una época en la que todo funcionaba de forma 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 usar 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 eficientemente como las tablas modernas de routing IP que manejan rutas por subred
  • Para hacer bridging eficiente había que recordar en qué bus estaba cada dirección MAC
  • Para evitar configurar eso manualmente se necesitó aprendizaje automático e interacciones complejas
• Las redes complejas de bridges se sostuvieron con mecanismos como spanning tree, acompañados de flooding de broadcasts, rutas no óptimas y poca capacidad de depuración
• En los bridges intermedios no existía el concepto de dirección en Ethernet normal, así que no podían crearse herramientas tipo traceroute; en la práctica, el bridging era una estructura casi imposible de depurar
• Aun así, gracias a la optimización por hardware, el bridging funcionaba muy rápido, casi a velocidad de línea Ethernet, y eso era una gran ventaja en ese momento

Internet funcionando sobre un bus

• A partir de una estructura que conectaba computadoras individuales mediante enlaces punto a punto de larga distancia, poco a poco surgió la necesidad de conectar LAN completas a larga distancia
• Un bridging simple de larga distancia no funcionaba por problemas de control de congestión, y el bridging Ethernet solo operaba bajo la suposición de que todas las velocidades de enlace eran parecidas o de que casi no había congestión
• No había esperanza en puentear directamente un Ethernet de 10 Mbps con un enlace punto a punto de 0.128 Mbps, y el descubrimiento de rutas basado en flooding era demasiado derrochador en enlaces lentos
• El routing no óptimo que en un entorno local podía tolerarse se volvía fatal en enlaces lentos y costosos de larga distancia, así que no escalaba
• Ese conjunto de problemas ya era territorio que Internet estaba abordando, 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 Internet sobre LAN como Ethernet y arcnet, y ahí fue donde empezaron los problemas
• Si dentro de un segmento Ethernet había varios routers IP, había que distinguir cuál de ellos recibiría y reenviaría el paquete, y el IP final de destino no bastaba para expresar esa elección
• Por eso fue necesario dejar el destino final en el encabezado IP, mientras que el router del siguiente salto real se indicaba con la dirección MAC del frame Ethernet
• La información real que una persona quiere expresar es enviar al IP de destino 10.1.1.1 a la MAC del router 11:22:33:44:55:66, pero el sistema operativo termina manejándolo como algo tipo vía el IP del router 192.168.1.1
• Para esa abstracción, el sistema operativo primero necesitó encontrar la dirección Ethernet del IP del router, y como paso intermedio se agregó ARP
• ARP funciona enviando un broadcast a todo el Ethernet local para encontrar al dueño de un IP específico, y si había bridges, ese broadcast Ethernet debía reenviarse por todas las interfaces
• En grandes Ethernet interconectados, el exceso de broadcasts se volvió una de las peores pesadillas, y era aún peor en wifi
• Después, los bridges y switches empezaron a introducir hacks especiales para reducir el alcance de ARP, y algunos dispositivos, especialmente los puntos de acceso wifi, incluso generaban respuestas ARP falsas, pero todo eso era básicamente un hack técnico

Muerte por legado

• Con el tiempo, los protocolos no IP sobre Ethernet casi desaparecieron, y la red quedó fijada como una estructura con buses de capa 2 sobre cables de capa física, bridges que conectan esos buses, y routers de capa 3 encima
• A medida que se volvió más pesado configurar IP manualmente, surgió la necesidad 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 únicas permanentes desde fabricación
• Asignar direcciones IP solo de manera secuencial nos devolvería otra vez a una estructura no jerárquica como Ethernet, así que no era una buena solución
• Por eso aparecieron bootp y DHCP, y se convirtieron en protocolos que requerían trato especial, como ARP
• Como DHCP debe enviarse primero desde un nodo que aún no tiene dirección IP, tuvo que rellenar un encabezado IP prácticamente sin sentido pero con el formato exigido por el RFC, y el servidor DHCP debía construirlo directamente con raw sockets en vez de usar la capa IP del kernel
• Como bootp y DHCP al final necesitan conocer la dirección Ethernet para asignar una dirección IP, terminan cumpliendo un papel parecido al ARP al revés
• Se menciona que RARP hacía lo mismo de una manera más simple, pero aquí casi no se trata
• Como resultado, Ethernet e IP quedaron cada vez más fuertemente entrelazados y hoy son casi inseparables
• Las tablas de routing IP fingen especificar routers con direcciones IP, pero en realidad están especificando direcciones MAC de forma indirecta; ARP atraviesa bridges y DHCP parece un paquete IP, pero en realidad se parece más a un protocolo Ethernet
• Al mismo tiempo, tanto el bridging como el routing se volvieron más complejos, y quedaron separados: el bridging mayormente en el mundo IEEE y hardware, y el routing mayormente en el mundo IETF y software, cada uno actuando como si el otro no existiera
• Los operadores de red elegían entre bridging y routing según las exigencias de velocidad y su aversión a configurar servidores DHCP, usando tanto bridging como fuera posible y routing solo cuando hacía falta
• La complejidad del bridging terminó elevando las decisiones de capa 2 a capas superiores y administrándolas centralmente mediante protocolos sobre IP, lo que desembocó en SDN
• SDN era mejor que dejar que switches y bridges actuaran cada uno por su cuenta, pero se señala que hay algo fundamentalmente irónico en ello, porque IP mismo ya era una red definida por software que trataba por software una red que se había vuelto demasiado grande
• A IPv4 al principio le costaba la aceleración por hardware y en la práctica tampoco la obtuvo lo suficiente, y como configurar DHCP era muy engorroso, los operadores aprendieron a puentear dominios cada vez más grandes
• Hoy se describe a los grandes datacenters como algo que en la práctica funciona como una enorme red virtual en bus basada en SDN, y a menudo ni siquiera enruta los paquetes de verdad

Ahora olvidemos por un momento lo anterior

• Cuando la IETF empezó a concebir IPv6 a principios de los noventa, gran parte del caos ya estaba en marcha, pero el diseño avanzó bajo la suposición de que todavía podía evitarse el desastre venidero
• Uno de los cambios clave de ese proceso fue que el uso de redes físicas en bus ya se había abandonado casi por completo
• Ethernet ya no era realmente un bus; solo fingía serlo, y al aumentar la velocidad dejó de poder mantener CSMA/CD, así que volvió a una topología en estrella
• Se generalizó una estructura con cables individuales desde cada estación hasta un switch central, llenando paredes, techos y pisos con haces grandes y costosos de cable Ethernet
• Incluso wifi, que parece el bus definitivo por ser un medio inalámbrico compartido, en la práctica casi siempre imita una enorme topología en estrella con infrastructure mode
• Incluso dos estaciones wifi conectadas al mismo punto de acceso no se comunican directamente: envían al punto de acceso un paquete con la MAC del otro nodo, y el punto de acceso lo retransmite
• Si el nodo X envía al nodo de Internet Z, pasando por el router IP Y y por 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, de modo que las capas de direccionamiento se superponen de forma compleja
• Para eso, 802.11 ofrece un modo de 3 direcciones que permite llevar tanto el destino Ethernet real como el destino Ethernet intermedio
• Además, existen bits to-AP y from-AP para indicar la dirección estación→AP y AP→estación, y si ambos son verdaderos a la vez también puede expresarse el funcionamiento de repetidor entre APs
• Si A es un repeater que debe reenviar otra vez hacia la estación base B, entonces el emisor y receptor reales en el aire y el origen y destino Ethernet son todos distintos, así que hace falta un modo de 4 direcciones
• En la malla 802.11s existe incluso un modo de 6 direcciones, y se dice que a esa altura ya no vale la pena tratar de entenderlo

El mundo en que IPv6 era un buen diseño

• La IETF que pensaba en IPv6, viendo el caos ya existente y el que todavía venía, 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 la internetwork de capa 2, la eliminación del broadcast, de las direcciones MAC, de ARP y DHCP, un encabezado IP simple acelerable por hardware, el fin de la escasez de direcciones y el fin de la configuración manual de IP fuera del core
• Si la capa 2 siempre fuera punto a punto, no habría ni siquiera a quién enviar broadcasts, así que podrían reemplazarse por multicast; y como el par de envío y recepción sería obvio, las direcciones MAC tampoco harían falta
• Si desaparecían las direcciones MAC, tampoco haría falta mapear entre IP y MAC, por lo que ARP y DHCP también podrían desaparecer, y habría suficiente espacio de direcciones como para volver a usar routing de subredes grandes
• En ese mundo, se plantea la idea de que los repeaters wifi, los puntos de acceso wifi, los switches Ethernet e incluso SDN habrían funcionado todos como routers IPv6
• Entonces desaparecerían las ARP storm, los bridges con IGMP snooping y los bridging loop, y todos los problemas de routing podrían seguirse con traceroute
• Podrían eliminarse 12 bytes de direcciones MAC de origen y destino en cada paquete Ethernet y 18 bytes de información de direcciones en cada paquete wifi; así, aunque IPv6 use direcciones 24 bytes más grandes que IPv4, si se elimina el encabezado Ethernet el sobrecosto real sería de solo 12 bytes
• Se dice que esta expectativa de poder eliminar algún día las direcciones Ethernet mismas ayudó a justificar la elección de una longitud de dirección IPv6 que de otro modo parecía excesiva
• Pero este hermoso diseño no llegó a materializarse en el mundo real

Réquiem por un sueño

• La conclusión general se resume en una frase de un colega: “las capas solo se agregan; no se eliminan”
• Las ventajas de IPv6 solo tenían sentido si era posible abandonar el legado existente y empezar de nuevo, pero en la práctica eso resultó 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 direcciones 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, todavía más complejo que ARP, y aunque las redes en bus hayan desaparecido, sigue siendo necesario simular algo parecido al broadcast para reproducir el comportamiento tipo ARP
• En casa hay que seguir operando un servidor DHCP local para hacer funcionar una vieja bombilla IPv4, y si esa bombilla quiere llegar a Internet también seguirá haciendo falta NAT
• Peor aún, se evalúa que el equipo de IPv6 dejó sin resolver el problema de mobile IP, lo que hizo que el horrible bridging de capa 2 siguiera siendo necesario
• Se dice que probablemente el plan era desplegar primero IPv6 en pocos años y resolver mobile IP con más facilidad una vez que IPv4 y las direcciones MAC hubieran desaparecido
• En esa época se pensaba que casi no había casos de uso para computadoras en movimiento, así que apenas podían imaginar la escena torpe de ir cambiando una computadora de un puerto Ethernet a otro mientras un ftp seguía activo

Mobile IP, la killer app

• Después, la historia normalizó el caso de uso de llevar computadoras encima, es decir, teléfonos, moviéndose entre varios puntos de acceso inalámbricos
• En LTE ese movimiento casi siempre funciona y en wifi a veces funciona, pero se señala que el secreto no está en el routing de Internet sino en el bridging de capa 2
• El routing de Internet no maneja en absoluto la movilidad, y si un dispositivo se mueve en una red IP y cambia de dirección IP, todas las conexiones abiertas se rompen
• El wifi empresarial hace bridging de toda la LAN en capa 2 para que un servidor DHCP central entregue la misma dirección IP sin importar a qué punto de acceso se conecte el dispositivo, y así mantiene la conexión salvo por unos segundos de confusión mientras se reconfigura el bridge
• El wifi doméstico con varios extender o repeater usa la misma técnica
• En cambio, si uno camina entre redes wifi distintas, como los wifi públicos de tienda en tienda, recibe una nueva dirección IP cada vez y todas las conexiones se cortan
• LTE va más lejos y mantiene la misma dirección IP incluso al desplazarse varios kilómetros entre estaciones base, y se menciona que en las redes móviles normalmente se usan direcciones IPv6
• La forma de lograrlo es tunelizar el tráfico hacia un punto central y luego hacer bridging, junto con muchos firewalls, como si fuera una sola LAN virtual gigantesca de capa 2; el precio es una complejidad enorme y una latencia adicional vergonzosa
• Se dice que a las operadoras les gustaría arreglar esto, pero que es casi imposible

Cómo hacer que mobile IP funcione de verdad 1

• La respuesta a por qué mobile IP no termina de funcionar bien lleva a la conclusión de que la famosa definición del 4-tuple usada para identificar sesiones está mal
• Las sesiones TCP y UDP se identifican como (source ip, source port, destination ip, destination port), y esa estructura cruza capa 3 y capa 4, por lo que es vulnerable a cambios en la dirección IP
• Se plantea que si la identificación de sesión se hiciera solo con datos de capa 4, mobile IP funcionaría perfectamente
• Por ejemplo, cuando X:1111 se comunica con Y:80 y X cambia su dirección a Q, el paquete pasa a ser (Q,1111,Y,80), por lo que Y ya no lo reconoce como la sesión existente y lo descarta; además, los paquetes de respuesta (Y,80,X,1111) tampoco llegan ya a X
• Como alternativa, se propone ampliar los números de puerto, hoy de 16 bits, hacia 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 direcciones (X,Y) en capa 3 para el routing, pero al recibirlos el kernel no usaría la información de capa 3 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 nueva sesión, y después podría ignorarse u omitirse
• El kernel de Y guardaría en caché que recientemente recibió paquetes de la sesión (uuid) desde X, y si X se mueve a Q y sigue llegando con la misma etiqueta (uuid,80), podría asociarlo con esa sesión y actualizar el destino de respuesta de X a Q
• Así la conexión se mantendría, aunque se advierte que haría falta cuidado adicional para evitar el secuestro de conexiones por suplantación
• Pero ni UDP ni TCP funcionan así, y cambiarlo ahora se evalúa como una clase de proyecto que parecía tan fácil como pasar de IPv4 a IPv6, pero que décadas después sigue incompleto en menos de la mitad

QUIC y una posibilidad de bypass

• Como nota positiva, se plantea una solución indirecta a través de otra violación de capas
• Si se abandona el viejo TCP y se usa QUIC sobre UDP, puede hacerse de una forma que no use el 4-tuple de UDP como identificador de conexión
• Si el puerto UDP fuera un puerto especial para una mobility layer, entonces su contenido podría desempaquetarse otra vez como paquetes internos con la etiqueta uuid adecuada y asociarse a la sesión y al socket correctos
• Se dice que el protocolo experimental QUIC ya tiene, al menos en teoría, un formato de paquete apto para esta estructura
• Como el cifrado y la autenticación stateless que usa QUIC ya requieren de por sí identificadores o claves de sesión únicos, se sugiere que podría añadirse soporte transparente para roaming con relativamente poco trabajo
• Si eso ocurriera, solo faltaría eliminar de Internet todo lo que queda de UDP y TCP, y entonces ahora sí dejaría de hacer falta el bridging de capa 2, y también podrían eliminarse broadcast, direcciones MAC, SDN y DHCP
• El texto cierra con la idea de recuperar la elegancia de Internet

Correcciones complementarias

• Corrección 2017-08-16

  • La idea anterior relacionada con mobile IP no se limita a IPv6
  • Se corrigió para indicar que también puede funcionar en entornos con IPv4 y NAT, e incluso en roaming a través de varios NAT

• Corrección 2017-08-15

  • Como forma de evitar el secuestro de conexiones, se propone como ejemplo más simple un intercambio tipo SYN-ACK-SYNACK al inicio de TCP
  • Si Y confiara inmediatamente en el primer paquete del nuevo host Q, sería muy fácil para un atacante en cualquier lugar de Internet secuestrar una conexión X→Y
  • Si Y envía una cookie y Q la recibe, la procesa y la devuelve a Y, al menos el ataque ya requeriría estar en el medio y no sería posible para un atacante externo simple
  • En el caso de protocolos cifrados como QUIC, ese handshake también podría protegerse con la clave de sesión

• Corrección 2017-10-24

  • Además de QUIC, existen candidatos a protocolos de reemplazo de TCP con soporte de roaming de este tipo, y se menciona a MinimaLT como ejemplo
  • Se dice que MinimaLT fue el primer protocolo del que oyó hablar que resolvía elegantemente el problema del roaming, y que es posible que las soluciones futuras imiten esa estructura

• Corrección 2020-07-09

  • Solo se menciona que publicó en otro texto reflexiones adicionales sobre la migración e interoperabilidad entre IPv4/IPv6, sin explicaciones extra dentro del cuerpo

[GN⁺]

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.

  • Para mí, eso es una afirmación todavía más fuerte. Casi todas las alternativas mejores que propone la gente en realidad ya se evaluaron durante el proceso de diseño de IPv6 y, por lo general, fueron descartadas por razones suficientemente válidas.
  • Viéndolo en retrospectiva, quizá habría bastado con añadirle 16 o 32 bits a IPv4, pero aun así estoy de acuerdo en que IPv6 está bien y funciona bien. La mayoría de las quejas que escucho vienen de la ignorancia, pero hay una excepción: las direcciones largas. Eso sí es realmente incómodo y además la codificación legible para humanos no es muy buena, así que solo con mejorar la forma de representarlas de manera más legible ya ayudaría bastante.
  • No estoy de acuerdo con esa interpretación. El mundo sigue cambiando, e IPv6, en mi opinión, fue diseñado en 1998 principalmente alrededor de las necesidades de las empresas de equipos de red. Siento que no se reflejaron lo suficiente las perspectivas del usuario final, del administrador de red ni del desarrollador de aplicaciones. Si sigue vigente hasta hoy, creo que en gran parte es por el costo hundido y por una deuda técnica muy antigua. Si se diseñara hoy desde cero, con condiciones completamente distintas como SD-WAN, la demanda móvil y los cambios en el precio de los chips, es muy probable que saliera otro protocolo. También creo que habría que replantear el propio concepto de direcciones de origen y destino. Una capa de red sin cifrado 0RTT por defecto en 2026 se siente anacrónica. Elementos como ND, ARP, RA y DHCP también son inseguros porque parten de la confianza por defecto y no tienen autenticación. Si un dispositivo vecino afirma tener cierta dirección, me pregunto por qué mi equipo debería simplemente creerle. Ya sea en red cableada o inalámbrica, también me frustra que al conectarte a una red no se verifique la seguridad ni el sistema de identidad de la red del otro lado. Los problemas de seguridad, confianza e identidad deberían estar en el centro, y no lo estuvieron; además, da la impresión de que las nuevas funciones terminan ajustándose a la estructura de ingresos de los vendors. Más allá de la seguridad, también creo que es importante avanzar hacia identity-based addressing en lugar de direcciones basadas en números. Dado el enorme nivel de dependencia de esta tecnología, siento que también hace falta intervención gubernamental, y me parece amargo dejarles a las generaciones futuras y a las colonias en Marte los problemas de direccionamiento y seguridad propios de 2005.
  • No estoy de acuerdo con la interpretación de que no podían haberlo hecho mejor. Se siente más bien como si simplemente lo hubieran lanzado y ya. En vez de hacer un cambio tan grande como IPv6, creo que deberían haberlo refinado varias veces más y haber creado algo más cercano a un ipv4+ como extensión de IPv4.

• 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.

  • Al ponerlo en orden, me parece interesante que las discusiones con exactamente el mismo título se repitan una y otra vez, como el hilo de agosto de 2023, con 306 comentarios, el hilo de diciembre de 2020, con 131 comentarios, el hilo de junio de 2019, con 238 comentarios y el hilo de agosto de 2017, con 191 comentarios.

• 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.

  • Claro, no creo que ARP sea la única forma de resolver direcciones de capa 2. ARP provoca una violación de capas y demasiado tráfico broadcast, y siento que eso genera problemas adicionales en entornos como WiFi. Por ejemplo, NDP en IPv6 funciona sobre paquetes IPv6 reales basados en ICMPv6, así que no tiene esa violación, y gracias al multicast también reduce la necesidad de mandar broadcast a toda la capa 2.

• 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.

  • Para ser precisos, hoy en día la mayoría de los equipos que no son servidores suelen usar semantically opaque interface identifiers descritos en RFC8064 y RFC7217 en lugar de direcciones basadas en MAC o EUI64. Las direcciones estables se usan principalmente para tráfico entrante, y para tráfico saliente se pueden usar privacy address temporales que cambian con el tiempo. Y lo de stateless significa, justamente, que el equipo configura por sí solo su dirección con SLAAC sin una configuración centralizada como DHCPv6.
  • Creo que lo que está reclamando Xbox probablemente no sea IPv6 en sí, sino la ausencia de UPnP. Claro, con IPv6 algunos de esos problemas pueden reducirse. Aunque, irónicamente, el soporte de IPv6 en consolas más bien llegó tarde, así que yo también tengo curiosidad de qué tan bien lo soporta Xbox en la práctica.
  • Yo, en cambio, tengo curiosidad por saber si Xbox funciona bien sin IPv4. Los equipos Windows de mi empresa no lo hacen, y sé que otras consolas de videojuegos también siguen dependiendo de IPv4.

• 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.

  • Como referencia, desde Android 11 sí existe soporte de DHCPv6 en forma de Prefix Delegation. Aun así, viendo este artículo relacionado, sigo sintiendo que todavía hay algo de ese enfoque de plataforma de nosotros sabemos más.

• 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.

  • Hasta donde sé, WiFi desde el principio ha usado CSMA/CA, y desde 802.11ax también aprovecha OFDMA. Este trasfondo se ve bien en la explicación del problema del nodo oculto.

• 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.

  • Siento que primero habría que aclarar quiénes somos nosotros aquí. Antes podías pedir incluso un /24, pero ahora muchas veces terminas comprando de segunda mano bloques que usaban redes de spam ya cerradas y que vienen con una reputación IP pésima. Incluso si quieres alojar algo por tu cuenta, salvo que operes a gran escala, a menudo en la práctica terminas teniendo que alquilar una IPv4 de una empresa estadounidense. Para mí eso se parece a decir que el uranio existe teóricamente en el mercado, cuando en la práctica es extremadamente difícil de conseguir.
  • Yo sí creo que ese problema sigue siendo importante. La mera existencia de parches como NAT ya me parece prueba de ello. La gente se ha acostumbrado cada vez más a un entorno peor, y ya ve como normal cosas como la mala calidad de llamadas por alta latencia o que toda la comunicación se bloquee cuando se cae infraestructura como la de Cloudflare. Pero Internet originalmente fue diseñado para evitar ese tipo de dependencia centralizada. Para mí, decir que no hay problema es como decir que el tráfico vehicular no es un problema solo porque hoy lograste llegar al trabajo. Hay que verlo a más largo plazo y con una visión más amplia.