Re: ipv4 and ipv6 Coexistence.

Victor Kuarsingh <victor@jvknet.com> Thu, 20 February 2020 03:06 UTC

Return-Path: <victor@jvknet.com>
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 67CB2120133 for <ietf@ietfa.amsl.com>; Wed, 19 Feb 2020 19:06:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jvknet-com.20150623.gappssmtp.com
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 3MOAZlEb9wdR for <ietf@ietfa.amsl.com>; Wed, 19 Feb 2020 19:06:28 -0800 (PST)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E471F1200F5 for <ietf@ietf.org>; Wed, 19 Feb 2020 19:06:27 -0800 (PST)
Received: by mail-wm1-x32d.google.com with SMTP id a9so410249wmj.3 for <ietf@ietf.org>; Wed, 19 Feb 2020 19:06:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RxsYG1rYfJRgQB5wnRldI2bH55wWv2UGz1S3oYRsA8M=; b=ud3nevTPxbxZZJQsfy9YF2lCO815Er0azh7TGz2agy16DC057CZnivaFZVdHwE/nB8 ZhPsqTLYOrg/YKR+a7OoLTwsD+JZkiUdeXw1YkX58CPR5Lfqyh1Mz81fq/ss49EA/fQh EcbwoLzP4na4JpLYDkMDMo+n6Rzg50Rg6lnmgFjrjLBzhY2jkos+kce2i+FDUa5p6yLe 5+fKr9VJ8WXtCAU10qURxeN2kC9eKrWPxhsKGrQ+sqZVMwdXAD2UJRMLyMN26wftJaOX 5bu/k0sAIh0UkEs4irEmBAHEjHJ1U4sjAytRsjH0FT9LceDLRudF2Uj+fCC4irw4ghG0 wLEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RxsYG1rYfJRgQB5wnRldI2bH55wWv2UGz1S3oYRsA8M=; b=rlDSOIuJoFRjwikd9+Wj3bIMFl65AG98rESkw5a+RXFETQd5Jvm2l3HMrzRDVPdEXK niQPP9cxLW3TP+ozr0Z8JAaYT2PfXl0ez6OIGc8yihMqVidgWR8o1O/uHLJ8rWdW8WKi 5ISWu8Y1zwEO/WnoODpfj2QfhflfT+bEJ/ocfUsPDV3mocLGtM+KFrgaS1GPT7q6udIS 4Xoe6EGczscu+kuO6DMI/4zQqdhivsiISlEJxKYTbB72kbKYwXsb6aEghZkD84tGjALj 0yeJZl/zDBlxjahL2KVrMsowVURefPgegXVCWcbsV+dkYjdPGY5vI3fG1pl8J7tHxQW7 snSw==
X-Gm-Message-State: APjAAAVJ518gljJWx6Sz+nZ5dcZM79Shpf7WG10KJWTCyVZEBRVIYdqa ItrIFORUS46eLAJt8eSv1eEZdeBlgqQb7zu1oxHLVg==
X-Google-Smtp-Source: APXvYqxlW9/sCqY5ckfgO7wwkJSUD6mhVo1Ql+JubCjSs2cJcJUbb4jCEcZgwJkNgi2jvIPX/zwDaXucod5GeSpB49c=
X-Received: by 2002:a05:600c:118a:: with SMTP id i10mr1303925wmf.142.1582167986179; Wed, 19 Feb 2020 19:06:26 -0800 (PST)
MIME-Version: 1.0
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> <PR3P194MB0843112CA5B461547C294CE7AE130@PR3P194MB0843.EURP194.PROD.OUTLOOK.COM>
In-Reply-To: <PR3P194MB0843112CA5B461547C294CE7AE130@PR3P194MB0843.EURP194.PROD.OUTLOOK.COM>
From: Victor Kuarsingh <victor@jvknet.com>
Date: Wed, 19 Feb 2020 22:06:14 -0500
Message-ID: <CAJc3aaOHh7QUms0AfFV7g6y7H=zK65G7MBLqFMXvrzuZDGhYVQ@mail.gmail.com>
Subject: Re: ipv4 and ipv6 Coexistence.
To: Khaled Omar <eng.khaled.omar@outlook.com>
Cc: IETF Rinse Repeat <ietf@ietf.org>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000caa3ed059ef93041"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/HI2eVc2x2q3S1HUz8Lcix1BQ5uo>
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 03:06:33 -0000

Khaled,

I am certainly not intending to stop anyone from inventing anything or
working on things.  I am just sharing an opinion based on experience.

We have historical experience that seems to indicate that a
one-size-fits-all approach is difficult for a number of technical and
operational reasons.  The Internet is a highly distributed system where
each network operator gets to decide for themselves what they need and
want.  I am also yet to see any two networks which manifest
identical requirements.  So any attempt to convince everyone to adopt an
all-in-one solution will likely be difficult to apply to all uses cases or
the general use case.

There has been a long list of transition technologies developed, none of
which fit all uses cases which is likely ok.    The largest barrier I see
at this point, which will apply to those slow to adopt IPv6, and have
anyone who has already enabled a transition technology, is cost
(economics).  Any solution which requires people to re-invest money (even
if a new solution is better) will likely be met with opposition given
competing requirements and opportunity cost.

To exemplify, if I was an operator who enabled transition technology X
which operated moderately well.  If presented with the option to enable a
new technology Y, which is definitely better, but would bare significant
deployment time and costs, I would likely not action it since I would be
giving up an opportunity to spend that time and money on other functions.

For those whom have not enabled IPv6 yet, there may be some economic or
other practical reason to overcome to get them to adopt a solution.

regards,

Victor K







On Wed, Feb 19, 2020 at 9:45 PM Khaled Omar <eng.khaled.omar@outlook.com>
wrote:

> What i meant is that if you have nothing to add then don't stop what
> others are trying to do, keep working on what you are trying to do even if
> it didn't work for long time but you believe on it, but as long as our one
> goal is to find a solution then the end result will be good for all ones
> leaving the stoppers aside.
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> ------------------------------
> *From:* Victor Kuarsingh <victor@jvknet.com>
> *Sent:* Thursday, February 20, 2020 4:29:43 AM
> *To:* Mark Andrews <marka@isc.org>
> *Cc:* Khaled Omar <eng.khaled.omar@outlook.com>om>; IETF Rinse Repeat <
> ietf@ietf.org>gt;; JORDI PALET MARTINEZ <jordi.palet=
> 40consulintel.es@dmarc.ietf.org>
> *Subject:* Re: ipv4 and ipv6 Coexistence.
>
>  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
>
>