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

[Ted Lemon <[e-mail]>]

David, the issue is, can we actually implement known-ULA for all cases.
It's not clear that we can, so then the question is, what cases we can't
address do we care about, and what should we do about it. I don't think
you've answered that question.

Regarding "the old behavior is okay," we are always going to have a long
tail of legacy devices. The question is, for which of these devices is
their current behavior bad enough that we need to do something about it,
and if we need to do something about it, what can we do given that they
aren't updating their stacks?

On Mon, Apr 15, 2024 at 2:50 PM David Farmer <[e-mail]> wrote:

> You say, "In these cases, we will get the old behavior, which works well
> enough."
>
> However, RFC6724 is not implemented universally or entirely. Therefore,
> the current behavior, or the old behavior compared to this update, is a mix
> of RFC3484, RFC6724, and a hybrid of the two in gai.conf.
>
> Moreover, you and others might feel RFC6724's behavior is good enough, but
> at least many of those instigating this draft think preferring IPv4-IPv4 or
> ULA-ULA is incorrect behavior and contrary to the intent of preferring IPv6
> to IPv4.
>
> It would be best for all IPv6 implementations to implement known-local
> ULAs. The normative language best suited to accomplishing that is
> debatable; I'm fine with SHOULD or MUST, with a slight preference for MUST.
>
> Nevertheless, any implementation that does not implement known-local ULAs
> should raise the ULA label's preference above that of the IPv4 label. Give
> that at least most implementations that use gai.conf already do that that
> is not inconsistent with the current behavior works good enough.
>
> Thanks
>
> On Mon, Apr 15, 2024 at 8:02 AM Ted Lemon <[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.
>>
>> Op ma 15 apr 2024 om 04:06 schreef Ole Troan <[e-mail]>
>>
>>>
>>>
>>> > On 11 Apr 2024, at 05:30, Lorenzo Colitti <lorenzo=
>>> [e-mail]> wrote:
>>> >
>>> > On Thu, Apr 11, 2024 at 1:04 AM Ted Lemon <[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]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
>
> --
> ===============================================
> David Farmer               Email:[e-mail]
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>