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

[Tim Chown <[e-mail]>]

On 15 Apr 2024, at 16:38, Mark Smith <[e-mail]> wrote:

On Tue, 16 Apr 2024, 00:22 Tim Chown, <Tim.Chown=[e-mail]<mailto:[e-mail]>> wrote:
Hi,

On 15 Apr 2024, at 15:11, Ted Lemon <[e-mail]<mailto:[e-mail]>> 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?

My personal take on the “compromise” we’re heading towards is that we are, but only for ULAs that are known to be local, but for those cases we’re also preferring them ahead of GUAs.

But the authors will put whatever consensus arises from the WG into the document :)

Tim

Tim

On Mon, Apr 15, 2024 at 9:13 AM Tim Chown <[e-mail]<mailto:[e-mail]>> wrote:
On 15 Apr 2024, at 14:02, Ted Lemon <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>


> On 11 Apr 2024, at 05:30, Lorenzo Colitti <lorenzo=[e-mail]<mailto:[e-mail]>> wrote:
>
> On Thu, Apr 11, 2024 at 1:04 AM Ted Lemon <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


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