Re: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-00.txt

Hi Ted, Hi Kyle, Thanks for your explanations – I agree to what you said.

Except “applications”.
IMHO: this flag is not needed per application. “Per host” would be enough.
I proposed to just change the label of the particular ULA PIO (could be /48, /64, or anything in between) to the same as GUA.
It would already permit to have sessions from this ULA PIO (as a source) to any GUA as the destination.

Theoretically, other actions are possible. But I have not heard any other proposal for what to do with the “NAT_or_NTP available” flag.
Eduard
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: Monday, October 23, 2023 7:23 PM
To: Kyle Rose <krose@krose.org>
Cc: Ole Trøan <otroan=40employees.org@dmarc.ietf.org>; Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>; 6man WG <ipv6@ietf.org>
Subject: Re: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-00.txt

Hi Kyle,

On Mon, Oct 23, 2023 at 4:33 PM Kyle Rose <krose@krose.org<mailto:krose@krose.org>> wrote:
On Mon, Oct 23, 2023 at 9:26 AM Ole Trøan <otroan=40employees.org@dmarc.ietf.org<mailto:40employees.org@dmarc.ietf.org>> wrote:
I don’t see your point.
Please give an example where signaling solves something…

I'm not 100% what Vasilenko means, but to me the impasse can be described by two scenarios:

1. ULA is able to reach the public internet via NAT/NPT. No GUA is available (for whatever reason). Either IPv4 or IPv6 can be used to reach the public internet.
2. ULA is not able to reach the public internet, and will be filtered or rejected at the border. No GUA is available (for whatever reason). IPv4 is required to reach the public internet.

Dealing with these two situations in the absence of an explicit signal about ULA->public internet reachability requires mutually exclusive configurations. There is no default policy configuration, much less a default policy table in the 3484 sense, that will accommodate both.

This forces us to make a choice about which of the two behaviors will be made the default. I of course have my preference (as stated elsewhere) but regardless, if we want to make progress we all need to accept that this choice is unavoidable within the existing source address selection framework in the absence of further signaling from the network.

Thanks for this precis of the situation.  I will point out that ULAs, on their creation as a replacement for site-local, were described to the rest of the IETF as following 2 (at the time without any possibility of 1, see RFC 4193 section 4.1 and 5).

There are, as a result, many existing contexts in which the application's presumption is for 2.  Using an explicit signal to indicate a change in the protocol's characteristics permits at least some hope that the application will have access to that signal and can adjust its behavior accordingly (as others have pointed out, this is non-trivial to arrange, but within the realm of possibility).  Without an explicit signal a new default has significant failure modes for the applications that there is no real way for us to address.

I would personal prefer to move to a state where both behaviors are explicitly signaled and the absence of a signal indicates that the upgraded mechanism is not in use.  This is similar to, but distinct from, retaining the original default (in that it lets you identify when a network's choice of signal is deliberate).

Just my personal opinion,

regards,

Ted Hardie

Kyle
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------