Re: ipv4 and ipv6 Coexistence.

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Thu, 20 February 2020 04:00 UTC

Return-Path: <prvs=1319f974a5=jordi.palet@consulintel.es>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB25112002E for <ietf@ietfa.amsl.com>; Wed, 19 Feb 2020 20:00:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KcWiT4iRs14 for <ietf@ietfa.amsl.com>; Wed, 19 Feb 2020 20:00:18 -0800 (PST)
Received: from mail.consulintel.com (mail.consulintel.com [IPv6:2001:470:1f1d:275::250]) by ietfa.amsl.com (Postfix) with ESMTP id C7B441200C1 for <ietf@ietf.org>; Wed, 19 Feb 2020 20:00:17 -0800 (PST)
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.com, Thu, 20 Feb 2020 05:00:16 +0100
Received: from mail.consulintel.es ([2001:470:1f09:495::5]) by mail.consulintel.com ([2001:470:1f1d:275::250]) (Cipher TLSv1:AES-SHA:128) (MDaemon PRO v16.5.2) with ESMTPS id md50001034309.msg for <ietf@ietf.org>; Thu, 20 Feb 2020 05:00:15 +0100
X-Spam-Processed: mail.consulintel.com, Thu, 20 Feb 2020 05:00:15 +0100 (not processed: spam filter heuristic analysis disabled)
X-MDRemoteIP: 2001:470:1f09:495::5
X-MDHelo: mail.consulintel.es
X-MDArrival-Date: Thu, 20 Feb 2020 05:00:15 +0100
X-Return-Path: prvs=1319f974a5=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1582171190; x=1582775990; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=2WyFhfAkGF7JuGAL1727bLSQUzogzPZLEf qfDIzdPrg=; b=DCbgxTE3tSMn4lyUCnkfomMo5Ja6M1DngUXNCMDmwSf6fqnwO1 s161YjNzlNdzM51naTzX0hKpNWQXvOc1EXK7UEtBBZR+4pewzMew1jNIrSruPlas Byh34lO9/vcdn12ZRnydeQ+/sN93RZHIDTe/a1DcLantIQL5L+ZZC56oo=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Thu, 20 Feb 2020 04:59:50 +0100
X-Spam-Processed: mail.consulintel.es, Thu, 20 Feb 2020 04:59:49 +0100
Received: from [220.247.146.197] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000063745.msg for <ietf@ietf.org>; Thu, 20 Feb 2020 04:59:48 +0100
User-Agent: Microsoft-MacOutlook/10.22.0.200209
Date: Thu, 20 Feb 2020 14:59:34 +1100
Subject: Re: ipv4 and ipv6 Coexistence.
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: IETF Rinse Repeat <ietf@ietf.org>
Message-ID: <440FD502-B4C8-498D-91B8-339E632304D8@consulintel.es>
Thread-Topic: ipv4 and ipv6 Coexistence.
References: <PR3P194MB0843ACAE01F33CEC57266A1AAE100@PR3P194MB0843.EURP194.PROD.OUTLOOK.COM> <EDAE6375-EE0B-4864-9834-C1FBC209D581@sobco.com> <PR3P194MB08431E138262F2A43C1D0621AE100@PR3P194MB0843.EURP194.PROD.OUTLOOK.COM> <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es> <PR3P194MB0843939F3B38426960A66E70AE130@PR3P194MB0843.EURP194.PROD.OUTLOOK.COM> <D8063303-7DDA-41F8-A63A-C0244E3E9E25@isc.org> <CAJc3aaN_t3BgdOV20jJV=ncYNZqL9VYDO+cTO+tvbjK6c1ci_A@mail.gmail.com> <B298CD63-5A51-40ED-A414-96672646F1C8@consulintel.es> <CAJc3aaPcrP2WeUMCadSWbRp6ATS1HU+NaeBgLOb7Z4C6S1wMmw@mail.gmail.com>
In-Reply-To: <CAJc3aaPcrP2WeUMCadSWbRp6ATS1HU+NaeBgLOb7Z4C6S1wMmw@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3665055582_1339363906"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Sj0XGLQ4oeZ97T_mVMro0FHXGf4>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Feb 2020 04:00:23 -0000

Hi Victor,

 

Of course, I see your points and I’m not saying that IETF has nothing to do with that, neither that it applies the same to every possible country case. It was just part of this discussion.

 

I’ve worked for a few governments, on this, with more or less success depending on the case, and most of the time is a matter of the right schedule, not saying the existing services should support IPv6 tomorrow, but “new” or “updated” services should do it in a given timing. This was my point 1.

 

Regarding 2, I think if a country ban importing or selling IPv4-only products, with a determined time scale (to be studied case by case), is perfectly valid and not impacting global Internet at all. Existing IPv4 services can remain. Products in stock can be sold during “n” months, not afterwards.

 

Example, SmartTVs without IPv6 could be sold during 6 additional months, not imported anymore after 3 months, etc.

 

I only see a disadvantage like “gaming console x” can’t be sold anymore in country “x” after 6 months. And this is a real case, which a big name, we all know. Sorry, react if you want to continue being sold in all the countries.

 

Another extreme case. Accounting app “z”, still doesn’t support IPv6. I’m sure if they have not started already to resolve the problem, they will rush in case they expect to have new customers in that country. Otherwise competitors win.

 

Regards,

Jordi

@jordipalet

 

 

 

El 20/2/20 14:19, "ietf en nombre de Victor Kuarsingh" <ietf-bounces@ietf.org en nombre de victor@jvknet.com> escribió:

 

Jordi,

 

As noted, I am not opposed, but think that it may not be a clear cut.  

 

For your item 1, I guess that could work, but in the case where there is a service which may be absolutely needed, and if not available on IPv6, would a given government be willing to cause harm in pursuit of a preference or long term agenda?   

 

For item 2, good points except - however in the case of iPv4 and IPv6 as it applies to global networking,  it may be more nuanced than, DTV and therefore not as clear cut. 

 

Please note, I am a firm supporter of IPv6 deployments and have led deployment initiatives in multiple networks.  I am definitely in the choir, but I also look at things from a practical angle.  

 

regards,

 

Victor K

 

 

 

On Wed, Feb 19, 2020 at 9:49 PM JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org> wrote:

At some point some degree of government involvement is needed. For example:

 

1.       Now: Governments should not buy anything that doesn’t support IPv6. They manage public resources, and it will be against our taxes, if they buy any service, transit, hardware or software that doesn’t work today in dual-stack and tomorrow as IPv6-only.

2.       Next future: Governments have the obligation to protect consumers. Example: When DTV is setup in every country, governments ban after some time, importing/manufacturing/selling products that don’t support DTV, otherwise consumers are cheated. At some point, in countries where the industry/retails are not moving by themselves, some governments may need to take similar decisions with IPv4-only products.

 

Regards,

Jordi

@jordipalet

 

 

 

El 20/2/20 13:30, "ietf en nombre de Victor Kuarsingh" <ietf-bounces@ietf.org en nombre de victor@jvknet.com> escribió:

 

 The sad reality is anyone whom is responsible to build, expand or manage a network needs to deal with the IPv4 long tail connectivity needs.  

 

I would agree with Mark's comment related to the notion we have enough transition technologies today.  As far as I can see, anyone who needed to deploy IPv6 and/or create a pathway to legacy IPv4 has been able to do so (perhaps there are corner cases, but I would say for the vast majority, they could do what they needed to do).   

 

As for the governments intervening, I am not so sure about that, but I am not opposed (just don't think it will work). Bureaucracy rarely solves what turns out to be a fundamental market problem.. 

 

regards,

 

Victor K

 

 

On Wed, Feb 19, 2020 at 8:27 PM Mark Andrews <marka@isc.org> wrote:

Really we do not need to be inventing anything new in this space.
We already have too many mechanisms.  ISPs just need to DEPLOY the
existing mechanism.

We have plain dual stack.

We have public IPv4 + 6rd for ISPs where the access network doesn’t
support IPv6..

We have CGN + 6RD + 100.64/10 for ISPs where the access network doesn’t
support IPv6 and they have run out of IPv4 space.

We have DS-Lite, MAP-E, MAP-T, NAT64 … providing IPV4AAS for when the ISP
has run out of IPv4 and the access network supports IPv6.

We have CGN + IPv6.

Do we really need something more at the protocol level?

We do need Governments to ban the selling of new IPv4-only domestic
devices (CPE routers, TV’s, game boxes, etc.).

Mark

> On 20 Feb 2020, at 11:32, Khaled Omar <eng.khaled.omar@outlook.com> wrote:
> 
> Regardless the different %s, lets take the average one, it can not make us optimistic and stop thinking about a better solution, we should learn from the long time passed without full migration occured, if we will wait till that happens, the division will occur which is not good for the internet, lets welcome new ideas and give it the space, time, and opportunity fairly, if it will be good then welcome, if not, trash is made for this. 
> 
> Get Outlook for Android
> 
> From: ietf <ietf-bounces@ietf.org> on behalf of JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
> Sent: Thursday, February 20, 2020 2:00:58 AM
> To: IETF Rinse Repeat <ietf@ietf.org>
> Subject: Re: ipv4 and ipv6 Coexistence.
>  
> And you're missing several points about how those stats are looked at.
> 
> The % in the stats shown by google/others is only what they can measure, but they can't measure *all*. There are countries (big ones) that don't allow measurements, or at least the same level of details, and however, are doing massive IPv6 deployments.
> 
> All the CDNs and caches have IPv6. The customers that have those caches and enable IPv6 for their subscribers, are getting ranges over 65%, sometimes even up to 85-90% of IPv6 traffic when mainly the subscribers are householders instead of big enterprises.
> 
> Also, the google (and others) measurements, show average worldwide, but if you look to many countries they have even surpassed the 50% or so..
> 
> Regards,
> Jordi
> @jordipalet
>  
>  
> 
> El 20/2/20 5:38, "ietf en nombre de Khaled Omar" <ietf-bounces@ietf.org en nombre de eng.khaled.omar@outlook.com> escribió:
> 
>     Since long time I was observing this, still almost the same, no clear progress occurred.
>     
>     Thanks,
>     
>     Khaled Omar
>     
>     -----Original Message-----
>     From: Scott O. Bradner <sob@sobco.com> 
>     Sent: Wednesday, February 19, 2020 8:11 PM
>     To: Khaled Omar <eng.khaled.omar@outlook.com>
>     Cc: IETF Rinse Repeat <ietf@ietf.org>
>     Subject: Re: ipv4 and ipv6 Coexistence.
>     
>     Quite a few folk are already there - see https://www.google.com/intl/en/ipv6/statistics.html
>     
>     Scott
>     
>     
> 
> 
> 
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company..com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
> 
> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.