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

[Ted Lemon <[e-mail]>]

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?