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

[Kyle Rose <[e-mail]>]

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.

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


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


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


> I think it makes sense that you wouldn't care about this feature—I can't
> imagine it being useful for an ISP—but do you really care so much about
> /not/ requiring this that you'd take this capability away from sites that
> would benefit (greatly, IMHO) from it?
>
>> I want something published. What started as a very simple change to
>> elevate ULA->ULA over IPv4->IPv4 has turned into a major effort I mostly
>> just don't care about. I want the default policy table changed. That's the
>> extent of my interest here. So am I opposed to these other things? Only in
>> the sense that I want something published soon, so stacks will start
>> implementing changes in my lifetime. The simpler, the better from that
>> perspective.
>>
>
> This sounds like it might be your core motivation: you worry that it will
> take longer to publish the document with MUST than SHOULD. Is that the
> case? Given the number of voices in support of making known ULA support
> mandatory, do you think your worry is really justified? Or are you worried
> that implementors will read the document and ignore it because of the MUST,
> and so you won't get the stuff you really want? Or is the issue that you
> don't feel you can write an RFP that requires implementation of the updated
> spec?
>

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