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

[Ted Lemon <[e-mail]>]

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?


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

You and I work in very different spaces, so it's not surprising that we see
this differently. From my perspective, though, what you are proposing works
no better for you, but at great cost to my users, whereas what I am
proposing works just fine for you and (I think!) greatly benefits my users.


> So I'm curious whether your objection is because you don't care about the
>> ULA-in-the-DNS case (I don't either!) or whether you knew about the
>> benefits of enabling local ULAs to be preferred over GUAs
>>
> 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 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?