[lacnog] Fwd: [IPv6]Android now supports DHCPv6 PD

[Fernando Gont]

On 15/09/2025 20:42, Carlos Martinez-Cagnazzo wrote:
> Tan solo 10-15 años de discusiones :-) Pero bienvenido sea, más vale 
> tarde que nunca.

De acuerdo en eso.

Hay que decir tambien que lo que implementaron es DHCPv6-PD, y no 
simplemente DHCPV6. Por lo cual, esto no sirve para solucionar el 
problema en ambintes enterprise que utilizan DHCPv6.

Por otro lado, algo me dice que SLAAC-sized (*) prefixes implica que 
piden prefijos de al menos /64... lo cual es una tontera. Porque si 
pidieron inclusive prefijos mas largos (bloques mas chicos), entonces 
inclusive este soporte podria servir para apalear los problemas de 
deployment en ambientes enterprise donde se desea utilizar IPv6.


(*) Eso de "SLAAC-sized" tambien es incorrecto. SLAAC en si no requiere 
prefijos de ningun largo en particular. Simplemente, en el momento en 
que los IIDs se generaban mediante las direcciones MAC, era ese formato 
(y *no* algo intrinsico a SLAAC) el que te exigia IIDs de 64-bits.

Desde RFC7217/RFC8064, ese constraint no existe -- de hecho, el lenguaje 
utilizado en RFC7217 es cuidadoso en este aspecto: el documento dice 
cosas como "agarra tantos bits como sea necesario", en vez de "agarra 64 
bits".  Y hay implementaciones de SLAAC como la de openbsd que funcionan 
con IIDs mas cortos/prefijos mas largos.



El debate sobre SLAAC vs. DHCPv6 es tal vez de los mas ridiculos que han 
habido en torno a IPv6:

* En lo que respecta a SLAAC en particular, es un "artefacto de la 
historia" -- mas que el "state of the art" en materia de autoconfiguracion.

* Hay cosas muy basicas del protocolo que no fueron consideradas. 
Ejemplo, esto: 
https://www.ietf.org/archive/id/draft-gont-v6ops-multi-ipv6-02.html

* Uno de los argumentos en contra de DHCPv6 es que es "menos responsive" 
que SLAAC. Pero la misma gente que argumenta eso, es la misma gente que 
luego dice que hay que enviar los RAs con menor frecuencia, para que no 
se drene la bateria de los moviles. -- lease: entonces tenes 
requrimientos incompatibles entre si.

* Creo tambien que hay cierta expectativa poco realista respecto a los 
casos de uso de las direcciones IPv6. -- si, hay miles de cosas que uno 
podria hacer....  pero que nadie hace, ni planea hacer. Ejemplo, eso de 
esperar que un host corra muchas VMs y que gracias a PD ahora obtenga un 
prefijo, y asigne todas las direcciones de ese prefijo. En el mejor de 
los casos es tan nicho que es irrelevante.

* Inclusive en el caso de los contenedores (e.g. kubernetes clusters), 
la industria ha ido por otro lado. Datapoint: Los clusters de Kubernetes 
del propio GCP utilizan IPv6 NAT.

* Claramente uno no puede volver el tiempo atras, y rediseñar desde cero 
un monton de cosas. Pero lo que *si* podria hacer es:

   + Guiar sobre la forma recomendada para desplegar ipv6 (hecho)
   + proveer las herramientas (*) para que la gente implemente IPv6 como
     le de la gana. -- y en este punto digo lo que digo: NAT IPv6, SLAAC,
     DHCPv6, DHCPv6-PD o lo que quieran. Al final del dia, desde el punto
     de vista de despliegue (adopcion), cualquiera de estas variantes es
     mejor que la no adopcion.


(*): alguien diria "darle mas libertad" a quien despliega o diseña una 
red. -- pero dado que se vienen haciendo cosas muy raras y locas en 
nombre de la libertad :-), prefiero limitarme a decir "opciones" :-)


* En este sentido, IETF ha ido en el sentido contrario:
   + se ha empeorado DHCPv6 (se le ha quitado el soporte de direcciones 
temporales)
   + Estandarizar cosas como "registro de direcciones SLAAC en DHCPv6" 
(si queres tal cosa, deberias estar utilizando DHCPv6".



>     FYI, we announced DHCPv6 PD support on Android today:
> 
>     https://android-developers.googleblog.com/2025/09/simplifying-
>     advanced-networking-with.html <https://android-
>     developers.googleblog.com/2025/09/simplifying-advanced-networking-
>     with.html>
> 
>     This change should already be live on most Android devices running
>     Android 11 and above. Specifically:
> 
>       * RFC 9762: if the P flag is set, the device will ask for a SLAAC-
>         sized prefix, and if it gets it, use it to form addresses. Some
>         devices will also disable SLAAC as per the SHOULD in the RFC.
>         Not all devices will support this because it requires a kernel
>         change which will be rolling out over the coming months. In
>         future releases, we expect that the prefix will be shared with
>         downstream devices, wearable devices, VMs, etc.

Por lo que leo, alguien planea ponerle direcciones publicas a "wereable 
devices".  -- espero que no se refieran a health devices, porque la cosa 
va a terminar muy mal :-). ("disable ipv6... if you want to live" :-) )




>       * Heuristic: if the device obtains a default route but not PIO, it
>         will ask for a prefix, and if it gets it, use it to form
>         addresses. This allows DHCPv6-only networks to support Android
>         devices today without having to upgrade their routers to set the
>         P flag.

Heuristic en este caso se traduce a que tenemos un toooodo un grupo de 
protocolos que claramente no funcionan bien en su conjunto. Entonces nos 
salimos de la especificacion e implementamos "heuristicas" para intentar 
ver si de alguna forma las cosas funcionan -- aunque de forma no 
deterministica.

Por otro lado, todo esto se solucionaba incorporando soporte para DHCPv6 
(IA_NA) y listo.

Por si hace falta la aclaracion: hacer de "dhcpv6 vs slaac" un debate 
"religioso" me parece una tontera. De hecho, a esta altura del partido, 
es ridiculo el planteo "dhcpv6 vs. slaac".


-- 
Fernando Gont
SI6 Networks
e-mail: fgont en si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494