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

[Ted Lemon <[e-mail]>]

Okay, let's say your case is "natural." In your setup, you'd need to make
fc00::/6 a "known-local" ULA, and then you would get the behavior you want,
right? And you could do this by always publishing an fc00::/6 route in all
your default routers (or a subset, if that makes more sense).

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

> On Mon, Apr 15, 2024 at 1:33 PM Ted Lemon <[e-mail]> wrote:
>
>> 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.
>>
>
> Neither. Each site has its own prefix, and the routers hosting the VPN at
> each site route packets over the VPN to the proper site based on the
> destination prefix. Only the site routers are aware of all three prefixes.
>
> 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?
>>
>
> My setup is not at all contrived or especially complex. The fact that a
> VPN is involved is somewhat extraneous. So, replace "VPN" with "backbone",
> and imagine that krose.net has acquired a few other companies (
> example1.com through example9.com), each with their own ULA prefixes,
> that it wants to attach to the krose.net backbone to save on transit
> costs. Are you contending that all ten sites need to have every one of
> their ULA prefixes distributed and configured statically on every other
> site in order to achieve the objective of routing traffic over the backbone
> via an internal addressing scheme rather than falling back to the public
> internet? (Presumably the backbone could have higher-preference backbone
> routes for known GUAs, but you quickly run into policy management
> complexity if you want internal traffic to be treated differently, and
> then need to apply different policy to the same address pairs depending on
> which link a packet comes in over, an unsafe network segmentation practice.)
>
> 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.
>>
>
> It turns out there's already a solution to routing packets from a device
> with a single uplink: a default route. If ULA is preferred to IPv4, the
> packets get where they're supposed to go by going from the client, to the
> default gateway (which happens to be the router), over the VPN to the other
> site, and from there to the destination. All without the clients needing to
> know who owns the destination ULA prefix or how it's managed.
>
> I'm contending mine is a very simple, natural, and *basic* use case that
> should be supported. It in fact works today with the hybrid glibc policy
> table. The proposal to require known-local with reduced preference for
> not-known-local ULA implies that every device, not even every router, needs
> to have what amounts to an enterprise-wide ULA DFZ FIB. That seems absurd
> and unnecessary.
>
> Kyle
>
>