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

[Ted Lemon <[e-mail]>]

First of all, remember that the point of this is to improve the behavior of
the stack. What we have works now, but has some issues we want to resolve.
We do not need to achieve perfection here—we just need to make things
better than they were.

Regarding your VPN setup, I would expect one of two things to be true:
either the VPN is giving the device connecting through it a prefix on the
known ULA, or it doesn't expect the device to try to use the ULA, and hence
it should not be treated as known. If there are cases where it's expected
that some other ULA on the known-ULA list would work as a source address in
communicating with the ULA from which no source address configuration is
provided, then the VPN configuration could include that ULA prefix as
"known." This seems straightforward and not experimental. Of course it
would require some work in the stack.

As for the table size question, your VPN setup seems unusual and extreme.
Is this a real use case, or something you pulled out of your hat? I think
it's perfectly reasonable to have three /48s in your known-ULA table, but I
agree that hosts shouldn't have to support arbitrarily large ULAs. The
question I have is, when does this happen in practice? Given how ULAs are
allocated, we can't expect an enterprise that needs more than a /48 to be
able to aggregate, but how often is it the case that we need ULA<->ULA to
work well for multiple /48s? What is the downside to it not working well?

If your point is that there are still unknowns here, I think you're right;
my point in saying that this problem is well-understood is that for most
use cases, it really is. There are of course some cases where we will need
different behavior that is as-yet undescribed. I will point out though that
the worst-case scenario is that a particular enterprise just declares all
of fc00::/6 to be "known-local" and then gets the behavior we all
previously agreed was "good enough." This can already be accomplished (in
our proposed model) by publishing an RIO for fc00::/6 in addition to the
default route.

On Mon, Apr 15, 2024 at 12:19 PM Kyle Rose <[e-mail]> wrote:

> I have a mesh VPN connecting three sites. RAs in each site advertise their
> own site ULA prefix, along with a default v6 route that works for both GUA
> and ULA. A site's router itself has v6 routes over the VPN to each of the
> other sites, but the other devices on each network are oblivious to those
> prefixes being local or not, or indeed what "local" even means. Their
> ULA/ULA traffic does wind up transiting the VPN when addressed to prefixes
> from other sites, which is precisely what I want.
>
> What mechanism exactly would cause these prefixes to be regarded as
> known-local?
>
> Moreover, this seems to imply that attached devices need state space and
> management to scale with the number of sites, akin to source routing,
> rather than having the same property most devices on the Internet have,
> which is to have a single default route and to let the network get the
> packet to the right destination.
>
> (Finally, I'll note that my site has a catch-all firewall role to
> ICMP-reject packets sent to unroutable ULA prefixes, which partly solves
> the problem of ULA in global DNS, at least for applications that can
> mitigate by falling back to a different address pair. I might also try to
> figure out a way to have my recursive filter ULA AAAA records from external
> sources, since I can think of no legitimate reason my devices would want to
> see them, anyway.)
>
> Kyle
>
> On Mon, Apr 15, 2024, 11:58 AM Ted Lemon <[e-mail]> wrote:
>
>> I think we've already clearly defined what it means for a prefix to be
>> "known-local." Possibly the document needs to be updated to make it more
>> clear. But this isn't a situation where we're speculating. We know how to
>> determine that a prefix is local. Of course we could add more mechanisms
>> for doing so, but realistically RA and DHCP are the ways it's going to
>> happen, so we don't have a difficult bit of text to write. If we think that
>> RA and DHCP aren't adequate to the task, that's a case to be made, but I
>> think they are, and I haven't see any non-hand-wavey argument to the
>> contrary.
>>
>> On Mon, Apr 15, 2024 at 11:24 AM Kyle Rose <[e-mail]> wrote:
>>
>>> This:
>>>
>>> Well, if we agree to the MUST (with the usual caveat of any IETF ‘MUST’
>>>> for an implementor :) then we need to review the rest of the text, which
>>>> would include the default policy table, and the section David contributed.
>>>> I think you’re right, that proposed default table as is would have to
>>>> change.
>>>>
>>>
>>> is part of the reason I'm uneasy with a blanket MUST for known-local.
>>>
>>> I would be 100% fine with normative language that essentially says "IF
>>> (via some future proposed mechanism) you learn known-local prefixes and
>>> insert them into your policy table, THEN you may prefer v4/v4 to
>>> not-known-local ULA/ULA; but if you do not, then you must prefer ULA/ULA to
>>> v4/v4." My reasoning is that currently there is no specified mechanism for
>>> learning and managing known-local ULA prefixes; and it will be a long time
>>> before the long tail of stacks respond to yet-to-be-specified network
>>> signals for managing those prefixes; yet, in the absence of such an
>>> ecosystem I want ULA/ULA to take precedence over v4/v4, because under 6724
>>> they are currently mostly useless, and I want ULA to be useful now¹, not in
>>> some distant future.
>>>
>>> Kyle
>>>
>>> ¹ As it happens to be on glibc deployments, which don't comply with
>>> either 3484 or 6724.
>>>
>>>
>>>