Re: [v6ops] Implementation Status of PREF64

[Clark Gaylord <[e-mail]>]

The predictability of assigned/managed addresses is less a problem for your
arbitrary client/phone and more of an issue for the potential use case, for
example, of IoT/instrumentation devices where the endpoints are perceived
to need more active management than the typical phone.


--ckg

On Sun, Oct 10, 2021, 16:27 Philip Homburg <[e-mail]>
wrote:

> >In an effort to find a compromise that allows Android to support DHCPv6
> and
> >therefore the managed-assignment addressing model, I'm suggesting it is
> >reasonable for DHCPv6 clients to require the availability of more than one
> >IPv6 address before it enables it's IPv6 stack, and it sounds like Lorenzo
> >is at least open to discuss such a comprise.
>
> There is one thing I don't quite understand in this discussion. For a
> long time it seemed to be the position of Andoid devs that only SLAAC could
> support the number of addresses Android needs. DHCP IA_NA was not suitable.
>
> Now we are having a discussion whether networks should for example support
> 64 addresses using IA_NA.
>
> Android is not a new operating system with many unexpected features.
> Android 12 was released recently. I don't know for how long I have had
> android devices connect to my network using IPv6, but it is quite a
> few years.
>
> In all that time, I never noticed the android device using more than one
> or two IPv6 addresses.
>
> Now obviously I'm not pushing my phone enough that I don't see it using
> more than, say, 10 addresses. I'm a bit curious, what are those extra
> addresses for? Addresses that are so special, you need them immediately
> when connecting to the network.
>
> The strange thing is, my laptop has quite a few IPv4 address. Each VM with
> a
> network in bridge mode gets its own address for the guest. Addresses
> get added when VMs get started. And expire as stopped VMs fail to
> renew leases.
>
> Why is it that android is so special, it cannot dynamically request more
> addresses when it needs them?
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>