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

[Brian E Carpenter <[e-mail]>]

On 24-Oct-23 05:23, Ted Hardie wrote:
> Hi Kyle,
> 
> On Mon, Oct 23, 2023 at 4:33 PM Kyle Rose <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     On Mon, Oct 23, 2023 at 9:26 AM Ole Trøan <otroan=[e-mail] <mailto:[e-mail]>> 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,

Not really, because I fully agree, as a direct result of writing the code at https://github.com/becarpenter/getapr/ . Nothing made any sense until I defined a Boolean NPTv6 which defaults to False, and only flips to True when the code successfully connects from a ULA source to a GUA destination. After that, everythinng became straightforward.

   Brian