[NCAP-Discuss] Current Status of the NCAP Project

Tue Nov 15 08:08:03 UTC 2022

Just to reset some folks’ understanding of IPv6 adoption, I recently was quite shocked by a presentation by Google at M3AAWG this fall on that very topic.  Google is seeing 40% of their traffic coming from native IPv6.  We should be reaching a tipping point soon where a majority of traffic (at least to Google) is over v6 and not from v4.

https://www.google.com/intl/en/ipv6/statistics.html

The growth rate has been steady and robust over the last 6-7 years, and what I had in my head of under 20% due to old numbers and thinking was completely shredded by actual data.  I’m going to be shelving my v6 jokes going forward...

This is largely driven by mobile (duh) but is highly geographical as well (see above website).  And yes the “server side” is still vastly different, but making assumptions about v6 based on the industry group-mindset we’ve had for years about v6 isn’t actually so wise.

Just something to consider in discussions - we just don’t know how things are going to look 5-6 years from now based on assumptions made today.

Cheers,

Rod

> On Nov 14, 2022, at 10:48 AM, James Galvin <galvin at elistx.com> wrote:
> 
> I agree with your observation that controlled interruption fails for IPv6-only hosts.  I’m not yet ready to concede that dual-stacked or XLAT networks are not similarly impacted as we haven’t looked at that scenario.
> 
> As far as adding IPv6 support to collision assessment being a zero-sum game, I disagree with that.  As I noted below, IPv6 usage may be small and increasing at a very low rate however, as a technical point, this does not justify dismissing collision assessments on an IPv6 network.
> 
> At a minimum, the DG was tasked to consider how to assess collisions in the future.  Since IPv6 is present today and is increasing, however slowly, I think the DG would be remiss if it did not consider whether or not there was a solution for when IPv6 was in use.  Since we have found a solution the DG would be negligent if it did not call it out, on its technical merits.
> 
> Jim
> 
> 
> On 13 Nov 2022, at 19:20, rubensk at nic.br wrote:
> 
>>> On 12 Nov 2022, at 22:53, James Galvin <galvin at elistx.com> wrote:
>>> 
>>> A few comments inline.
>>> 
>>> On 11 Nov 2022, at 10:52, Casey Deccio wrote:
>>> 
>>>>> \On Nov 10, 2022, at 4:34 AM, James Galvin <galvin at elistx.com> wrote:
>>>>> 
>>>>> I consider the following things better.
>>>>> 
>>>>> 1. Frankly, [lack of IPv6 support] was a serious technical gap in the 2012 Controlled Interruption
>>>> 
>>>> It is a fact that controlled interruption does not support IPv6.  While I do agree that IPv6 support is *desirable*, I am interested to know why you feel that this is a "serious technical gap".  And to be clear, I'm not talking about the general advancement of IPv6; I'm talking about the goals of controlled interruption.  I have taken time to write categories for technical consideration in the comparison doc, among which are the goals for alerting and data collection.  Also in that doc are descriptions of how controlled interruption and the other proposed techniques measure up.
>>> 
>>> A goal of controlled interruption is to work on today’s Internet.  Today’s Internet includes IPv6.  Failing to cover IPv6 increases the risk that controlled interruption will not achieve the goal of manifesting name collisions.  And while the traffic volume of IPv6 may be increasing ever so slowly, whatever that rate is becomes the same rate at which the risk of controlled interruption failing to achieve its goal will also increase.
>>> 
>>> Thus, on this one key point, both PCA and ACA are vastly superior to controlled interruption.
>> 
>> Today's Internet is composed of IPv4-only hosts and IPv4 and IPv6 capable hosts (either thru dual-stacked networks or IPv6 + 464 XLAT networks). Controlled interruption only fails in IPv6-only hosts, for which there are almost none whatsoever. So this alleged improvement is 0 at this point and in the foreseeable future.
>> 
>> 
>> Rubens
> _______________________________________________
> NCAP-Discuss mailing list
> NCAP-Discuss at icann.org
> https://mm.icann.org/mailman/listinfo/ncap-discuss
> 
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20221115/511586c9/signature.asc>