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

[Jared Mauch <[e-mail]>]

> On Apr 15, 2024, at 1:32 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. 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.


I worry about how we standardize these things then make gripes about uRPF not working when the devices can’t have knowledge of the prefixes that are in-scope.  (Eg: savnet)

The multiple on-link prefixes and link-local do provide the option to keep traffic there, but not all applications bind to * AF_ANY and could source from GUA, ULA or otherwise.

- Jared