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

[Ted Lemon <[e-mail]>]

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