Submissions for this Proceeding

Submission Summary:

The Registries Stakeholder Group (RySG) agrees that the need for an IPv6 Controlled Interruption methodology has increased substantially since the 2012 Round of New gTLDs. The RySG requests that ICANN investigate the impact on the NCAP Report and propose an implementation plan to be reviewed by the community. Pending the review of the implementation plan, the RySG agrees that, based on the results of the research studies, the use of ...

Submission Summary:

Please find attached (PDF) the ALAC Statement on the Name Collision IPv6 Research Study. Ratification information is included on the cover page.

Kind Regards,

ICANN Policy Staff in support of the At-Large Community

Submission Summary:

This comment supports the selection of ::ffff:7f00:3535 as the IPv6 Controlled Interruption address based on the study’s findings that it is safe, non-routable, consistent with IPv4 CI behavior, and preserves the educational value of CI. The comment highlights concerns with alternative multicast and link-local options and encourages future collaboration with the IETF to define a dedicated IPv6 loopback block.

Submission Summary:

The Root Server System Advisory Committee (RSSAC) appreciates this opportunity to provide feedback on the Name Collision IPv6 Research Study.

The RSSAC believes that controlled interruption for new gTLDs is a good practice for both IPv4 and IPv6. Furthermore, the RSSAC has no objections to the IP address ::ffff:127.0.53.53 being used for IPv6 controlled interruption.

Submission Summary:

Using ffff::127.0.0.53 is a bad use of ffff:: prefix.

Please note that the IETF intends to shortly have a IETF draft (and later a RFC) about specific IPv6 address(es) for very similar/more generic use (i.e., not only for TLD). So, suggest to delay any decision until this IETF draft is submitted.

Submission Summary:

Special purpose IP address registries are maintained by IANA.

IANA is a function operated by ICANN on behalf of the IETF and the relationship is governed by a legal agreement between ICANN and the IETF, signed on March 1, 2000 called "IETF-ICANN Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority":

https://www.icann.org/resources/unthemed-pages/ietf-icann-mou-20...

Submission Summary:

I urge ICANN to formally engage with the IETF to come up with a solution to this problem.

Submission Summary:

IMHO, using an IPv4-mapped IPv6 address is not a good idea, as many libraries/APIs might treat is as a special address. However it's not the main point I'd like to make.

There are two fundamental questions to answer:

1. Is returning a special address a right way to solve the problem?

2. If it is the right way, what IPv4 and IPv6 addresses to use?

While I do not have any strong opinion on the item #...

Submission Summary:

It was a huge mistake to use 127.0.53.53 for this without following the appropriate procedure by means of an IETF I-D. It MUST be corrected now that we know it for the proper registration of the prefix that IETF decides is best for this. So please, also submit an I-D for the correct IPv4 address to be chosen by the IETF consensus process.

Consequently, doing it again for IPv6 will be an even bigger mistake. Please, use the procedures, by...

Submission Summary:

Please see https://mailarchive.ietf.org/arch/msg/v6ops/B2GCyjHDYtSDPCI6UJOKcGc618s/

Submission Summary:

This proposal needs to be made via the an Internet Draft submitted to the IETF v6ops working group. Only IANA can assign special purposes to IPv4 and IPv6 addresses after IETF review and approval.

Submission Summary:

The use of 127.0.0.0/8 prevents a useful reverse name that would explain what is going on. Some PTR like possible-future-tld.icann.org would help users of that "string" to understand what is going on.