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

[Kyle Rose <[e-mail]>]

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