[NCAP-Discuss] Adding IPv6 to Controlled interruption (was: Re: Remaining Public Comments to Discuss)

[Casey Deccio]

> On Mar 4, 2024, at 9:40 PM, Michael Puckett <michael.puckett at icann.org> wrote:
> 
> I’m starting a thread for topics from public comments that need to be discussed by the DG. 
>  
> IPV6 support to CI:
> (Rubens Kuhl): The dichotomy suggested in the report between IPv6 and Controlled Interruption is not based on fact-based finding, but on lack of testing. ::1 (meaning ::1/128 as in IPv6 there is no localhost subnet, only a localhost) is a perfectly good solution to add IPv6 support to Controlled Interruption, targeting IPv6-only hosts. I support doing a study with a few key operating systems to confirm its usefulness and lack of side effects before the final report is published, so it gets quicker to a name collision framework without reconvening NCAP DG.


Here is the relevant text referred to in the study 2 report (section 3.5.2):

"The DG notes that there is no exact IPv6 equivalent of the IPv4 addresses used for controlled interruption. While IPv6 solutions have been mentioned in DG meetings, none have been thoroughly discussed or tested. For this reason, controlled interruption, as proposed, only works with IPv4. Despite this apparent shortcoming, this only affects notification for the few, if any, affected hosts that have IPv6-only connectivity."

My thoughts on this:

1. I am not opposed to IPv6 -- neither generally, nor as part of a name collision notification technique.

2. I haven't tested the functionality of using ::1 as a controlled interruption address, but I have no reason to believe that it wouldn't be effective at disruption.

3. Recall that part of controlled interruption (and frankly all the other proposed mechanisms) is about leaving hints to help the affected parties identify the problem as related to name collisions.  Thus, the 127.0.53.53 was different enough from 127.0.0.1 that it was expected to elicit web searches to look it up (understanding that the root cause analysis found various degrees of success with this). However,  ::1 has no such attribute.  Thus, ::1 disrupts but has no avenue for "hints" to help the affected users identify and fix the problem.  Since everything we have proposed in study to is about is about enhancing our abilities to help affected parties (both through their direct experience and indirectly, through the TRT analysis and outreach), I don't think using ::1 for interruption would add enough value.  Remember also that it really only matters for hosts without IPv4 connectivity.  We potentially lose a lot and we gain little.

(Side note. The other mechanisms leave hints in other ways.  For example, visible interruption and visible interruption and notification both use reverse DNS entries, and visible interruption and notification uses HTTP-layer interception.)

That's my 2 cents.

Thanks,
Casey

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20240313/c99be790/attachment-0003.html>