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

[Kyle Rose <[e-mail]>]

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