Re: [v6ops] sense of draft-vf-v6ops-ipv6-deployment

Gyan Mishra <hayabusagsm@gmail.com> Tue, 30 March 2021 16:23 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F873A19DC for <v6ops@ietfa.amsl.com>; Tue, 30 Mar 2021 09:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 kePCysCw5R63 for <v6ops@ietfa.amsl.com>; Tue, 30 Mar 2021 09:23:25 -0700 (PDT)
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 E8A8B3A18D7 for <v6ops@ietf.org>; Tue, 30 Mar 2021 09:23:24 -0700 (PDT)
Received: by mail-pg1-x531.google.com with SMTP id v186so12080990pgv.7 for <v6ops@ietf.org>; Tue, 30 Mar 2021 09:23:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=72R0mxsTz7WdgSHbyM7dGsc4cILne2KpdhHLA/mJRME=; b=M9rvYH5G71mB8vQWqWUoWIYtYpeSD5kaTxUAzoVbf63fuKo0M24iuiI19DNljuGOc6 Q+3Kn7Fw4svKsw5CQV8WchV9+BuQwBMurFLlFaYOq5OdIedOIvgceA3IIRJpW+1hYIA2 98/M6Rx+DidpIffSIgj6KtGdoQotEHDodalyXPRwYKzKy3UkDXH5SHRyprUTowopPsVT nwxBT3z74hsuDNQQTb0r4bI4k1zu9L0Qc4Ux/BmJggsU3l56CmEmKcgUN3oIOwGm94Is 4SGnm6JslPgCDBp2o1GDieO89bpu5vAx9fT5po1qlocwKwwRN5BDjMooTLTHG1j3OqdM qguw==
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=72R0mxsTz7WdgSHbyM7dGsc4cILne2KpdhHLA/mJRME=; b=KZqg/VfVYkgEd3At7RY3pgY8ZfXwYE+58KQb9Tr/Ije+IOT5RebGe7hca9cHkL+9gf l+krsUIb9pH+XYAccU8nLibLkT4071ijI6i2D468aUwUZMfLgkLuhZ+LNKijL+J06njD +QfU3qewquKw8JqiFeCniBp1mhYj+00fQdDqs9k8e2OJLu1gHixMmXFsiMEQ7MwCG6Hy zNAjJrj4iMJm1db85efN0F/VFgeL5qpwJblhZ/eNXIAQH4CetCGm/B0/mdQjHN0D0v/Y iIhRAnEcLmGLnPSheylpn+zV5rVBEjqImr5SjVkj+XPRfDts6k+8NTtK0Adl5hDejytR zs6w==
X-Gm-Message-State: AOAM532TWDPunwGHSzFlseI41VkAcHwvjLxay2wORFh3n3NFLe5swX6i n7hBAQgUmIZcguu7vFzA06k6MXXXDujgnLNjhcnWN8rSh1sjdA==
X-Google-Smtp-Source: ABdhPJyx+IuOn7gLVyFbc39icfbB1aW6MXiKxXbmemb1FH38/q+lyV7dyo+b/0rCW3+xRnRRq93+v68EkvtN21NbvDw=
X-Received: by 2002:aa7:985d:0:b029:211:9311:79f with SMTP id n29-20020aa7985d0000b02902119311079fmr30899412pfq.20.1617121402377; Tue, 30 Mar 2021 09:23:22 -0700 (PDT)
MIME-Version: 1.0
References: <6fe89c92-a7f1-baf2-6225-7c1bc397c8ee@gmail.com> <7837404c0ba34ef38567a1d74df6381c@huawei.com> <82bbfb68-4489-6987-11fd-954e8e9eccf5@gmail.com> <2EF62E53-DCB6-436D-A240-6969483A98EC@consulintel.es> <caaba643-f99c-b45c-f7fa-b3ad55e79ae5@gmail.com> <95710B27-53CB-4450-9A5D-D1E45C60D62E@consulintel.es> <cfc6d594-7dc8-1747-3598-618c2115cb05@gmail.com> <83A79378-07DD-482F-A6BD-52278D42FA10@consulintel.es> <d6174e54-7bf4-4c24-628d-bbac5f9bcd7d@gmail.com>
In-Reply-To: <d6174e54-7bf4-4c24-628d-bbac5f9bcd7d@gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Tue, 30 Mar 2021 12:22:56 -0400
Message-ID: <CABNhwV1PO=Zo7-eYNkR+0myxO+SM3U3PCmoDqKZdrJjr4ZsU4w@mail.gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: v6ops@ietf.org
Content-Type: multipart/alternative; boundary="000000000000bf582d05bec36a94"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/kQ5x_SRD2G1JF6GwqTbs07ohEZI>
Subject: Re: [v6ops] sense of draft-vf-v6ops-ipv6-deployment
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Mar 2021 16:23:30 -0000

>From a network infrastructure perspective the core and edge both enterprise
and service providers are already on there way and evolving to IPv6 only
especially with the benefits of SRv6 that ball is progressing forward
quickly.

The overlay VPN payload will continue to carry and support both IPv4 and
IPv6 until IPv4 is eliminated from customer network.  The big caveat here
from a network infrastructure perspective is that BGP IPv6 can carry IPv4
NLRI with IPv6 next hop encoding acting as a pure transport, however the
IGP OSPF and ISIS cannot cannot even with OSPFv3 you have to maintain dual
stacking single process with the two address families TLV format versus
fixed format for LSAs and ISIS MT instances separate for each address
family.  So the edge customer infrastructure as it’s not always overlay /
underlay based and in most cases is a underlay only that has to be dual
stacked to carry the IPv4 and IPv6 NLRI.

The edge access location site spokes can definitely go IPv6 only and even
fixed broadband and mobile 4G/5G as well but then would need the transition
mechanism either provide IPv4 access to IPv6 host or mobile endpoints.

This draft provides a list of IPv4 as a service transition solutions for v4
access over IPv6 only infrastructure endpoint devices.

https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-06

>From a host OS perspective, Windows, Apple, Linux, Chromebook popular ones
that sit on IPv6 only networks I would think that the host supporting dual
stack and having all the parameters under “ipconfig /all” for both v4 and
v6 field but just would show the v4 fields as empty, and everything should
work fine.

Even for servers with a static address could just have an IPv6 GUI w/o IPv4
defined and should work fine.

The key here is until all content public internet, extranet and private
intranet all web content and all resources are 100% IPv6 you will have to
provide IPv4 reachability for a long time to come over IPv6 for IPv6 only
endpoints.

I do agree from an OPEX and provisioning standpoint their is much to gain
for operators to go IPv6 only.

The trade off here is now having to maintain for a long time till IPv4
disappears off the face of the earth - maintain the complexity of  IPv6
tunneling transition technologies to provide IPv4 access over IPv6.

Cheers,

Gyan



On Tue, Mar 30, 2021 at 11:40 AM Alexandre Petrescu <
alexandre.petrescu@gmail.com> wrote:

>
>
> Le 30/03/2021 à 17:12, JORDI PALET MARTINEZ a écrit :
> > We can't and must not take out IPv4 in "client OSs" unless you are
> > 100% sure that they will never need to connect to another IPv4
> > "whatever" in the other end of Internet. It will be a bad practice,
> > especially for non-technically aware people using those systems.
>
> Sounds as a balance to be made between who to put on IPv6.
>
> I think the client OSs did already enough on their part to move to IPv6
> but some servers still insist to run on IPv4.
>
> > The relevance is what is the cost and implications for operators. If
> >  they can get rid-off IPv4 in the core, or the access or any other
> > part of the network (or several of them), that has many advantages,
> > and money talks.
>
> Well, on one hand it is good to use as much as possible what is already
> deployed - maximise the cost effectiveness.  Use IPv4 in the core.
>
> But in addition to cost considerations at existing operators there might
> be a new operator around the corner.  Such an incumbent might get
> confused about this 'IPv6-only' term.  That ideal operator wanting to
> deploy from scratch should not bother about 'IPv6-only' terms, not even
> about 'dual-stack'.
>
> 'Dual' is oftentimes understood as an intrication of two things that
> cant be disentagled: wave and particle of light, 0 and 1 in qubits,
> civilian and military uses.  In that sense, a 'dual stack' made of IPv4
> and IPv6 necessitates to continue that way for a long time, maybe
> forever, which is, probably, little desirable.
>
> On another hand, a 'heavy stack' made of an essential IP protocol and a
> superfluous old IPv4 stack could be seen as subject of evolution where
> IPv4 would disappear.
>
> Alex
>
> >
> >
> >
> > El 30/3/21 16:55, "v6ops en nombre de Alexandre Petrescu"
> > <v6ops-bounces@ietf.org en nombre de alexandre.petrescu@gmail.com>
> > escribió:
> >
> >
> >
> > Le 30/03/2021 à 16:38, JORDI PALET MARTINEZ a écrit :
> >> I disagree, it may be different interfaces.
> >
> > This is right.
> >
> >> It may be an IPv6-only VPN on top of a dual stack "physical"
> >> interface, etc., etc.
> >
> > I see.
> >
> >> It is necessary to describe the specific context to be accurate
> >> when we say "IPv6-only".
> >
> > Some times it looks like a never ending story.
> >
> > As it stands now, I wonder why we still speak about IPv6-only when
> > IPv4 is there everywhere anyways.
> >
> > Still, there are FreeBSD computers whose IPv4 stack has been
> > stripped off of the kernel, and Windows machines that turned off IPv4
> > from some interfaces.  But, strangely enough, it is not these
> > computers that we call 'IPv6-only'.
> >
> > What we seem to be calling 'IPv6-only' is the linux-based
> > smartphones whose IPv4 stack is still in them.
> >
> > Alex
> >
> >>
> >> Regards, Jordi @jordipalet
> >>
> >>
> >>
> >> El 30/3/21 14:14, "v6ops en nombre de Alexandre Petrescu"
> >> <v6ops-bounces@ietf.org en nombre de alexandre.petrescu@gmail.com>
> >>  escribió:
> >>
> >>
> >>
> >> Le 30/03/2021 à 13:25, JORDI PALET MARTINEZ a écrit :
> >>> You only need IPv4 support if the other side of the communication
> >>> is IPv4-only.
> >>>
> >>> I read RFC6540, in this context as if the app, protocol,
> >>> service, etc. will work if IPv4 is disabled.
> >>>
> >>> So this is true in all the IPv6-only mechanisms, because
> >>> precisely the idea is to make sure that if at some point there
> >>> are no more "IPv4-only whatever", it will still work.
> >>
> >> We cant talk about IPv6-only and IPv4 at the same time in the same
> >>  computer.
> >>
> >> The point is to make sure that IPv6 works ok without IPv4.
> >>
> >> Alex
> >>
> >>>
> >>> Regards, Jordi @jordipalet
> >>>
> >>>
> >>>
> >>> El 30/3/21 12:08, "v6ops en nombre de Alexandre Petrescu"
> >>> <v6ops-bounces@ietf.org en nombre de
> >>> alexandre.petrescu@gmail.com> escribió:
> >>>
> >>>
> >>>
> >>> Le 30/03/2021 à 09:44, Giuseppe Fioccola a écrit :
> >>>> Hi Alexandre, Yes, the main scope is to describe the global
> >>>> IPv6 deployment and provide an overview on how the transition
> >>>> to IPv6 is progressing, indeed the draft is informational.
> >>>> Anyway, according to the statistics and to the surveys, it can
> >>>>  be possible to make some general considerations and report
> >>>> transition challenges in order to encourage actions in the
> >>>> areas identified (e.g. section "Call for action").
> >>>
> >>> I agree.
> >>>
> >>> However, I have a doubt.  At a point this draft says:
> >>>
> >>> "It is recommended that all networking standards assume the use
> >>> of IPv6 and be written so they do not require IPv4 ([RFC6540])."
> >>>
> >>> Incidentally, I agree with the recommendation, but it is still
> >>> an advice.  If we want to not put an advice then we dont put it,
> >>> end of phrase.
> >>>
> >>> Besides, the paragraph above sounds great, and I agree with it.
> >>> But it refers to RFC6540.  That RFC is great, and is a BCP.
> >>>
> >>> But in detail, it (RFC6540) says this, among other things that
> >>> are ok:
> >>>> To ensure interoperability and flexibility, the best practices
> >>>>  are as follows:
> >>>>
> >>> [...]
> >>>>
> >>>> o  New and updated IP networking implementations should
> >>>> support IPv4 and IPv6 coexistence (dual-stack), but must not
> >>>> require IPv4 for proper and complete function.
> >>>
> >>> This requirement is great, but in practice, 464XLAT needs IPv4
> >>> in order to work.  So the 'must not require IPv4 for proper and
> >>> complete function' is not respected.
> >>>
> >>> A smartphone that is qualified as 'IPv6-only' by many still has
> >>> an IPv4 stack in it and still runs IPv4 software.
> >>>
> >>> That is a problem.
> >>>
> >>> This might represent a basis that - when shaken - goes up to the
> >>>  'it is recommended' of this draft that I mentioned earlier.
> >>>
> >>> Alex
> >>>
> >>>
> >>>
> >>>>
> >>>> Giuseppe
> >>>>
> >>>> -----Original Message----- From: v6ops
> >>>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre
> >>>> Petrescu Sent: Monday, March 29, 2021 6:48 PM To:
> >>>> v6ops@ietf.org Subject: [v6ops] sense of
> >>>> draft-vf-v6ops-ipv6-deployment
> >>>>
> >>>> I wanted to ask whether the sense of the intention of
> >>>> draft-vf-v6ops-ipv6-deployment is:
> >>>>
> >>>> - to describe deployment?
> >>>>
> >>>> - or to give advice about what the deployment should be?
> >>>>
> >>>> For my part, I think it should solely describe deployment.
> >>>>
> >>>> Alex
> >>>>
> >>>> _______________________________________________ v6ops mailing
> >>>> list v6ops@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/v6ops
> >>>>
> >>>
> >>> _______________________________________________ v6ops mailing
> >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
> >>>
> >>>
> >>>
> >>> ********************************************** 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.
> >>>
> >>>
> >>>
> >>> _______________________________________________ v6ops mailing
> >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
> >>>
> >>
> >> _______________________________________________ v6ops mailing list
> >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
> >>
> >>
> >>
> >> ********************************************** 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.
> >>
> >>
> >>
> >> _______________________________________________ v6ops mailing list
> >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
> >>
> >
> > _______________________________________________ v6ops mailing list
> > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
> >
> >
> >
> > ********************************************** 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.
> >
> >
> >
> > _______________________________________________ v6ops mailing list
> > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
> >
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*