Re: [v6ops] Implementation Status of PREF64

[David Farmer <[e-mail]>]

On Tue, Sep 28, 2021 at 17:37 Mark Smith <[e-mail]> wrote:

>
> Lorenzo has worked out like I have worked out that reducing external
> dependencies (such as a dependency on a central server) makes things more
> reliable, and also makes deploying new capabilities to hosts easier and
> quicker.
>

I had told myself I was going to stay out of this round of the DHCP vs. RA
config, oh well, that lasted about 5 days, guess I was lying to myself. :(

So you are saying we should ditch DNS and go back to HOST files? Because
external dependencies are BAD! Well, it ain't quite that simple.
Sometimes, external dependencies help a solution scale and they are
necessary.

Oh, and where is the shared fate we were promised for PREF64 RA? A script
that announces a separate RA doesn't provide any shared fate. Yes, it is
only a temporary hack, I get that. But, there is the rub, there is a
chicken-and-egg problem here. Until, at least some, router vendors
implement PREF64 RA, why would host vendors implement it? And, until, at
least some, host vendors implement PREF64 RA, why would any router
vendors implement it?

So why would DHCPv6 be any different, well, most DHCP
server implementations have a way to encode, at least, basic unknown DHCP
Options, it's not pretty, but it avoids the chicken-and-egg problem. I'm
not aware of any router advertisement implementations that have a mechanism
to encode unknown RA options, mostly because there weren’t supposed to be
very many options, supposedly, that was going to be DHCP's realm.

However, by deciding the DHCPv6 is BAD, you have changed part of that
equation, without accounting for an easier way to implement new RA options
that become necessary without DHCPv6 being available. Furthermore, DHCPv6
is necessary for certain kinds of networks. If you don't want Android used
on those kinds of networks, say that, and also stop selling Android to
users of those networks. Otherwise, if you want to keep selling Android to
users of those networks, at least provides an optional DHCPv6 client,
disable it by default, or require a separate installation, but don't
require jailbreaking to install a DHCPv6 client on Android. And, if you
insist on not providing an Android DHCPv6 client then work with the
community to provide a mechanism to ease the issue of unknown RAs. I don't
think draft-troan-6man-universal-ra-option was that solution, but that
doesn’t mean we don't need one.

In many cases, your arguments are correct, but you are not providing
complete solutions, to replace the solutions you are rejecting.

I'm really getting sick and tired of this argument, especially everyone
talking past each other, and despite what you think this is very much
delaying IPv6 deployment for many networks.

Thanks.