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

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 Mar 2021 18:47:57 +0200

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

---

From: Giuseppe Fioccola <[email-masked]>
Date: Tue, 30 Mar 2021 07:44:59 +0000

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").

Giuseppe

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Monday, March 29, 2021 6:48 PM
To: [email-masked]
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:

Alex

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 30 Mar 2021 12:07:34 +0200

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:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Monday, March 29, 2021 6:48 PM To: [email-masked] Subject:
> [v6ops] sense of draft-vf-v6ops-ipv6-deployment
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 30 Mar 2021 13:25:24 +0200

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.

Regards,
Jordi
@jordipalet

El 30/3/21 12:08, "v6ops en nombre de Alexandre Petrescu" <[email-masked] en nombre de [email-masked]> escribió:

    I agree.

    [...]

    That is a problem.

    Alex

**********************************************
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.

---

From: Giuseppe Fioccola <[email-masked]>
Date: Tue, 30 Mar 2021 11:55:23 +0000

Hi Alexandre,
Yes, we have to change the wording of that sentence in the next revision. We are referring to RFC6540 that makes recommendations about the use of IPv6.

Regards,

Giuseppe

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Tuesday, March 30, 2021 12:08 PM
To: Giuseppe Fioccola <[email-masked]>; [email-masked]
Subject: Re: [v6ops] sense of draft-vf-v6ops-ipv6-deployment

I agree.

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:
> 
[...]
> 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:[email-masked]] 
> On Behalf Of Alexandre Petrescu

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 30 Mar 2021 14:13:16 +0200

Le 30/03/2021 à 13:25, JORDI PALET MARTINEZ a écrit :
> 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"
> <[email-masked] en nombre de [email-masked]>
> escribió:
> 
> 
> 
>> 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.
> 
> Besides, the paragraph above sounds great, and I agree with it.  But
> it refers to RFC6540.  That RFC is great, and is a BCP.
> 
>> 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
>> 
> ********************************************** 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.
> 
> 
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 30 Mar 2021 16:38:54 +0200

I disagree, it may be different interfaces. It may be an IPv6-only VPN on top of a dual stack "physical" interface, etc., etc.

It is necessary to describe the specific context to be accurate when we say "IPv6-only".

Regards,
Jordi
@jordipalet

El 30/3/21 14:14, "v6ops en nombre de Alexandre Petrescu" <[email-masked] en nombre de [email-masked]> escribió:

    Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 30 Mar 2021 16:54:41 +0200

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 30 Mar 2021 17:12:05 +0200

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.

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.

El 30/3/21 16:55, "v6ops en nombre de Alexandre Petrescu" <[email-masked] en nombre de [email-masked]> escribió:

    This is right.

    I see.

    Alex

---

From: Gabor LENCSE <[email-masked]>
Date: Tue, 30 Mar 2021 17:17:39 +0200

I think, I can understand both of you. :-)

Perhaps the root cause of the difference of your understanding of 
"IPv6-only" is your "word view", I mean that:

Jordi as the first author of RFC 8585 uses the expression "IPv6-only" in 
the meaning of _connectivity_, as used in the terminology of RFC 8585:

    "IPv4aaS" stands for "IPv4-as-a-Service", meaning transition
    technologies for delivering IPv4 in IPv6-only connectivity.

Alex is experimenting with systems that were get rid of IPv4 completely 
by removing or switching off the IPv4 protocol stack, and thus uses the 
term in this sense.

We can decide to use "IPv6-only" for the first one or for the second 
one, but it will be still only our convention. Could we perhaps create 
and use some more precise terms?

Gábor

On 3/30/2021 4:54 PM, Alexandre Petrescu wrote:
> As it stands now, I wonder why we still speak about IPv6-only when 
> IPv4 is there everywhere anyways.
>
>> El 30/3/21 14:14, "v6ops en nombre de Alexandre Petrescu" 
>>      > 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.
>>
>>      >
>>      > Regards, Jordi @jordipalet
>>      >
>>      >
>>      >
>>      > El 30/3/21 12:08, "v6ops en nombre de Alexandre Petrescu"
>>      > <[email-masked] en nombre de 
>> [email-masked]>
>>      > 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:[email-masked]] On Behalf Of Alexandre Petrescu
>>      >> Sent: Monday, March 29, 2021 6:48 PM To: [email-masked] 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
>>      >> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>      >>
>>      >
>>      > _______________________________________________ v6ops mailing 
>> list
>>      > [email-masked] 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
>>      > [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>      >
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 30 Mar 2021 17:38:36 +0200

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" 
> 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
> 
>> 
>>> 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.
>> 
>>> <[email-masked] en nombre de 
>>> [email-masked]> escribió:
>>> 
>>> 
>>> 
>>>> 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.
>>> 
>>> "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.
>>> 
>>>> 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 
>>> 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
>>>> 
>>>> [mailto:[email-masked]] On Behalf Of Alexandre
>>>> Petrescu Sent: Monday, March 29, 2021 6:48 PM To:
>>>> [email-masked] Subject: [v6ops] sense of
>>>> draft-vf-v6ops-ipv6-deployment
>>>> 
>>>> _______________________________________________ v6ops mailing 
>>>> list [email-masked] 
>>> _______________________________________________ v6ops mailing 
>>> list [email-masked] 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
>>> _______________________________________________ v6ops mailing 
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>> 
>> 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.
>> 
>> 
>> 
>  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.
> 
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 30 Mar 2021 17:39:34 +0200

> and use some more precise terms?

I agree and fully support the intention!

Alex

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 30 Mar 2021 12:22:56 -0400

>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

-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 30 Mar 2021 12:50:04 -0400

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 <[email-masked]> 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.
>
> This draft provides a list of IPv4 as a service transition solutions for
> v4 access over IPv6 only infrastructure endpoint devices.
>
> Even for servers with a static address could just have an IPv6 GUI w/o
> IPv4 defined and should work fine.
>

*Gyan Mishra*

*M 301 502-1347*

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Mar 2021 09:24:09 +1300

On 31-Mar-21 04:17, Gabor LENCSE wrote:
> Perhaps the root cause of the difference of your understanding of "IPv6-only" is your "word view", I mean that:
> 
> Jordi as the first author of RFC 8585 uses the expression "IPv6-only" in the meaning of _connectivity_, as used in the terminology of RFC 8585:
> 
> Alex is experimenting with systems that were get rid of IPv4 completely by removing or switching off the IPv4 protocol stack, and thus uses the term in this sense.
> 
> We can decide to use "IPv6-only" for the first one or for the second one, but it will be still only our convention. Could we perhaps create and use some more precise terms?

An "IPv6-only host" seems quite unambiguous to me, as does "IPv6-only CPE". An "IPv6-only ISP" seems like a recipe for bankruptcy, however: the only question for an ISP is *how* to provide dual stack service, surely?

Regards,
    Brian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 31 Mar 2021 09:45:51 +1100

> On 31 Mar 2021, at 07:24, Brian E Carpenter <[email-masked]> wrote:
> 

IPv4aaS can be outsourced.  DS-Lite, 464XLAT, DNS64/NAT64 and I presume others are all amenable to be outsourced.
Eventually IPv6-only ISPs will exist and you will get your IPv4 via a third party.  This is no different to all
those that are getting their IPv6 via HE.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Tue, 30 Mar 2021 16:07:04 -0700

> An "IPv6-only host" seems quite unambiguous to me, as does "IPv6-only CPE". An "IPv6-only ISP" seems like a recipe for bankruptcy, however: the only question for an ISP is *how* to provide dual sta…

Didn’t the speaker from Reliance JIO say, at IETF 109, that most of their services were in fact IPv6-only? The only reason they had for implementing IPv4 at all was certain services that they marketed to enterprises, which appear to be composed of Luddites.

I guess that part of the question is whether the phrase “IPv6-only ISP” says what the ISP implements, or whether it says how they communicate  with neighboring IPv6-incapable networks. I might describe T-Mobile as IPv6-only in the sense that they only implement or manage IPv6; they run 464XLAT (which is to say, translation) when a neighboring ISP is IPv6-incapable, but that is invariably in another network. An IPv6-incapable device in a T-Mobile network is about as communicative as a rock.

No, I don’t think dual stack is the end of the road. It is where we are at the moment.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Mar 2021 14:13:01 +1300

> No, I don’t think dual stack is the end of the road. It is where we are at the moment.

I think this conversation shows that we're *only* talking about terminology. I don't care *how* an ISP connects retail customers to IPv4-only services, or *how* it connects IPv4-only enterprise customers to their users. But it will do so, unless it wants to leave a lot of money on the table.

Believe me, I'd love to see IPv4 down to 1% of total traffic, but I doubt that I will live long enough. Meanwhile, I don't expect AF_INET to vanish from the socket API.

   Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 31 Mar 2021 10:16:42 +0200

I think the point is not if we will keep having 1 or 10 or 30% of IPv4 traffic and how much time.

The relevance is that you can keep offering IPv4 as a Service in such way that the opex for the ISP is marginal or even neglectable (IPv4 peering/transit and routing tables, few IPv4 addresses in the edge of the NAT64 which, as said by Mark can be even outsourced). And then you don't care at all about "how" much IPv4 the customers use.

I recall the history of Telefonica when they wanted to stop offering the service of "old" rotary dial phones. The number of customers was very low compared to the cost of keeping it, that they decided to cancel the contracts. Same as now they are trying to cancel the phone booths.

At some point, more and more ISPs will tell customers: If you want to keep using IPv4, we offer you IPv6-only with IPv4aaS and may be this is an outsourced service so it will take "x" extra ms. End of history. Having IPv4aaS, it doesn't matter if you want to do this when you only have 30% or just 1% of IPv4 traffic: you have the control of the decision, not the amount of traffic.

For some ISPs (those with mainly have cellular or residential customers), this will happen much sooner.

With dual-stack, that's not possible and that means that you are investing in "multiple" transitions to IPv6, or postponing the inevitable final one (which means more opex during more time).

Regards,
Jordi
@jordipalet

El 31/3/21 3:13, "v6ops en nombre de Brian E Carpenter" <[email-masked] en nombre de [email-masked]> escribió:

       Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 31 Mar 2021 10:58:49 +0200

Le 31/03/2021 à 10:16, JORDI PALET MARTINEZ a écrit :
> The relevance is that you can keep offering IPv4 as a Service in such
> way that the opex for the ISP is marginal or even neglectable (IPv4
> peering/transit and routing tables, few IPv4 addresses in the edge of
> the NAT64 which, as said by Mark can be even outsourced). And then
> you don't care at all about "how" much IPv4 the customers use.
> 
> I recall the history of Telefonica when they wanted to stop offering
>  the service of "old" rotary dial phones. The number of customers was
>  very low compared to the cost of keeping it, that they decided to 
> cancel the contracts. Same as now they are trying to cancel the phone
> booths.
> 
> At some point, more and more ISPs will tell customers: If you want to
> keep using IPv4, we offer you IPv6-only with IPv4aaS and may be this
> is an outsourced service so it will take "x" extra ms. End of 
> history. Having IPv4aaS, it doesn't matter if you want to do this 
> when you only have 30% or just 1% of IPv4 traffic: you have the 
> control of the decision, not the amount of traffic.
> 
> For some ISPs (those with mainly have cellular or residential 
> customers), this will happen much sooner.

I agree almost entirely with the argumentation above, it is an
encouraging perspective.

> With dual-stack, that's not possible and that means that you are 
> investing in "multiple" transitions to IPv6, or postponing the 
> inevitable final one (which means more opex during more time).

I disagree to compare the IPv4aaS effort to the 'dual-stack' deployment
effort; this latter effort is at least as laudable.  A 'dual-stack'
deployment leads to more and more websites to become accessible on IPv6.

I will not tell what IPv4aaS means with respect to websites moving
towards becoming accessible on IPv6.

Alex

> El 31/3/21 3:13, "v6ops en nombre de Brian E Carpenter" 
> <[email-masked] en nombre de [email-masked]> 
> escribió:
> 
>>> An "IPv6-only host" seems quite unambiguous to me, as does 
>>> "IPv6-only CPE". An "IPv6-only ISP" seems like a recipe for 
>>> bankruptcy, however: the only question for an ISP is *how* to 
>>> provide dual stack service, surely?
>> 
>> Didn’t the speaker from Reliance JIO say, at IETF 109, that most of
>> their services were in fact IPv6-only? The only reason they had for
>> implementing IPv4 at all was certain services that they marketed to
>> enterprises, which appear to be composed of Luddites.
>> 
>> I guess that part of the question is whether the phrase “IPv6-only
>>  ISP” says what the ISP implements, or whether it says how they 
>> communicate  with neighboring IPv6-incapable networks. I might 
>> describe T-Mobile as IPv6-only in the sense that they only 
>> implement or manage IPv6; they run 464XLAT (which is to say, 
>> translation) when a neighboring ISP is IPv6-incapable, but that is
>>  invariably in another network. An IPv6-incapable device in a 
>> T-Mobile network is about as communicative as a rock.
>> 
> I think this conversation shows that we're *only* talking about 
> terminology. I don't care *how* an ISP connects retail customers to 
> IPv4-only services, or *how* it connects IPv4-only enterprise 
> customers to their users. But it will do so, unless it wants to leave
> a lot of money on the table.
> 
> Believe me, I'd love to see IPv4 down to 1% of total traffic, but I 
> doubt that I will live long enough. Meanwhile, I don't expect AF_INET
> to vanish from the socket API.
> 
> Brian
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 31 Mar 2021 11:12:33 +0200

I'm talking about IPv4aaS for clients, not services.

Anyway, now that you say it, if all the web sites, services, etc., keep "real" dual-stack, you don't encourage ISPs (and users) to move to IPv6.

If you use IPv6-only in the DC, as for example Facebook as been doing for many years, you still can offer "dual-stack" to outside the DC, but IPv6 is 40% faster than IPv4 (time to complete an HTTP get), so your IPv6 "performance" is much better.

This has been measured for years by Facebook and some other CDNs.

And by the way, yes, IPv6-only with IPv4aaS can also be done in datacenters, there are several ways to achieve that. Facebook uses one, SIIT-DC is another one, pure load-balancers can be used as well, etc.

    Alex

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 31 Mar 2021 11:47:33 +0200

Someone asked me in private for a reference on this. I thought it was well-known, but just in case:

https://www.internetsociety.org/blog/2015/04/facebook-news-feeds-load-20-40-faster-over-ipv6

The explanation is simple: IPv6 is end-to-end, while IPv4 will have one NAT at the CPE, one translation at the border of the Facebook DC and possibly another translation at the CGN.

There are multiple articles and presentations about that. Akamai also did similar measurements. Just google for: 40% faster IPv6

Saludos,
Jordi
@jordipalet

El 31/3/21 11:13, "v6ops en nombre de JORDI PALET MARTINEZ" <[email-masked] en nombre de jordi.palet=[email-masked]> escribió:

        Alex