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> wrote:

> On Mon, Oct 23, 2023 at 9:26 AM Ole Trøan <otroan=
> 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
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>