Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05

[David Farmer <[e-mail]>]

On Mon, May 27, 2019 at 4:08 PM Nick Hilliard <[e-mail]> wrote:

> David Farmer wrote on 27/05/2019 20:23:
> > But it's not DHCPv4 we're actually talking about but the robustness IPv4
> > to a failure of DHCPv4.  So let's be clear, Philip is proposing reducing
> > the robustness of IPv4 in the presence of IPv6, at least the robustness
> > of on-link communications with IPv4. Whereas using the flag only reduces
> > the robustness of IPv4 in the presence of the IPv6-Only Flag. While I'm
> > fine with either option, many people objected to tying IPv4 and IPv6
> > together, but which of these two options does more violence to IPv4?
>
> personally, I don't think either of these options is compelling - and
> separately, would tend to agree with the idea that causing different
> protocols to share fate is something that should be avoided, unless
> there are overwhelmingly good reasons to do so.  So the question of
> which "does more violence to ipv4" seems more like a question along the
> lines of "each option has its problems, but which is the least bad?", to
> which I'm inclined to answer: "well, neither is necessary, nor
> advisable, so maybe neither option would be best".
>

I'm sorry if you don't seem to think there is a problem worth solving, so
of us think this is a real problem especially if you want to simplify your
operations to single stack that isn't IPv4.  I don't want to be stuck in an
IPv4 world forever, and the current dual-stack model effectively requires
this. The problem is ever since we created the dual-stack model, the fate
IPv4 and IPv6 have been intertwined. Be it happy eyeballs or simply
preferring one version over the other, the stack has to choose which one to
use and if it chooses badly the user experience sucks, the fates of the two
protocols are intertwined by the dual-stack model.  I think what we are
attempting to do is separate their fates. In particular sperate IPv6 from
IPv4.

Tuning of IPv4, at least over the wire, really only makes sense if you are
doing NAT64 or something like it where IPv4 is a service over IPv6 the IPv4
on the wire is redundant. Since many seem to be interested only in a
heuristic approach, maybe tie the heuristic to for tuning off IPv4 LL and
the presence of a pref64 in the RA from draft-ietf-6man-ra-pref64. That way
the IPv6-Only state is only triggered if there are no IPv4 DHCPOFFERS and
there is a Perf64 defined, then IPv4 LL SHOULD NOT be configured.

Thanks




-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================