Re: [IPv6] Second Working Group Last Call for <draft-ietf-6man-rfc6724-update>

[Ted Lemon <[e-mail]>]

On Thu, Apr 11, 2024 at 9:09 AM Kyle Rose <[e-mail]> wrote:

> I'm not going to go point-by-point here because this is quickly exceeding
> the degree of effort I want to spend on explaining my preferences. I'll
> just say that if your goal is to make problems obvious and
> easily-diagnosed, you don't want a lot of layers of mitigation on top of
> the actual network behavior. Better to make the problem of publishing
> unreachable addresses obvious to the user than to introduce a new mechanism
> that might work 99% of the time once fully-deployed but will also
> incentivize the publishing of ULA to global DNS, increasing the actual
> incidence of that problem by a far greater order of magnitude. This is what
> economists call "moral hazard".
>

Kyle, I don't know if you can hear this, but we are in violent agreement
here, and yet you keep arguing with me. Clearly neither of us are
benefiting from continuing to argue—you've said you don't want to do it,
and I'm actually on vacation right now and would prefer to get back to it.
I'm arguing with you because this is important to me—apparently more
important than it is to you, as you've expressed above.

>From experience, the most important principle of network operations is
> arguably that of "least surprise". This is why Happy Eyeballs and similar
> mitigations are a double-edged sword: they are great for users when the
> network is only partially broken, but it is still critical for the operator
> to be able to monitor for and observe the problems that are being
> mitigated. So, putting that mitigation at the application layer on the end
> user device, rather than in the network or network stack, seems like the
> right compromise because the brokenness is still apparent at a high enough
> layer for the operator to easily be able to identify the faulty application
> with sufficient telemetry.
>
>>
The point of what we are doing here is to avoid needing Happy Eyeballs,
precisely because it complicates things. I would personally prefer that we
get rid of Happy Eyeballs entirely, and that position is 100% consistent
with my wish that we make the "known-ULA" behavior mandatory. If we don't
make it mandatory, that makes things worse.

The status quo ante is that ULAs in the DNS don't cause a problem because
ULAs are never preferred over GUAs or IPv4 addresses.

You want to change the status quo to prefer ULAs over IPv4 addresses. You
are in a hurry to make this happen. I think we agree about this. Maybe I've
misrepresented your position, though—please let me know.

If we change that status quo, then something that was previously harmless
(ULAs in the DNS) now becomes potentially a problem. So we've made things
worse. It doesn't matter whether that's a "misconfiguration" or not. It
will happen, and it will cause delay, because we made this change.

The known-ULA behavior mitigates this damage. It mitigates it whether you
think publishing ULAs in the DNS is good or bad.

The known-ULA behavior also eliminates a lot of the need for Happy
Eyeballs, which is why I like it.

So why are we arguing about this? It seems obvious to me that the known-ULA
behavior makes things better for you. The only reasons you've given against
it are "ULAs in the DNS are bad," which is a non-sequitur, and
"implementing this is harder," which is simply an invalid reason for making
something a SHOULD.