[dhcwg] Re: [v6ops] Re: Re: Re: [IPv6]Re: An droid now supports DHCPv6 PD

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 <[email protected]> wrote:

> Hi,
>
> On Tue, 16 Sept 2025 at 19:05, Lorenzo Colitti <lorenzo=
> [email protected]> 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=
>> [email protected]> 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=
>>> [email protected]> 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=
>>> [email protected]> wrote:
>>>
>>> There's a reddit thread:
>>>
>>>
>>> https://www.reddit.com/r/Android/comments/1nhzsst/android_developers_blog_simplifying_advanced/
>>>
>>> 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 <[email protected]> wrote:
>>> >
>>> > Congrats!
>>> >
>>> > On Mon, Sep 15, 2025 at 6:32 PM Lorenzo Colitti <lorenzo=
>>> [email protected]> wrote:
>>> >>
>>> >> FYI, we announced DHCPv6 PD support on Android today:
>>> >>
>>> >>
>>> 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.
>>> >> 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 -- [email protected]
>>> >> To unsubscribe send an email to [email protected]
>>> >
>>> > --------------------------------------------------------------------
>>> > IETF IPv6 working group mailing list
>>> > [email protected]
>>> > List Info: https://mailman3.ietf.org/mailman3/lists/[email protected]/
>>> > --------------------------------------------------------------------
>>>
>>> --
>>> Maciej Żenczykowski, Kernel Networking Developer @ Google
>>>
>>> _______________________________________________
>>
> dhcwg mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>>
> _______________________________________________
> v6ops mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
[image: 9eb9e675cfd5983f2907e91254d424679cc4450a]
​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​

_______________________________________________
dhcwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]