[IPv6]Re: [v6ops] Re: [dhcwg] Re: Re: Re: Android now supports DHCPv6 PD

[Lorenzo Colitti <[e-mail]>]

Did you enable PD via the P flag or with the heuristic? If you use the P
flag but the A flag is still set, then the device will have IPv6 addresses
from both autoconf and PD, and it will generally only use one of those. In
this case they might be picking the SLAAC address. If you use the heuristic
(i.e., send an RA with non-zero lifetime, but no PIO, or with a PIO with
A=0), then the device should only have IPv6 addresses from PD.

Do the devices also have IPv4? Generally Android devices should prefer IPv6
over IPv4. Are you observing that all traffic just uses IPv4? If nothing
else, the connectivity probes (e.g., connectivitycheck.gstatic.com) should
always use IPv6. If you're seeing the devices remain IPv4-only then we need
to look into this further - get in touch off-thread and we can try to debug
together.

On Tue, Sep 16, 2025 at 10:09 PM Daryll Swer <contact=
[e-mail]> wrote:

> Lorenzo
>
> From the perspective of a network operator, how do I verify the Android
> devices are actually making use of the PD they leased from the network? And
> how they sub-lease it, if they are doing that in some cases.
>
> For instance, in my personal home lab, I do /64 PD in addition to SLAAC,
> and some Android devices from other users indeed pulls a /64 lease, which I
> can see on my router/DHCPv6 server.
>
> But no traffic ever flows in/out of the delegated PD, the devices appear
> to pull the lease and then proceed to do nothing. These are non-AOSP
> Android devices, so it probably varies by many of the various Android OEM
> implementations. For example, Xiaomi devices floods my VLAN with Router
> Advertisements!
>
> *--*
> Best Regards
> Daryll Swer
> Website: daryllswer.com
> <https://l.shortlink.es/l/d23649aed4c2ecb19e878bc80984f94257888400?u=2153471>
>
>
> On Tue, 16 Sept 2025 at 18:08, Daryll Swer <[e-mail]> wrote:
>
>> I'm working on an IPv6 deployment right now where I accounted for RFC9663
>> or simply in other words: ia_pd on endpoints.
>>
>> I'm doing /38 per campus, /51 per VLAN, /60 per endpoint, 512 devices per
>> VLAN, 8192 VLANs/VNIs.
>>
>> The reason for /60s is an edge case involving users with compute nodes
>> and their own hypervisors. If I exclude this factor, then /64 per endpoint
>> is sufficient in other more common scenarios.
>>
>> --
>> Sent from my iPhone
>>
>>
>> On Tue, 16 Sep 2025 at 5:19 PM, Mark Smith <[e-mail]>
>> wrote:
>>
>>> Hi,
>>>
>>> On Tue, 16 Sept 2025 at 19:05, Lorenzo Colitti <lorenzo=
>>> [e-mail]> wrote:
>>>
>>>> Recommendations for network operators are written in RFC 9663. Some
>>>> text about expected prefix lengths is in section 8 of that RFC. RFC 9762
>>>> says the prefix must be SLAAC-sized, which currently means it must be a /64
>>>> per device. A /48 is fine for a small or medium network, but a campus with
>>>> tens of thousands of devices on it probably needs more than that.
>>>>
>>>
>>> I would assume (and I'm interested to find out otherwise) that once a
>>> network gets to say 30K hosts, then they've moved to BGP as their main
>>> routing protocol. 65 536 /64 routes in BGP is a walk in the park, so a /48
>>> for a network of say 50K hosts each with is own /64 and 15K /64s left over
>>> for everything else would seem to be a large network. In other words, I
>>> think a /48 would suit all but the largest networks.
>>>
>>> Are there large enterprise or university networks with 10s of 1000s of
>>> hosts that aren't using BGP (yet?).
>>>
>>> Regards,
>>> Mark.
>>>
>>>
>>>>
>>>> On Tue, Sep 16, 2025 at 5:59 PM Tim Chown <Tim.Chown=
>>>> [e-mail]> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> Good news, thanks.
>>>>>
>>>>>
>>>>>
>>>>> What’s the recommended deployment model for PD to the host in a campus
>>>>> WiFi scenario?   I can certainly see advantages for it, as you’ve
>>>>> highlighted in your email.  The linked article explains “what this means
>>>>> for app developers” but a “what this means for enterprise/campus network
>>>>> operators” would be useful.
>>>>>
>>>>>
>>>>>
>>>>> Is it a given that in a middling or large campus the operator will
>>>>> need to now receive more than a /48 from their NREN?  Or was that always
>>>>> too cautious?  A small but growing number here are obtaining LIR status
>>>>> directly.
>>>>>
>>>>>
>>>>>
>>>>> Tim
>>>>>
>>>>>
>>>>>
>>>>> On 16/09/2025, 09:49, "Lorenzo Colitti" <lorenzo=
>>>>> [e-mail]> wrote:
>>>>>
>>>>>
>>>>>
>>>>> There was a typo in the original post. It was fixed earlier today; it
>>>>> now says "Android 11 and above"
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Sep 16, 2025 at 3:21 PM Maciej Żenczykowski <maze=
>>>>> [e-mail]> wrote:
>>>>>
>>>>> There's a reddit thread:
>>>>>
>>>>>
>>>>> https://www.reddit.com/r/Android/comments/1nhzsst/android_developers_blog_simplifying_advanced/
>>>>> <https://l.shortlink.es/l/94320df07ba30152b776a3bb291de9de682ecb31?u=2153471>
>>>>>
>>>>> First comment:
>>>>>
>>>>> There's a mistake in the page: running Android and above before the
>>>>> end of the year via a Google Play System Update.
>>>>>
>>>>> Which version?
>>>>>
>>>>>
>>>>> On Tue, Sep 16, 2025 at 3:59 AM Stan Barber <[e-mail]> wrote:
>>>>> >
>>>>> > Congrats!
>>>>> >
>>>>> > On Mon, Sep 15, 2025 at 6:32 PM Lorenzo Colitti <lorenzo=
>>>>> [e-mail]> wrote:
>>>>> >>
>>>>> >> FYI, we announced DHCPv6 PD support on Android today:
>>>>> >>
>>>>> >>
>>>>> https://android-developers.googleblog.com/2025/09/simplifying-advanced-networking-with.html
>>>>> <https://l.shortlink.es/l/e1fede7071e6cf4b46d6593b2ad9cd6dd3156bfa?u=2153471>
>>>>> >>
>>>>> >> 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.
>>>>> >> 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.
>>>>> >>
>>>>> >> Over the next few months we also plan to roll out support for
>>>>> DHCPv6 address registration (RFC 9686).
>>>>> >>
>>>>> >> I would like to thank everyone who contributed to RFC 9663, RFC
>>>>> 9762 and RFC 9686. We think that DHCPv6 PD is *better* than either SLAAC or
>>>>> IA_NA, because it allows the device to provide end-to-end connectivity to
>>>>> unlimited devices, containers, VMs etc. without scaling load on the
>>>>> network. Plus the prefix can be tracked and managed by the operator, which
>>>>> means that it should be possible to deploy it in networks that require
>>>>> DHCPv6 or that have scaling issues dealing with many addresses. We hope
>>>>> that this will allow at least some enterprise operators to deploy IPv6 to
>>>>> Android devices.
>>>>> >>
>>>>> >> Cheers,
>>>>> >> Lorenzo
>>>>> >> _______________________________________________
>>>>> >> v6ops mailing list -- [e-mail]
>>>>> >> To unsubscribe send an email to [e-mail]
>>>>> >
>>>>> > --------------------------------------------------------------------
>>>>> > IETF IPv6 working group mailing list
>>>>> > [e-mail]
>>>>> > List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
>>>>> <https://l.shortlink.es/l/8c35987be16c96d285bacf1db33a24154967198a?u=2153471>
>>>>> > --------------------------------------------------------------------
>>>>>
>>>>> --
>>>>> Maciej Żenczykowski, Kernel Networking Developer @ Google
>>>>>
>>>>> _______________________________________________
>>>>
>>> dhcwg mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>> _______________________________________________
>>> v6ops mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>> [image: 9eb9e675cfd5983f2907e91254d424679cc4450a]
>
>