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

[Kyle Rose <[e-mail]>]

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".

I am absolutely sympathetic to autoconfiguration and want to see more of
it. But care needs to be taken to avoid creating perverse incentives to
misconfiguration. Misconfigurations should be easily detected and
corrected, not hidden behind layers of mitigation until the problem finally
exceeds the reach of the mitigation, requiring the operator to unravel
layers of complexity that introduce incomprehensible responses to
diagnostic steps.

>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.

Kyle


On Thu, Apr 11, 2024 at 8:36 AM Ted Lemon <[e-mail]> wrote:

> On Thu, Apr 11, 2024 at 8:17 AM Kyle Rose <[e-mail]> wrote:
>
>> On Wed, Apr 10, 2024 at 10:13 PM Ted Lemon <[e-mail]> wrote:
>>
>>> On Wed, Apr 10, 2024 at 8:25 PM Kyle Rose <[e-mail]> wrote:
>>>
>>>> Yes. It would make no difference to how my sites would operate. I am
>>>> concerned about complexity, however, and the more complex a change that is
>>>> required, the less widely implemented it is likely to be.
>>>>
>>>
>>> This is sort of a truism, but I don't see why it should affect what we
>>> put in the document. E.g. PCI certification /still/ does not require TLS
>>> 1.2, even, much less TLS 1.3 It took a long time for mbedtls to implement
>>> TLS 1.3. Should we not have published TLS 1.3 because we thought mbedtls
>>> wouldn't implement it?
>>>
>>
>> TLS offers a handshake allowing pairwise interop between versions. This
>> known-local mandate by contrast would enable many of the configurations
>> proponents desire, on networks that require more than pairwise
>> compatibility, only after every device supports it. It's a long ramp to an
>> uncertain future.
>>
>
> I don't think this requires pairwise compatibility. If a host has a ULA,
> and a GUA, and both are advertised locally, right now hosts will always use
> the GUA. With the proposed change, they will use the ULA if it is known
> local. Hosts that do not implement this will continue to use the GUA, which
> will work, just not as consistently. It's okay to have a long tail here.
>
>
>> The reason to prefer known ULA<->known ULA over GUA<->GUA is that it
>>> enables sites to reliably number internally with a ULA and for that ULA to
>>> then be used for internal communication in preference to GUAs, which may be
>>> renumbered arbitrarily as ISP contracts change or at the whim of the ISP,
>>> for that matter.
>>>
>>>> That's not the only way to enable this outcome. I solve this problem by
>>>> using different names internally. Split horizon would also work here, by
>>>> showing you only ULA internally and only GUA externally.
>>>>
>>>
>>> That's not something that can be done automatically on a home network.
>>>
>> "That" = ...split horizon DNS? Surely using different names internally is
>> a thing that home users would generally do by default, since they tend to
>> have most services firewalled from outside, except for things like port 22
>> for power users or services that reach out to provide return connectivity,
>> e.g., for IoT devices like thermostats and doorbell cams. (I suspect most
>> home users' internal services are advertised via mDNS, which under 6724 on
>> a dual stack network generally means the v6 addresses associated with a
>> .local name will never be used. I and everyone on this list am probably far
>> out on the tail of home users in that I run my own recursive DNS server.)
>>
>
> Okay, there's a lot wrong with this picture of how things work. First of
> all, the direction that IoT is evolving at the moment is away from the
> "reach-out-to-the-cloud" model. That model has a lot of problems, not the
> least of which is that it doesn't work when the cloud isn't reachable. Do
> you want to not be able to turn your lights off when the Internet is down?
> The privacy challenges presented by having random people outside your home
> be able to know whether you've turned your thermostat down and when your
> lights are on also definitely militates for local rather than cloud control
> of IoT.
>
> You are right that most services on home networks today are advertised by
> mDNS. However, we are trying to move away from that towards using SRP and
> unicast DNS-SD. And we now have 802.15.4 networks in the home, and these
> are IPv6-only and use SRP plus an advertising proxy to advertise services
> on the home infrastructure network. mDNS and SRP advertisements include all
> public (non-temporary) addresses a host has, including ULAs. When the
> choice is between a ULA and a GUA, and the ULA is known-local, the benefit
> of choosing the ULA is that we don't lose connectivity when the ISP
> renumbers the network.
>
> I think a key disconnect in the way you are thinking about this is that
> you're thinking in terms of networks being managed, rather than unmanaged,
> and of DNS advertisements as being set up manually, or through some
> management UI, rather than automatically. The proposed mandatory behavior
> makes it much easier to set up a network that is largely autonomous
> (self-configuring), rather than managed, and have it work predictably and
> reliably in the face of normal events such as ISP renumbering, multihoming,
> and so on. You're right that if you are your own operator, there are other
> ways to solve the same problem, but this assumption gets less and less
> viable as time goes forward.
>
>
>> The fact that you can do a heavy lift like that and make it work is a
>>> credit to your company's operational acumen, but doesn't help implementors
>>> of RFC7084, for example.
>>>
>> Just to be clear, my "sites" are my home networks. My interest in this is
>> personal/hobbyist, not professional.
>>
>
> Right, I'm realizing that based on your previous statement. But you are
> many standard deviations outside of the user we are designing for.
>
>
>> I mean, I *see* the advantages if you have DNS names that map to both, or
>>> other static configuration that wants to be able to use one or the other
>>> under a variety of network environments, where there is some policy,
>>> routing, efficiency, performance, reliability, or other benefit to using
>>> ULA where it is available. I'm not blind to that. I just haven't been
>>> convinced that address selection is the best way to solve those problems.
>>>
>>> Do you have some other solution to propose that doesn't involve
>>> maintaining parallel DNS namespaces and training users to operate them? Can
>>> this solution be deployed transparently and automatically?
>>>
>> I guess I'm just not that sympathetic to the goal of optimizing
>> initial-config simplicity for operators of networks beyond a minimal level
>> of complexity. IMO, trying to simplify network operations by putting all
>> possible addresses for a service into a single DNS name and assuming the
>> client will choose the optimal pair via 6724-style address selection is a
>> case where seeming simplicity of configuration is likely to lead to
>> hard-to-diagnose problems later. Lorenzo's open advocacy of publishing
>> unreachable ULA to global DNS and letting the client sort it out, certainly
>> much more extreme than any other position I've read on these threads over
>> the past 10 months, is maybe the perfect example of just the kind of
>> "theoretically, this should work" thinking that we are likely to come to
>> regret in ten years' time.
>>
>
> Actually the thinking we've come to regret from ten years ago is mostly
> the opposite: expecting that clever workarounds on the network will not
> hide actual problems and make them hard to debug. Things that fail in
> obvious ways are pretty easy to debug. The more subtle your network setup
> is, the harder it is to figure out why it's broken, and indeed the more
> likely it will be that things you think are working actually aren't,
> meaning that e.g. it's only when IPv4 suddenly stops working that you
> realize your IPv6 configuration is completely FUBAR.
>
>
>> I don't really have anything to add to my stated justification. It really
>> boils down to "more complex means greater time-to-done". I want the default
>> policy table change published 6 months ago.
>>
>
> Okay. But I think you're thinking that the MUST we're asking for is "more
> complex," whereas we're claiming that it's "less complex." :)
>
> Have you followed any of Jen's presentations on IPv6-mostly?
>