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

[Mark Smith <[e-mail]>]

On Tue, 16 Sept 2025, 22:29 Ondřej Caletka, <[e-mail]>
wrote:

> Hello Tim, Lorenzo, all,
>
> I would like to chime in with the current IPv6 policy in the RIPE NCC
> service region described in
> [RIPE-738](https://www.ripe.net/publications/docs/ripe-738/#26-assign).
> The RIPE community reached consensus on this definition of Assignment,
> which sort of predates this PD-to-device:
>
> > To “assign” means to delegate address space to an ISP or End User for
> > specific use within the Internet infrastructure they operate.
> > Assignments must only be made for specific purposes documented by
> > specific organisations and are not to be sub-assigned to other parties.
> >
> > Providing another entity with separate addresses (not prefixes) from a
> > subnet used on a link operated by the assignment holder is not
> > considered a sub-assignment. This includes for example letting
> > visitors connect to the assignment holder's network, connecting a
> > server or appliance to an assignment holder's network and setting up
> > point-to-point links with 3rd parties.
> >
>
> This means that if an end user has an Assignment either from their ISP
> (Provider Aggregatable) or directly from the RIPE NCC (Provider
> Independent), they are explicitly not allowed to use DHCP PD with a
> third party (for instance guest Wi-Fi).


Doesn't this clause cover that?

"This includes for example letting visitors connect to the assignment
holder's network"

A guest Wifi network (as in "guest of the current network") would be
attached to the assignment holders network wouldn't it?



Therefore under current
> policies, networks using DHCP PD with third parties need to be
> registered as aggregate assignments (RIPE Database status
> [AGGREGATED-BY-LIR](
> https://www.ripe.net/manage-ips-and-asns/ipv6/documenting-ipv6-assignments-in-the-ripe-database/#using-inet6num-objects-with-status-aggregated-by-lir))
>
> and this is only possible for address blocks held by LIRs, ie. it is not
> possible to get a Provider Independent block from the RIPE NCC to be
> used for DHCP PD with third parties.
>
> In spite of this new protocol being supported, I think it would be a
> good idea to reopen the discussion in the [RIPE Address Policy Working
> Group](https://www.ripe.net/community/wg/active-wg/ap/) to see whether
> this definition should be adjusted or amended.
>
> --
> Best regards,
>
> Ondřej Caletka
>
> N.B. this post does note represent any statement of any RIR
>
>
> On 16/09/2025 11:04, Lorenzo Colitti 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.
> >
> > 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/
> >
> >         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
> >         >>
> >         >> 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]/
> >         >
> >
>  --------------------------------------------------------------------
> >
> >         --
> >         Maciej Żenczykowski, Kernel Networking Developer @ Google
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
> --------------------------------------------------------------------
>