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

[Gyan Mishra <[e-mail]>]

Most operators are leveraging CGN to extend the life of IPv4 instead of
going with IPv4 as a service.


I think the problem here is as CGN works well what is the business driver
for operators to go to IPv4 as a service complexity to provide IPv4 access
over IPv6 is a hard sell.

I think until operators see that we get close to a tipping point of greater
then 50% of the traffic on the internet is IPv6 that they see the light at
the end of the tunnel that they don’t have to maintain the complexity of
IPv4 as a service transitional technology for decades till IPv4 completely
disappears.

Until that happens operators will continue to stay with the mantra “if it’s
not broken don’t try to fix it” and stay with CGN.

This is somewhat of a catch 22 and until operators get on board that the
right thing to do and not take the path of least resistance easy way out
 staying with CGN,  but forge forward with IPv4 as a service, the traffic
volume will struggle to get to that tipping point where operators can see
the light at the end of the tunnel that v4 is on its way out to the
technology graveyard.

Kind Regards

Gyan
On Tue, Mar 30, 2021 at 12:22 PM Gyan Mishra <[e-mail]> wrote:

>
> 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 <
> [e-mail]> 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"
>> > <[e-mail] en nombre de [e-mail]>
>> > 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"
>> >> <[e-mail] en nombre de [e-mail]>
>> >>  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"
>> >>> <[e-mail] en nombre de
>> >>> [e-mail]> 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:[e-mail]] On Behalf Of Alexandre
>> >>>> Petrescu Sent: Monday, March 29, 2021 6:48 PM To:
>> >>>> [e-mail] 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 [e-mail]
>> >>>> https://www.ietf.org/mailman/listinfo/v6ops
>> >>>>
>> >>>
>> >>> _______________________________________________ v6ops mailing
>> >>> list [e-mail] 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 [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>> >>>
>> >>
>> >> _______________________________________________ v6ops mailing list
>> >> [e-mail] 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
>> >> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>> >>
>> >
>> > _______________________________________________ v6ops mailing list
>> > [e-mail] 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
>> > [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>> >
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [e-mail] <[e-mail]>*
>
>
>
> *M 301 502-1347*
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*