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

[Kyle Rose <[e-mail]>]

On Wed, Apr 10, 2024 at 5:45 PM Ted Lemon <[e-mail]> wrote:

> On Wed, Apr 10, 2024 at 12:11 PM Kyle Rose <krose=
> [e-mail]> wrote:
>
>>  * At my sites I am fine with preferring GUA->GUA over ULA->ULA, in large
>> part because I don't have any names that map to both types of address.
>>
>
> It seems to be the case that your setup would work just fine with the new
> required behavior, if we required it, no?
>
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.

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

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

> Or do you think we should just always prefer ULAs over GUAs (sounds like
> no)?
>
I am agnostic on this. AFAICT, this fails only when you encounter ULA that
you can't reach, otherwise known as a misconfiguration. That said, I
haven't spent a lot of time thinking about the implications here, and I'm
trying to get the minimal change to enable the behavior I want.

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

Kyle