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

[Mark Smith <[e-mail]>]

Hi,

On Tue, 16 Apr 2024, 01:37 Tim Chown, <Tim.Chown=[e-mail]>
wrote:

> Hi,
>
> On 15 Apr 2024, at 16:23, Kyle Rose <krose=[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.
>
>
> Well, it will take time for the default policy table to be changed on
> various platforms as well.
>
> If your policy table is configurable, and you can manage your network
> devices, then you can of course configure it today for the policy you want.
>
> We also now have two different protagonists for change here, with some
> overlap.  Those who want to see ULA-ULA elevated over IPv4-IPv4, but also
> those who want known-local ULAs to be used ahead of GUAs, which is
> something we didn’t originally include in even the WG-adopted -00, but it’s
> evolved over the last few weeks as quite a nice stretch goal from the
> document.
>

It's not really a stretch goal. It's this ID solving the two problems RFC
6723 created:

- Preferred IPv4 over IPv6 (ULA).

- Preferred GUA over the site-local replacement (ULA), when site-locals
were preferred over GUAs in RFC 3484.

which was justified by a rare configuration error of putting ULA in global
DNS.

RFC 6784 was optimised for a rare error case, not a common working case.

Regards,
Mark.


> Tim
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>