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

On Tue, 16 Apr 2024, 00:22 Tim Chown, <Tim.Chown=40jisc.ac.uk@dmarc.ietf.org>
wrote:

> Hi,
>
> On 15 Apr 2024, at 15:11, Ted Lemon <mellon@fugue.com> wrote:
>
> I think we're possibly having different interpretations about what
> adopting the MUST language would mean. I'm assuming that it means that we
> do not change the priority of ULA other than known-local ULA.
>
>
> 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.
>
> Thanks for holding my feet to the fire on this—I'd completely glossed over
> the fact that if we /just/ change the SHOULD to a MUST, we haven't done
> that.
>
>
> It’s the SHOULD that’s fuzzy. I’d personally lean towards doing the same,
> i.e. making the default the “safe” one, keeping general ULA-ULA below
> IPv4-IPv4 (despite saying we shouldn’t design for misconfigurations), but I
> may not be speaking for all authors (we’ve not discussed it yet).
>

Preferring IPv4 over ULA is preferring IPv4 over IPv6.

Aren't we supposed to be phasing out IPv4 as soon as possible by preferring
IPv6?

> Tim
>
> On Mon, Apr 15, 2024 at 9:13 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
>
>> On 15 Apr 2024, at 14:02, Ted Lemon <mellon@fugue.com> wrote:
>>
>> What should says is the the behavior is not optional—we don’t think there
>> is a good reason for an implementation not to do the behavior.  Which is
>> true here.
>>
>> It’s also true, as you say, that not all prefixes will be identifiable as
>> local in all cases.  In these cases, we will get the old behavior, which
>> works well enough.
>>
>>
>> That’s not true, hence my other email just now about (new vs old) default
>> behaviour…
>>
>> Tim
>>
>> Op ma 15 apr 2024 om 04:06 schreef Ole Troan <otroan@employees.org>
>>
>>>
>>>
>>> > On 11 Apr 2024, at 05:30, Lorenzo Colitti <lorenzo=
>>> 40google.com@dmarc.ietf.org> wrote:
>>> >
>>> > On Thu, Apr 11, 2024 at 1:04 AM Ted Lemon <mellon@fugue.com> wrote:
>>> > I continue to think that section 3,  "Operational Issues Regarding
>>> Preference for IPv4 addresses over ULAs," should make the new proposed ULA
>>> behavior mandatory rather than optional. I don't see a downside to making
>>> it mandatory. Hosts will come into compliance when they can; older
>>> implementations will not implement this new behavior, but I don't see any
>>> point in perpetuating that.
>>> >
>>> > Absolutely agree. This document should not proceed without that MUST.
>>> Preferring non-local ULA over IPv4 is incorrect because IPv4 implies global
>>> reachability, and ULA does not offer global reachability. So publishing
>>> this document without the MUST is harmful: an implementation that does not
>>> implement the SHOULD will cause regressions and break use cases that work
>>> today.
>>>
>>> A host should not make those assumptions.
>>> A RFC1918 IPv4 address may or may not have global reachability.
>>> A ULA may (or may not) have global reachability.
>>>
>>> In essence SA/DA combination can be assumed to provide reachability. It
>>> has to be probed.
>>> The _only_ thing SAS/DAS selection should be used for is ordering of the
>>> candidate list.
>>>
>>> > Also, MUST allows us to make ULA more useful than it is today. It is
>>> *desirable* to be able to publish non-local ULAs and have hosts know what
>>> is local and what is not. As a simple example: once all hosts implement the
>>> MUST, it will be safe to publish local ULAs in the global DNS, because
>>> hosts won't try to use them unless they are local.
>>>
>>> That’s likely a simplification. As they are certainly going to be
>>> networks where there will not be possible to signal all ULA prefixes to
>>> every host.
>>> The IETF conviction that as long as we make something a MUST then every
>>> implementor will implement it is flawed. The only thing it does is to water
>>> out the value of the MUST. Any MUST/SHOULD debate motivated by this (as
>>> opposed to a real interoperability breaking issue) is bike-shedding.
>>>
>>> O.
>>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>