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

From: Ron Bonica <[email-masked]>
Date: Mon, 15 Mar 2021 13:48:41 +0000

Folks,

Each week between now and IETF 111, we will review and discuss one draft with an eye towards progressing it.

This week, please review and comment on draft-vf-v6ops-ipv6-deployment.

                                                             Fred and Ron

Juniper Business Use Only

---

From: Fred Baker <[email-masked]>
Date: Wed, 17 Mar 2021 22:21:19 -0700

> On Mar 15, 2021, at 6:48 AM, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> Folks,
> 

Some thoughts on the draft:

  "Looking globally, IPv6 is growing faster than IPv4 and this means
   that the collective wisdom of the networking industry has selected
   IPv6 for the future." Is a run-on sentence (https://www.merriam-webster.com/dictionary/run-on%20sentence)
   It would be more understandable, which is the principal complaint with such sentences, if the "and"
   Were placed with an end-of sentence and start of a new one ("IPv6 is growing faster than IPv4. This means...").

  "Then it is presented the survey among network operators"
   I think the authors intended to say "then it presents a survey of network operators..."

  "It was started an IPv6 poll to more than 50 network operators ..."
  I think the authors meant "more than 50 network operators were polled", or "a poll was started of more than 50 network operators"

  Section 8.1.1 mentions 6to4 (RFC 3068, which we declared historic several years ago and obsoleted in RFC 7526).
  Do we still see significant deployment of this? What are the statistics?

  Section 8.1.2 refers to lmhp-v6ops-transition-comparison. SHOuld this draft be published as an RFC,
  That will be at best a "work in progress". The authors asked for it to be adopted as a working group draft
  and eventually published as an RFC. Would the authors of draft-vf-v6ops-ipv6-deployment like to see that
  happen, so that they can refer to a stable document?

  What I draw out of section 9 is that the logical conclusion for mobile networks is the abandon IPv4 in favor of IPv6.
  We already know of some mobile networks that have done so (464XLAT was developed in that process). If that is a
  General recommendation, it would make sense to say so clearly, and identify the down-sides of doing so.

---

From: Paolo Volpato <[email-masked]>
Date: Fri, 19 Mar 2021 08:39:45 +0000

Hi Fred,
Many thanks for your comments.
We will incorporate your suggestions, in particular those regarding a better usage of English, in the next version of the draft.

About 6to4 as found in section 8.1.1 we will remove the reference. It was there only to mention that technology without intention to further propose it. Based on your comment it is meaningless to leave it there.

For lmhp-v6ops-transition-comparison, on behalf of the authors of draft-vf-v6ops-ipv6-deployment I can say we are in favor of the WG adoption. Not only is it a good description of the transition technologies to IPv6, but it also constitutes a basis for our draft.

We will also review section 9 to add more considerations for both sides of the issue, to further support the adoption of IPv6 in mobile networks but also to provide the down-sides.

BR
Paolo

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 19 Mar 2021 15:18:37 +0530

Hi,

I have read the I-D and found it to be useful in describing the
current status, challenges, and next steps for IPv6 deployments.

Should we add some text on IPv6 in the campus networks at
universities, they have been early adopters in past and some of the
enterprise considerations that apply to them, however,
business/government incentives might be different.

I think we should highlight that we do not have visibility inside the
enterprises beyond the external-facing website or email and thus it is
also difficult to gauge the IPv6 deployments inside enterprises.

Some minor nits -
- Consider updating the boilerplate from RFC 2119 to RFC8174.
- Add a reference for the IAB statement in Section 1.
- Expand RIR, 6rd on first use, you expand it later on!
- Expand SRv6, SDO

Thanks!
Dhruv

On Mon, Mar 15, 2021 at 7:19 PM Ron Bonica
<rbonica=[email-masked]> wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Paolo Volpato <[email-masked]>
Date: Mon, 22 Mar 2021 14:56:01 +0000

Hi Dhruv,

Please see inline our considerations.

Best regards

Paolo

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Friday, March 19, 2021 10:49 AM
To: Ron Bonica <rbonica=[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

Hi,

I have read the I-D and found it to be useful in describing the current status, challenges, and next steps for IPv6 deployments.

Should we add some text on IPv6 in the campus networks at universities, they have been early adopters in past and some of the enterprise considerations that apply to them, however, business/government incentives might be different.

[PV] Good suggestion. Actually, it may give a positive perspective, as you said some of them gained a good experience on early IPv6 adoption.

I think we should highlight that we do not have visibility inside the enterprises beyond the external-facing website or email and thus it is also difficult to gauge the IPv6 deployments inside enterprises.

[PV] Ok. Probably here you refer to small-medium enterprises. For large enterprises public data on the usage of IPv6 can be retrieved (Nalini, in copy, provided a good input on IPv6 in large organizations). We will better specify this point in the next version of the draft.

Some minor nits -

- Expand SRv6, SDO

[PV]. Sure, we will integrate all of your recommendations in the next version.

Thanks!

Dhruv

On Mon, Mar 15, 2021 at 7:19 PM Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>> wrote:

>                                                              Fred and

> Ron

> [email-masked]<mailto:[email-masked]>

v6ops mailing list

[email-masked]<mailto:[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Mar 2021 14:16:23 +1300

Hi,

I haven't had time for a thorough review, but I think this draft is useful and should be developed further. One comment is that I think in some places it is slightly like a sales document, and any tendency of that kind should be avoided. From what I see from time to time in on-line forums such as The Register, many network practitioners remain negative about IPv6 (due to false information in many cases) and they are the likely readers of this draft if it becomes an RFC. They need technical arguments, not sales talk.

I wonder if this draft, or another document, should cover common technical misunderstandings about IPv6 (such as that it would have been so simple to just increase the size of IPv4 addresses, or not to implement automatic address configuration, etc.). These things are not really technical barriers, but they create a learning curve and *mental* barriers. IT managers will deploy IPv6 when their techies tell them it's both easy and necessary.

Regards
   Brian

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 23 Mar 2021 10:09:18 +0530

Hi Paolo,

> [PV] Ok. Probably here you refer to small-medium enterprises. For large enterprises public data on the usage of IPv6 can be retrieved (Nalini, in copy, provided a good input on IPv6 in large organi…

I had this NIST data in mind -
https://fedv6-deployment.antd.nist.gov/cgi-bin/generate-com which
includes large enterprises and relies on DNS, mail, external website.
Also, see Eric's site -
https://www.vyncke.org/ipv6status/detailed.php?country=in

Thanks!
Dhruv

---

From: hsyu <[email-masked]>
Date: Tue, 23 Mar 2021 14:21:10 +0800

Hi Paolo,

I can also provide some data on the deployment of IPv6 in China.

http://218.2.231.237:5001/cgi-bin/generate

Best regards.

Haisheng Yu(Johnson)

[email-masked]

签名由
网易邮箱大师
定制

On 3/23/2021 12:40，Dhruv Dhody<[email-masked]> wrote：

Hi Paolo,

Thanks!
Dhruv

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 23 Mar 2021 10:50:14 +0000 (UTC)

Dhruv & Paolo,
> I think we should highlight that we do not have visibility inside the enterprises beyond the external-facing website or email and >thus it is also difficult to gauge the IPv6 deployments inside enterprises.

Large enterprises will have external connections to the Internet which can be monitored via services which can be accessed publicly such as DNS and web.
They will also generally have very large private networks which cannot be accessed publicly.   These may included connections to business partners and government agencies (Medicare, Social Security, Federal Reserve, IRS, etc).  It is very difficult to tell what is going on inside those networks because they are private.   And these companies are not keen to be forthcoming about their topology.
At our non-profit, Industry Network Technology Council, we did a poll to such large organizations asking about IPv6 implementation inside their org and got about 50 responses.  This is a non-scientific poll and the respondents are self-selecting.  But the result would lead me to think that there is a spectrum.  Some have blocked IPv6 while others are dual-stacking.     
We will continue to pursue.
Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360 

    On Tuesday, March 23, 2021, 12:39:56 AM EDT, Dhruv Dhody <[email-masked]> wrote:  
 
 Hi Paolo,

Thanks!
Dhruv

---

From: Paolo Volpato <[email-masked]>
Date: Tue, 23 Mar 2021 14:40:59 +0000

Dear Brian,
Many thanks for the interest to the draft and your considerations.
We tried to address some of misunderstandings on IPv6 in the section named "Call for action". We consider it still a work in progress and will expand in the next versions taking into consideration both your observations and those collected from the list these days. In the end, removing the misconceptions around IPv6 is one of the targets of the draft.

About the draft having a bit of "sales style", it is good to have this feedback. The comments received so far require that we review some of its parts, so we will try to address them going back to the technical level.

Best regards
Paolo

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Tuesday, March 23, 2021 2:16 AM
To: IPv6 Operations <[email-masked]>
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

Hi,

Regards
   Brian

---

From: Paolo Volpato <[email-masked]>
Date: Tue, 23 Mar 2021 14:56:28 +0000

Looking at the links shared by Dhruv (thanks for that!), the use of IPv6 in the different types of organizations is not uniform at all, varying based on the economy and the type of network.
As Nalini pointed out, more analysis is needed, in particular in the enterprise and government domains.

This is one of the parts of the draft that we will complement with more analytics.
As discussed in another thread, we will also try to counter the misconceptions about IPv6 in those domains.

Best regards
Paolo

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 23, 2021 11:50 AM
To: Paolo Volpato <[email-masked]>; Dhruv Dhody <[email-masked]>
Cc: [email-masked]; Ron Bonica <rbonica=[email-masked]>; Giuseppe Fioccola <[email-masked]>
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

Dhruv & Paolo,

Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com<http://www.insidethestack.com>
(831) 659-8360

On Tuesday, March 23, 2021, 12:39:56 AM EDT, Dhruv Dhody <[email-masked]<mailto:[email-masked]>> wrote:

Hi Paolo,

I had this NIST data in mind -
https://fedv6-deployment.antd.nist.gov/cgi-bin/generate-com <https://fedv6-deployment.antd.nist.gov/cgi-bin/generate-com%20> which
includes large enterprises and relies on DNS, mail, external website.
Also, see Eric's site -
https://www.vyncke.org/ipv6status/detailed.php?country=in

Thanks!
Dhruv

---

From: Paolo Volpato <[email-masked]>
Date: Tue, 23 Mar 2021 16:14:06 +0000

Hi Johnson,

Very useful material, thanks for sharing.
The data about IPv6 in China is very relevant to complement the analysis on the enterprise, education and government domains.
Feel free to contribute with more information for the next versions of the draft.

Best regards
Paolo

From: Haisheng Yu [mailto:[email-masked]]
Sent: Tuesday, March 23, 2021 7:19 AM
To: Paolo Volpato <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

Hi Paolo,

Best regards.

[Image removed by sender.]

Haisheng Yu(Johnson)

[email-masked]

签名由 网易邮箱大师<https://mail.163.com/dashi/dlpro.html?from=mail81> 定制
On 3/23/2021 13:09，Dhruv Dhody<[email-masked]><mailto:[email-masked]> wrote：
Hi Paolo,
I think we should highlight that we do not have visibility inside the enterprises beyond the external-facing website or email and thus it is also difficult to gauge the IPv6 deployments inside enterprises.

Thanks!
Dhruv

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 23 Mar 2021 19:09:50 +0100

Hi,

This is a side note, in the series of checking for IPv6 connectivity.

Le 23/03/2021 à 05:39, Dhruv Dhody a écrit :
> https://fedv6-deployment.antd.nist.gov/cgi-bin/generate-com 

Clicking on this link does not work.  I use a browser on my IPv6-only 
computer (Windows with IPv4 unchecked on the interface Properties).

which
> https://www.vyncke.org/ipv6status/detailed.php?country=in

This link clicks ok.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 23 Mar 2021 19:14:30 +0100

Hi,

Thank you for the link in China about IPv6 deployment.

But I can not see it :-(

When I copy paste that link (http://218.2.231.237:5001/cgi-bin/generate)
in my web browser  it responds that the connection has failed.  I use an
IPv6-only computer (Windows with IPv4 unchecked in the interface
Properties).

Ideally, one would put data about IPv6 on a server that is also capable
of doing IPv6.

Maybe one can put an IPv6 address on the server 218.2.231.237?

Alex

Le 23/03/2021 à 07:21, hsyu a écrit :
> Hi Paolo, I can also provide some data on the deployment of IPv6 in
> China. http://218.2.231.237:5001/cgi-bin/generate
> 
> Best regards.
> 
>  Haisheng Yu(Johnson) [email-masked]
> 
> <https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&name=Haisheng+Yu%28Johnson%29&uid=hsyu%40cfiec.net&iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fsm50a1433bca9fb284d4265d35e9ed54d3.jpg&items=%5B%22%22%2C%22hsyu%40cfiec.net%22%2C%22%22%2C%22%22%2C%22%22%5D>
> 
> 
> 签名由 网易邮箱大师 <https://mail.163.com/dashi/dlpro.html?from=mail81> 定制 On
> 3/23/2021 12:40，Dhruv Dhody<[email-masked]> 
> <mailto:[email-masked]> wrote：
> 
> Hi Paolo,
> 
> enterprises beyond the external-facing website or email and thus it
> is also difficult to gauge the IPv6 deployments inside enterprises.
> 
> [PV] Ok. Probably here you refer to small-medium enterprises. For
> large enterprises public data on the usage of IPv6 can be retrieved
> (Nalini, in copy, provided a good input on IPv6 in large
> organizations). We will better specify this point in the next version
> of the draft.
> 
> 
> includes large enterprises and relies on DNS, mail, external
> website. Also, see Eric's site - 
> Thanks! Dhruv
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: hsyu <[email-masked]>
Date: Wed, 24 Mar 2021 11:14:09 +0800

Dear Paolo and  Alexandre，

Thank you very much for your interest in this website.

This is a test website, and the current data still needs further confirmation. Therefore, I will post it after the data is corrected.

Haisheng Yu(Johnson)

[email-masked]

签名由
网易邮箱大师
定制

On 3/24/2021 02:14，Alexandre Petrescu<[email-masked]> wrote：

Hi,

But I can not see it :-(

Alex

Best regards.

Hi Paolo,

Thanks! Dhruv

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Mar 2021 08:52:06 +0100

Le 24/03/2021 à 04:14, hsyu a écrit :
>          This is a test website, and the current data still needs 
> further confirmation. Therefore, I will post it after the data is corrected.

Hi,

Thank you for the reply.

The data on the website might be correct already.  I can see it on an 
IPv4 connection.

But the access to that data should be on IPv6 too, not only on IPv4.

Ideally, one should add an IPv6 address to the computer's interface. 
Then the URL would be something like
https://[2001:db8:1::1]:5001/cgi-bin/generate
(attention that is an IPv6 address for documentation, do not put that
  particular address on the interface)

Alex

> 签名由 网易邮箱大师 <https://mail.163.com/dashi/dlpro.html?from=mail81> 
> 定制
> On 3/24/2021 02:14，Alexandre Petrescu<[email-masked]> 
> <mailto:[email-masked]> wrote：
> 
>     Hi,
> 
>         签名由 网易邮箱大师
>         <https://mail.163.com/dashi/dlpro.html?from=mail81> 定制 On

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 24 Mar 2021 09:02:07 +0100

It will be much better to use DNS, not literals!

You probably don't see that from an IPv6-only network because it is a literal (if you have NAT64+DNS64 it will work with DNS, if you have 464XLAT it will also work with a literal IPv4).

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

    Hi,

    Thank you for the reply.

    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: Gabor LENCSE <[email-masked]>
Date: Wed, 24 Mar 2021 09:39:06 +0100

Of course, it is better to use DNS, but if you have only an IPv4 literal 
AND you know the NAT64 prefix used in your network, then you can 
synthesize the (RFC 6052) IPv4-embedded IPv6 address manually. :-)

The URL would look like:

https://[64:ff9b::218.2.231.237]:5001/cgi-bin/generate

Hopefully, your ISP uses a Network-Specific Prefix, and not the NAT64 
Well-Known Prefix.

Gábor

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Mar 2021 10:59:28 +0100

:-)

Le 24/03/2021 à 09:39, Gabor LENCSE a écrit :
> Of course, it is better to use DNS,

I agree.

> but if you have only an IPv4 literal AND you know the NAT64 prefix 
> used in your network, then you can synthesize the (RFC 6052) 
> IPv4-embedded IPv6 address manually. :-)

For that to work there is a need to implement some conversion in a 
network box (NAT64?  464XLAT?) _and_ in the client.

> https://[64:ff9b::218.2.231.237]:5001/cgi-bin/generate

thanks for the converted URL.

I clicked on it in my Mail User Agent (MUA) client Thunderbird on an 
IPv6-only PC and it quickly complains about something that might relate 
to security.  It complains about it very quickly, there is no circling 
pointing to wait for response of discoverying some server in the infra, 
or waiting reply from a site.

It says: "The link text indicates 'A' but it leads to 'A'" where A is 
the hex text with ":" everywhere converted from the hex you provided 
above containing 4 dots.  Remark A is the same as A, and the error 
reporting is wrong.  That is a client problem that deserves correction 
(a bug).

But it is a larger client problem too in that clients on PCs dont have 
that support for '64::' addresses.  Smartphones might have that 
support.  I am not sure it is good to consider that lack of 
implementation of "64::" addresses in clients to be a bug.

Alex

PS: for firefox: when I copy paste that URL 
https://[64:ff9b::218.2.231.237]:5001/cgi-bin/generate on my address bar 
of web browser firefox on my IPv6-only PC it tries to connect to 
something, waitslike 10 seconds, and then firefox reports 'The wait 
delay has been reached' (translated) and stops waiting.  Firefox is also 
affected by this problem in protocols.

>> You probably don't see that from an IPv6-only network because it is a 
>> literal (if you have NAT64+DNS64 it will work with DNS, if you have 
>> 464XLAT it will also work with a literal IPv4).
>>
>> El 24/3/21 8:53, "v6ops en nombre de Alexandre Petrescu" 
>> <[email-masked] en nombre de [email-masked]> 
>> escribió:
>>
>>
>>
>>      > Dear Paolo and  Alexandre，
>>      >
>>      > Thank you very much for your interest in this website.
>>      >          This is a test website, and the current data still needs
>>      > further confirmation. Therefore, I will post it after the data 
>> is corrected.
>>
>>      Hi,
>>
>>      Thank you for the reply.
>>
>>      >
>>      >
>>      > Haisheng Yu(Johnson)
>>      > [email-masked]
>>      >
>>      > 
>>      >
>>      > 签名由 网易邮箱大师 
>> <https://mail.163.com/dashi/dlpro.html?from=mail81>
>>      > 定制
>>      > On 3/24/2021 02:14，Alexandre 
>> Petrescu<[email-masked]>
>>      > <mailto:[email-masked]> wrote：
>>      >
>>      >     Hi,
>>      >
>>      >     Thank you for the link in China about IPv6 deployment.
>>      >
>>      >     But I can not see it :-(
>>      >
>>      >     When I copy paste that link 
>> (http://218.2.231.237:5001/cgi-bin/generate)
>>      >     in my web browser  it responds that the connection has 
>> failed.  I use an
>>      >     IPv6-only computer (Windows with IPv4 unchecked in the 
>> interface
>>      >     Properties).
>>      >
>>      >     Ideally, one would put data about IPv6 on a server that is 
>> also capable
>>      >     of doing IPv6.
>>      >
>>      >     Maybe one can put an IPv6 address on the server 
>> 218.2.231.237?
>>      >
>>      >     Alex
>>      >
>>      >
>>      >     Le 23/03/2021 à 07:21, hsyu a écrit :
>>      >
>>      >         Hi Paolo, I can also provide some data on the 
>> deployment of IPv6 in
>>      >         China. http://218.2.231.237:5001/cgi-bin/generate
>>      >
>>      >         Best regards.
>>      >
>>      >         Haisheng Yu(Johnson) [email-masked]
>>      >
>>      > 
>>      >
>>      >
>>      >         签名由 网易邮箱大师
>>      > <https://mail.163.com/dashi/dlpro.html?from=mail81> 定制 On
>>      >         3/23/2021 12:40，Dhruv Dhody<[email-masked]>
>>      > <mailto:[email-masked]> wrote：
>>      >
>>      >         Hi Paolo,
>>      >
>>      >         I think we should highlight that we do not have 
>> visibility
>>      >         inside the
>>      >         enterprises beyond the external-facing website or 
>> email and thus it
>>      >         is also difficult to gauge the IPv6 deployments inside 
>> enterprises.
>>      >
>>      >         [PV] Ok. Probably here you refer to small-medium 
>> enterprises. For
>>      >         large enterprises public data on the usage of IPv6 can 
>> be retrieved
>>      >         (Nalini, in copy, provided a good input on IPv6 in large
>>      >         organizations). We will better specify this point in 
>> the next
>>      >         version
>>      >         of the draft.
>>      >
>>      >
>>      >         I had this NIST data in mind -
>>      > https://fedv6-deployment.antd.nist.gov/cgi-bin/generate-com which
>>      >         includes large enterprises and relies on DNS, mail, 
>> external
>>      >         website. Also, see Eric's site -
>>      > https://www.vyncke.org/ipv6status/detailed.php?country=in
>>      >
>>      >         Thanks! Dhruv
>>      >
>>      > _______________________________________________ v6ops mailing 
>> list
>>      > [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>      >
>>      >
>>      > _______________________________________________ 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.
>>
>>
>>

---

From: Gabor LENCSE <[email-masked]>
Date: Wed, 24 Mar 2021 13:11:52 +0100

Dear Alex,

I meant that you need to do the address synthesis manually. I intended 
the 64:ff9b::/96 WKP only as an example.

First, you need to find out the NAT64 prefix used by your ISP. (RFC 7050 
describes the process.)

Then, you can synthesize and use the proper IPv4-Embedded IPv6 Address. 
(I hope that the IPv6 routing will find the NAT64 gateway based on the 
NAT64 prefix.)

Of course, it is just a hack, DNS64 makes our life easier, if the IPv4 
only server is registered in the DNS system. And, naturally, the real 
solution is that the server should have an IPv6 address. :-)

Best regards,

Gábor

On 3/24/2021 10:59 AM, Alexandre Petrescu wrote:
> IPv6-only PC and it quickly complains about something that might 
> relate to security.  It complains about it very quickly, there is no 
> circling pointing to wait for response of discoverying some server in 
> the infra, or waiting reply from a site.
>
> https://[64:ff9b::218.2.231.237]:5001/cgi-bin/generate on my address 
> bar of web browser firefox on my IPv6-only PC it tries to connect to 
> delay has been reached' (translated) and stops waiting.  Firefox is 
> also affected by this problem in protocols.
>
>
>>
>>> You probably don't see that from an IPv6-only network because it is 
>>> a literal (if you have NAT64+DNS64 it will work with DNS, if you 
>>> have 464XLAT it will also work with a literal IPv4).
>>>
>>>      > further confirmation. Therefore, I will post it after the 
>>> data is corrected.
>>>
>>>      Hi,
>>>
>>>      Thank you for the reply.
>>>
>>>      >     Ideally, one would put data about IPv6 on a server that 
>>> is also capable
>>>      >     of doing IPv6.
>>>      >
>>>      >         is also difficult to gauge the IPv6 deployments 
>>> inside enterprises.
>>>      >
>>>      >         large enterprises public data on the usage of IPv6 
>>> can be retrieved
>>> 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: Wed, 24 Mar 2021 15:32:08 +0100

Hi, Gabor,

Thanks for the reply.  Allow me to continue this discussion.

Le 24/03/2021 à 13:11, Gabor LENCSE a écrit :
> Dear Alex,
> 
> I meant that you need to do the address synthesis manually. I 
> intended the 64:ff9b::/96 WKP only as an example.

As a side note,  I think that 64:ff9b::/96 prefix might need a 32bit
IID, which is probably forbidden by the IPv6 Addressing Architecture RFC
4291 ("For all unicast addresses, except those that start with the
binary value 000, Interface IDs are required to be 64 bits long").

This is not to say that I disagree with the 64:: prefix, but maybe point
to what appears to me to be a slight incoherency.

> First, you need to find out the NAT64 prefix used by your ISP. (RFC 
> 7050 describes the process.)

I wanted to ask: do you mean the NAT64 prefix that my ISP uses, or the
ISP that the data provider (the URL in question) uses?

I am saying this because I think my ISP does not provide NAT64 service
to home.  It is probably an optional feature.

> Then, you can synthesize and use the proper IPv4-Embedded IPv6 
> Address. (I hope that the IPv6 routing will find the NAT64 gateway 
> based on the NAT64 prefix.)
> 
> Of course, it is just a hack, DNS64 makes our life easier, if the 
> IPv4 only server is registered in the DNS system. And, naturally,
> the real solution is that the server should have an IPv6 address.
> :-)

Yes, I agree with it too.

Alex

>>> but if you have only an IPv4 literal AND you know the NAT64 
>>> prefix used in your network, then you can synthesize the (RFC 
>>> 6052) IPv4-embedded IPv6 address manually. :-)
>> 
>> 
>> I clicked on it in my Mail User Agent (MUA) client Thunderbird on 
>> an IPv6-only PC and it quickly complains about something that
>> might relate to security.  It complains about it very quickly,
>> there is no circling pointing to wait for response of discoverying
>> some server in the infra, or waiting reply from a site.
>> 
>> It says: "The link text indicates 'A' but it leads to 'A'" where A 
>> is the hex text with ":" everywhere converted from the hex you 
>> provided above containing 4 dots.  Remark A is the same as A, and 
>> the error reporting is wrong.  That is a client problem that 
>> deserves correction (a bug).
>> 
>> But it is a larger client problem too in that clients on PCs dont 
>> have that support for '64::' addresses.  Smartphones might have 
>> that support.  I am not sure it is good to consider that lack of 
>> https://[64:ff9b::218.2.231.237]:5001/cgi-bin/generate on my 
>> address bar of web browser firefox on my IPv6-only PC it tries to 
>> connect to something, waitslike 10 seconds, and then firefox 
>> reports 'The wait delay has been reached' (translated) and stops 
>> waiting.  Firefox is also affected by this problem in protocols.
>> 
>> 
>>> 
>>> Hopefully, your ISP uses a Network-Specific Prefix, and not the 
>>> NAT64 Well-Known Prefix.
>>> 
>>> Gábor
>>> 
>>>> You probably don't see that from an IPv6-only network because 
>>>> it is a literal (if you have NAT64+DNS64 it will work with
>>>> DNS, if you have 464XLAT it will also work with a literal
>>>> IPv4).
>>>> 
>>>> <[email-masked] en nombre de 
>>>> [email-masked]> escribió:
>>>> 
>>>> 
>>>> 
>>>>> Thank you very much for your interest in this website. This 
>>>>> is a test website, and the current data still
>>>> needs
>>>> The data on the website might be correct already.  I can see
>>>> it on an IPv4 connection.
>>>> 
>>>> Ideally, one should add an IPv6 address to the computer's 
>>>> interface. Then the URL would be something like 
>>>> https://[2001:db8:1::1]:5001/cgi-bin/generate (attention that 
>>>> is an IPv6 address for documentation, do not put that 
>>>>> 定制 On 3/24/2021 02:14，Alexandre
>>>>> When I copy paste that link
>>>>> 签名由 网易邮箱大师 <https://mail.163.com/dashi 
>>>>> /dlpro.html?from=mail81> 定制 On 3/23/2021 12:40，Dhruv 
>>>>> Dhody<[email-masked]> <mailto:[email-masked]> 
>>>>> wrote：
>>>>> 
>>>>> Hi Paolo,
>>>>> 
>>>>> I think we should highlight that we do not have
>>>> visibility
>>>>> inside the enterprises beyond the external-facing website or
>>>>> 
>>>> email and thus it
>>>>> organizations). We will better specify this point in
>>>> the next
>>>>> version of the draft.
>>>>> 
>>>>> 
>>>>> _______________________________________________ v6ops
>>>>> mailing
>>>>> 
>>>> list
>>>>> _______________________________________________ v6ops
>>>>> mailing
>>>>> 
>>>> list
>>>> _______________________________________________ v6ops mailing 
>>>> list [email-masked] 
>>>> ********************************************** IPv4 is over
>>>> 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] 
>>> _______________________________________________ v6ops mailing 
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>

---

From: Gert Doering <[email-masked]>
Date: Wed, 24 Mar 2021 15:36:37 +0100

HI,

> binary value 000, Interface IDs are required to be 64 bits long").

64:: does start with 000

And it has no IID at all, not "/32".

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Mar 2021 15:44:29 +0100

>> binary value 000, Interface IDs are required to be 64 bits long").

ah sorry, I missed again something in my calculator - that's my 
expertise :-)

0000 0000 0110 0100 is indeed 64::

But it is not my fault.

I have a big problem in talking about addresses that start with 000 
binary because there are so many ways to express these addresses in an 
IPv6 literal format.  Also the 1000::/3 start with 000, also 1FFF::/3 
start with 000, also 64::/96 start with 000.

Because of that problem of talking about addresses, and because of the 
000 exception, it is difficult to talk about IPv6 64bit boundaries.

This problem is not apparent only when talking about 64bit boundaries, 
but also when talking about ULAs FC an FD.

> And it has no IID at all, not "/32".

An address with no IID at all?

Bon, ok...

Alex

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 24 Mar 2021 15:48:12 +0100

I think you need to read the NAT64 and related RFCs ...

If your ISP doesn't offer the NAT64, then it is really bad to use IPv6-only in your network. I may understand that you do that as an experiment, but then you can setup your own NAT64, it is really simple in any Linux or even an OpenWRT CPE.

You may also setup a DNS64 and I will suggest also to setup a CLAT, all that can be done via VMs, even a single VM in your own network.

Regards,
Jordi
@jordipalet

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

    Hi, Gabor,

    Alex

---

From: Gert Doering <[email-masked]>
Date: Wed, 24 Mar 2021 15:49:24 +0100

Hi,

> start with 000, also 64::/96 start with 000.

There is an RFC that clearly states how addresses SHOULD be written,
and with a bit of experience, it is also clear that 0000 ... 01FF is
"FP 000", while 2000: to 3fff: is "FP 001" (which is currently the only
one governed by the RIR system).

> 000 exception, it is difficult to talk about IPv6 64bit boundaries.

Uh... no?

[..]
> An address with no IID at all?

Generally speaking, NAT64 is a packet translation rule.  So it has no
"interface" at all.  Even if it has one, because that's easier for
implementations to configure and present, it won't have an IID, because
the translator does not need an address in the /96.

Gert Doering
        -- NetMaster

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 24 Mar 2021 15:08:19 +0000

Hi Jordi,
But NAT64 should have one interface in IPv4. That is not possible on the "single VM in your own network" if your network is IPv6 only.
You have to pay some cloud provider for this VM together with public IPv4.
It is not expensive (like 5$ per month), but it is probably too much hassle for the majority of users.

I do not believe that there is any provider with IPv6-only, but without NAT64. They would lose too many users as a result of such policy.
Hence it is better to search for proper prefix in particular IPv6-only network.
Eduard
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: Wednesday, March 24, 2021 5:48 PM
To: [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

Regards,
Jordi
@jordipalet

    Hi, Gabor,

    Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Mar 2021 16:09:56 +0100

Hi, Gert,

I do not disagree with you :-)

But there are a few points that I could say without worrying of not 
saying the ultra-corect things.

> one governed by the RIR system).

'FP' is new to me.

> the translator does not need an address in the /96.

I can understand that a translation rule might have just a prefix and a 
plen as keys.

But it is also true that the C representation of that rule most 
certainly uses 128bit structs and hence IIDs.

An http URL containing a 64:: address to paste in an address bar is 
almost certain to have an IID.

That IID-less address might not be attached to an interface, but at that 
point one might wonder what is the meaning of this quote from RFC4291 
"IPv6 addresses are 128-bit identifiers for interfaces and sets of 
interfaces (where "interface" is as defined in Section 2 of [IPV6])."

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Mar 2021 16:12:24 +0100

Le 24/03/2021 à 15:48, JORDI PALET MARTINEZ a écrit :
> If your ISP doesn't offer the NAT64, then it is really bad to use 
> IPv6-only in your network.

?

No no, I live well in the IPv6 world without NAT64... I dont understand
why NAT64 is so required?

> I may understand that you do that as an experiment, but then you can
> setup your own NAT64, it is really simple in any Linux or even an
> OpenWRT CPE.

I dont want to set up new boxes at home.  It is indeed possible, but at 
this time I do not want.

> You may also setup a DNS64 and I will suggest also to setup a CLAT, 
> all that can be done via VMs, even a single VM in your own network.

YEs, that is possible too.

But can I do without it please?

Does IPv6 mandate the use of DNS64 and NAT64?

Alex

> 
> Regards, Jordi @jordipalet
> 
> 
> 
> El 24/3/21 15:33, "v6ops en nombre de Alexandre Petrescu" 
>  IID, which is probably forbidden by the IPv6 Addressing
> Architecture RFC 4291 ("For all unicast addresses, except those that
> start with the binary value 000, Interface IDs are required to be 64
> bits long").
> 
> This is not to say that I disagree with the 64:: prefix, but maybe 
> point to what appears to me to be a slight incoherency.
> 
> I wanted to ask: do you mean the NAT64 prefix that my ISP uses, or 
> the ISP that the data provider (the URL in question) uses?
> 
> I am saying this because I think my ISP does not provide NAT64 
> service to home.  It is probably an optional feature.
> 
>>> For that to work there is a need to implement some conversion in 
>>> a network box (NAT64?  464XLAT?) _and_ in the client.
>>> 
>>> 
>>>> 
>>>> The URL would look like:
>>>> 
>>> there is no circling pointing to wait for response of 
>>> discoverying some server in the infra, or waiting reply from a 
>>> site.
>>> 
>>> It says: "The link text indicates 'A' but it leads to 'A'" where 
>>> A is the hex text with ":" everywhere converted from the hex you
>>>  provided above containing 4 dots.  Remark A is the same as A, 
>>> and the error reporting is wrong.  That is a client problem that
>>>>> 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
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 24 Mar 2021 16:13:12 +0100

Yes, but I'm guessing that Alex is doing an "experiment" and the ISP actually provides him dual-stack. I think he mention already Free in a previous email.

Regards,
Jordi
@jordipalet

El 24/3/21 16:09, "v6ops en nombre de Vasilenko Eduard" <[email-masked] en nombre de [email-masked]> escribió:

    Hi Jordi,

    -----Original Message-----
    From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
    Sent: Wednesday, March 24, 2021 5:48 PM
    To: [email-masked]
    Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

    Regards,
    Jordi
    @jordipalet

        Hi, Gabor,

        Alex

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 24 Mar 2021 16:14:46 +0100

If you want to be able to connect to IPv4-only services in Internet, you really need 464XLAT. NAT64+DNS64 will break for you with any app using literals, etc.

Regards,
Jordi
@jordipalet

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

    ?

    Alex

---

From: Gabor LENCSE <[email-masked]>
Date: Wed, 24 Mar 2021 16:59:28 +0100

Dear Alex,

On 3/24/2021 4:12 PM, Alexandre Petrescu wrote:
[...]
> Does IPv6 mandate the use of DNS64 and NAT64?

Of course, not. :)

There are several IPv4 as a Services solutions exist. We have covered 
the five most prominent ones 464XLAT, DS-Lite, MAP-E, MAP-T and lw4o6 in 
our I-D: 
https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-06

Your ISP is likely using one of them.

Best regards,

Gábor

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Mar 2021 17:03:59 +0100

Le 24/03/2021 à 16:14, JORDI PALET MARTINEZ a écrit :
> If you want to be able to connect to IPv4-only services in Internet,
>  you really need 464XLAT. NAT64+DNS64 will break for you with any app
>  using literals, etc.

I can agree.

Basically the experiment is: whenever someone invites me to click on
some link, and if I have enough time, I first turn off IPv4 and then I
click.

In the future Internet there would be no IPv4 to try, no DNSv4, no
NAT64, etc.  The future Internet of a sort.

Since I started these experiments a few years ago, as time goes by, more
and more URLs work ok on IPv6 and browsed from IPv6-only computers.

There are still some important issues with security and IPv6 at sites
that are known to be good for IPv6 (e.g. Google is known to be good with
IPv6, but some security checking comes to mind; and it is not the only
one, Cloud logins also comes to mind as not working ok on IPv6 even
though their dataspace is ok on IPv6).

There are other issues as well.  I am not trying only the HTTPS URLs but
also other new services that appear very often, or the old mail servers
like smtp.gmail.com STARTTLS.

There are many things to be learned about IPv6 deployment during all
these experiments of turning off IPv4.

Alex

> El 24/3/21 16:13, "v6ops en nombre de Alexandre Petrescu" 
> No no, I live well in the IPv6 world without NAT64... I dont 
> understand why NAT64 is so required?
> 
>> I may understand that you do that as an experiment, but then you 
>> can setup your own NAT64, it is really simple in any Linux or even
>>  an OpenWRT CPE.
> 
> I dont want to set up new boxes at home.  It is indeed possible, but
>  at this time I do not want.
> 
>> You may also setup a DNS64 and I will suggest also to setup a
>> CLAT, all that can be done via VMs, even a single VM in your own 
>> network.
> 
>> As a side note,  I think that 64:ff9b::/96 prefix might need a 
>> 32bit IID, which is probably forbidden by the IPv6 Addressing 
>> Architecture RFC 4291 ("For all unicast addresses, except those 
>> that start with the binary value 000, Interface IDs are required to
>> be 64 bits long").
>> 
>>> First, you need to find out the NAT64 prefix used by your ISP. 
>>> (RFC 7050 describes the process.)
>> 
>>> Address. (I hope that the IPv6 routing will find the NAT64 
>>> gateway based on the NAT64 prefix.)
>>> 
>>> Of course, it is just a hack, DNS64 makes our life easier, if
>>> the IPv4 only server is registered in the DNS system. And,
>>> naturally, the real solution is that the server should have an
>>> IPv6 address. :-)
>> 
>>>>> prefix used in your network, then you can synthesize the
>>>>> (RFC 6052) IPv4-embedded IPv6 address manually. :-)
>>>> 
>>>> 
>>>> For that to work there is a need to implement some conversion 
>>>> in a network box (NAT64?  464XLAT?) _and_ in the client.
>>>> 
>>>> 
>>>>> 
>>>>> The URL would look like:
>>>>> 
>>>> I clicked on it in my Mail User Agent (MUA) client Thunderbird
>>>>  on an IPv6-only PC and it quickly complains about something 
>>>> that might relate to security.  It complains about it very 
>>>> quickly, there is no circling pointing to wait for response of 
>>>> It says: "The link text indicates 'A' but it leads to 'A'" 
>>>> where A is the hex text with ":" everywhere converted from the
>>>>  hex you provided above containing 4 dots.  Remark A is the
>>>> same as A, and the error reporting is wrong.  That is a client
>>>>  problem that deserves correction (a bug).
>>>> 
>>>> But it is a larger client problem too in that clients on PCs 
>>>> dont have that support for '64::' addresses.  Smartphones might
>>>> have that support.  I am not sure it is good to consider that
>>>> lack of implementation of "64::" addresses in clients to be a
>>>> bug.
>>>> 
>>>> 
>>>> Alex
>>>> 
>>>> address bar of web browser firefox on my IPv6-only PC it tries
>>>>  to connect to something, waitslike 10 seconds, and then
>>>> firefox reports 'The wait delay has been reached' (translated)
>>>> and stops waiting.  Firefox is also affected by this problem
>>>> in protocols.
>>>> 
>>>> 
>>>>> 
>>>>> Hopefully, your ISP uses a Network-Specific Prefix, and not 
>>>>> the NAT64 Well-Known Prefix.
>>>>> 
>>>>> Gábor
>>>>> 
>>>>>> You probably don't see that from an IPv6-only network 
>>>>>> because it is a literal (if you have NAT64+DNS64 it will 
>>>>>> work with DNS, if you have 464XLAT it will also work with a
>>>>>> literal IPv4).
>>>>>> 
>>>>>>> further confirmation. Therefore, I will post it after 
>>>>>>> the
>>>>>> data is corrected.
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Thank you for the reply.
>>>>>> 
>>>>>> The data on the website might be correct already.  I can 
>>>>>> see it on an IPv4 connection.
>>>>>> 
>>>>>> https://[2001:db8:1::1]:5001/cgi-bin/generate (attention 
>>>>>> that is an IPv6 address for documentation, do not put that 
>>>>>>> Dhody<[email-masked]>
>>>>>> mailing list [email-masked] 
>>>>>> ********************************************** IPv4 is
>>>>>> over Are you ready for the new Internet ? 
>>>>>> 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,
>>>>>> 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
>>>>>> mailing list [email-masked] 
>>>>> mailing list [email-masked] 
>> ********************************************** IPv4 is over Are
>> you ready for the new Internet ? http://www.theipv6company.com The
>> IPv6 Company
>> 
>> 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: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Mar 2021 17:22:59 +0100

Le 24/03/2021 à 16:59, Gabor LENCSE a écrit :
> Dear Alex,
> 
> On 3/24/2021 4:12 PM, Alexandre Petrescu wrote: [...]

So I agree with you about that.

> There are several IPv4 as a Services solutions exist. We have
> covered the five most prominent ones 464XLAT, DS-Lite, MAP-E, MAP-T
> and lw4o6 in our I-D: 

For clarification - my ISP is called 'Free' (it has freedom features).

They offer me paid IPv4 and IPv6 native access at home on ADSL.  It's
one publicly routable IPv4 address and an IPv6 /56 prefix globally
routable prefix (a 'GUP' if I can say so, not a GUA'(ddress)).

Up to now, looking through the configuration interface of my freebox at
home I could not see the options that you mention (464XLAT, DSLITE,
MAP-E, MAP-T, lw4o6).  One might say that they are there invisible, but
I doubt that, I need a proof of it.  How can I check for presence of 
options 464XLAT, DSLITE, MAP-E, MAP-T or lw4o6?

The problems that appear when I try to browse IPv6 sites that absolutely
need IPv4 might be because I turned off the IPv4 stack on my computer's
interface (Windows Properties on the Interface, check off IPv4).  This
operation (turning off IPv4 in a computer) is possible only on Windows,
not on linux, AFAIR.  One cant do 'rmmod ipv4' in linux.

That also explains the fact that installing IPv4-IPv6 translation boxes
(NAT64, 464LAT, etc.) in a network is not sufficient to access IPv4
sites from an IPv6-only computer.

In order to access IPv4 sites from IPv6-only computers one also needs
the IPv4 stack to work ok on that computer and, moreover, it needs some
times software features in the Client that support the 64:: notation of
IPv6 addresses.  For example, thunderbird (a very modern MUA) does not
understand it and gets confused by it.  It takes it for an fqdn, and
does not even try to connect the translation boxes.

This means that if one wants to migrate more to IPv6 then one has to
think about the NAT64 and 464XLAT concepts more outside of the cellular
network concept.

And yes, I agree with you, NAT64 and 464XLAT are good tools to
migrate.  In particular, if one is on a smartphone or other computer
using an OS that cant turn off their IPv4 stacks.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Mar 2021 18:11:21 +0100

To be more concrete.

There are two IPv6 logos at the bottom of that page: "IPv6 Forum" and 
"IPv6 validated by ipv6-test.com".

However, my IPv6 experiments from an IPv6--only computer does not see 
the page:

http://218.2.231.237:5001/cgi-bin/generate
https://[64:ff9b::da02:e7ed]:5001/cgi-bin/generate

So maybe there is a need need to update the criteria of the IPv6 Forum 
and of the ipv6-test.com.  Or update that web page simply to remove the 
two logos.

Furthermore, browsing the ipv6-test.com website from an IPv6-only 
computer is strange too.  If one tries to browse it from an IPv6-only 
computer, then one can see what I mean.  It says I have a score of 10 
out of 20, and recommends to install IPv4 to reach a higher score of 20.

That is a very strange recommendation in my oppinion.

On the contrary, if one would like IPv6 to succeed more quiuckly, then 
one would construct a website ipv6-test.com which recommends to turn off 
IPv4.

But I would not qualify these days an IPv6-only computer to be a score 
10/20.  It's really not possible.

Alex

Le 24/03/2021 à 17:03, Alexandre Petrescu a écrit :
>>> setup your own NAT64, it is really simple in any Linux or even
>>>  an OpenWRT CPE.
>>
>>> IID, which is probably forbidden by the IPv6 Addressing Architecture 
>>> RFC 4291 ("For all unicast addresses, except those that start with 
>>> the binary value 000, Interface IDs are required to
>>> be 64 bits long").
>>>
>>>>>> used in your network, then you can synthesize the
>>>>>  on an IPv6-only PC and it quickly complains about something that 
>>>>> is the hex text with ":" everywhere converted from the
>>>>> have that support for '64::' addresses.  Smartphones might
>>>>>>> You probably don't see that from an IPv6-only network because it 
>>>>>>> is a literal (if you have NAT64+DNS64 it will work with DNS, if 
>>>>>>> you have 464XLAT it will also work with a
>>>>>>> literal IPv4).
>>>>>>>
>>>>>>>> Thank you very much for your interest in this website. This is a 
>>>>>>>> test website, and the current data still
>>>>>>> needs
>>>>>>> The data on the website might be correct already.  I can see it 
>>>>>>> on an IPv4 connection.
>>>>>>>
>>>>>>> https://[2001:db8:1::1]:5001/cgi-bin/generate (attention that is 
>>>>>>> an IPv6 address for documentation, do not put that particular 
>>>>>>> address on the interface)
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>>
>>>>>>>>
>>> authorized disclosure, copying, distribution or use
>>> 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.
>>>
>>>
>>>
>> authorized disclosure, copying, distribution or use of the contents of 
>> this information, even if partially, including attached files, is

---

From: Martin Hunek <[email-masked]>
Date: Wed, 24 Mar 2021 19:08:50 +0100

Dear Alex,

Just comment about turning off IPv4 in Linux:

It is possible to turn it off, at least if you are using NetworkManager you can change settings on IPv4 tab from "Automatic" to "Disabled". Then there will be no annoying IPv4 lying on your interface. :-)

If you are not using NM, you can always do "ip addr del <IPv4> dev <device>" and not to run DHCPv4 daemon.

Good luck with fight against IPv4,
Martin

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Mar 2021 19:20:54 +0100

Hi,

I do not fight against IPv4, but to progress to IPv6 one might be
better at getting IPv4 off.

Otherwise there might be complaints not only about IPv6 being too long
addresses, but IPv4 and IPv6 together to be a too big thing too.

Le 24/03/2021 à 19:08, Martin Hunek a écrit :
> It is possible to turn it off, at least if you are using 
> NetworkManager you can change settings on IPv4 tab from "Automatic" 
> to "Disabled". Then there will be no annoying IPv4 lying on your 
> interface. :-)

But, if I do that, the linux apps would still form IPv4 LL addresses on
the interface, no?

There would still be an IPv4 address in /etc/resolv.conf, so a
temptation to contact an IPv4 resolver.

On Windows, turning off IPv4 in Properties would disable IPv4 LL (link
local) addresses as well.

There is also a 'Remove IPv4' possibility in Windows, but that I never
dared.

> <device>" and not to run DHCPv4 daemon.

For DHCPv4 I understand.

But some other apps attach an IPv4 address to the interface, not DHCPv4.

So it would mean I have to be very fast at typing an 'ip addr del IPv4
address' each time I start an app.  It's very difficult.

I heard about 'clatd' for example.  Does clatd attach an IPv4 address on
an interface?  Or add an IPv4 conversion rule in a table?

Alex

> 
> Good luck with fight against IPv4, Martin Dne středa 24. března 2021 
> 17:22:59 CET, Alexandre Petrescu napsal(a):
>> 
>>> covered the five most prominent ones 464XLAT, DS-Lite, MAP-E, 
>>> MAP-T and lw4o6 in our I-D: 
>> They offer me paid IPv4 and IPv6 native access at home on ADSL. 
>> It's one publicly routable IPv4 address and an IPv6 /56 prefix 
>> globally routable prefix (a 'GUP' if I can say so, not a 
>> GUA'(ddress)).
>> 
>> Up to now, looking through the configuration interface of my 
>> freebox at home I could not see the options that you mention 
>> (464XLAT, DSLITE, MAP-E, MAP-T, lw4o6).  One might say that they 
>> are there invisible, but I doubt that, I need a proof of it.  How 
>> can I check for presence of options 464XLAT, DSLITE, MAP-E, MAP-T 
>> or lw4o6?
>> 
>> The problems that appear when I try to browse IPv6 sites that 
>> absolutely need IPv4 might be because I turned off the IPv4 stack 
>> on my computer's interface (Windows Properties on the Interface, 
>> check off IPv4).  This operation (turning off IPv4 in a computer) 
>> is possible only on Windows, not on linux, AFAIR.  One cant do 
>> 'rmmod ipv4' in linux.
>> 
>> That also explains the fact that installing IPv4-IPv6 translation 
>> boxes (NAT64, 464LAT, etc.) in a network is not sufficient to 
>> access IPv4 sites from an IPv6-only computer.
>> 
>> In order to access IPv4 sites from IPv6-only computers one also 
>> needs the IPv4 stack to work ok on that computer and, moreover, it 
>> needs some times software features in the Client that support the 
>> 64:: notation of IPv6 addresses.  For example, thunderbird (a very 
>> modern MUA) does not understand it and gets confused by it.  It 
>> takes it for an fqdn, and does not even try to connect the 
>> translation boxes.
>> 
>> This means that if one wants to migrate more to IPv6 then one has 
>> to think about the NAT64 and 464XLAT concepts more outside of the 
>> cellular network concept.
>> 
>> migrate.  In particular, if one is on a smartphone or other 
>> computer using an OS that cant turn off their IPv4 stacks.
>> 
>> Alex
>> 
>>> 
>>> Best regards,
>>> 
>>> Gábor
>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Mar 2021 23:31:01 +0100

> It is possible to turn it off,

The best possibility to turn IPv4 off in linux is to make the IPv4 stack
a module.  That means to add some hooks, and other tweaks.  In that way
one will be able to 'rmmod ipv4' just like one is able to 'rmmod ipv6'
today.

Then remove 127.0.0.1 from /etc/hosts and the IPv4 resolver from
/etc/resolve.conf and one is good to go.

I agree it is very much programming effort and nobody did it since
years.  One needs to struggle through hundreds of thousands of lines of
code to see who calls whom, and then interfere.   But it is a good goal,
I think.

Maybe in OpenBSD or FreeBSD the situation is different?  Maybe there one
_is_ able to remove the IPv4 stack from the kernel...

Alex

---

From: hsyu <[email-masked]>
Date: Thu, 25 Mar 2021 15:50:06 +0800

Hi, Alexandre and all,

Because the program for detecting whether a website supports IPv6 and the web corresponding to the program are deployed on the same server, in order to ensure the accuracy of the detection, the reachability of the network is the first consideration.  This is why IPv4 addresses are used in the website.

About adding the IPv6 forum and IPv6-test logos to the web, it's because I get some help from these two sites. However, in order to eliminate the misunderstanding, I will delete these two logos from the website.

Regarding the use of IPv6 addresses and DNS domain names to display this website, I need to apply for relevant resources to support it.

Since there are many disputes on the website and the website is currently only a test version, the website will be closed for a while to modify the content.

Best regards.

Haisheng Yu(Johnson)

[email-masked]

ndre Petrescu<[email-masked]> wrote：

To be more concrete.

Alex

I can agree.

Alex

?

Alex

Hi, Gabor,

Dear Alex,

Alex

Best regards,

Gábor

:-)

I agree.

The URL would look like:

Alex

Gábor

needs

further confirmation. Therefore, I will post it after the

data is corrected.

Hi,

Thank you for the reply.

But the access to that data should be on IPv6 too, not
only on IPv4.

Alex

签名由 网易邮箱大师

Hi,

But I can not see it :-(

in my web browser  it responds that the connection has

failed.  I use an

IPv6-only computer (Windows with IPv4 unchecked in the

interface

Properties).

Ideally, one would put data about IPv6 on a server that

is also capable

of doing IPv6.

Maybe one can put an IPv6 address on the server

218.2.231.237?

Alex

Hi Paolo, I can also provide some data on the

deployment of IPv6 in

Best regards.

Hi Paolo,

visibility

inside the enterprises beyond the external-facing
website or

email and thus it

is also difficult to gauge the IPv6 deployments

inside enterprises.

[PV] Ok. Probably here you refer to small-medium

enterprises. For

large enterprises public data on the usage of IPv6

can be retrieved

the next

version of the draft.

which

includes large enterprises and relies on DNS, mail,

external

Thanks! Dhruv

list

list

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 25 Mar 2021 10:15:40 +0100

Free was using 6RD initially, not sure if they turned into dual-stack, may be with IPv4 via CGN.

Regards,
Jordi
@jordipalet

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

    Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 25 Mar 2021 10:50:33 +0100

> dual-stack, may be with IPv4 via CGN.

I dont know (?), I am an end user.

For the moment I am happy with the way my ISP presents my access with
respect to IPv4 and IPv6 to the Internet.

There are some improvements necessary, with respect to SLAAC+DHCP, and
with respect to PD...

For example, if I turn on DHCPv6 on my freebox then my Android tablet
stops working even though my Windows PC works ok.  Ideally, DHCPv6 and
SLAAC should work ok together.

Also, if I add IPv6 subnets in my home then I must manually configure
the next-hop address in the GUI on the freebox, to tell that a prefix
P1::/63 (or so) to point to a particular IPv6 address.  Ideally, this
should be auto-configured, with tools and protocols that exist on client
Hosts.

Alex

> El 24/3/21 17:23, "v6ops en nombre de Alexandre Petrescu"
> Up to now, looking through the configuration interface of my freebox
> at home I could not see the options that you mention (464XLAT,
> DSLITE, MAP-E, MAP-T, lw4o6).  One might say that they are there
> invisible, but I doubt that, I need a proof of it.  How can I check
> for presence of options 464XLAT, DSLITE, MAP-E, MAP-T or lw4o6?
> 
> absolutely need IPv4 might be because I turned off the IPv4 stack on
> my computer's interface (Windows Properties on the Interface, check
> off IPv4).  This operation (turning off IPv4 in a computer) is
> possible only on Windows, not on linux, AFAIR.  One cant do 'rmmod
> ipv4' in linux.
> 
> boxes (NAT64, 464LAT, etc.) in a network is not sufficient to access
> IPv4 sites from an IPv6-only computer.
> 
> modern MUA) does not understand it and gets confused by it.  It takes
> it for an fqdn, and does not even try to connect the translation
> boxes.
> 
> think about the NAT64 and 464XLAT concepts more outside of the

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 25 Mar 2021 13:46:10 +0100

Johnson,

I want to say that I am happy that you posted the example and the
discussion.

It is great we have this opportunity to improve things, and I might be
wrong myself at times :-)

Alex

Le 24/03/2021 à 04:14, hsyu a écrit :
> Thank you very much for your interest in this website. This is a test
> website, and the current data still needs further confirmation.
> Therefore, I will post it after the data is corrected.
> 
> 3/24/2021 02:14，Alexandre Petrescu<[email-masked]> 
> (http://218.2.231.237:5001/cgi-bin/generate) in my web browser  it
> responds that the connection has failed.  I use an IPv6-only computer
> (Windows with IPv4 unchecked in the interface Properties).
> 
> Ideally, one would put data about IPv6 on a server that is also
> capable of doing IPv6.
> 
> I think we should highlight that we do not have visibility inside
> the enterprises beyond the external-facing website or email and thus
> it is also difficult to gauge the IPv6 deployments inside
> enterprises.
> 
> organizations). We will better specify this point in the next 
> version of the draft.
> 
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 25 Mar 2021 13:33:05 +0000

Hi Johnson,
I did try to abuse this data for one document but after investigation
I have found that it is strange that so many servers respond to IPv6 (everything green),
But almost no one has the record in the DNS (everything red).
Could you inform this alias when you believe the data could be used?
Thanks a lot! Any statistics from outside of China Firewall are not as reliable as from inside.
It is very valuable to understand what is going on 1/4 of the world-wide market.
Eduard
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Thursday, March 25, 2021 3:46 PM
To: hsyu <[email-masked]>; Paolo Volpato <[email-masked]>
Cc: rbonica=[email-masked]; [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

Johnson,

I want to say that I am happy that you posted the example and the discussion.

It is great we have this opportunity to improve things, and I might be wrong myself at times :-)

Alex

Le 24/03/2021 à 04:14, hsyu a écrit :
> <https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftl
> Id=1&name=Haisheng+Yu%28Johnson%29&uid=hsyu%40cfiec.net&iconUrl=https%
> 3A%2F%2Fmail-online.nosdn.127.net%2Fsm50a1433bca9fb284d4265d35e9ed54d3
> .jpg&items=%5B%22%22%2C%22hsyu%40cfiec.net%22%2C%22%22%2C%22%22%2C%22%
> 22%5D>
> 
> 
> <https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftl
> Id=1&name=Haisheng+Yu%28Johnson%29&uid=hsyu%40cfiec.net&iconUrl=https%
> 3A%2F%2Fmail-online.nosdn.127.net%2Fsm50a1433bca9fb284d4265d35e9ed54d3
> .jpg&items=%5B%22%22%2C%22hsyu%40cfiec.net%22%2C%22%22%2C%22%22%2C%22%
> 22%5D>
>
> 
>

---

From: Gert Doering <[email-masked]>
Date: Thu, 25 Mar 2021 14:40:59 +0100

Hi,

> _is_ able to remove the IPv4 stack from the kernel...

People have built FreeBSD kernels without IPv4 support years ago.

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 25 Mar 2021 16:05:41 +0100

> People have built FreeBSD kernels without IPv4 support years ago.

But once IPv4 removed from the kernel can one simply re-insert it, and 
re-remove it?  Or does one have to go through a reboot?

Alex

---

From: Gert Doering <[email-masked]>
Date: Thu, 25 Mar 2021 17:25:03 +0100

Hi,

> re-remove it?  Or does one have to go through a reboot?

As far as I'm aware, FreeBSD IPv4/IPv6 is not modular in the Linux
sense ("modprobe ipv6.ko").  You build a kernel with a protocol family,
or without, and boot into it.

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 26 Mar 2021 07:03:47 +0100

Le 24/03/2021 à 16:59, Gabor LENCSE a écrit :
>  the five most prominent ones 464XLAT, DS-Lite, MAP-E, MAP-T and
> lw4o6 in our I-D: 

I looked at it.

There is a need to illustrate also a drawback in 464XLAT/DNS64 in
cellular operator networks: they can be used to offer an IPv6 address to
a smartphone and the smartphone to browse IPv4 sites.

But they cant be used to offer an IPv6 address to a server behind an IoT
router and be reachable from another IPv6 client in the Internet.

The result of that impossibility is that IPv4 with port translation (but
not PCP) is preferred in such a setting, instead of IPv6.  It is not a
happy situation.

The use-case is the following: in a street deployment a traffic lights
controller controls the traffic lights.  This controller is a PC with
Ethernet interface, linux, IPv6 and IPv4 stacks.  The car needs to know
the status of the color (red/green, time left, etc.)  The car tries to
http to that PC Server.  The PC needs to connect to the Internet via a
cellular network operator.  An IoT router (4G and Ethernet small router,
linux, IPv4, IPv6) is thus plugged on the PC.  The cellular network
operator offers a /64, and also NAT64/DNS64 to those who need it.

In trying to identify where in the draft could this be already
explained, I found section "4.3.  Support for Public Server Operation".
  But I think that section does not really explain my problem.

Alex

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 26 Mar 2021 15:48:19 +0100

If both end-sites have IPv6 support, the IPv6 addresses will be reachable.

In your example you mention that the PC server is dual-stacked (it can be IPv6-only), and the car can be either dual-stacked or IPv6-only. So, the car can always contact the PC server. There is no need for any transition mechanism in this scenario.

What it doesn't make any sense in today's world is to do this deployment with IPv4-only in any of the sides. That's a negation of the reality: IoT with IPv4 (and in general any new deployment with IPv4) doesn't make any sense.

One example of this was, a few years ago, the contract awarded to Telefónica for 53 millions of gas and electricity meters in UK, worth 1.5 billion pounds in 15 years, using cellular and 6LOWPAN. If they have done it with IPv4, they will have needed 34 million NATs, according to their own calculations.

https://www.google.com/search?q=telefonica+awarded+uk+meters

Now, if you want to make it more complex, and you really need to keep IPv4 incoming connections, you can still configure the NAT64 for that, either for specific ports or addresses. However, as said, it doesn't make sense to use IPv4 for new deployments of "anything".

Regards,
Jordi
@jordipalet

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

    I looked at it.

    Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 26 Mar 2021 15:53:46 +0100

Le 26/03/2021 à 15:48, JORDI PALET MARTINEZ a écrit :
> In your example you mention that the PC server is dual-stacked (it
> can be IPv6-only), and the car can be either dual-stacked or
> IPv6-only.

Yes.

> So, the car can always contact the PC server. There is no
> need for any transition mechanism in this scenario.

But how the PC gets an IPv6 address through the Ethernet on the IoT 
Router that connects on 4G?  The 4G only gives it a /64.  The IoT Router 
does not implement clatd etc.

> What it doesn't make any sense in today's world is to do this
> deployment with IPv4-only in any of the sides. That's a negation of
> the reality: IoT with IPv4 (and in general any new deployment with
> IPv4) doesn't make any sense.

I agree.

> One example of this was, a few years ago, the contract awarded to
> Telefónica for 53 millions of gas and electricity meters in UK, worth
> 1.5 billion pounds in 15 years, using cellular and 6LOWPAN. If they
> have done it with IPv4, they will have needed 34 million NATs,
> according to their own calculations.

The IoT devices that I acquire on the market dont do 6lowpan.  There are 
indeed many 6lowpan devices but there are also many other IoT devices 
that connect on 4G, have Bluetooth/WiFi/Ethernet/Galileo and yet dont do 
6lowpan.

> Now, if you want to make it more complex, and you really need to keep
> IPv4 incoming connections, you can still configure the NAT64 for
> that, either for specific ports or addresses. However, as said, it
> doesn't make sense to use IPv4 for new deployments of "anything".

If I _have_ to do NAT, then NAT44 is largely sufficient.  There is no 
need for v4-v6 transition mechanisms (I mean not in these trials I 
consider).

Alex

> El 26/3/21 7:04, "v6ops en nombre de Alexandre Petrescu"
> cellular operator networks: they can be used to offer an IPv6 address
> to a smartphone and the smartphone to browse IPv4 sites.
> 
> But they cant be used to offer an IPv6 address to a server behind an
> IoT router and be reachable from another IPv6 client in the
> Internet.
> 
> The result of that impossibility is that IPv4 with port translation
> (but not PCP) is preferred in such a setting, instead of IPv6.  It is
> not a happy situation.
> 
> The use-case is the following: in a street deployment a traffic
> lights controller controls the traffic lights.  This controller is a
> PC with Ethernet interface, linux, IPv6 and IPv4 stacks.  The car
> needs to know the status of the color (red/green, time left, etc.)
> The car tries to http to that PC Server.  The PC needs to connect to
> the Internet via a cellular network operator.  An IoT router (4G and
> Ethernet small router, linux, IPv4, IPv6) is thus plugged on the PC.
> The cellular network operator offers a /64, and also NAT64/DNS64 to
> those who need it.
> 
> explained, I found section "4.3.  Support for Public Server
> Operation". But I think that section does not really explain my
> problem.
> 
> Alex
> 
>>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 26 Mar 2021 16:12:36 +0100

-> The 4G devices today, allow /64 prefix sharing, same they do for tethering. I agree that ideally, we should have DHCPv6-PD, and in some pilot scenarios, I've used it. We have talked about this many times. It is not blocked by "hardware" but may be by baseband modem firmware.

-> Those devices don't deserve the right to be called IoT then. A real IoT devices must have IPv6 support.

-> It is utopic to believe that NAT44 will keep scaling ...

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 26 Mar 2021 16:20:39 +0100

Le 26/03/2021 à 16:12, JORDI PALET MARTINEZ a écrit :
> 
>> So, the car can always contact the PC server. There is no need for
>> any transition mechanism in this scenario.
> 
> Router that connects on 4G?  The 4G only gives it a /64.  The IoT
> Router does not implement clatd etc.
> 
> -> The 4G devices today, allow /64 prefix sharing,

Only smartphones Android and iOS allow for /64 prefix sharing.  They
promote that functionality in an app.

Other IoT routers on 4G dont do that.

> same they do for tethering. I agree that ideally, we should have
> DHCPv6-PD, and in some pilot scenarios, I've used it. We have talked
> about this many times. 

Yes, and yes.

> It is not blocked by "hardware" but may be by
> baseband modem firmware.

'is not' on one hand and 'may' on the other hand - I can only agree with 
you, but there is something missing.

That is the situation right now.

>> Telefónica for 53 millions of gas and electricity meters in UK,
>> worth 1.5 billion pounds in 15 years, using cellular and 6LOWPAN.
>> If they have done it with IPv4, they will have needed 34 million
>> NATs, according to their own calculations.
> 
> The IoT devices that I acquire on the market dont do 6lowpan.  There
> are indeed many 6lowpan devices but there are also many other IoT
> devices that connect on 4G, have Bluetooth/WiFi/Ethernet/Galileo and
> yet dont do 6lowpan.
> 

Ah?  DO you mean that an IoT device on the market that does not do 
6lowpan or does not do IPv6 can not be called IoT?

This might go very far, but should be considered.

>> Now, if you want to make it more complex, and you really need to
>> keep IPv4 incoming connections, you can still configure the NAT64
>> for that, either for specific ports or addresses. However, as said,
>> it doesn't make sense to use IPv4 for new deployments of
>> "anything".
> 
> If I _have_ to do NAT, then NAT44 is largely sufficient.  There is
> no need for v4-v6 transition mechanisms (I mean not in these trials
> I consider).
> 

I can agree that in the long term NAT44 might not scale, but I can also 
agree that NAT64 wouldnt scale either.

Yes, let us do IPv6, unless one calls IPv6 the IPv4+translation :-)

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 26 Mar 2021 16:37:59 +0100

I forgot to say something...

> I agree that ideally, we should have DHCPv6-PD, and in some pilot
> scenarios, I've used it. We have talked about this many times. 

That rich discussion was not overlooked by me.

We worked, tested and wrote with a colleague an entire Internet Draft 
about how to do DHCPv6-PD and PDP protocol on a 4G link, describing more 
precisely the different computers and software that takes part in that 
protocol.

What I think that might have worked for you is the model where a 4G USB 
dongle is plugged on a laptop in our experiments.

So all I can do is to ask you for confirmation?  Was that on an USB key?

> 
>    Additional experiments with using of USB dongle were performed.  The
>    following figure illustrates the successful DHCPv6-PD test on Orange
>    with dongle.  It uses a Huawei E392 USB dongle on laptop (and not the
>    Sierra Wireless mangOH Red).
> 
> 
>                      +---------------+       |
>                      |      PGW      |       |
>                      |   Delegating  |       |
>                      |     Router    |       |
>                      +---------------+       |
>                              |               |
>                              |               |
>                      +---------------+       |
>                      |      SGW      |       | Cellular infrastructure
>                      +---------------+       |
>                              |               |
>                              |               |
>                      +---------------+       |
>                      |    eNodeB     |       |
>                      +---------------+       |
>                              |               |
>                              |               |
>                              ~               ~  Wireless OFDMA 3G/4G
>                              |               |
>                      +---------------+       |
>                      |   +--------+  |       |
>                      |   |  E392  |  |       |
>                      |   |  USB   |  |       |
>                      |   | dongle |  |       |
>                      |   +--------+  |       |
>                      |       |       |       | User Equipment
>                      |   +--------+  |       |
>                      |   | Laptop |  |       |
>                      |   +--------+  |       |
>                      |               |       |
>                      +---------------+       |

Alex

It is
> not blocked by "hardware" but may be by baseband modem firmware.
> 
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 26 Mar 2021 16:42:56 +0100

-> They are broken then - complain to the vendor, they should support it to be full conformant to 4G, just a minor firmware update should resolve it. Now, if you mean a dumb 4G "interface" such as an USB stick, should the prefix sharing be handled by the PC OS ? Anyway, I will not use in a new deployment so bad devices! You don't save money because that, so there is no reason to use crap hardware.

    Yes, and yes.

-> IETF is not the place to resolve buggy implementations, only complaining to vendors will resolve it, and ultimately, finding alternative suppliers.

-> From the perspective of IETF, technically we could document it. However, the problem is more a marketing advise. Most of the companies selling all kind of cheap sensors, just don't care, they will keep calling "IoT" to any crap hardware, even if is not IP enabled at all (I've seen RF-only sensors being called IoT sensors ...).

-> NAT64 scales if we continue "real" IPv6 deployment *because* it means that you use less and less NAT64 translations, so less IPv4 addresses required on the NAT64 Internet-facing interfaces. The nice think about 464XLAT is that you "drop" IPv4 in a natural way, just passing the time, nothing to be done. When you do IPv6-only deployments (with IPv4aaS) in ISPs, you suddenly see (at least in residential networks) 75%-85% of the traffic being IPv6-only end-to-end.

    Alex

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 26 Mar 2021 16:48:41 +0100

-> We have several tested devices. Some were CPEs with a 3G USB dongle, but also, we had a Chinese CPE with built-in SIM "pocket". Unfortunately, the testing was done "by chance" as part of another project. We just had "all the pieces" at hand and I decided to try, why not? And it worked, but being work for a customer I can't disclose details (and in fact I don't have some of them because it was not the goal of the project, do didn't took sufficient notes to name vendors or models or chipsets). As said, I don't think is a chipset problem at all, it is some firmware closing the relevant ports.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 26 Mar 2021 16:51:04 +0100

Le 26/03/2021 à 16:42, JORDI PALET MARTINEZ a écrit :
> -> They are broken then - complain to the vendor, 

How can I complain to a vendor of not implementing '64hare' which is an 
INFORMATIONAL RFC?

Either make the RFC Stds Track or not try to put it on the list of 
absolute requirements for a device...

> -> IETF is not the place to resolve buggy implementations, only complaining to vendors will resolve it, and ultimately, finding alternative suppliers.

We will not resolve buggy implementations here.

We will continue to stale.

> -> From the perspective of IETF, technically we could document it. However, the problem is more a marketing advise. Most of the companies selling all kind of cheap sensors, just don't care, they wi…

Might be to say IoT sensors are just the RF-only devices.

But how about 'IoT Routers'?

We propose the definition of an 'IoT Router' to be this:
>    IoT Router - a device of class IoT.  It has several wired and
>    wireless interfaces.  One wireless interface is of type cellular,
>    like 4G or 5G.  This cellular interface is egress.  The other
>    interfaces are ingress.  There are at least two ingress interfaces.
>    There is at least one set of two interfaces that can not be bridged
>    together, for example 802.11b and Bluetooth.  If all ingress
>    interfaces in the IoT Router can be bridged, for example 802.11b and
>    Ethernet, then there is at least one other router in the same local
>    network as the IoT Router, that can not be bridged to this IoT
>    Router.  The IoT Router needs more than one /64 prefix.  An example
>    of IoT Router is Sierra Wirelss mangOH Red, or Maestro Wireless E220.

> -> NAT64 scales if we continue "real" IPv6 deployment *because* it means that you use less and less NAT64 translations, so less IPv4 addresses required on the NAT64 Internet-facing interfaces. The…

Hmmm, thinking abou tit.

Alex

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 26 Mar 2021 17:14:36 +0100

-> Vendors don't really care so much about if an RFC is class "a" or "b" or "c". Money talks. Don't buy them.

    >    of IoT Router is Sierra Wirelss mangOH Red, or Maestro Wireless E220.

-> I think and IoT router definition don't need to enforce any specific interface, because it depends on the scenario. However, it needs to enforce IPv6 support.

    Hmmm, thinking abou tit.

    Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 26 Mar 2021 17:25:29 +0100

> -> Vendors don't really care so much about if an RFC is class "a" or "b" or "c". Money talks. Don't buy them.

I was _offered_ these devices and then bulk price for more.

One cant beat that.

That should be compared to the gratuitous 64share software but on a 
1000Eur hardware smartphone package.

Compare it too to the price I'd have to may out of my own pocket to 
submit our own DHCPv6-PD client compiled from open source in order to 
get it a place in the store.  And even if I paid that, I think it would 
be refused by the store owner because of other non technical reasons 
against DHCP.

This situation is far from desirable.

If there were a cheap IoT router on the market with root ssh and not 
block DHCPv6 on 4G then I am all ears :-)  But there isnt :-(  So it's 
staled.

Alex

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 26 Mar 2021 17:31:00 +0100

Alibaba/Aliexpress is your friend.

You have many models from 10 to 100's of USD which typically run OpenWRT, and you can do that with them, either with built-in SIM or external USB dongle. 

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

    One cant beat that.

    Alex

---

From: Gert Doering <[email-masked]>
Date: Fri, 26 Mar 2021 17:35:33 +0100

Hi,

> Other IoT routers on 4G dont do that.

Nothing stops those other vendors from doing this.  It's not magic.

Android is even open source, so a linux based IoT router could just
copy the functionality from Android...

If you as a customer demand it, and order enough devices, vendors will
deliver.  If you complain to IETF lists instead, nothing will happen.

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 26 Mar 2021 17:36:07 +0100

Le 26/03/2021 à 17:31, JORDI PALET MARTINEZ a écrit :
> You have many models from 10 to 100's of USD which typically run OpenWRT, and you can do that with them, 

I can try but how to be sure they dont block DHCPv6 when I know so many 
other things I tried with Balong and Qualcomm models block it?

I cant buy all offers on Alibaba either :-)

Alex

either with built-in SIM or external USB dongle.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Mar 2021 12:40:46 -0400

On Mar 26, 2021, at 12:36 PM, Alexandre Petrescu <[email-masked]> wrote:
> I can try but how to be sure they dont block DHCPv6 when I know so many other things I tried with Balong and Qualcomm models block it?

Do the modems do DHCPv6 Information Request?

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 26 Mar 2021 17:41:44 +0100

Le 26/03/2021 à 17:35, Gert Doering a écrit :
>> Only smartphones Android and iOS allow for /64 prefix sharing.
>> They promote that functionality in an app.
>> 
> If you as a customer demand it, and order enough devices, vendors
> will deliver.  If you complain to IETF lists instead, nothing will
> happen.

Yes yes, I stop complaining.

But maybe I can tell you that me as a customer does not see the
organisation that is in charge and that can solve he problem, directly.

Me as a customer I acquire box that has many manufacturers inside.  Then
it goes via the operator as well.  I had to go through very many many
contacts with this.  I can tell you that the end user has nothing to say
or request.  The protocol decisions are made way far from what what the
end user (or maybe it's just me) needs :-)

Ok, I stop complaining here :-)

We wrote a personal submission Internet Draft about it and I leave it
there about v6ops WG :-)

Alex

> 
> Gert Doering -- NetMaster
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 26 Mar 2021 17:44:27 +0100

How do you do in any other shop? Ask them before buying!

I did in Alibaba and Aliexpress, several times, for some other technical questions and it worked and I got the right product. You many need to ask to several vendors until you find the right one, but it works.

As a recent example, I designed my own LFP solar battery with 90 x 3,2V 280Ah cells, and sent the Chinese providers a PDF with my own design of the copper laminated busbars and plastic covers, etc., and everything worked fine.

Regards,
Jordi
@jordipalet

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

    Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 26 Mar 2021 17:59:57 +0100

> How do you do in any other shop? Ask them before buying!

All descriptions of these small devices dont go into such detail about
their devices.  If some IoT device says 'DHCP' then it's for sure IPv4;
if it says 'IPv6' then it's for sure SLAAC.  If it ever says 'DHCPv6' it
means it is for Ethernet.  If it's DHCPv6-PD for something else than
Ethernet then it's for ADSL.  If it is DHCPv6-PD on 4G then there is a
little star that says that only some operator only in some country on
some freq band; but they dont say which :-)

It's an endless story.

If there were a product that said 'DHCPv6-PD on 4G  with operator Orange
in France' then I buy it instantly.

> I did in Alibaba and Aliexpress, several times, for some other 
> technical questions and it worked and I got the right product. You 
> many need to ask to several vendors until you find the right one,
> but it works.> As a recent example, I designed my own LFP solar
> battery with 90 x 3,2V 280Ah cells, and sent the Chinese providers a
> PDF with my own design of the copper laminated busbars and plastic
> covers, etc., and everything worked fine.

Maybe you had just one or two manufacturers in front of you.  Maybe you
had the human who actually made these panels.  An on-purpose 'turnkey'
design.

But when you look at a mass-produced product like an IoT router, there
are so many manufacturers involved :-)

Alex

> El 26/3/21 17:36, "v6ops en nombre de Alexandre Petrescu" 
> I can try but how to be sure they dont block DHCPv6 when I know so 
> many other things I tried with Balong and Qualcomm models block it?
> 
>> El 26/3/21 17:26, "v6ops en nombre de Alexandre Petrescu" 
>>> How can I complain to a vendor of not implementing '64hare'
>>> which is an INFORMATIONAL RFC?
>>> 
>>> Either make the RFC Stds Track or not try to put it on the list 
>>> of absolute requirements for a device...
>>> 
>>> -> Vendors don't really care so much about if an RFC is class
>>> "a" or "b" or "c". Money talks. Don't buy them.
>> 
>> submit our own DHCPv6-PD client compiled from open source in order
>> to get it a place in the store.  And even if I paid that, I think
>> it would be refused by the store owner because of other non 
>> technical reasons against DHCP.
>> 
>> If there were a cheap IoT router on the market with root ssh and 
>> not block DHCPv6 on 4G then I am all ears :-)  But there isnt :-( 
>> So it's staled.
>> 
>> Alex
>> 
>>> 
>>>>> It is not blocked by "hardware" but may be by baseband modem 
>>>>> firmware.
>>>> 
>>>> 'is not' on one hand and 'may' on the other hand - I can only 
>>>> agree with you, but there is something missing.
>>>> 
>>>> -> IETF is not the place to resolve buggy implementations,
>>>> only complaining to vendors will resolve it, and ultimately,
>>>> finding alternative suppliers.
>>> 
>>>>>> One example of this was, a few years ago, the contract 
>>>>>> awarded to Telefónica for 53 millions of gas and 
>>>>>> electricity meters in UK, worth 1.5 billion pounds in 15 
>>>>>> years, using cellular and 6LOWPAN. If they have done it 
>>>>>> with IPv4, they will have needed 34 million NATs,
>>>>> The IoT devices that I acquire on the market dont do
>>>>> 6lowpan. There are indeed many 6lowpan devices but there are
>>>>> also many other IoT devices that connect on 4G, have 
>>>>> Bluetooth/WiFi/Ethernet/Galileo and yet dont do 6lowpan.
>>>>> 
>>>>> -> Those devices don't deserve the right to be called IoT 
>>>>> then. A real IoT devices must have IPv6 support.
>>>> 
>>>> Ah?  DO you mean that an IoT device on the market that does
>>>> not do 6lowpan or does not do IPv6 can not be called IoT?
>>>> 
>>>> -> From the perspective of IETF, technically we could document 
>>>> it. However, the problem is more a marketing advise. Most of 
>>>> the companies selling all kind of cheap sensors, just don't 
>>>> care, they will keep calling "IoT" to any crap hardware, even 
>>>> if is not IP enabled at all (I've seen RF-only sensors being 
>>>> called IoT sensors ...).
>>> 
>>>> wireless interfaces.  One wireless interface is of type 
>>>> cellular, like 4G or 5G.  This cellular interface is egress. 
>>>> The other interfaces are ingress.  There are at least two 
>>>> ingress interfaces. There is at least one set of two
>>>> interfaces that can not be bridged together, for example
>>>> 802.11b and Bluetooth.  If all ingress interfaces in the IoT
>>>> Router can be bridged, for example 802.11b and Ethernet, then
>>>> there is at least one other router in the same local network as
>>>> the IoT Router, that can not be bridged to this IoT Router.
>>>> The IoT Router needs more than one /64 prefix.  An example of
>>>> IoT Router is Sierra Wirelss mangOH Red, or Maestro Wireless
>>>> E220.
>>> 
>>> -> I think and IoT router definition don't need to enforce any 
>>> specific interface, because it depends on the scenario. However, 
>>> it needs to enforce IPv6 support.
>>> 
>>>> 
>>>>>> Now, if you want to make it more complex, and you really 
>>>>>> need to keep IPv4 incoming connections, you can still 
>>>>>> configure the NAT64 for that, either for specific ports or 
>>>>>> addresses. However, as said, it doesn't make sense to use 
>>>>>> IPv4 for new deployments of "anything".
>>>>> 
>>>>> If I _have_ to do NAT, then NAT44 is largely sufficient. 
>>>>> There is no need for v4-v6 transition mechanisms (I mean not 
>>>>> in these trials I consider).
>>>>> 
>>>> I can agree that in the long term NAT44 might not scale, but I 
>>>> can also agree that NAT64 wouldnt scale either.
>>>> 
>>>> -> NAT64 scales if we continue "real" IPv6 deployment
>>>> *because* it means that you use less and less NAT64
>>>> translations, so less IPv4 addresses required on the NAT64
>>>> Internet-facing interfaces. The nice think about 464XLAT is
>>>> that you "drop" IPv4 in a natural way, just passing the time,
>>>> nothing to be done. When you do IPv6-only deployments (with
>>>> IPv4aaS) in ISPs, you suddenly see (at least in residential
>>>> networks) 75%-85% of the traffic being IPv6-only end-to-end.
>>> 
>>> Hmmm, thinking abou tit.
>>> 
>>> Alex
>>> 
>>>> 
>>>>> and further non-explicilty authorized disclosure, copying, 
>>>>> distribution or use of the contents of this information,
>>>>> even if partially, including attached files, is strictly 
>>>>>  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.
>>>>> 
>>>>> 
>>>>> 
>>> you ready for the new Internet ? http://www.theipv6company.com 
>>> The IPv6 Company
>>> 
>>> partially, including attached files, is strictly prohibited and
>>> will be considered a criminal offense. If you are not the
>>> partially, including attached files, is strictly prohibited, will
>>> be considered a criminal offense, so you must reply to the

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 26 Mar 2021 18:04:37 +0100

Believe me, before buying anything I've asked at least to 10-12 of the possible suppliers.

I'm never trusting the published specs I ask for specific questions, including if they are the real manufacturer or they can pass questions to the real one.

I ask them very detailed specs. I will not ask for DHCP, I will use the RFC if necessary.

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

    It's an endless story.

    Alex

---

From: Fred Baker <[email-masked]>
Date: Fri, 26 Mar 2021 21:58:07 -0700

> On Mar 19, 2021, at 1:39 AM, Paolo Volpato <[email-masked]> wrote:
> 

OK, let me put this to the working group. We asked about adoption of draft-lmhp-v6ops-transition-comparison once before (in January 2020), and got essentially no response. It has come up on the list twice since, in July and in November. The authors of draft-vf-v6ops-ipv6-deployment would like to see it adopted. The two sets of authors are disjoint. I therefore have at least nine people that would like to see us adopt and publish it. What other folks have opinions, pro or con?

Along the same lines, are there opinions regarding the adoption of draft-vf-v6ops-ipv6-deployment?

https://mailarchive.ietf.org/arch/search/?qdr=a&q=%22draft-lmhp-v6ops-transition-comparison%22
https://mailarchive.ietf.org/arch/search/?qdr=a&q=%22draft-vf-v6ops-ipv6-deployment%22

---

From: Xipengxiao <[email-masked]>
Date: Sat, 27 Mar 2021 12:05:51 +0000

Hi All,

I support the adoption of both drafts, as they provide (1) useful information about the current deployment status of IPv6, and (2) useful information for operators to consider while deploying IPv6.   With almost 500 IPv6-related RFCs, it's difficult for IPv6-deployers to find all the relevant information.  So these summary-and-advice types of  documents are useful for our industry at this stage.  

XiPeng 

> From: v6ops [mailto:[email-masked]] On Behalf Of Fred Baker
> Sent: Saturday, March 27, 2021 5:58 AM
> To: [email-masked]
> Cc: [email-masked]; draft-vf-v6ops-ipv6-
> [email-masked]
> Subject: [v6ops] draft-vf-v6ops-ipv6-deployment and draft-vf-v6ops-ipv6-
> deployment
> 
> 
> 
> > For lmhp-v6ops-transition-comparison, on behalf of the authors of draft-vf-
> v6ops-ipv6-deployment I can say we are in favor of the WG adoption. Not
> only is it a good description of the transition technologies to IPv6, but it also
> constitutes a basis for our draft.
> 
> OK, let me put this to the working group. We asked about adoption of draft-
> lmhp-v6ops-transition-comparison once before (in January 2020), and got
> essentially no response. It has come up on the list twice since, in July and in
> November. The authors of draft-vf-v6ops-ipv6-deployment would like to see
> it adopted. The two sets of authors are disjoint. I therefore have at least nine
> people that would like to see us adopt and publish it. What other folks have
> opinions, pro or con?
>

---

From: Gabor LENCSE <[email-masked]>
Date: Sat, 27 Mar 2021 16:35:13 +0100

Dear All,

I have read draft-vf-v6ops-ipv6-deployment-02 and I found it useful and 
I support its adoption.

I have found a typo at the bottom of page 18:

"Yet, this worsening effect may appea_e_ as disturbing for a plain 
transition to IPv6." --> "Yet, this worsening effect may appea*r* as 
disturbing for a plain transition to IPv6."

Regarding IPv6 Security in Section 11.4, I think it is also worth 
considering the additional security issues brought into existence by the 
applied IPv6 transition technologies used to implement IPv4aaS, like 
464XLAT, DS-Lite, etc. You can find some basic hints in our paper:

G. Lencse and Y. Kadobayashi, "Methodology for the identification of 
potential security issues of different IPv6 transition technologies: 
Threat analysis of DNS64 and stateful NAT64", /Computers & Security/ 
(Elsevier), vol. 77, no. 1, pp. 397-411, August 1, 2018, DOI: 
10.1016/j.cose.2018.04.012

Available from: 
http://www.hit.bme.hu/~lencse/publications/ECS-2018-Methodology-revised.pdf

As for our draft, draft-lmhp-v6ops-transition-comparison-06, I am 
working on an RFC 8219 compliant performance measurement tool to be able 
to add relevant data to Section 5 about Performance Comparison. I have 
just prepared the very much alpha state version of a stateful NAT64 
tester, by enabling siitperf for stateful tests: 
https://github.com/lencsegabor/siitperf/tree/stateful

It is capable of benchmarking both stateful NAT64 and stateful NAT44 
(CGNAT) implementations. Its documentation is to be updated yet, but I 
am glad the help, if any you would like to use it.

Best regards,

Gábor

p.s.: I have corrected the subject line, as I think Fred intended to 
include both drafts in it.

---

From: "[email-masked]" <[email-masked]>
Date: Sun, 28 Mar 2021 15:13:22 +0800

6rd is a mode of IPv6 over IPv4, it is opposite to the concept of "IPv4 as a Service" of IPv6-only, so it should be replaced to make IPv6 as a univeral and underlying network protocol gradually.

Regards
Chongfeng

From: JORDI PALET MARTINEZ
Date: 2021-03-25 17:15
To: [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment
Free was using 6RD initially, not sure if they turned into dual-stack, may be with IPv4 via CGN.
 
Regards,
Jordi
@jordipalet

 

 

 

 

    Alex

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 28 Mar 2021 10:25:41 +0200

Yes and not … IPv6 in IPv4 (6in4, proto41, etc.) … 6over4 is another protocol.

Agree, right thing is to use IPv6-only and IPv4aaS, I was just saying that Free was the initiation of 6RD and they were using that. I’m not saying they still use the same or they should keep using the same.

Regards,

Jordi

@jordipalet

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

Regards

Chongfeng

Date: 2021-03-25 17:15

To: [email-masked]

Regards,

Jordi

@jordipalet

 

    network concept.

    Alex

    v6ops mailing list

    [email-masked]

 

IPv4 is over

The IPv6 Company

 

v6ops mailing list

[email-masked]

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Mar 2021 07:47:44 +1300

> Agree, right thing is to use IPv6-only and IPv4aaS, I was just saying that Free was the initiation of 6RD and they were using that. I’m not saying they still use the same or they should keep using…

But please consider that if an operator is already supporting its customers using classical dual stack or a solid solution like 6rd, there may be no good reason to change for the next ten years or more. Dual stack has no time limit.

I think this statement in the draft:
"For this reason, when IPv6 increases to a certain limit,
it would be better to switch to the IPv6-only stage."
is too vague to be useful. Switching costs might be very high, including loss of customers. In fact, the criterion for switching might be as simple as "when IPv4 traffic is vanishingly small."

   Brian

> 
>  
> 
> Regards,
> 
> Jordi
> 
> @jordipalet
> 
>  
> 
>  
> 
>  
> 
> El 28/3/21 9:14, "v6ops en nombre de [email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]> en nombre de [email-masked] <mailto:[email-masked]>> escribió:
> 
>  
> 
>  
> 
>  
> 
>     *From:* JORDI PALET MARTINEZ <mailto:jordi.palet=[email-masked]>
> 
>     *Date:* 2021-03-25 17:15
> 
>     *To:* [email-masked] <mailto:[email-masked]>
> 
>     *Subject:* Re: [v6ops] draft-vf-v6ops-ipv6-deployment
> 
>         > Dear Alex,
>         > On 3/24/2021 4:12 PM, Alexandre Petrescu wrote: [...]
> 
>         >> Does IPv6 mandate the use of DNS64 and NAT64?
> 
>         >
> 
>         > Of course, not. :)
> 
>      
> 
>         > There are several IPv4 as a Services solutions exist. We have
> 
>         > covered the five most prominent ones 464XLAT, DS-Lite, MAP-E, MAP-T
> 
>         > and lw4o6 in our I-D:
> 
>         > https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-06
> 
>         > > Your ISP is likely using one of them.
> 
>      
> 
>         > Best regards,
>         > Gábor
>         > _______________________________________________ v6ops mailing list
>

---

From: Lencse Gábor <[email-masked]>
Date: Sun, 28 Mar 2021 21:24:39 +0200

However, a statement like:

"For this reason, when IPv4 traffic is vanishingly small (e.g. less than 1%), it would be better to switch to the IPv6-only stage."

seems to be trivial.

Can we state something stronger?

For example:

"For this reason, when IPv6 increases to a certain limit (e.g. more than 90%), it would be better to switch to the IPv6-only stage."

Rationale:
- Introducing an IPv4aaS technology has its costs, but the selling of 
the lions share of the public IPv4 addresses brings in more money.
- The maintenance cost of the IPv4aaS solution is less than that of a 
complete IPv4 network.

I do not state that it is true, I just ask, if it can be true. Because 
if it is so, then it could be a better guidance.

Gábor

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 28 Mar 2021 22:15:59 +0200

-> Yes, agree, I was not trying to say that existing IPv6 deployments (with *any* transition mechanism) should move to IPv6-only with IPv4aaS. My sentence was thinking in "if you deploy IPv6 now".

-> Agree. I think it is a case-by-case basis. However, it should be considered that certain customers may need "real" dual-stack (example customer hosting dual-stack contents in their own premises), so one of the reasons may be releasing IPv4 addressers where they aren't longer "absolutely" needed, for other "better" usages, or even because the transfer of IPv4 addresses may cover the cost of moving to IPv6-only. Note also that IPv6-only with IPv4aaS has one more advantage for the ISP: you only manage a single stack, which means less opex, and this impacts more as less IPv4 traffic is there, and you don't need to "disable" IPv4, because it is "automatically" disabled. Instead using "real" dual-stack or older transition mechanisms, means that at some point in the future you may want to do a "new" transition to IPv6-only (which has a cost).

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 28 Mar 2021 22:19:43 +0200

I can confirm that ... just say it in my previous email ...

Note also that for residential ISPs, reaching IPv6 levels close to 90% is trivial. It happens overnight, because the big volume of traffic to CDNs such as Netflix, Youtube/Google, Facebook, Akamai, etc., etc. which have already IPv6 on.

El 28/3/21 21:25, "v6ops en nombre de Lencse Gábor" <[email-masked] en nombre de [email-masked]> escribió:

    seems to be trivial.

    For example:

    Rationale:

    Gábor

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 29 Mar 2021 07:33:01 +0000

Hi Jordi,
Your last statement is probably too strong.
About half of Mobile carriers have 464XLAT, but only a couple of them reached 90%+.
If one would think logically about this fact then one would conclude that 90% is not easy to reach, not overnight.
I have seen in some RFC (do not remember the number) that 75% is easy to reach (it was supported by numbers), but it was a few years ago - this data should be better now because we have 20%+ CAGR for Webservers IPv6 support.
Hence, the truth is probably somewhere between 75% and 90%.
Eduard
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: Sunday, March 28, 2021 11:20 PM
To: [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

 

    seems to be trivial.

    For example:

    Rationale:

    Gábor

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 29 Mar 2021 07:41:13 +0000

Do we have any fixed carrier in the world that has reached 75% for IPv6?
It is primarily "CPE problem". Mobile UE could be not compliant too, but It is a much smaller probability.
Eduard
-----Original Message-----
From: Vasilenko Eduard 
Sent: Monday, March 29, 2021 10:34 AM
To: 'JORDI PALET MARTINEZ' <jordi.palet=[email-masked]>; [email-masked]
Subject: RE: [v6ops] draft-vf-v6ops-ipv6-deployment

Hi Jordi,
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: Sunday, March 28, 2021 11:20 PM
To: [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

 

    seems to be trivial.

    For example:

    Rationale:

    Gábor

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 29 Mar 2021 07:52:57 +0000

Hi,
Thank you for the inputs about this statement "For this reason, when IPv6 increases to a certain limit, it would be better to switch to the IPv6-only stage."
I agree that it is not very specific and we should extend the concept in this paragraph.
We can say that the "limit" can be "when IPv4 traffic is vanishingly small" or "when IPv6 increases to more than 90%", anyway it is difficult to be conclusive since it also depends on several factors.
As highlighted by Jordi, it should be considered on a case-by-case basis looking at the different strategies of the ISPs and at the different costs involved. 
We will surely explain and add more considerations on this point in the next revision of the draft.

Regards,

Giuseppe

---

From: Lencse Gábor <[email-masked]>
Date: Mon, 29 Mar 2021 10:40:51 +0200

24/03/2021 17:22 keltezéssel, Alexandre Petrescu írta:

[...]

> options 464XLAT, DSLITE, MAP-E, MAP-T or lw4o6?

I can imagine two situations:

1. The user can configure in the CPE, which IPv4aaS technology is to be 
used. (Or at least it is displayed for the user without the opportunity 
to change the settings.)

This is the trivial case.

2. Even though one of the above mentioned IPv4aaS technologies is used, 
the CPE hides it from the user.

Of course, all five IPv4aaS technologies try to imitate the situation of 
carrier grade NAT for IPv4. The question is, whether the user can point 
out the fact the an IPv4aaS technology is used, and possibly also 
determine its kind.

Now, again, we may distinguish two cases:
- If the user can observe the traffic on the outside (WAN) interface of 
the CPE (e.g. using tcpdump, tshark, etc.), then it is quite easy.
- If the user cannot do that, then it is really interesting.

Can anyone recommend a suitable method for the second case?

Do you know such properties of the user side behavior (e.g. traffic 
pattern) of any of the 464XLAT, DSLITE, MAP-E, MAP-T or lw4o6 
technologies that could indicate their presence?

Gábor

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Mar 2021 21:43:02 +1300

On 29-Mar-21 20:41, Vasilenko Eduard wrote:
> It is primarily "CPE problem". 

Yes, so any ISP that supplies CPEs to most of its customers could easily reach 75%. I've had an ISP-provided dual stack CPE since 2013. However, I don't have data, and I don't know if any ISPs publish such data.

   Brian

> Mobile UE could be not compliant too, but It is a much smaller probability.
> Eduard

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 29 Mar 2021 09:13:05 +0000

Looking to the fact that RFC 8585 has specified IPv4aaS requirements to CPE less than 2 years ago
And Fixed Broadband CPEs have 5+years refreshment cycle.
I am very doubt that any fixed carrier has achieved 75% of IPv6 up today.
CPEs is the most expensive layer in carrier's networks (CPE itself + replacement cost) - very difficult to replace.
Potentially, it could be India, Pakistan, or Bangladesh where we could still see many new home subscribers per year. Or China where IPv6 is national program and money are not so important.

It would be very valuable if anyone would claim the biggest % for IPv6 FBB,
Even if carrier name would not be mentioned.

My expectation (not supported by facts) that FBB overnight is not more than 50%.
It is definitely above 30%, because I know example.
Ed/
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Monday, March 29, 2021 11:43 AM
To: [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

   Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 29 Mar 2021 11:19:31 +0200

HI Eduard,

Life is not so easy!

Even in a cellular network, you may still have an interesting % of users with old phones, even not "smartphones", they may be only 2.5G, etc. This is something key when you work in countries "less developed". This is one of the first parts of the analysis that we do for every customer, questions such as how many phones support IPv6? How many are iOS vs Android vs Windows (others typically are meaningless)? How much time typically take users to get a "new" phone? Are those "new" phones not really new but 2nd hand (so may be still not supporting IPv6)?, etc., etc.

So clearly if you know, for example, that 20% of your customers have outated or non-IPv6 phones, you will not be able to reach more than 80%.

In the case of residential (wireline) services, some users may have replaced the router, and it may not be IPv6-capable (according to the ISP offering), so they need to keep it dual-stack or just IPv4.

Also, some times (both in cellular and wireline), you don't do the IPv6 turn-on in the complete network in a single stage, you may do it per regions, or depending on users contracts, UE capabilities, etc., etc. It is very common an approach such as: New customers get IPv6-only with IPv4aaS + customers with replaced CPEs (failure of the CPE, moving from DSL to GPON, moving to a new location, etc.); then you plan for new service offerings that require a CPE replacement (example triple play, higher bandwidh, better WiFi coverage, 1Gig ports instead of fast ethernet, etc.) - in this case it may mean "customer needs to pay an small extra fee"; then you may want to enforce the replacement of the rest per regions, etc.

By the way, the 4 big mobile carriers in US are already over the 90%. This is reported by ISOC stats, based on measurements.

When I say overnight, I actually should explain it better, and explain that this % is from the users where you enable IPv6-only with IPv4aaS, otherwise, if you still have a % of users that still have older CPEs or UEs, it can't be true.

And yes, agree ... probably the figure is closer to 90% than 75%, at least in the case of mobile providers in stronger economies, which tend to have a faster "update" rate of smartphones.

El 29/3/21 9:33, "v6ops en nombre de Vasilenko Eduard" <[email-masked] en nombre de [email-masked]> escribió:

    Hi Jordi,
    -----Original Message-----
    From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
    Sent: Sunday, March 28, 2021 11:20 PM
    To: [email-masked]
    Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

        seems to be trivial.

        For example:

        Rationale:

        Gábor

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 29 Mar 2021 11:24:26 +0200

May be instead of having a "conclusive" description, we should use some of the text and data that we have been exchanging in the last emails?

My inputs are based on real deployment cases. I can't cite specific ones, because customer confidentiality, but also responding to Eduard, yes, there are wireline ISPs that already surpassed 75%. There are both cases where you can apply this % to the total network, and cases where you can apply this % to those customers that already got IPv6 deployed. Again, it depends on the specific ISP strategy (enabling all customers in "n" months, or "overnight" or "in different phases across a multi-year plan").
 
Regards,
Jordi
@jordipalet

El 29/3/21 9:53, "v6ops en nombre de Giuseppe Fioccola" <[email-masked] en nombre de [email-masked]> escribió:

    Hi,

    Regards,

    Giuseppe

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 29 Mar 2021 11:27:06 +0200

Free is probably one of them actually, also Swisscom, may be some of the Belgium ones, Sky, Comcast, etc.

If you look at the stats from APNIC, you can dig in a country level and then ASN level, I recall. Of course, this data only shows "total" network, and we don't know if for example only 50% of the customers got IPv6 enabled in every case. As Brian said, normally, ISPs don't publish this data.
 
Regards,
Jordi
@jordipalet

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

       Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 29 Mar 2021 11:30:36 +0200

I think most of the ISPs that reached >75% where "pre-" IPv6-only an IPv4aaS, they are based on dual-stack (even with IPv4-CGN), 6rd and DS-Lite.

El 29/3/21 11:13, "v6ops en nombre de Vasilenko Eduard" <[email-masked] en nombre de [email-masked]> escribió:

    -----Original Message-----
    From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
    Sent: Monday, March 29, 2021 11:43 AM
    To: [email-masked]
    Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

       Brian

---

From: Lencse Gábor <[email-masked]>
Date: Mon, 29 Mar 2021 11:35:21 +0200

29/03/2021 11:19 keltezéssel, JORDI PALET MARTINEZ írta:

[...]
> So clearly if you know, for example, that 20% of your customers have outated or non-IPv6 phones, you will not be able to reach more than 80%.
The percentage of what are we talking about?
- Percentage of the users: Yes, your statement is trivially true. :-)
- Percentage of the traffic: The 20% of users with old phones is likely 
to generate significantly less than 20% of the traffic. May be less then 
10%.

Gábor

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 29 Mar 2021 09:36:15 +0000

Hi Jordi,
IMHO: % of IPv6 traffic from IPv6-capable devices are interesting too.
It could be 90%+ with some IPv4aaS service.

But it is not the replacement of overall IPv6 traffic that is needed too. This number is more important for Carrier.
Eduard
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: Monday, March 29, 2021 12:20 PM
To: [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

HI Eduard,

Life is not so easy!

    Hi Jordi,
    -----Original Message-----
    From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
    Sent: Sunday, March 28, 2021 11:20 PM
    To: [email-masked]
    Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

        seems to be trivial.

        For example:

        Rationale:

        Gábor

---

From: Olivier MJ Crépin-Leblond <[email-masked]>
Date: Mon, 29 Mar 2021 11:51:51 +0200

> Even in a cellular network, you may still have an interesting % of users with old phones, even not "smartphones", they may be only 2.5G, etc. This is something key when you work in countries "less…

End of life coming soon:
https://www.lightreading.com/5g/goodbye-3g-heres-when-t-mobile-atandt-and-verizon-will-shut-it-off-/d/d-id/763362

Now some carriers are pausing their 3G network sunset for the time 
being, but 3G sunset is real. I shouldn't be too concerned about 2.5G 
phones - I imagine their battery life to be equally as abysmal.
Kindest regards,

Olivier

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 29 Mar 2021 11:54:46 +0200

Somebody told me once "stats can be read depending on how you want to ..."

Yes, we are mixing different metrics. The problem is that measuring % of traffic vs % of subscribers that actually can use IPv6 can't be done, unless the ISPs provide the data, or we look into source prefixes for the traffic ... which will be a huge project.

So I think it will be better to explain all this in the document instead of talking about "absolute %" and the reader will be able to have a better view with that perspective, instead of something that can be misleading.

El 29/3/21 11:36, "v6ops en nombre de Lencse Gábor" <[email-masked] en nombre de [email-masked]> escribió:

    [...]

    Gábor

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 29 Mar 2021 09:59:31 +0000

Hi Jordi,
Yes, this is exactly my plan.
I will surely use data from the mailing list discussion. I will also try to research public statistics on that, even if, as already noted, it will be very difficult since normally ISPs don't publish this data about their customers.

Regards,

Giuseppe

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: Monday, March 29, 2021 11:24 AM
To: [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

 
Regards,
Jordi
@jordipalet

    Hi,

    Regards,

    Giuseppe

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 Mar 2021 12:15:19 +0200

Le 29/03/2021 à 11:30, JORDI PALET MARTINEZ a écrit :
> I think most of the ISPs that reached >75% where "pre-" IPv6-only an
>  IPv4aaS, they are based on dual-stack (even with IPv4-CGN), 6rd and
>  DS-Lite.

Maybe 'IPv4aaS' is a term to mean 'IPv4 as a service', in comparison to
the term 'IPv6 as a service'.  In that sense, IPv4aaS means that IPv4
packets are encapsulated in IPv6 packets.

But from the point of 'service', there are some difficulties.

Free recently offered at home an option called "fixed IP V4 address full
stack" ("adresse IP fixe V4 full-stack", fr.)  It is 'full stack' in
that the IP address can service all port numbers. A 'non full' stack IP
V4 address is probably an address where only some port numbers are
serviced by a CPE and the others are serviced at the same IP address but
at another neighboring CPE.  Here again, remark that this frenglish
'full-stack' term is not related to the term 'IPv4 IPv6 dual stack'.

Hopefully this helps towards clarifying, and not add to confusion.

For my part, I would like to ask whether the term 'IPv4aaS' is defined
in an RFC?

Alex

> 
> 
> El 29/3/21 11:13, "v6ops en nombre de Vasilenko Eduard" 
> <[email-masked] en nombre de [email-masked]> 
> escribió:
> 
> Looking to the fact that RFC 8585 has specified IPv4aaS requirements
>  to CPE less than 2 years ago And Fixed Broadband CPEs have 5+years 
> refreshment cycle. I am very doubt that any fixed carrier has 
> achieved 75% of IPv6 up today. CPEs is the most expensive layer in 
> carrier's networks (CPE itself + replacement cost) - very difficult 
> to replace. Potentially, it could be India, Pakistan, or Bangladesh 
> where we could still see many new home subscribers per year. Or China
> where IPv6 is national program and money are not so important.
> 
> It would be very valuable if anyone would claim the biggest % for 
> IPv6 FBB, Even if carrier name would not be mentioned.
> 
> My expectation (not supported by facts) that FBB overnight is not 
> more than 50%. It is definitely above 30%, because I know example. 
> Ed/ -----Original Message----- From: v6ops 
> [mailto:[email-masked]] On Behalf Of Brian E Carpenter Sent:
>  Monday, March 29, 2021 11:43 AM To: [email-masked] Subject: Re: 
> [v6ops] draft-vf-v6ops-ipv6-deployment
> 
>> Do we have any fixed carrier in the world that has reached 75% for
>>  IPv6? It is primarily "CPE problem".
> 
> Yes, so any ISP that supplies CPEs to most of its customers could 
> easily reach 75%. I've had an ISP-provided dual stack CPE since 2013.
> However, I don't have data, and I don't know if any ISPs publish such
> data.
> 
> Brian
> 
>> Mobile UE could be not compliant too, but It is a much smaller 
>> probability. Eduard -----Original Message----- From: Vasilenko 
>> Eduard Sent: Monday, March 29, 2021 10:34 AM To: 'JORDI PALET 
>> MARTINEZ' <jordi.palet=[email-masked]>; 
>> [email-masked] Subject: RE: [v6ops] draft-vf-v6ops-ipv6-deployment
>> 
>> Hi Jordi, Your last statement is probably too strong. About half of
>> Mobile carriers have 464XLAT, but only a couple of them reached 
>> 90%+. If one would think logically about this fact then one would 
>> conclude that 90% is not easy to reach, not overnight. I have seen
>>  in some RFC (do not remember the number) that 75% is easy to reach
>>  (it was supported by numbers), but it was a few years ago - this 
>> data should be better now because we have 20%+ CAGR for Webservers
>>  IPv6 support. Hence, the truth is probably somewhere between 75% 
>> and 90%. Eduard -----Original Message----- From: v6ops 
>> [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ 
>> Sent: Sunday, March 28, 2021 11:20 PM To: [email-masked] Subject: 
>> Re: [v6ops] draft-vf-v6ops-ipv6-deployment
>> 
>> Note also that for residential ISPs, reaching IPv6 levels close to
>>  90% is trivial. It happens overnight, because the big volume of 
>> traffic to CDNs such as Netflix, Youtube/Google, Facebook, Akamai,
>>  etc., etc. which have already IPv6 on.
>> 
>> 
>> 
>> 
>> El 28/3/21 21:25, "v6ops en nombre de Lencse Gábor" 
>> <[email-masked] en nombre de [email-masked]> escribió:
>> 
>> "For this reason, when IPv4 traffic is vanishingly small (e.g. less
>> than 1%), it would be better to switch to the IPv6-only stage."
>> 
>> seems to be trivial.
>> 
>> "For this reason, when IPv6 increases to a certain limit (e.g. more
>> than 90%), it would be better to switch to the IPv6-only stage."
>> 
>> Rationale: - Introducing an IPv4aaS technology has its costs, but 
>> the selling of the lions share of the public IPv4 addresses brings
>>  in more money. - The maintenance cost of the IPv4aaS solution is 
>> less than that of a complete IPv4 network.
>> 
>> I do not state that it is true, I just ask, if it can be true. 
>> Because if it is so, then it could be a better guidance.
>> 
>> Gábor
>> 
>>>> Agree, right thing is to use IPv6-only and IPv4aaS, I was just
>>>>  saying that Free was the initiation of 6RD and they were using
>>>>  that. I’m not saying they still use the same or they should 
>>>> keep using the same.
>>> But please consider that if an operator is already supporting its
>>> customers using classical dual stack or a solid solution like
>>> 6rd, there may be no good reason to change for the next ten years
>>> or more. Dual stack has no time limit.
>>> 
>>> I think this statement in the draft: "For this reason, when IPv6
>>>  increases to a certain limit, it would be better to switch to 
>>> the IPv6-only stage." is too vague to be useful. Switching costs
>>>  might be very high, including loss of customers. In fact, the 
>>> criterion for switching might be as simple as "when IPv4 traffic
>>>  is vanishingly small."
>>> 
>>> Brian
>>> 
>>> 
>>> 
>>>> 
>>>> 
>>>> Regards,
>>>> 
>>>> Jordi
>>>> 
>>>> @jordipalet
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> El 28/3/21 9:14, "v6ops en nombre de [email-masked] 
>>>> <mailto:[email-masked]>" <[email-masked] 
>>>> <mailto:[email-masked]> en nombre de 
>>>> [email-masked] <mailto:[email-masked]>> 
>>>> escribió:
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 6rd is a mode of IPv6 over IPv4, it is opposite to the concept
>>>>  of "IPv4 as a Service" of IPv6-only, so it should be replaced
>>>>  to make IPv6 as a univeral and underlying network protocol 
>>>> gradually.
>>>> 
>>>> 
>>>> 
>>>> Regards
>>>> 
>>>> Chongfeng
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> *From:* JORDI PALET MARTINEZ 
>>>> <mailto:jordi.palet=[email-masked]>
>>>> 
>>>> *Date:* 2021-03-25 17:15
>>>> 
>>>>> MAP-T
>>>> It's
>>>> freebox at
>>>> absolutely
>>>>  cellular
>>>> computer
>>>> if partially, including attached files, is strictly prohibited,
>>>> if partially, including attached files, is strictly prohibited,

---

From: <[email-masked]>
Date: Mon, 29 Mar 2021 10:18:55 +0000

BTW are you aware of any vendor implementations for these IPv4aaS technologies in service provider edge devices and large field deployments anywhere? AFAI remember most of the legacy vendors did not push these technologies very much, or did I overlook something in the last few month?
Thanks
	Olaf

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Vasilenko Eduard
Sent: Montag, 29. März 2021 11:13
To: Brian E Carpenter <[email-masked]>; [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

Looking to the fact that RFC 8585 has specified IPv4aaS requirements to CPE less than 2 years ago And Fixed Broadband CPEs have 5+years refreshment cycle.
I am very doubt that any fixed carrier has achieved 75% of IPv6 up today.
CPEs is the most expensive layer in carrier's networks (CPE itself + replacement cost) - very difficult to replace.
Potentially, it could be India, Pakistan, or Bangladesh where we could still see many new home subscribers per year. Or China where IPv6 is national program and money are not so important.

It would be very valuable if anyone would claim the biggest % for IPv6 FBB, Even if carrier name would not be mentioned.

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Monday, March 29, 2021 11:43 AM
To: [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

   Brian

> To: 'JORDI PALET MARTINEZ' 
> <jordi.palet=[email-masked]>; [email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 29 Mar 2021 12:21:43 +0200

It is not just encapsulation can be translation or combinations. See RFC8585.

Regards,
Jordi
@jordipalet

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

    Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 Mar 2021 12:23:56 +0200

> Somebody told me once "stats can be read depending on how you want to

For what is worth, in a recent report it is written that "[...] [only]
27% of most visited websites in France are accessible in IPv6"
("[seulement] 27 % des sites web les plus visités en France sont
aujourd’hui accessibles en IPv6.", fr.)

> Yes, we are mixing different metrics. The problem is that measuring %
> of traffic vs % of subscribers that actually can use IPv6 can't be 
> done, unless the ISPs provide the data, or we look into source 
> prefixes for the traffic ... which will be a huge project.
> 
> So I think it will be better to explain all this in the document 
> instead of talking about "absolute %" and the reader will be able to
>  have a better view with that perspective, instead of something that
>  can be misleading.

Other than that metric, there is an organizational metric that could be
added.

An organizational metric would express whether or not ISPs have teams or
groups of people focused on an IPv6 part of the business.  It could say
how large these groups are, and what layer in a hierarchy are they
represented.

Alex

> 
> 
> El 29/3/21 11:36, "v6ops en nombre de Lencse Gábor" 
>> So clearly if you know, for example, that 20% of your customers 
>> have outated or non-IPv6 phones, you will not be able to reach more
>> than 80%.
> The percentage of what are we talking about? - Percentage of the 
> users: Yes, your statement is trivially true. :-) - Percentage of the
> traffic: The 20% of users with old phones is likely to generate 
> significantly less than 20% of the traffic. May be less then 10%.
> 
> Gábor
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 Mar 2021 12:27:31 +0200

> It is not just encapsulation can be translation or combinations. See RFC8585.

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

I thought the core networks of CPE operators (and mobile operators) are 
mostly situated on an IPv4 substrate, but I might be wrong.

I have no way to check.

Alex

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 29 Mar 2021 12:27:50 +0200

Hi Olaf,

Yes, there are more CPE vendors that support them that you could imagine. Look at the co-authors of RFC8585.

I'm working also with several other vendors, most of them provide firmware per-project basis. Also, I recall Sky developed their own.

And of course, you have support for all them in OpenWRT and VPP.

Also, the BBForum I recall supports DS-LITE and MAP, at least?

As a note of a recent case, still not completed, I'm working with several CPE vendors in a 25.000.000 subscribers deployment using 464XLAT (DSL, GPON and cellular). Unfortunately, it is slow down because the Covid and I can't disclose further details. I just can say that the pilot "proof of concept" worked perfectly for already a year.

Regards,
Jordi
@jordipalet

El 29/3/21 12:19, "[email-masked] en nombre de [email-masked]" <[email-masked] en nombre de [email-masked]> escribió:

    -----Original Message-----
    From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
    Sent: Monday, March 29, 2021 11:43 AM
    To: [email-masked]
    Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

       Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 29 Mar 2021 12:45:35 +0200

ISPs that deployed IPv6, typically have dual-stack core.

IPv6-only with IPv4aaS allows them to do IPv6-only in the "distribution" and/or "access", sometimes for all the subscribers, or only a subset (example residential vs business). This allows to get rid of many IPv4 addresses and use some of them (as you will require much less) in the NAT64 (in the case of 464XLAT). You can then reuse those IPv4 addresses in other part of the network (example business customers that require a "real" dual-stack) or even transfer them to other ISPs that don't use IPv4aaS, etc.

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

    I have no way to check.

    Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 Mar 2021 13:26:32 +0200

Le 29/03/2021 à 12:45, JORDI PALET MARTINEZ a écrit :
> IPv6-only with IPv4aaS allows them to do IPv6-only in the 
> "distribution" and/or "access", sometimes for all the subscribers,
> or only a subset (example residential vs business).

I think this might be specific to CPE deployments, and different than in
cellular.

In cellular networks, the first hop from the phone to the P-GW is often,
indeed, an IPv6-only support; in it IPv4 packets are encapsulated.  This
can be seen in the parameter PDP type that is set in the smartphone.  It
is a parameter that can and must be set by the end user in the
Parameters.  Generally, there are 3 possible PDP types: IPv4, IPv6 and
IPv4IPv6.

When the mobile operator requests the end user to set PDP type 'IPv6' in
her smartphone then one might assume a sort of 'IPv4aaS' to happen indeed.

But even then, it is not that simple.  The core network of mobile
operators are often (last time I checked) on IPv4 substrate - GTP is an
UDPv4 protocol.  In that part of the network it is no longer 'IPv4 as a
service', but 'IPv4 carried in IPv4'.

At that point, we might be talking about a 'half-full IPv4aaS', and not
really a 'full IPv4aaS'.  A 'full IPv4aaS' would be when all the
transport in the edge and core are IPv6 entirely and only.  I am afraid
that does not exist -yet - but I dont know for sure.

In CPE networks it might be different.

The questions would be:
- how to check in a CPE network whether the first hop between CPE and
   the core network is on IPv6?
- how to check in the core of the CPE network whether the transport is
   on IPv6?

Alex

  This allows to get
> rid of many IPv4 addresses and use some of them (as you will require 
> much less) in the NAT64 (in the case of 464XLAT). You can then reuse 
> those IPv4 addresses in other part of the network (example business 
> customers that require a "real" dual-stack) or even transfer them to 
> other ISPs that don't use IPv4aaS, etc.

> 
> 
> 
> El 29/3/21 12:28, "v6ops en nombre de Alexandre Petrescu" 
> It says: ""IPv4aaS" stands for "IPv4-as-a-Service", meaning 
> transition technologies for delivering IPv4 in IPv6-only 
> connectivity."
> 
> I thought the core networks of CPE operators (and mobile operators) 
> are mostly situated on an IPv4 substrate, but I might be wrong.
> 
> I have no way to check.
> 
> Alex
> 
>> 
>> El 29/3/21 12:16, "v6ops en nombre de Alexandre Petrescu" 
>>> I think most of the ISPs that reached >75% where "pre-"
>>> IPv6-only an IPv4aaS, they are based on dual-stack (even with
>>> IPv4-CGN), 6rd and DS-Lite.
>> 
>> Maybe 'IPv4aaS' is a term to mean 'IPv4 as a service', in 
>> comparison to the term 'IPv6 as a service'.  In that sense,
>> IPv4aaS means that IPv4 packets are encapsulated in IPv6 packets.
>> 
>> Free recently offered at home an option called "fixed IP V4
>> address full stack" ("adresse IP fixe V4 full-stack", fr.)  It is
>> 'full stack' in that the IP address can service all port numbers. A
>> 'non full' stack IP V4 address is probably an address where only
>> some port numbers are serviced by a CPE and the others are serviced
>> at the same IP address but at another neighboring CPE.  Here
>> again, remark that this frenglish 'full-stack' term is not related
>> to the term 'IPv4 IPv6 dual stack'.
>> 
>> For my part, I would like to ask whether the term 'IPv4aaS' is 
>> defined in an RFC?
>> 
>> Alex
>> 
>>> 
>>> 
>>> Looking to the fact that RFC 8585 has specified IPv4aaS 
>>> requirements to CPE less than 2 years ago And Fixed Broadband 
>>> CPEs have 5+years refreshment cycle. I am very doubt that any 
>>> fixed carrier has achieved 75% of IPv6 up today. CPEs is the
>>> most expensive layer in carrier's networks (CPE itself +
>>> replacement cost) - very difficult to replace. Potentially, it
>>> could be India, Pakistan, or Bangladesh where we could still see
>>> many new home subscribers per year. Or China where IPv6 is
>>> national program and money are not so important.
>>> 
>>> more than 50%. It is definitely above 30%, because I know 
>>> example. Ed/ -----Original Message----- From: v6ops 
>>> [mailto:[email-masked]] On Behalf Of Brian E Carpenter 
>>> Sent: Monday, March 29, 2021 11:43 AM To: [email-masked]
>>>> Do we have any fixed carrier in the world that has reached 75% 
>>>> for IPv6? It is primarily "CPE problem".
>>> 
>>> easily reach 75%. I've had an ISP-provided dual stack CPE since
>>> 2013. However, I don't have data, and I don't know if any ISPs
>>> publish such data.
>>> 
>>> Brian
>>> 
>>>> Hi Jordi, Your last statement is probably too strong. About 
>>>> half of Mobile carriers have 464XLAT, but only a couple of
>>>> them reached 90%+. If one would think logically about this fact
>>>> then one would conclude that 90% is not easy to reach, not 
>>>> overnight. I have seen in some RFC (do not remember the
>>>> number) that 75% is easy to reach (it was supported by
>>>> numbers), but it was a few years ago - this data should be
>>>> better now because we have 20%+ CAGR for Webservers IPv6
>>>> support. Hence, the truth is probably somewhere between 75% and
>>>> 90%. Eduard -----Original Message----- From: v6ops
>>>> [mailto:[email-masked]] On Behalf Of JORDI PALET
>>>> MARTINEZ Sent: Sunday, March 28, 2021 11:20 PM To:
>>>> [email-masked] Subject: Re: [v6ops] 
>>>> draft-vf-v6ops-ipv6-deployment
>>>> 
>>>> Note also that for residential ISPs, reaching IPv6 levels
>>>> close to 90% is trivial. It happens overnight, because the big
>>>> volume of traffic to CDNs such as Netflix, Youtube/Google,
>>>> Facebook, Akamai, etc., etc. which have already IPv6 on.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> "For this reason, when IPv4 traffic is vanishingly small (e.g. 
>>>> less than 1%), it would be better to switch to the IPv6-only 
>>>> stage."
>>>> 
>>>> seems to be trivial.
>>>> 
>>>> "For this reason, when IPv6 increases to a certain limit (e.g. 
>>>> more than 90%), it would be better to switch to the IPv6-only 
>>>> stage."
>>>> 
>>>> Rationale: - Introducing an IPv4aaS technology has its costs, 
>>>> but the selling of the lions share of the public IPv4
>>>> addresses brings in more money. - The maintenance cost of the
>>>> IPv4aaS solution is less than that of a complete IPv4 network.
>>>> 
>>>>>> Agree, right thing is to use IPv6-only and IPv4aaS, I was 
>>>>>> just saying that Free was the initiation of 6RD and they 
>>>>>> were using that. I’m not saying they still use the same or 
>>>>>> they should keep using the same.
>>>>> But please consider that if an operator is already
>>>>> supporting its customers using classical dual stack or a
>>>>> solid solution like 6rd, there may be no good reason to
>>>>> change for the next ten years or more. Dual stack has no time
>>>>> limit.
>>>>> 
>>>>> I think this statement in the draft: "For this reason, when 
>>>>> IPv6 increases to a certain limit, it would be better to 
>>>>> switch to the IPv6-only stage." is too vague to be useful. 
>>>>> Switching costs might be very high, including loss of 
>>>>> customers. In fact, the criterion for switching might be as 
>>>>> simple as "when IPv4 traffic is vanishingly small."
>>>>> 
>>>>> Brian
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> Jordi
>>>>>> 
>>>>>> @jordipalet
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 6rd is a mode of IPv6 over IPv4, it is opposite to the 
>>>>>> concept of "IPv4 as a Service" of IPv6-only, so it should 
>>>>>> be replaced to make IPv6 as a univeral and underlying 
>>>>>> network protocol gradually.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Regards
>>>>>> 
>>>>>> Chongfeng
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> mailing list
>>>>>> 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.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 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: Mon, 29 Mar 2021 12:04:09 +0000

Hi Gabor,
Thanks a lot for your support and for the suggestion regarding IPv6 security.
We will have a look at your paper and revise our security part.
I think we can also highlight the main points from https://tools.ietf.org/html/draft-ietf-opsec-v6-24#section-2.7

Regards,

Giuseppe

From: v6ops [mailto:[email-masked]] On Behalf Of Gabor LENCSE
Sent: Saturday, March 27, 2021 4:35 PM
To: [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment and draft-lmhp-v6ops-transition-comparison

Dear All,

I have read draft-vf-v6ops-ipv6-deployment-02 and I found it useful and I support its adoption.

"Yet, this worsening effect may appeae as disturbing for a plain transition to IPv6." --> "Yet, this worsening effect may appear as disturbing for a plain transition to IPv6."

Regarding IPv6 Security in Section 11.4, I think it is also worth considering the additional security issues brought into existence by the applied IPv6 transition technologies used to implement IPv4aaS, like 464XLAT, DS-Lite, etc. You can find some basic hints in our paper:

G. Lencse and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", Computers & Security (Elsevier), vol. 77, no. 1, pp. 397-411, August 1, 2018, DOI: 10.1016/j.cose.2018.04.012

Available from: http://www.hit.bme.hu/~lencse/publications/ECS-2018-Methodology-revised.pdf

As for our draft, draft-lmhp-v6ops-transition-comparison-06, I am working on an RFC 8219 compliant performance measurement tool to be able to add relevant data to Section 5 about Performance Comparison. I have just prepared the very much alpha state version of a stateful NAT64 tester, by enabling siitperf for stateful tests: https://github.com/lencsegabor/siitperf/tree/stateful

It is capable of benchmarking both stateful NAT64 and stateful NAT44 (CGNAT) implementations. Its documentation is to be updated yet, but I am glad the help, if any you would like to use it.

Best regards,

Gábor

p.s.: I have corrected the subject line, as I think Fred intended to include both drafts in it.
On 3/27/2021 1:05 PM, Xipengxiao wrote:

Hi All,

XiPeng

-----Original Message-----

To: [email-masked]<mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>; draft-vf-v6ops-ipv6-

[email-masked]<mailto:[email-masked]>

deployment

On Mar 19, 2021, at 1:39 AM, Paolo Volpato <[email-masked]><mailto:[email-masked]>

wrote:

opinions, pro or con?

Along the same lines, are there opinions regarding the adoption of draft-vf-

v6ops-ipv6-deployment?

https://mailarchive.ietf.org/arch/search/?qdr=a&q=%22draft-lmhp-v6ops-

transition-comparison%22

https://mailarchive.ietf.org/arch/search/?qdr=a&q=%22draft-vf-v6ops-ipv6-

deployment%22

v6ops mailing list

---

From: [email-masked]
Date: Mon, 29 Mar 2021 15:47:12 +0200

> Of course, all five IPv4aaS technologies try to imitate the situation of carrier grade NAT for IPv4. The question is, whether the user can point out the fact the an IPv4aaS technology is used, and possibly also determine its kind.

While 464XLAT and DS-lite are based on CGNs that's not the intention nor implementation of MAP/LW46.

> - If the user can observe the traffic on the outside (WAN) interface of the CPE (e.g. using tcpdump, tshark, etc.), then it is quite easy.
> Do you know such properties of the user side behavior (e.g. traffic pattern) of any of the 464XLAT, DSLITE, MAP-E, MAP-T or lw4o6 technologies that could indicate their presence?

Assuming you can also observe traffic on a outside host.

You can use various NAT detection techniques.
See if you see common bits between the users IPv6 address and the outside IPv4 address.
See if ports are restricted and try to identify the port allocation algorithm used.
Although the MAP PSID algorithm might also be used by NAT444 CGNs.
You can see if you get IP options or DF flag behaviour to detect translation.

It's going to be a bunch of heauristics thought.
Even the MTU difference between v4 (encapsulated or translated) and v6 could be masked by the ISP.

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 Mar 2021 15:53:59 +0200

> And it has no IID at all, not "/32".

I must complain about this, sorry :-)

For some reason - why? - we end up with two kinds of unreachable
addresses: '64::'s and 'fc's (which can also be noted as 'fd's).

They are called "Local-Use IPv4/IPv6 Translation Prefix" and "ULA"s,
which are two different things.

Both these LUTs and ULAs cant go in the Internet - in principle - but
they are distinct spaces.

I wonder why LUT designers didnt use ULAs?

2. These 64:: prefixed addresses might actually _be_ attached to
interfaces, and not just results of algorithms or rt table entries.

I noticed DNS64 resolvers that tell on the Internet that they own such
address, so one would query it from inside that particular network, but
not from the Internet.

I think there might be a misunderstanding here: IANA does not allocate
them but people make it look as if they are allocated.

Also, there might be a problem at IANA as well.

IANA makes some confusing statement about this 64:: space.

For example it says that "64:ff9b::/96" is globally reachable, but when
when I try to reach it from an IPv6-only computer it isnt.  This
'globally reachable' is said on the same web page that says fc00::/7
(ULA) is not globally reachable.
https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

Maybe someone has a "64::" addresses computer that I could ping6 or
query with an nslookup server command?

Alex

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 29 Mar 2021 22:03:48 +0800

Hi，Giuseppe, Paolo,

This draft provide latest worldwide IPv6 status from various aspects，it is a constructive and useful document and I support its adoption. In addition, I provide some comments and personal suggestions as below,

P4.    Section 2 mentions "NAT and the address transfer to counter the IPv4 exhaustion".

It should be noted that in some cases, private address space can not provide adequate address,  it is reused in the same network which make the network even more complex, so NAT can not solve the problem of address shortage.
Since each address blocks of Internet is owned by specific owner, which is stored in routing DB for the verification of the authenticity of routing information, frequent address transfer may make the global routing unstable and even in disorder. 

P7,    Section 4 listed several transtion technologies, they mainly provide access to users at the edge of the network, so it better to add "for user access" when they are introdueced.

P8.  Section 5 illustrate about IPv6 for enterprise, IPv6 show its advantages in the case of acqiusition, when enterprise merge two networks which use IPv4 private addresses, the address space of the two networks may overlap which make the merging difficult.

P9. "In this latter case, the service is delivered solely on IPv6." should be changed to "In this latter case, the traffic is delivered solely on IPv6, Including the traffic originated from IPv4-based nodes.

     In addition,  "6to4" should be deleted since it has been outdated in IETF.

P10.    In  "The CPE has only an IPv6 address at the WAN side and uses an IPv6 connection to the operator gateway, e.g"
         My understanding is that In dual-stack mode, CPE has an IPv6 address and IPv4 address simultaneously.

         "when IPv6 increases to a certain limit, it would be better to switch to the IPv6-only stage." should be changed to "when IPv6 usage increases to a certain limit, it would be better to switch to the IPv6-only stage."

In section 8.1.2, the following clause should be added,
    "For an network operator, IPv6-only means that the whole network use IPv6 as the universal network protocol for all traffic delivery."

P12.  In "All MPLS services can be guaranteed in IPv6 as well through 6PE/6VPE protocols."

        It should be noted that the coverage of MPLS is limted, for instance, it does not reach into the cloud/DC generally, therefore, it can not take effect in this scenario.

p13， I propose the following clause about IPv6 action plan should be added following the clause of  "The  Call for Comment is at [US-FR] and [US-CIO]."

     "In China, the goverment launched IPv6 action plan in 2017, which requires that networks, applications and terminal devices will fully support the adoption of IPv6 by the end of 2025."

      Reference: http://www.china.org.cn/business/2017-11/27/content_41948814.htm 

Regards
Chongfeng

From: Fred Baker
Date: 2021-03-27 12:58
To: [email-masked]
CC: [email-masked]; [email-masked]
Subject: [v6ops] draft-vf-v6ops-ipv6-deployment and draft-vf-v6ops-ipv6-deployment

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 Mar 2021 16:06:37 +0200

I think we should first say what one means by 'IPv4aaS'.

I think this term is very loosely defined technically.

It might be a very good marketing term, and an excellent overall goal 
for developments of features on roadmaps.

But I have some ideas about how to check what you ask.

> Can anyone recommend a suitable method for the second case?

One could check tables of IP addresses of DNS64 resolvers offered by 
some operators to their respective users (but not to others).  Such a 
table is available for all operators in France, at regulator.  On page 
57 of the pdf at this URL one can see such a table
https://en.arcep.fr/uploads/tx_gspublication/report-state-internet_2020-edition_250620-ENG.pdf

If a provider provides a DNS64 resolver it is highly likely that end 
users might benefit from some features of the concept 'IPv4aaS'.

> technologies that could indicate their presence?

That is an excellent question.  I think it is possible to write a packet 
analyzer that looks at the interface of the end user and depending on 
the contents of the packets to determine a pattern telling whether or 
not 464XLAT is used.

 From these two things (tables of DNS64 resolvers, and packet 
analyzers), it might be possible to build web sites that not only reply 
to the question "what is my IP address" but also tell whether "IPv4aaS" 
is used or not.

Also, right now a "what is my IP addreess" website replies my
with my IP address, but can also tell whether I am behind a NAT or not.
  A similar logic could be used to tell whether I am behind a another
sort of address translation.

Alex

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 29 Mar 2021 14:53:20 +0000

> From: v6ops <[email-masked]> On Behalf Of Fred Baker
> Sent: Friday, March 26, 2021 11:58 PM
> To: [email-masked]
> v6ops-ipv6-deployment I can say we are in favor of the WG adoption. Not only
> is it a good description of the transition technologies to IPv6, but it also
> November. The authors of draft-vf-v6ops-ipv6-deployment would like to see it
> adopted. The two sets of authors are disjoint. I therefore have at least nine

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 29 Mar 2021 15:09:12 +0000

Hi Chongfeng,
Thanks a lot for your support.
I appreciate your comments which we can address in the next version.
Please find my answers inline tagged as [GF]

Regards,

Giuseppe

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 29, 2021 4:04 PM
To: Fred Baker <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment and draft-vf-v6ops-ipv6-deployment

Hi，Giuseppe, Paolo,

[GF]: Agree, it is important to highlight in this section how private 10.0.0.0/8 space (RFC1918) is not enough in some cases. Also the transfer of IPv4 addresses has also some drawbacks for the global routing as you noted.

[GF]: Will do.

[GF]: Good point. We can add this motivation for IPv6 for enterprise.

[GF]: Will do.

[GF]: Ok, I will revise this sentence.

[GF]: There was some discussion on this statement in a related thread. We plan to extend the concept of this paragraph and we will try to better define the "limit" that could be "when IPv4 traffic is vanishingly small" or "when IPv6 usage increases to a certain limit" as you suggested. We will include some considerations about what is a reasonable limit, in particular based on the data from the mailing list discussion or that we can find looking at public statistics.

[GF]: Sure, Will do.

[GF]: Ok, it is better to specify.

[GF]: This is a very good reference about the government incentives in China. We will surely add it.

Regards
Chongfeng

From: Fred Baker<mailto:[email-masked]>
Date: 2021-03-27 12:58
To: [email-masked]<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [v6ops] draft-vf-v6ops-ipv6-deployment and draft-vf-v6ops-ipv6-deployment

> On Mar 19, 2021, at 1:39 AM, Paolo Volpato <[email-masked]<mailto:[email-masked]>> wrote:
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 29 Mar 2021 15:11:46 +0000

<sigh> This time with comments. </sigh>

> people that would like to see us adopt and publish it. What other folks have

I've looked at this draft and am not in favor of adopting it with its current scope and (lack of) focus.
I think the statistics will be stale before publication.
I was getting confused in reading various sections as to which market segment it was trying to address.
The draft jumps around various market segments in its various sections, and it's often unclear as to
which market segment a section is referring to. I should point out that a lot of enterprise network
equipment involved in IPv6 transition is also referred to as "CPE", since that is a generic term that means
"Customer Premises Equipment". But the enterprise CPE that provides IP connectivity to the Internet 
and the mass market CPE that provides IP connectivity to the Internet are very dissimilar.

If this draft were to be more focused in what it wanted to accomplish, there might be something to adopt.

> Along the same lines, are there opinions regarding the adoption of draft-vf-

I've looked at this draft and am in favor of adoption. I think it has some very useful and practical information.
One thing I'd like to mention is that if anyone wants configuration for 464XLAT and lw406 via TR-069,
this is very simple to achieve. Just tell me what parameters you think are needed (like enable/disable
and any parameters that need to be configured) and agree to review the proposed additions to TR-181
(which I would provide by email to specific people or I could liaise to the WG) and it can be in the next 
release of TR-181 (most likely end of this year).

Barbara

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 29 Mar 2021 16:36:39 +0000

Hi Barbara,
Thank you for being in favor of the adoption of draft-vf-v6ops-ipv6-deployment.
The fact that the configuration for 464XLAT and lw4o6 via TR-069 can be simple is relevant.

Regards,

Giuseppe

-----Original Message-----
From: STARK, BARBARA H [mailto:[email-masked]] 
Sent: Monday, March 29, 2021 5:12 PM
To: 'Fred Baker' <[email-masked]>; [email-masked]' <[email-masked]>
Cc: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: RE: [v6ops] draft-vf-v6ops-ipv6-deployment and draft-vf-v6ops-ipv6-deployment

> v6ops-ipv6-deployment I can say we are in favor of the WG adoption. 
> Not only is it a good description of the transition technologies to 
> IPv6, but it also constitutes a basis for our draft.
> 
> OK, let me put this to the working group. We asked about adoption of 
> draft- lmhp-v6ops-transition-comparison once before (in January 2020), 
> and got essentially no response. It has come up on the list twice 
> since, in July and in November. The authors of 
> draft-vf-v6ops-ipv6-deployment would like to see it adopted. The two 
> sets of authors are disjoint. I therefore have at least nine people 
> that would like to see us adopt and publish it. What other folks have opinions, pro or con?

I've looked at this draft and am not in favor of adopting it with its current scope and (lack of) focus.
I think the statistics will be stale before publication.
I was getting confused in reading various sections as to which market segment it was trying to address.
The draft jumps around various market segments in its various sections, and it's often unclear as to which market segment a section is referring to. I should point out that a lot of enterprise network equipment involved in IPv6 transition is also referred to as "CPE", since that is a generic term that means "Customer Premises Equipment". But the enterprise CPE that provides IP connectivity to the Internet and the mass market CPE that provides IP connectivity to the Internet are very dissimilar.

> Along the same lines, are there opinions regarding the adoption of 
> draft-vf- v6ops-ipv6-deployment?

I've looked at this draft and am in favor of adoption. I think it has some very useful and practical information.
One thing I'd like to mention is that if anyone wants configuration for 464XLAT and lw406 via TR-069, this is very simple to achieve. Just tell me what parameters you think are needed (like enable/disable and any parameters that need to be configured) and agree to review the proposed additions to TR-181 (which I would provide by email to specific people or I could liaise to the WG) and it can be in the next release of TR-181 (most likely end of this year).

Barbara

---

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

Le 27/03/2021 à 05:58, Fred Baker a écrit :
>> For lmhp-v6ops-transition-comparison, on behalf of the authors of
>> draft-vf-v6ops-ipv6-deployment I can say we are in favor of the WG
>> adoption. Not only is it a good description of the transition
>> technologies to IPv6, but it also constitutes a basis for our
>> draft.
> 
> draft-lmhp-v6ops-transition-comparison once before (in January 2020),
> draft-vf-v6ops-ipv6-deployment?

Hi, Fred,

Generally speaking I am in favor of immediate adoption of drafts that 
describe IPv6 deployments, so of these ones too.

I have some input to offer from my experiments on an IPv6-only computer 
connected to the Internet.  For example I would suggest to not use any 
URL that does not work.

There is an 'IPv6 survey' reported in the draft, so I could offer 
another results of IPv6 survey, in English, but from France.

There is advice that is provided in the draft as well.  I might agree 
with some advice and disagree with some other, and suggest another one.

I would suggest to describe more of the pure translation-less IPv6 
deployments on 'bare metal' where IPv4 is completely absent.  Maybe use 
more of a perspective where IPv4 does not exist and IP is all there is 
to be (to signify IPv6).

Then there is the 64bit problem that I really believe to be a problem of 
IPv6 deployments and mobile networks, but which is not mentioned.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 Mar 2021 19:13:59 +0200

about the authorship,

[...]

> The two sets of authors are disjoint. I therefore have at least nine 
> people that would like to see us adopt and publish it. What other 
> folks have opinions, pro or con?

I am not an author.

Given that large number of authors it might be possible to go with a
schema of 2 authors whose names appear on the frontpage and the others
to be Contributors listed too but not on the front page.

The authors on the frontpage could be Editors.

I think it should be possible to let open the possibility to have more
than 10 authors in the Contributors.  Maybe they would be called
Authors, not just Contributors, if that is more inline with their
expectations.

Alex

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 29 Mar 2021 19:15:46 +0200

Regarding 8.1.2, I think that’s not correct.

Some operators may do IPv6-only at the access network only. It is a case-by-case basis.

I will try to update ASAP I’ve some free time:

https://tools.ietf.org/html/draft-palet-v6ops-ipv6-only-05

Regards,

Jordi

@jordipalet

El 29/3/21 17:09, "v6ops en nombre de Giuseppe Fioccola" <[email-masked] en nombre de [email-masked]> escribió:

Hi Chongfeng,

Regards,

Giuseppe

 

Hi，Giuseppe, Paolo,

 

[GF]: Will do.

[GF]: Will do.

[GF]: Sure, Will do.

Regards

Chongfeng

From: Fred Baker

Date: 2021-03-27 12:58

To: [email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 29 Mar 2021 19:22:10 +0200

For all the protocols, I think enable/disable, of course.

I will need to dig into lw4o6, may be the information in RFC8585 is sufficient.

For 464XLAT, I think it could be good to allow the configuration of a specific NAT64 prefix (either the WKP, or the NSP). By default, it should be the WKP.

All those things can be done via other protocols as described in RFC8585, however, TR-069 could be very helpful.

I'm happy to contribute to this work, if required.

As a first step, it will be helpful to understand if DS-LITE, MAP E/T, are already supported (or there is a draft on that), to have a view on how they are supported in order to make the support for lw4o6 and 464XLAT as much "symmetric" as possible.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 29 Mar 2021 17:32:23 +0000

> For 464XLAT, I think it could be good to allow the configuration of a specific
> NAT64 prefix (either the WKP, or the NSP). By default, it should be the WKP.
> 
> As a first step, it will be helpful to understand if DS-LITE, MAP E/T, are already
> supported (or there is a draft on that), to have a view on how they are supported
> in order to make the support for lw4o6 and 464XLAT as much "symmetric" as
> possible.

https://cwmp-data-models.broadband-forum.org/tr-181-2-14-1-cwmp.html#D.Device:2.Device.MAP.
https://cwmp-data-models.broadband-forum.org/tr-181-2-14-1-cwmp.html#D.Device:2.Device.DSLite.

Please feel free to unicast me if you have any questions.
Thx,
Barbara

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Mar 2021 07:42:00 +1300

I didn't mention IPv6aas. Of course that is too new for 75% to be a reasonable expectation.

As made clear by the draft, dual stack is the most popular solution today. At least where I live, the national move to fibre to the home has led to massive replacement of CPE in recent years. Put those facts together and you will find a lot of IPv6.

Regards
   Brian

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 29 Mar 2021 19:05:43 +0000

Hi Brian,
No doubt that Dual-Stack is the most popular worldwide at the moment.
But many carriers are still choosing.
Would you suggest Dual-Stack or IPv6-only services (IPv4aaS) for the new transition to IPv6? I am not sure that it is legal to call it "green-field".
Eduard
-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Monday, March 29, 2021 9:42 PM
To: Vasilenko Eduard <[email-masked]>; [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

Regards
   Brian

On 29-Mar-21 22:13, Vasilenko Eduard wrote:
> to CPE less than 2 years ago And Fixed Broadband CPEs have 5+years refreshment cycle.
> It would be very valuable if anyone would claim the biggest % for IPv6 
> FBB, Even if carrier name would not be mentioned.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Mar 2021 08:27:42 +1300

> Would you suggest Dual-Stack or IPv6-only services (IPv4aaS) for the new transition to IPv6? I am not sure that it is legal to call it "green-field".

I think each ISP will have to make its own OPEX and risk evaluations. For an operator with zero experience with IPv6, there is an obvious risk with IPv4aaS compared to dual stack.

   Brian

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 29 Mar 2021 20:25:30 +0000

> > Would you suggest Dual-Stack or IPv6-only services (IPv4aaS) for the new
> transition to IPv6? I am not sure that it is legal to call it "green-field".
> 
> I think each ISP will have to make its own OPEX and risk evaluations. 

I agree. I see from https://www.worldipv6launch.org/measurements/ that my current employer is shown as being at 75.24% for wireline and 83.52% wireless (of traffic to certain sites from those ASNs). My *guess* is that the remaining 25% of wireline is due to enterprises and people with non-IPv6 retail routers connected to the CE router, because it's been 9 years since IPv6 launch. Wireless is probably due to old (non VoLTE) UEs.

With that said, I can't envision recommending to my employer that it move from the current dual stack to IPv4aaS. It makes no sense business-wise and provides no benefit to customers. The costs of deploying dual stack are sunk. The help desk knows how to support it. It works extremely well.  Why recommend the high cost of deploying something new and different (on wireline: development and testing in the CE router and network elements, teams of people spending massive time, help desk training, etc.) when it provides zero benefit over what you have? Wireless is working fine, too.
Barbara

> For an
> operator with zero experience with IPv6, there is an obvious risk with IPv4aaS
> compared to dual stack.
> 
>    Brian
> 
> > Eduard
> > As made clear by the draft, dual stack is the most popular solution today. At
> least where I live, the national move to fibre to the home has led to massive
> replacement of CPE in recent years. Put those facts together and you will find a
> lot of IPv6.
> >
> > Regards
> >    Brian
> >
> refreshment cycle.
> >> CPEs is the most expensive layer in carrier's networks (CPE itself +
> replacement cost) - very difficult to replace.
> >> Potentially, it could be India, Pakistan, or Bangladesh where we could still see
> many new home subscribers per year. Or China where IPv6 is national program
> and money are not so important.
> >>
> >> Yes, so any ISP that supplies CPEs to most of its customers could easily reach
> 75%. I've had an ISP-provided dual stack CPE since 2013. However, I don't have
> data, and I don't know if any ISPs publish such data.
> >>
> >>    Brian
> >>
> >>> I have seen in some RFC (do not remember the number) that 75% is easy to
> reach (it was supported by numbers), but it was a few years ago - this data
> should be better now because we have 20%+ CAGR for Webservers IPv6
> support.
> >>> Note also that for residential ISPs, reaching IPv6 levels close to 90% is
> trivial. It happens overnight, because the big volume of traffic to CDNs such as
> Netflix, Youtube/Google, Facebook, Akamai, etc., etc. which have already IPv6
> on.
> >>>
> >>>
> >>>
> >>>
> >>> El 28/3/21 21:25, "v6ops en nombre de Lencse Gábor" <v6ops-
> [email-masked] en nombre de [email-masked]> escribió:
> >>>
> >>>     "For this reason, when IPv4 traffic is vanishingly small (e.g. less than 1%),
> >>>     "For this reason, when IPv6 increases to a certain limit (e.g. more than
> 90%), it would be better to switch to the IPv6-only stage."
> >>>
> >>>     Rationale:
> >>>     >> Agree, right thing is to use IPv6-only and IPv4aaS, I was just saying that
> Free was the initiation of 6RD and they were using that. I’m not saying they still
> use the same or they should keep using the same.
> customers using classical dual stack or a solid solution like 6rd, there may be no
> good reason to change for the next ten years or more. Dual stack has no time
> limit.
> >>>     >
> >>>     > is too vague to be useful. Switching costs might be very high, including
> loss of customers. In fact, the criterion for switching might be as simple as
> "when IPv4 traffic is vanishingly small."
> >>>     >
> >>>     >     Brian
> >>>     >
> >>>     >
> >>>     >
> >>>     >>
> >>>     >>
> >>>     >> Regards,
> >>>     >>
> >>>     >> Jordi
> >>>     >>
> >>>     >> @jordipalet
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >>
> <mailto:[email-masked]>" <[email-masked] <mailto:v6ops-
> [email-masked]> en nombre de [email-masked]
> <mailto:[email-masked]>> escribió:
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >> 6rd is a mode of IPv6 over IPv4, it is opposite to the concept of "IPv4
> as a Service" of IPv6-only, so it should be replaced to make IPv6 as a univeral
> and underlying network protocol gradually.
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >> Regards
> >>>     >>
> >>>     >> Chongfeng
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >>      El 24/3/21 17:23, "v6ops en nombre de Alexandre Petrescu" <v6ops-
> [email-masked] en nombre de [email-masked]> escribió:
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >>          > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-
> lmhp-v6ops-transition-comparison-
> 06__;!!BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdC
> dReme-vw$
> >>>     >>
> boxes
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
> BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
> xw$
> >>>     >>
> >>>     >>
> >>>     >>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
> BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
> xw$
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >>
> >>>     >>
> https://urldefense.com/v3/__http://www.theipv6company.com__;!!BhdT!zHXQ
> sXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCdIu5dCHQ$
> >>>     >>
> >>>     >>      The IPv6 Company
> >>>     >>
> >>>     >>
> >>>     >>
> 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
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
> BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
> xw$
> >>>     >>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
> BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
> xw$
> >>>     >>
> >>>     >>
> https://urldefense.com/v3/__http://www.theipv6company.com__;!!BhdT!zHXQ
> sXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCdIu5dCHQ$
> >>>     >> The IPv6 Company
> >>>     >>
> 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
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
> BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
> xw$
> >>>     >>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
> BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
> xw$
> >>>     >
> >>>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
> BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
> xw$
> >>>
> >>>
> >>>
> https://urldefense.com/v3/__http://www.theipv6company.com__;!!BhdT!zHXQ
> sXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCdIu5dCHQ$
> >>> 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
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
> BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
> xw$
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
> BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
> xw$
> >>>
> >>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
> BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
> xw$
> >>
> >
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
> BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
> xw$

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 29 Mar 2021 22:56:44 +0200

-> Yes, I forgot to mention it before. In my experience most of the "lack" of IPv6 traffic comes from enterprise customers. That's why I was insisting in wireline residential. Of course, when you look at stats (example APNIC) per ASN, most of the ISPs serve residential and enterprises using the same ASN, so again, we can't "look" into the details, unless the ISP discloses the data.

-> In most of the cases, it depends on your number of IPv4 addresses and future needs. Your employer may have sufficient addresses, most of the rest of the world is not in that situation. Of course, the alternative is to use CGN for the IPv4 (using only private addresses), but CGN and addresses to run it have a bigger cost even than replacing the CPEs. We did those numbers for real customers. There was a very recent discussion on that in NANOG, and several folks reached the same conclusion. There are also "service" consequences when using NAT444, such as that Sony Play Station blacklist forever the addresses detected in the CGN (NAT444, not in the case of NAT64), so you need to rotate your IPv4 pools, and at the end, you're forced to "buy" (via transfers) more and more IPv4 addresses. If that's the case, it is cheaper to buy "tons" of IPv4 addresses up-front and not use CGN at all ...

    Barbara

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 29 Mar 2021 18:46:10 -0400

Dear Authors

I found the the draft really helped capture the progression and current
state of IPv6 deployments across public and private sector vertical markets
as well as deployment considerations and challenges faced by operators.

The ETSI link I found very valuable especially the data point that web
content worldwide has up ticked to 15% and mostly the larger content
providers and streaming media technology giants like FAANG getting on board
Immediately with IPV6 and in some cases IPv6 only.

https://www.etsi.org/images/files/ETSIWhitePapers/etsi_WP35_IPv6_Best_Practices_Benefits_Transition_Challenges_and_the_Way_Forward.pdf

Page 11 of that link bar graph 2.2 would be good to show year over year
IPv6 web content growth.

This would be a good slide to capture the data point in the draft.

Nice to see that IPv6 is really making a dramatic gains and is outpacing
IPv4.  Awesome!!

A data point I think would be good to note in the draft  is as
infrastructure gets dual stacked from the SP ASNs down to fixed broadband
BNGs user community and wireless 4G 5G trending of IPv6 traffic on the
internet as compared to IPv4 and how the IPv6 traffic is trending up and
how far we are from the 50/50 breaking point.

When it comes to deployment, the infrastructure has to get built out which
had progresses nicely, after which as the infrastructure gets built as they
say “they will come” IPv6 traffic will eventually come and is coming but
the MAJOR factor here is IPv6 web content web sites proliferation to Dual
stack.

I think it’s worth mentioning Happy Eyeballs RFC 6555 and Happy Eyeballs 2
RFC 8305.  So one major aspect of application migration to IPv6 in the
framework of dual stacked is and the network build out and proliferation of
IPv6 at the network layer.  All host and network router OS’s by default
prefer IPv6 over IPv4.  Pre Happy Eyeballs was “sad eyeballs” meaning the
user experience as IPv6 was being deployed and in some cases IPv6 has
intermittent and not full routing connectivity.  So the host OS would send
out A / AAAA dns request and get a reply back and then would try IPv6 first
and then would undergo TCP RTO retransmission timeout approximately 20
seconds.  So with RFC 6555 what would happen is a almost simultaneous IPv4
and IPv6 connection SYN would go out with a 300ms preference for IPv6 goes
out sooner than IPv4 and so if IPv6 socket for whatever reason did not
establish the IPv6 connection would timeout in 300ms making it seamless to
the user of a network fault thus the name “Happy Eyeballs”.  This maybe
worth noting in the draft.

For enterprises the technical driver to IPv6 is much different then Service
Providers.  As most large companies NAT out to the internet and can use RFC
1918 address space internally that does allow shielding of the even large
enterprises from the impact of IPv4 assess depletion.  However for large to
very large companies or even mid size that are constantly buying up
companies as well as going through M&A that itself is a huge business
driver for those companies to move towards IPv6.  The other business driver
is service providers that also are involved in consulting services for IPv6
usually want the companies to be able to eat their own dog food so to speak
..here IPv6 is the dog food so in those cases as well the push for
enterprises to go dual stack ..eating their own ...some points here maybe
to mention under the enterprise section. For enterprises proxy capabilities
as well 4to6 allows enterprises to access v6 internet resource from
internal v4 only networks continuing the shielding of internal networks
from v4 depletion concerns and are still able to access v6 content.

>From a core proliferation perspective mention connecting IPv6 islands over
IPv4 core using 6PE global table routing and 6VPE VPN-IPv6 SAFI 128 129
over IPv4 core.  As operators migrate to v6 core MPLS LDPv6, SR-MPLSv6,
SRV6 they are able to start the elimination of IPv4 from the core underlay
transport while continuing to provide overlay v4 VPN services.

Kind Regards

Gyan

On Mon, Mar 29, 2021 at 4:58 PM JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

>     I agree. I see from https://www.worldipv6launch.org/measurements/
> that my current employer is shown as being at 75.24% for wireline and
> 83.52% wireless (of traffic to certain sites from those ASNs). My *guess*
> is that the remaining 25% of wireline is due to enterprises and people with
> non-IPv6 retail routers connected to the CE router, because it's been 9
> years since IPv6 launch. Wireless is probably due to old (non VoLTE) UEs.
>
> -> Yes, I forgot to mention it before. In my experience most of the "lack"
> of IPv6 traffic comes from enterprise customers. That's why I was insisting
> in wireline residential. Of course, when you look at stats (example APNIC)
> per ASN, most of the ISPs serve residential and enterprises using the same
> ASN, so again, we can't "look" into the details, unless the ISP discloses
> the data.
>
>     With that said, I can't envision recommending to my employer that it
> move from the current dual stack to IPv4aaS. It makes no sense
> business-wise and provides no benefit to customers. The costs of deploying
> dual stack are sunk. The help desk knows how to support it. It works
> extremely well.  Why recommend the high cost of deploying something new and
> different (on wireline: development and testing in the CE router and
> network elements, teams of people spending massive time, help desk
> training, etc.) when it provides zero benefit over what you have? Wireless
> is working fine, too.
>
> -> In most of the cases, it depends on your number of IPv4 addresses and
> future needs. Your employer may have sufficient addresses, most of the rest
> of the world is not in that situation. Of course, the alternative is to use
> CGN for the IPv4 (using only private addresses), but CGN and addresses to
> run it have a bigger cost even than replacing the CPEs. We did those
> numbers for real customers. There was a very recent discussion on that in
> NANOG, and several folks reached the same conclusion. There are also
> "service" consequences when using NAT444, such as that Sony Play Station
> blacklist forever the addresses detected in the CGN (NAT444, not in the
> case of NAT64), so you need to rotate your IPv4 pools, and at the end,
> you're forced to "buy" (via transfers) more and more IPv4 addresses. If
> that's the case, it is cheaper to buy "tons" of IPv4 addresses up-front and
> not use CGN at all ...
>
>     Barbara
>
>     > For an
>     > > I didn't mention IPv6aas. Of course that is too new for 75% to be
> a reasonable
>     > expectation.
>     > >
> requirements
> IPv6
> more than
>     > 50%.
> easily reach
> probability.
>     > >>> About half of Mobile carriers have 464XLAT, but only a couple of
> them
>     > reached 90%+.
>     > >>> If one would think logically about this fact then one would
> conclude that
>     > 90% is not easy to reach, not overnight.
>     > >>> From: v6ops [mailto:[email-masked]] On Behalf Of JORDI
> PALET
>     > >>> MARTINEZ
>     > >>>     >> Yes and not … IPv6 in IPv4 (6in4, proto41, etc.) … 6over4
> is another
>     > protocol.
>     > >>>     >>
>     > >>>     >>
>     > >>>     >>
> just saying that
> supporting its
> concept of "IPv4
>     > >>>     >>      Free was using 6RD initially, not sure if they
> turned into dual-stack,
>     > may be with IPv4 via CGN.
>     > >>>     >>
>     > >>>     >>
>     > >>>     >>
>     > >>>     >>      Regards,
>     > >>>     >>
>     > >>>     >>      Jordi
>     > >>>     >>
>     > >>>     >>      @jordipalet
>     > >>>     >>
>     > >>>     >>
>     > >>>     >>
>     > >>>     >>          home I could not see the options that you
> mention (464XLAT,
>     > DSLITE,
>     > >>>     >>
>     > >>>     >>          MAP-E, MAP-T, lw4o6).  One might say that they
> are there
>     > invisible, but
>     > >>>     >>
>     > >>>     >>          need IPv4 might be because I turned off the IPv4
> stack on my
>     > computer's
>     > >>>     >>
>     > >>>     >>          interface (Windows Properties on the Interface,
> check off IPv4).
>     > This
>     > >>>     >>
>     > >>>     >>          operation (turning off IPv4 in a computer) is
> possible only on
>     > Windows,
>     > >>>     >>
>     > >>>     >>          the IPv4 stack to work ok on that computer and,
> moreover, it
>     > needs some
>     > >>>     >>
>     > >>>     >>          times software features in the Client that
> support the 64::
>     > notation of
>     > >>>     >>
>     > >>>     >>          IPv6 addresses.  For example, thunderbird (a
> very modern MUA)
>     > does not
>     > >>>     >>
>     > >>>     >>          This means that if one wants to migrate more to
> IPv6 then one
>     > has to
>     > >>>     >>
> the exclusive use
> that any
> privileged
> use of the
> even if partially,
> even if partially,
> privileged or
> even if partially,
> even if partially,
> 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
> 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
-- 

<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: Mon, 29 Mar 2021 18:58:29 -0400

>From a core perspective in that framework mention RFC 5565 softwire mesh
framework which is a fancy way of using  VPN overlay tunnel context to
tunnel v6 edge over a v4 only core VPN IPv4 SAFI 128 129 global table 6PE
BGP LU SAFI 4 or the revere tunneling v4 edge over a v4 only core VPN IPv4
SAFI 128 129 global table 4PE BGP LU SAFI 4.  Basically the best practice
from a core architecture perspective is you never dual stack the core and
it’s either v4 only or v6 only but never dual stacked in a MPLS / SR VPN
overlay context.  In a case of IP routing no overlay just and underlay that
is the only time when dual stack is done in the core.

For DC architecture since overlay and underlay framework exist.  CLOS NVO3
BGP EVPN architecture the underlay as well is not dual stacked and is
either IPv4 only or IPv6 only but not both.

Kind Regards

Gyan

On Mon, Mar 29, 2021 at 6:46 PM Gyan Mishra <[email-masked]> wrote:

> For enterprises the technical driver to IPv6 is much different then
> Service Providers.  As most large companies NAT out to the internet and can
> use RFC 1918 address space internally that does allow shielding of the even
> large enterprises from the impact of IPv4 assess depletion.  However for
> large to very large companies or even mid size that are constantly buying
> up companies as well as going through M&A that itself is a huge business
>> -> Yes, I forgot to mention it before. In my experience most of the
>> "lack" of IPv6 traffic comes from enterprise customers. That's why I was
>> insisting in wireline residential. Of course, when you look at stats
>> (example APNIC) per ASN, most of the ISPs serve residential and enterprises
>> using the same ASN, so again, we can't "look" into the details, unless the
>> ISP discloses the data.
>>
>>     > >> My expectation (not supported by facts) that FBB overnight is
>> not more than
>>     > 50%.
>>     > >>> About half of Mobile carriers have 464XLAT, but only a couple
>> of them
>>     > reached 90%+.
>>     > >>>     >> Yes and not … IPv6 in IPv4 (6in4, proto41, etc.) …
>> 6over4 is another
>>     > protocol.
>>     > >>>     >>
>>     > >>>     >>
>>     > >>>     >>
>>     > >>>     >>          need IPv4 might be because I turned off the
>> IPv4 stack on my
>>     > computer's
>>     > >>>     >>
>> information, even
>> information, even
>> will be considered a

*Gyan Mishra*

*M 301 502-1347*

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 30 Mar 2021 01:34:05 +0000

Strongly support both the deployment and transition technology drafts.  

From an Enterprise perspective these represent the type of assistance and useful information we need to move forward with IPv6.  

The comparison draft addresses several issues that I have repetitively heard are a concern to many DC operators.  

Thanks to all authors!

Mike

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Fred Baker
Sent: Saturday, March 27, 2021 12:58 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [v6ops] draft-vf-v6ops-ipv6-deployment and draft-vf-v6ops-ipv6-deployment

[External email]

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

This message was secured by Zix(R).

---

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

Hi Alexandre,
Thanks for your support!
Please see my responses inline tagged as [GF].

Regards,

Giuseppe

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Monday, March 29, 2021 6:38 PM
To: [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment and draft-vf-v6ops-ipv6-deployment

Le 27/03/2021 à 05:58, Fred Baker a écrit :
>> technologies to IPv6, but it also constitutes a basis for our draft.
> 

Hi, Fred,

Generally speaking I am in favor of immediate adoption of drafts that describe IPv6 deployments, so of these ones too.

I have some input to offer from my experiments on an IPv6-only computer connected to the Internet.  For example I would suggest to not use any URL that does not work.

There is an 'IPv6 survey' reported in the draft, so I could offer another results of IPv6 survey, in English, but from France.

[GF]: Happy to receive your contribution here.

There is advice that is provided in the draft as well.  I might agree with some advice and disagree with some other, and suggest another one.

[GF]: Yes, we have tried to derive some advice based on the survey. Anyway the main scope of the draft is to give a global picture of IPv6 so we can revise that part according to the feedback received.

I would suggest to describe more of the pure translation-less IPv6 deployments on 'bare metal' where IPv4 is completely absent.  Maybe use more of a perspective where IPv4 does not exist and IP is all there is to be (to signify IPv6).

[GF]: Sure, this prospective can be added, even if it is not the most common situation.

[GF]: A new section on mobile networks can be introduced in the next version.

Alex

---

From: Giuseppe Fioccola <[email-masked]>
Date: Tue, 30 Mar 2021 08:27:16 +0000

Hi Jordi,
I see your point. IPv6-only alone can be misinterpreted. It can be referred to different portions of the network, to the underlay, to the overlay (services).
So I think it is good to put order and be aligned with the terminology. In section 8.1.2 we have to distinguish between IPv6-only services (IPv4aaS) and IPv6-only network, according to draft-palet-v6ops-ipv6-only.

Regards,

Giuseppe

From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: Monday, March 29, 2021 7:16 PM
To: [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment and draft-vf-v6ops-ipv6-deployment

Regards,
Jordi
@jordipalet

El 29/3/21 17:09, "v6ops en nombre de Giuseppe Fioccola" <[email-masked]<mailto:[email-masked]> en nombre de [email-masked]<mailto:[email-masked]>> escribió:

Hi Chongfeng,

Regards,

Giuseppe

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, March 29, 2021 4:04 PM
To: Fred Baker <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment and draft-vf-v6ops-ipv6-deployment

Hi，Giuseppe, Paolo,

[GF]: Will do.

[GF]: Will do.

[GF]: Sure, Will do.

Regards
Chongfeng

https://mailarchive.ietf.org/arch/search/?qdr=a&q=%22draft-lmhp-v6ops-transition-comparison%22
https://mailarchive.ietf.org/arch/search/?qdr=a&q=%22draft-vf-v6ops-ipv6-deployment%22
_______________________________________________ v6ops mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Tue, 30 Mar 2021 08:57:14 +0000

Hi Fred, Folks, 

I support the adoption of this work. 

I found the "Call for action" section is very valuable, which lists the aspects that could be further investigated. The WG could work more on these approaches and actions. 

References could be also added in the sections regarding the IPv6 extension headers to refer to the currently ongoing related works. 

Best regards, 
Shuping 

> Sent: Saturday, March 27, 2021 12:58 PM
> To: [email-masked]
> adoption. Not only is it a good description of the transition technologies to
> draft-lmhp-v6ops-transition-comparison once before (in January 2020), and
> got essentially no response. It has come up on the list twice since, in July and
> in November. The authors of draft-vf-v6ops-ipv6-deployment would like to
> see it adopted. The two sets of authors are disjoint. I therefore have at least
> nine people that would like to see us adopt and publish it. What other folks
> have opinions, pro or con?
>

---

From: Giuseppe Fioccola <[email-masked]>
Date: Tue, 30 Mar 2021 09:53:03 +0000

Hi Gyan,
Thanks for your good opinion and suggestions.

Please find my responses inline tagged as [GF] (for both emails).

Regards,

Giuseppe

From: v6ops [mailto:[email-masked]] On Behalf Of Gyan Mishra
Sent: Tuesday, March 30, 2021 12:58 AM
To: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

From a core perspective in that framework mention RFC 5565 softwire mesh framework which is a fancy way of using  VPN overlay tunnel context to tunnel v6 edge over a v4 only core VPN IPv4 SAFI 128 129 global table 6PE BGP LU SAFI 4 or the revere tunneling v4 edge over a v4 only core VPN IPv4 SAFI 128 129 global table 4PE BGP LU SAFI 4.  Basically the best practice from a core architecture perspective is you never dual stack the core and it’s either v4 only or v6 only but never dual stacked in a MPLS / SR VPN overlay context.  In a case of IP routing no overlay just and underlay that is the only time when dual stack is done in the core.

[GF]: These considerations could be mentioned in a new section on transport and core network.

For DC architecture since overlay and underlay framework exist.  CLOS NVO3 BGP EVPN architecture the underlay as well is not dual stacked and is either IPv4 only or IPv6 only but not both.

[GF]: Yes, for DC this is true.

Kind Regards

Gyan

On Mon, Mar 29, 2021 at 6:46 PM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:

Dear Authors

I found the the draft really helped capture the progression and current state of IPv6 deployments across public and private sector vertical markets as well as deployment considerations and challenges faced by operators.

The ETSI link I found very valuable especially the data point that web content worldwide has up ticked to 15% and mostly the larger content providers and streaming media technology giants like FAANG getting on board Immediately with IPV6 and in some cases IPv6 only.

Page 11 of that link bar graph 2.2 would be good to show year over year IPv6 web content growth.

[GF]: Sure, we can add these statistics also in this draft. Anyway, as you already noticed, not all websites are equal and biggest Content Providers already support IPv6 and therefore generate a lot more content than small websites. So, in reality, the percentage of content and traffic accessible in IPv6 should be much larger than 15%.

Nice to see that IPv6 is really making a dramatic gains and is outpacing IPv4.  Awesome!!

A data point I think would be good to note in the draft  is as infrastructure gets dual stacked from the SP ASNs down to fixed broadband BNGs user community and wireless 4G 5G trending of IPv6 traffic on the internet as compared to IPv4 and how the IPv6 traffic is trending up and how far we are from the 50/50 breaking point.

When it comes to deployment, the infrastructure has to get built out which had progresses nicely, after which as the infrastructure gets built as they say “they will come” IPv6 traffic will eventually come and is coming but the MAJOR factor here is IPv6 web content web sites proliferation to Dual stack.

[GF]: Agree, the important factor is the trend of the content supporting IPv6. This could be an important motivation for the IPv6 transition also for the infrastructure.

I think it’s worth mentioning Happy Eyeballs RFC 6555 and Happy Eyeballs 2 RFC 8305.  So one major aspect of application migration to IPv6 in the framework of dual stacked is and the network build out and proliferation of IPv6 at the network layer.  All host and network router OS’s by default prefer IPv6 over IPv4.  Pre Happy Eyeballs was “sad eyeballs” meaning the user experience as IPv6 was being deployed and in some cases IPv6 has intermittent and not full routing connectivity.  So the host OS would send out A / AAAA dns request and get a reply back and then would try IPv6 first and then would undergo TCP RTO retransmission timeout approximately 20 seconds.  So with RFC 6555 what would happen is a almost simultaneous IPv4 and IPv6 connection SYN would go out with a 300ms preference for IPv6 goes out sooner than IPv4 and so if IPv6 socket for whatever reason did not establish the IPv6 connection would timeout in 300ms making it seamless to the user of a network fault thus the name “Happy Eyeballs”.  This maybe worth noting in the draft.

[GF]: This is a good suggestion. We will definitely mention Happy Eyeballs v1 and v2 and how the preference for IPv6 is having positive impacts on the deployment. Maybe it is possible to find some statistics on that.

For enterprises the technical driver to IPv6 is much different then Service Providers.  As most large companies NAT out to the internet and can use RFC 1918 address space internally that does allow shielding of the even large enterprises from the impact of IPv4 assess depletion.  However for large to very large companies or even mid size that are constantly buying up companies as well as going through M&A that itself is a huge business driver for those companies to move towards IPv6.  The other business driver is service providers that also are involved in consulting services for IPv6 usually want the companies to be able to eat their own dog food so to speak ..here IPv6 is the dog food so in those cases as well the push for enterprises to go dual stack ..eating their own ...some points here maybe to mention under the enterprise section. For enterprises proxy capabilities as well 4to6 allows enterprises to access v6 internet resource from internal v4 only networks continuing the shielding of internal networks from v4 depletion concerns and are still able to access v6 content.

[GF]: Yes, this is something we already want to include regarding the enterprise. Enterprises that, after an acquisition, have to merge two networks which use IPv4 private addresses, they may encounter issues due to the overlapping address space.

From a core proliferation perspective mention connecting IPv6 islands over IPv4 core using 6PE global table routing and 6VPE VPN-IPv6 SAFI 128 129 over IPv4 core.  As operators migrate to v6 core MPLS LDPv6, SR-MPLSv6, SRV6 they are able to start the elimination of IPv4 from the core underlay transport while continuing to provide overlay v4 VPN services.

[GF]: I’m thinking to add a new section on transport and core network.

Kind Regards

Gyan

On Mon, Mar 29, 2021 at 4:58 PM JORDI PALET MARTINEZ <jordi.palet=[email-masked]<mailto:[email-masked]>> wrote:
    I agree. I see from https://www.worldipv6launch.org/measurements/ that my current employer is shown as being at 75.24% for wireline and 83.52% wireless (of traffic to certain sites from those ASNs). My *guess* is that the remaining 25% of wireline is due to enterprises and people with non-IPv6 retail routers connected to the CE router, because it's been 9 years since IPv6 launch. Wireless is probably due to old (non VoLTE) UEs.

    Barbara

    > > From: Brian E Carpenter [mailto:[email-masked]<mailto:[email-masked]>]
    > > To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
    > >> From: v6ops [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian E
    > >> Carpenter
    > >>> <jordi.palet=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
    > >>> From: v6ops [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of JORDI PALET
    > >>> MARTINEZ
    > [email-masked]<mailto:[email-masked]> en nombre de [email-masked]<mailto:[email-masked]>> escribió:
    > >>>
    > >>>     >> El 28/3/21 9:14, "v6ops en nombre de [email-masked]<mailto:[email-masked]>
    > <mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]> <mailto:v6ops-<mailto:v6ops->
    > [email-masked]<mailto:[email-masked]>> en nombre de [email-masked]<mailto:[email-masked]>
    > <mailto:[email-masked]<mailto:[email-masked]>>> escribió:
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > <mailto:jordi.palet<mailto:jordi.palet>=[email-masked]<mailto:[email-masked]>>
    > >>>     >>
    > >>>     >>      *Date:* 2021-03-25 17:15
    > >>>     >>
    > >>>     >>      *To:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    > >>>     >>
    > [email-masked]<mailto:[email-masked]> en nombre de [email-masked]<mailto:[email-masked]>> escribió:
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>          > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft->
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/v6ops__;>!!
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/v6ops__;>!!
    > https://urldefense.com/v3/__http://www.theipv6company.com__;!!BhdT!zHXQ<https://urldefense.com/v3/__http:/www.theipv6company.com__;!!BhdT!zHXQ>
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/v6ops__;>!!
    > mailing list [email-masked]<mailto:[email-masked]>
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/v6ops__;>!!
    > https://urldefense.com/v3/__http://www.theipv6company.com__;!!BhdT!zHXQ<https://urldefense.com/v3/__http:/www.theipv6company.com__;!!BhdT!zHXQ>
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/v6ops__;>!!
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/v6ops__;>!!
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/v6ops__;>!!
    > https://urldefense.com/v3/__http://www.theipv6company.com__;!!BhdT!zHXQ<https://urldefense.com/v3/__http:/www.theipv6company.com__;!!BhdT!zHXQ>
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/v6ops__;>!!
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/v6ops__;>!!
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/v6ops__;>!!
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/v6ops__;>!!

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Giuseppe Fioccola <[email-masked]>
Date: Tue, 30 Mar 2021 10:15:19 +0000

Hi Shuping,
Thanks for your support.
I will surely include the reference to the relevant 6MAN and V6OPS documents on IPv6 EHs.

Regards,

Giuseppe 

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Pengshuping (Peng Shuping)
Sent: Tuesday, March 30, 2021 10:57 AM
To: Fred Baker <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment and draft-vf-v6ops-ipv6-deployment

Hi Fred, Folks, 

Best regards, 
Shuping

---

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

The term 'IPv6-only' can be defined.

An 'IPv6-only' computer is a computer that runs IP and that IP is not
IPv4; it does not run IPv4 software.  For example, it does not have
127.0.0.1 in /etc/hosts, does not have an IPv4 stack in the running
kernel, etc.

An 'IPv6-only' link is a link that transmits only IPv6 packets and does
not transmit IPv4 packets.  For example the links of PDP Type IPv6 in 4G.

An 'IPv6-only' smartphone is a handheld portable computer connected on
an 'IPv6-only' link but, contrary to an 'IPv6-only' computer, it does
use an IPv4 stack and can browse IPv4 websites by means of address
translation.

We could also define an 'IPv6-only' marketing term, an 'IPv6-only'
concept, an 'IPv6-only' future Internet, etc.

Alex

Le 30/03/2021 à 10:27, Giuseppe Fioccola a écrit :
> Hi Jordi,
> 
> I see your point. IPv6-only alone can be misinterpreted. It can be 
> referred to different portions of the network, to the underlay, to
> the overlay (services).
> 
> So I think it is good to put order and be aligned with the
> terminology. In section 8.1.2 we have to distinguish between
> IPv6-only services (IPv4aaS) and IPv6-only network, according to
> draft-palet-v6ops-ipv6-only.
> 
> Regards,
> 
> Giuseppe
> 
> *From:*v6ops [mailto:[email-masked]] *On Behalf Of *JORDI
> PALET MARTINEZ *Sent:* Monday, March 29, 2021 7:16 PM *To:*
> [email-masked] *Subject:* Re: [v6ops] draft-vf-v6ops-ipv6-deployment
> and draft-vf-v6ops-ipv6-deployment
> 
> <https://tools.ietf.org/html/draft-palet-v6ops-ipv6-only-05>
> 
> Regards,
> 
> Jordi
> 
> @jordipalet
> 
> El 29/3/21 17:09, "v6ops en nombre de Giuseppe Fioccola" 
> <[email-masked] <mailto:[email-masked]>en nombre de 
> [email-masked] <mailto:[email-masked]>> 
> escribió:
> 
> Hi Chongfeng,
> 
> *From:[email-masked] 
> <mailto:[email-masked]>[mailto:[email-masked] 
> <mailto:[email-masked]>] *Sent:* Monday, March 29, 2021 4:04
> PM *To:* Fred Baker <[email-masked] 
> <mailto:[email-masked]>>; [email-masked]
> <mailto:[email-masked]> *Cc:*
> [email-masked] 
> <mailto:[email-masked]>; 
> [email-masked] 
> <mailto:[email-masked]> *Subject:* Re:
> [v6ops] draft-vf-v6ops-ipv6-deployment and 
> This draft provide latest worldwide IPv6 status from various aspects，
> it is a constructive and useful document and I support its adoption.
> In addition, I provide some comments and personal suggestions as
> below,
> 
> It should be noted that in some cases, private address space can not
>  provide adequate address,  it is reused in the same network which
> make the network even more complex, so NAT can not solve the problem
> of address shortage.
> 
> Since each address blocks of Internet is owned by specific owner,
> which is stored in routing DB for the verification of the
> authenticity of routing information, frequent address transfer may
> make the global routing unstable and even in disorder.
> 
> [GF]: Agree, it is important to highlight in this section how private
>  10.0.0.0/8 space (RFC1918) is not enough in some cases. Also the 
> transfer of IPv4 addresses has also some drawbacks for the global 
> routing as you noted.
> 
> P7,    Section 4 listed several transtion technologies, they mainly 
> provide access to users at the edge of the network, so it better to
> add "for user access" when they are introdueced.
> 
> [GF]: Will do.
> 
> P8.  Section 5 illustrate about IPv6 for enterprise, IPv6 show its 
> advantages in the case of acqiusition, when enterprise merge two 
> networks which use IPv4 private addresses, the address space of the
> two networks may overlap which make the merging difficult.
> 
> P9. "In this latter case, the service is delivered solely on IPv6." 
> should be changed to "In this latter case, the traffic is delivered 
> solely on IPv6, Including the traffic originated from IPv4-based
> nodes.
> 
> P10.    In  "The CPE has only an IPv6 address at the WAN side and
> uses an IPv6 connection to the operator gateway, e.g"
> 
> "when IPv6 increases to a certain limit, it would be better to switch
> to the IPv6-only stage." should be changed to "when IPv6 usage 
> increases to a certain limit, it would be better to switch to the 
> IPv6-only stage."
> 
> [GF]: There was some discussion on this statement in a related
> thread. We plan to extend the concept of this paragraph and we will
> try to betterdefine the "limit" that could be "when IPv4 traffic is
> vanishingly small" or "when IPv6 usage increases to a certain limit"
> as you suggested. We will include some considerations about what is a
>  reasonable limit, in particular based on the data from the mailing
> list discussion or that we can find looking at public statistics.
> 
> "For an network operator, IPv6-only means that the whole network use
> IPv6 as the universal network protocol for all traffic delivery."
> 
> [GF]: Sure, Will do.
> 
> It should be noted that the coverage of MPLS is limted, for instance,
> it does not reach into the cloud/DC generally, therefore, it can not
> take effect in this scenario.
> 
> p13， I propose the following clause about IPv6 action plan should be
>  added following the clause of  "The  Call for Comment is at [US-FR]
> and [US-CIO]."
> 
> "In China, the goverment launched IPv6 action plan in 2017, which 
> requires that networks, applications and terminal devices will fully
>  support the adoption of IPv6 by the end of 2025."
> 
> Reference: 
> http://www.china.org.cn/business/2017-11/27/content_41948814.htm 
> <http://www.china.org.cn/business/2017-11/27/content_41948814.htm>
> 
> 
> *From:*Fred Baker <mailto:[email-masked]>
> 
> *Date:* 2021-03-27 12:58
> 
> *To:[email-masked] <mailto:[email-masked]>
> 
> *CC:[email-masked] 
> <mailto:[email-masked]>; 
> [email-masked] 
> <mailto:[email-masked]>
> 
> *Subject:* [v6ops] draft-vf-v6ops-ipv6-deployment and 
>> On Mar 19, 2021, at 1:39 AM, Paolo Volpato
>> <[email-masked] <mailto:[email-masked]>>
>> wrote:
> 
>> 
> 
>> adoption. Not only is it a good description
> of the transition technologies to IPv6, but it also constitutes a 
> basis for our draft.
> 
<https://mailarchive.ietf.org/arch/search/?qdr=a&q=%22draft-lmhp-v6ops-transition-comparison%22>
> https://mailarchive.ietf.org/arch/search/?qdr=a&q=%22draft-vf-v6ops-ipv6-deployment%22
<https://mailarchive.ietf.org/arch/search/?qdr=a&q=%22draft-vf-v6ops-ipv6-deployment%22>
> <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/v6ops 
> <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> 
> ready for the new Internet ? http://www.theipv6company.com
> <http://www.theipv6company.com> The IPv6 Company
>

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 30 Mar 2021 16:09:10 +0530

Hi Fred,

I reviewed draft-vf-v6ops-ipv6-deployment [1]. I found it to be quite
useful and would like to see it adopted. The survey text showcased key
trends that are useful even if they would not reflect the latest
deployment numbers, post-publication.

There is still work to do, which is fine as we are talking about
adoption. Based on the long discussion on the list, there is
definitely interest in this work.

I also did a quick read of draft-lmhp-v6ops-transition-comparison, I
found the comparison to be quite useful and I would like to see both
drafts adopted and worked on by the WG.

Thanks!
Dhruv

[1] https://mailarchive.ietf.org/arch/msg/v6ops/Nawiok0A_Enby7IzrjUCO69Mn2o/

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 30 Mar 2021 21:20:42 +0800

Although there is  the word of "Service" in this term, it does not mean this is a marketing term, my understanding is that it only defines the role of remaining IPv4 traffic in IPv6-only network. Considering IPv4 traffic will not vanish in short term, so IPv4aaS will stay long and be a major feature of IPv6-only network.

Chongfeng

[email-masked]
 
From: Alexandre Petrescu
Date: 2021-03-29 22:06
To: v6ops
Subject: Re: [v6ops] How can one check the presence of IPv4aaS technologies? -- Re: draft-vf-v6ops-ipv6-deployment
I think we should first say what one means by 'IPv4aaS'.

 

 

 

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 30 Mar 2021 15:25:48 +0200

Le 30/03/2021 à 15:20, [email-masked] a écrit :
> Although there is  the word of "Service" in this term, it does not
> mean this is a marketing term, my understanding is that it only
> defines the role of remaining IPv4 traffic in IPv6-only network.

If it is an IPv6-only network then there is no remaining IPv4 traffic -
   neither on 'bare metal', nor encapsulated in IPv6.

But, I am open if there is another term (other than 'IPv6-only') that
designates a computer or a network where IPv4 is completely absent.

Alex

  Considering IPv4
> traffic will not vanish in short term, so IPv4aaS will stay long and
> be a major feature of IPv6-only network.
> 
> Chongfeng
> 
> 
> ------------------------------------------------------------------------
>
> 
[email-masked]
> 
> *From:* Alexandre Petrescu <mailto:[email-masked]> 
> *Date:* 2021-03-29 22:06 *To:* v6ops <mailto:[email-masked]> 
> *Subject:* Re: [v6ops] How can one check the presence of IPv4aaS 
> technologies? -- Re: draft-vf-v6ops-ipv6-deployment I think we should
> first say what one means by 'IPv4aaS'. I think this term is very
> loosely defined technically. It might be a very good marketing term,
> and an excellent overall goal for developments of features on
> roadmaps. But I have some ideas about how to check what you ask. Le
> 29/03/2021 à 10:40, Lencse Gábor a écrit :
>> 
>>> home I could not see the options that you mention (464XLAT,
>> Now, again, we may distinguish two cases: - If the user can observe
>> the traffic on the outside (WAN)
> interface of
> some operators to their respective users (but not to others).  Such
> a table is available for all operators in France, at regulator.  On
> page 57 of the pdf at this URL one can see such a table 
>> Do you know such properties of the user side behavior (e.g.
>> traffic pattern) of any of the 464XLAT, DSLITE, MAP-E, MAP-T or
>> lw4o6 technologies that could indicate their presence?
> That is an excellent question.  I think it is possible to write a 
> packet analyzer that looks at the interface of the end user and
> depending on the contents of the packets to determine a pattern
> telling whether or not 464XLAT is used. From these two things (tables
> of DNS64 resolvers, and packet analyzers), it might be possible to
> build web sites that not only reply to the question "what is my IP
> address" but also tell whether "IPv4aaS" is used or not. Also, right
> now a "what is my IP addreess" website replies my with my IP address,
> but can also tell whether I am behind a NAT or not. A similar logic
> could be used to tell whether I am behind a another sort of address
> translation. Alex
>> 
>> Gábor
>>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 30 Mar 2021 16:01:18 +0000

>     I agree. I see from
> https://www.worldipv6launch.org/measurements
> that my current employer is shown as
> being at 75.24% for wireline and 83.52% wireless (of traffic to certain sites from
> those ASNs). My *guess* is that the remaining 25% of wireline is due to
> enterprises and people with non-IPv6 retail routers connected to the CE router,
> because it's been 9 years since IPv6 launch. Wireless is probably due to old (non
> VoLTE) UEs.
> 
> -> Yes, I forgot to mention it before. In my experience most of the "lack" of IPv6
> traffic comes from enterprise customers. That's why I was insisting in wireline
> residential. Of course, when you look at stats (example APNIC) per ASN, most of
> the ISPs serve residential and enterprises using the same ASN, so again, we can't
> "look" into the details, unless the ISP discloses the data.
> 
>     With that said, I can't envision recommending to my employer that it move
> from the current dual stack to IPv4aaS. It makes no sense business-wise and
> provides no benefit to customers. The costs of deploying dual stack are sunk.
> The help desk knows how to support it. It works extremely well.  Why
> recommend the high cost of deploying something new and different (on
> wireline: development and testing in the CE router and network elements, teams
> of people spending massive time, help desk training, etc.) when it provides zero
> benefit over what you have? Wireless is working fine, too.
> 
> -> In most of the cases, it depends on your number of IPv4 addresses and future
> needs. Your employer may have sufficient addresses, most of the rest of the
> world is not in that situation. Of course, the alternative is to use CGN for the
> IPv4 (using only private addresses), but CGN and addresses to run it have a
> bigger cost even than replacing the CPEs. We did those numbers for real
> customers. There was a very recent discussion on that in NANOG, and several
> folks reached the same conclusion. There are also "service" consequences when
> using NAT444, such as that Sony Play Station blacklist forever the addresses
> detected in the CGN (NAT444, not in the case of NAT64), so you need to rotate
> your IPv4 pools, and at the end, you're forced to "buy" (via transfers) more and
> more IPv4 addresses. If that's the case, it is cheaper to buy "tons" of IPv4
> addresses up-front and not use CGN at all ...

Wireline ISPs who historically provided public IPv4 addresses to their customers
generally still have those IPv4 addresses (unless they chose to sell them). Some
have chosen to put new customers on CGN but not touch existing customers. 
If one of the new customers complains about needing to use a specific 
app/device that doesn't work when IPv4
is provided by CGN, that customer is moved to the public IPv4 address pool. This is
a simple process. Because of churn (existing customers terminating service) 
and the extremely small number of customers
who notice that IPv4 is done via NAT444 (or even NAT4444 if the customer has set
up their home network with double NAT), there is no danger of
running out of IPv4 addresses. There is also not a danger of running out of private
IPv4 space for most such operators. I completely disagree with the assessment that 
"CGN and addresses to run it have a bigger cost even than replacing the CPEs". 

I should note that as IPv4-only consumer electronic (CE) devices become fewer (PS4, 
launched in 2013 apparently had no usable IPv6; but PS5, launched last year, has
an IPv6 stack that sometimes works) then the need to support NAT-intolerant apps
becomes less. There is also less demand for IPv4 address ports. I think it would
make more sense to provide CE device makers with better advice on how to 
properly implement IP protocols (v4 and v6) than to suggest operators with
CGN spend resources on going from CGN to IPv4aaS.
Barbara

>     > > I didn't mention IPv6aas. Of course that is too new for 75% to be a
> reasonable
>     > expectation.
>     > >
>     > >> My expectation (not supported by facts) that FBB overnight is not more
> than
>     > 50%.
> <mailto:v6ops-
>     > >>>     >>      Free was using 6RD initially, not sure if they turned into dual-
> stack,
> <v6ops-
>     > >>>     >>          interface (Windows Properties on the Interface, check off
> IPv4).
>     > This
>     > >>>     >>
>     > >>>     >>          IPv6 addresses.  For example, thunderbird (a very modern
> MUA)
>     > does not
>     > >>>     >>
>     > >>>     >>          This means that if one wants to migrate more to IPv6 then
> one
>     > has to
>     > >>>     >>
> v6ops
> or
> BhdT!z7gS1YgZjaPb6_s7oiFZPjMqmWofHMp-
> TNIQHhMEajzFgKL0vSZ_mXmWW_X8dw$
> 
> 
> 
> https://urldefense.com/v3/__http://www.theipv6company.com__;!!BhdT!z7gS
> 1YgZjaPb6_s7oiFZPjMqmWofHMp-TNIQHhMEajzFgKL0vSZ_mXn9y1NJ5A$
> The IPv6 Company
> 
> BhdT!z7gS1YgZjaPb6_s7oiFZPjMqmWofHMp-
> TNIQHhMEajzFgKL0vSZ_mXmWW_X8dw$

---

From: Lencse Gábor <[email-masked]>
Date: Tue, 30 Mar 2021 19:05:57 +0200

> generally still have those IPv4 addresses (unless they chose to sell them). Some

Yes, it seems to be logical from the viewpoint of both parties to sell 
IPv4 addresses that are no more needed and to buy IPv4 addresses if they 
are needed.

However, it has a consequence for all the other operators, who do not 
take part in it. I have just recently met some statistics from the 
regular report of IIJ, Japan. I hope that the two tables will remain 
readable:

*Table 1: Number of Routes by Prefix Length for Full IPv4 Routes***

**

*Date***

*/8***

*/9***

*/10***

*/11***

*/12***

*/13***

*/14***

*/15***

*/16***

*/17***

*/18***

*/19***

*/20***

*/21***

*/22***

*/23***

*/24***

*Total***

Sep. 2011

19

12

27

81

233

457

794

1407

11909

5907

9885

19515

26476

26588

35515

34061

190276

363162

Sep. 2012

19

14

29

84

236

471

838

1526

12334

6349

10710

20927

30049

31793

42007

39517

219343

416246

Sep. 2013

16

11

30

93

250

480

903

1613

12748

6652

10971

22588

32202

34900

48915

42440

244822

459634

Sep. 2014

16

12

30

90

261

500

983

1702

13009

7013

11659

24527

35175

37560

54065

47372

268660

502634

Sep. 2015

18

13

36

96

261

500

999

1731

12863

7190

12317

25485

35904

38572

60900

52904

301381

551170

Sep. 2016

16

13

36

101

267

515

1050

1767

13106

7782

12917

25229

38459

40066

67270

58965

335884

603443

Sep. 2017

15

13

36

104

284

552

1047

1861

13391

7619

13385

24672

38704

41630

78779

64549

367474

654115

Sep. 2018

14

11

36

99

292

567

1094

1891

13325

7906

13771

25307

39408

45578

88476

72030

400488

710293

Sep. 2019

10

11

37

98

288

573

1142

1914

13243

7999

13730

25531

40128

47248

95983

77581

438926

764442

Sep. 2020

9

11

39

100

286

576

1172

1932

13438

8251

14003

25800

40821

49108

101799

84773

473899

816017

**

*Table 2: Total Number of Unique IPv4 Addresses in Full IPv4 Routes***

**

*Date***

*No. of IPv4 addresses***

Sep. 2011

2,470,856,448

Sep. 2012

2,588,775,936

Sep. 2013

2,638,256,384

Sep. 2014

2,705,751,040

Sep. 2015

2,791,345,920

Sep. 2016

2,824,538,880

Sep. 2017

2,852,547,328

Sep. 2018

2,855,087,616

Sep. 2019

2,834,175,488

Sep. 2020

2,850,284,544

Source: https://www.iij.ad.jp/en/dev/iir/pdf/iir_vol49_report_EN.pdf

While the number of unique IPv6 addresses has grown from 2.47M to 2.85M 
by only 15%, the number of routes has grown from 363k to 816k by 125% in 
the last 9 years. If you observe the details, you can see that the 
number of /8 prefixes decreased from 19 to 9, while the number of /22 
prefixes increased from 35k to 101k.

I expect that buying and selling of IPv4 addresses will likely intensify 
this tendency, as larger prefixes will be divided into smaller ones, and 
the size of global BGP routing table will grow significantly.

The need for buying more RAM or even replacing routers may be a driving 
force from CGN towards IPv4aaS.

Gábor

---

From: Yannis Nikolopoulos <[email-masked]>
Date: Tue, 30 Mar 2021 21:33:58 +0300

On 3/28/21 9:47 PM, Brian E Carpenter wrote:
> Dual stack has no time limit
(for us ISPs) it has, it painfully has, if your user base is still growing

---

From: Yannis Nikolopoulos <[email-masked]>
Date: Tue, 30 Mar 2021 21:39:31 +0300

Jordi,

as a large(ish) residential ISP will everything you mention and 90% of 
our residential customers with native IPv6, we struggle to get IPv6 
traffic near the 50% mark

Yannis

---

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

> (for us ISPs) it has, it painfully has, if your user base is still growing

Isn't that what CGN was invented for? That's the incumbent technology, with IPv4aaS as a new alternative.

(Don't misunderstand me, I hate CGN as much as anybody.)

   Brian

---

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

Hi Yanis,

Really surprised. A few possible reasons that I can spot:
1) Not all the CPEs have IPv6 enabled correctly.
2) Users replace their CPEs or set another CPE behind the one that you provide and it has no IPv6 enabled, or it is in "router" mode so IPv4 is a double NAT and IPv6 is not forwarded to the "real" user LANs.
3) There are too many "usual" accesses to local contents/services which aren't IPv6-enabled.
4) CDNs aren't IPv6-enabled or not reached correctly via IPv6.

In some cases we have seen similar problems, and the issue was happyeyeballs hiding the problems, and falling back to IPv4.

You also may have information of "what" are the major traffic flows from your users, and analyzing that can provide you the hints about what is going on.

Regards,
Jordi
@jordipalet

El 30/3/21 20:40, "v6ops en nombre de Yannis Nikolopoulos" <[email-masked] en nombre de [email-masked]> escribió:

    Jordi,

    Yannis

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 30 Mar 2021 16:19:30 -0400

> (for us ISPs) it has, it painfully has, if your user base is still growing

Gyan> I think to your POV there is a flip side as dual stack is simple and
easy cannot get any simpler than that, however the downside is the process
of deployment can be painfully slow but it all depends. If you are
provisioning 1000s of sites for dual stack that still can be done with ZTP
even with complex DMVPN or other overlay topologies dual stacked still not
difficult.  I think whenever manual configuration comes into play and you
have even a 100 sites or devices that can be painful and lengthy process.

There are definite tradeoffs.

Dual stack is less complexity but then you have IPv4  provisioning and
numbering plan so you could say that in itself is complex.

If it’s fixed broadband BNG or 4G/5G mobile the drawback as well with dual
stack is IPv4 addressing numbering plan but having to maintain
configuration for both IPv4 and IPv6 could be considered complex, even
though the dual stack process is as simple as it gets.

With IPv4 AAS the attraction could be the minimum configuration footprint
number of lines of config.

Learning curve yes for operators but you could say that for any technology
their is a learning curve.

I think the bigger deal for operators is how long the timeframe to maintain
IPv4AAS is a bigger factor as that could be decades and it could be almost
like a permanent solution.

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 30 Mar 2021 22:28:21 +0200

I will say that the “long” and “unpredictable” time for IPv4aaS is an advantage, because you “stop” provisioning IPv4 now, so it is one less problem to worry about.

You’re not longer worried about “how” much usage of IPv4 is done, except for a single thing: reducing the number of IPv4 addresses in the NAT64 (for example in the case of 464XLAT). You could even ignore that, but of course, it is good to reduce the number of IPv4 addresses if they are not used, because you can either transfer them and get some money back or use in other parts of the network.

The question is: Do you prefer to ged rid off IPv4 as in many parts of the network as possible sooner or later?

El 30/3/21 22:21, "v6ops en nombre de Gyan Mishra" <[email-masked] en nombre de [email-masked]> escribió:

On Tue, Mar 30, 2021 at 2:34 PM Yannis Nikolopoulos <[email-masked]> wrote:

Gyan> I think to your POV there is a flip side as dual stack is simple and easy cannot get any simpler than that, however the downside is the process of deployment can be painfully slow but it all depends. If you are provisioning 1000s of sites for dual stack that still can be done with ZTP even with complex DMVPN or other overlay topologies dual stacked still not difficult.  I think whenever manual configuration comes into play and you have even a 100 sites or devices that can be painful and lengthy process.  

Dual stack is less complexity but then you have IPv4  provisioning and numbering plan so you could say that in itself is complex.  

If it’s fixed broadband BNG or 4G/5G mobile the drawback as well with dual stack is IPv4 addressing numbering plan but having to maintain configuration for both IPv4 and IPv6 could be considered complex, even though the dual stack process is as simple as it gets.  

With IPv4 AAS the attraction could be the minimum configuration footprint number of lines of config.

Learning curve yes for operators but you could say that for any technology their is a learning curve. 

I think the bigger deal for operators is how long the timeframe to maintain IPv4AAS is a bigger factor as that could be decades and it could be almost like a permanent solution.  

-- 

Gyan Mishra

Email [email-masked]

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 31 Mar 2021 02:00:16 -0400

In theory if you flipped a switch and all fixed broadband and wireless
4G/5G access layer providers all around the world banded together and
ditched CGN and turned up IPv4AAS and so now all subscribers - all the
billions of subscribers around the world are now officially IPv6 only.

However let’s say this happened tomorrow but our web content and traffic
volume is still sitting steady at 15% IPv6 and 85% IPv4.

The needle would not have moved at all as we only fixed half the problem.

We need to get all the web content to move to IPv6 and that’s an problem of
economics that we need to push the envelope on all web content providers
charge high for IPv4 premium $$ to incentivize moving to IPv6 by forces of
economy where money talks.

Gyan

On Tue, Mar 30, 2021 at 4:29 PM JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

> I will say that the “long” and “unpredictable” time for IPv4aaS is an
> advantage, because you “stop” provisioning IPv4 now, so it is one less
> problem to worry about.
>
> You’re not longer worried about “how” much usage of IPv4 is done, except
> for a single thing: reducing the number of IPv4 addresses in the NAT64 (for
> example in the case of 464XLAT). You could even ignore that, but of course,
> it is good to reduce the number of IPv4 addresses if they are not used,
> because you can either transfer them and get some money back or use in
> other parts of the network.
>
> El 30/3/21 22:21, "v6ops en nombre de Gyan Mishra" <[email-masked]
> en nombre de [email-masked]> escribió:
>
>
>
>
>
>
>
> I think the bigger deal for operators is how long the timeframe to
> maintain IPv4AAS is a bigger factor as that could be decades and it could
> be almost like a permanent solution.
>
>
>
>
>
>
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 31 Mar 2021 07:03:06 +0000

Just small good news:
Content is not “sitting steady at 15% IPv6”.
It has healthy 23% CAGR by https://w3techs.com/technologies/history_overview/site_element/all
Chicken and egg are evolving one after another.
Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of Gyan Mishra
Sent: Wednesday, March 31, 2021 9:00 AM
To: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

In theory if you flipped a switch and all fixed broadband and wireless 4G/5G access layer providers all around the world banded together and ditched CGN and turned up IPv4AAS and so now all subscribers - all the billions of subscribers around the world are now officially IPv6 only.

However let’s say this happened tomorrow but our web content and traffic volume is still sitting steady at 15% IPv6 and 85% IPv4.

We need to get all the web content to move to IPv6 and that’s an problem of economics that we need to push the envelope on all web content providers charge high for IPv4 premium $$ to incentivize moving to IPv6 by forces of economy where money talks.

Gyan

On Tue, Mar 30, 2021 at 4:29 PM JORDI PALET MARTINEZ <jordi.palet=[email-masked]<mailto:[email-masked]>> wrote:
I will say that the “long” and “unpredictable” time for IPv4aaS is an advantage, because you “stop” provisioning IPv4 now, so it is one less problem to worry about.
You’re not longer worried about “how” much usage of IPv4 is done, except for a single thing: reducing the number of IPv4 addresses in the NAT64 (for example in the case of 464XLAT). You could even ignore that, but of course, it is good to reduce the number of IPv4 addresses if they are not used, because you can either transfer them and get some money back or use in other parts of the network.
The question is: Do you prefer to ged rid off IPv4 as in many parts of the network as possible sooner or later?

El 30/3/21 22:21, "v6ops en nombre de Gyan Mishra" <[email-masked]<mailto:[email-masked]> en nombre de [email-masked]<mailto:[email-masked]>> escribió:

On Tue, Mar 30, 2021 at 2:34 PM Yannis Nikolopoulos <[email-masked]<mailto:[email-masked]>> wrote:

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

M 301 502-1347

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

M 301 502-1347

---

From: Yannis Nikolopoulos <[email-masked]>
Date: Wed, 31 Mar 2021 10:25:01 +0300

> Isn't that what CGN was invented for? That's the incumbent technology, with IPv4aaS as a new alternative.

Yes, but CGN usually implies single stack, hence my comment.
In our case, we're also providing IPv6 to the NAT444 customers and have 
been messing with IPv4aaS (LW4o6 in the past and MAP-E currently) for a 
few years now

regards,
Yannis

---

From: Yannis Nikolopoulos <[email-masked]>
Date: Wed, 31 Mar 2021 10:32:24 +0300

Jordi,

in our case its mostly (3) and a little bit of (2), bordering on 
insignificant as a number. Of course, (4) also needs to be checked from 
time to time

Regards,
Yannis

---

From: [email-masked]
Date: Wed, 31 Mar 2021 09:33:59 +0200

> In theory if you flipped a switch and all fixed broadband and wireless 4G/5G access layer providers all around the world banded together and ditched CGN and turned up IPv4AAS and so now all subscri…

No, IPv4aaS offers dual-stack service to subsbcribers.
IPv4aaS allows an ISP to run IPv6 only in the access network. As an analogy that is little different from the ISP using MPLS in the access network, that does not make the subscribers MPLS-only.

The term "IPv6 only", to have meaning must be qualified.

An IPv6 only application on an IPv6 only network communicating through a NAT64 to an IPv4 only application is not IPv6 only end to end (e.g. referrals don't work).

Best regards,
Ole

---

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

True, but what you’re missing is that, at least according to the graphics I see in my customers and many other networks, depending on the % of residential vs business, the number of IPv6-enabled services is meaning 75-90% or even a bit more.

If your customers use Netflix, Google/Youtube, Facebook, and a few other CDNs, done. The % of traffic to non-IPv6 enabled web sites is going lower and lower every day.

There may be exceptional cases such as the one that Yanis mention yesterday, that may have a “local” non-IPv6 service(s), which by the way could be easily resolved probably a matter of training, but I tend to think that most of the time, if that happens is because the IPv6 connectivity is broken, so happy eyeballs is hiding the problem.

In some cases, some folks from CDNs told me “we needed to disable IPv6 here” because it was so poorly configured that it was breaking the services … They are in the list, they could confirm with more public/anonymous details.

Regards,

Jordi

@jordipalet

El 31/3/21 8:01, "v6ops en nombre de Gyan Mishra" <[email-masked] en nombre de [email-masked]> escribió:

Gyan 

On Tue, Mar 30, 2021 at 4:29 PM JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:

 

 

 

-- 

Gyan Mishra

M 301 502-1347

-- 

Gyan Mishra

M 301 502-1347

---

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

And more important than that … this site only shows “number” of websites, but it doesn’t show “how” much % of traffic those web sites are delivering vs. % worldwide.

This is very simple. We can make a poll and evaluate the results in the list. We can find a way to make it anonymous (no need to indicate your email or name). People could respond the poll without telling what is the ASN/network, just be honest when responding. What do you think Fred/Ron?

Each operator or people having details of one or more networks, to tell us how much traffic in your network is going to caches and CDNs, you don’t need to indicate which ones, just totals (so include all the big ones such as video services, social networks, or other well-know that have IPv6-enabled).

It doesn’t matter if you don’t offer IPv6 to your customers. If you know that (for example), 85% of your traffic is towards those services, we know that turning IPv6 on to your customers will turn your % of IPv6 traffic towards that figure.

Even if we ignore “smaller” sites, the % of traffic to them is probably negligible, even if an “important” service for an specific operator is not there. This can compensate somehow the % of IPv4 traffic to video sources from older (non-IPv6 enabled) smartTVs or STBs.

Regards,

Jordi

@jordipalet

El 31/3/21 9:03, "Vasilenko Eduard" <[email-masked]> escribió:

Just small good news:

Eduard

 

Gyan 

 

 

 

-- 

Gyan Mishra

M 301 502-1347

-- 

Gyan Mishra

M 301 502-1347

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 31 Mar 2021 10:21:28 +0000

Hi Jordi,
When I was on the big Carrier side
We have collected cFlowd sampled statistics (for many reasons).
Then it was possible to put it into some database
And then get N biggest traffic directions out of it.
It was a pure manual exercise in our case.
The result has given many surprises to us☺

The next option is to use DPI statistics that could be of the same rich. DPI (PCEF) is available only on Mobile.
I am not sure they have a pre-loaded template, but chances are good. Just one problem: the discussion below was more about FBB, not MBB.

Unfortunately, all off-line traffic engineering tools (I would not mention 3 vendor’s names here) collect statistics only for MPLS LSPs. That would not help here.
One other big tool has a big collection of sampled cFlowd but it refuses to let it out of a proprietary database.
Hence, such statistics could not be collected for free in any other process or tool.
It is a specialized “project”.

I am not sure that many Carriers could do what you want. This task was not easy a few years ago.
Staring from the fact that not all carriers collect sampled cFlowd from all ports to general-purpose collector, then facing the problem to aggregate it.

Additionally, they need some check which one destination is IPv6 ready. It would be a manual process too.
Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: Wednesday, March 31, 2021 11:42 AM
To: [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

Regards,
Jordi
@jordipalet

El 31/3/21 9:03, "Vasilenko Eduard" <[email-masked]<mailto:[email-masked]>> escribió:

Just small good news:
Content is not “sitting steady at 15% IPv6”.
It has healthy 23% CAGR by https://w3techs.com/technologies/history_overview/site_element/all
Chicken and egg are evolving one after another.
Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of Gyan Mishra
Sent: Wednesday, March 31, 2021 9:00 AM
To: JORDI PALET MARTINEZ <jordi.palet=[email-masked]<mailto:jordi.palet=[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

Gyan

Gyan Mishra

M 301 502-1347

Gyan Mishra

M 301 502-1347

---

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

Hi Eduard,

All the customers I’ve worked with, even just for trainings, and also operators that participated in “free/open trainings” for example in RIR and NOG meetings, have answered this question “do you know how much % of your traffic goes to CDNs/caches”? I’m talking about over 75.000 engineers that I’ve trained since 2001, and I started asking this question around 2010, so let’s say in the worst case only 1/3rd of them know the answer (because I did less trainings in the last 10 years than the first 10 ones).

I guess this is something they can measure at the edge of the border, peerings, etc., etc. I don’t really care how they do it, if it is fairly close to reallity, otherwise, they will haven’t answered so categorically. For example, they know how much traffic goes to the self-hosted CDNs/caches or IX, in case they don’t host their own CDNs/caches but the IXs offers them, etc.

The response has been initially “more than 65%”, then I started to get answers closer to 75%, 80-90%. I didn’t took note one by one to make my own “stats”, but when I consintently get an answer over 65% and I notice that, across the years that this response is going higher and higher, I think we can have some conclusions and not be too much erred.

We don’t need to “check” if the destination is IPv6 ready. Today, it will be dificult to believe that *any* CDN/cache is not IPv6-ready. We should not count if CDN “x” has disabled IPv6 for customer “y”, because that means “that” customer is not yet IPv6-enabled or they did a bad deployment and the CDN decided to turn it off to avoid issues.

What we pretend to measure is “if you do a good IPv6 deployment in all your customers (at least in the residential ones) how much traffic will use the CDNs/caches with IPv6”. Just knowing how much IPv4 traffic today is going to the same CDNs/caches, provides a very good anser to that question.

Regards,

Jordi

@jordipalet

El 31/3/21 12:22, "v6ops en nombre de Vasilenko Eduard" <[email-masked] en nombre de [email-masked]> escribió:

Hi Jordi,

The result has given many surprises to usJ

Eduard

Regards,

Jordi

@jordipalet

Just small good news:

Eduard

 

Gyan 

 

 

 

-- 

Gyan Mishra

M 301 502-1347

-- 

Gyan Mishra

M 301 502-1347

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 31 Mar 2021 11:10:29 +0000

Hi Jordi,
The fact that something is going to CDN would not help you. Because every CDN accelerates many Web sites.
If the original Web site does not support it – then CDN could not help here. It would continue to stream IPv4 for this request.
For your question: “how much traffic could be IPv6 overnight” – we need traffic per primary N Web sites.
Sorry, the cheapest is cFlowd statistics for this. DPI is more expensive.
Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: Wednesday, March 31, 2021 1:44 PM
To: [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

Hi Eduard,

Regards,
Jordi
@jordipalet

El 31/3/21 12:22, "v6ops en nombre de Vasilenko Eduard" <[email-masked]<mailto:[email-masked]> en nombre de [email-masked]<mailto:[email-masked]>> escribió:

Hi Jordi,

Regards,
Jordi
@jordipalet

Just small good news:

Gyan

Gyan Mishra

M 301 502-1347

Gyan Mishra

M 301 502-1347

---

From: Yannis Nikolopoulos <[email-masked]>
Date: Wed, 31 Mar 2021 17:05:43 +0300

Hello,

I can't speak for other operators, but we use netflow and BGP enrichment 
to analyse our traffic and its fairly trivial to break down IPv6/IPv4 
traffic going into / coming from CDNs/Caches/peers etc

regards,
Yannis

On 3/31/21 2:10 PM, Vasilenko Eduard wrote:
> If the original Web site does not support it – then CDN could not help 
> here. It would continue to stream IPv4 for this request.
>
> PALET MARTINEZ
> *Sent:* Wednesday, March 31, 2021 1:44 PM
> *To:* [email-masked]
> All the customers I’ve worked with, even just for trainings, and also 
> operators that participated in “free/open trainings” for example in 
> RIR and NOG meetings, have answered this question “do you know how 
> much % of your traffic goes to CDNs/caches”? I’m talking about over 
> 75.000 engineers that I’ve trained since 2001, and I started asking 
> this question around 2010, so let’s say in the worst case only 1/3^rd 
> of them know the answer (because I did less trainings in the last 10 
> years than the first 10 ones).
>
> I guess this is something they can measure at the edge of the border, 
> peerings, etc., etc. I don’t really care how they do it, if it is 
> fairly close to reallity, otherwise, they will haven’t answered so 
> categorically. For example, they know how much traffic goes to the 
> self-hosted CDNs/caches or IX, in case they don’t host their own 
> CDNs/caches but the IXs offers them, etc.
>
> The response has been initially “more than 65%”, then I started to get 
> answers closer to 75%, 80-90%. I didn’t took note one by one to make 
> my own “stats”, but when I consintently get an answer over 65% and I 
> notice that, across the years that this response is going higher and 
> higher, I think we can have some conclusions and not be too much erred.
>
> We don’t need to “check” if the destination is IPv6 ready. Today, it 
> will be dificult to believe that **any** CDN/cache is not IPv6-ready. 
> We should not count if CDN “x” has disabled IPv6 for customer “y”, 
> because that means “that” customer is not yet IPv6-enabled or they did 
> a bad deployment and the CDN decided to turn it off to avoid issues.
>
> What we pretend to measure is “if you do a good IPv6 deployment in all 
> your customers (at least in the residential ones) how much traffic 
> will use the CDNs/caches with IPv6”. Just knowing how much IPv4 
> traffic today is going to the same CDNs/caches, provides a very good 
> anser to that question.
>
> Regards,
>
> Jordi
>
> @jordipalet
>
> El 31/3/21 12:22, "v6ops en nombre de Vasilenko Eduard" 
> <[email-masked] <mailto:[email-masked]> en nombre de 
> [email-masked] <mailto:[email-masked]>> 
> escribió:
>
> Hi Jordi,
>
> The next option is to use DPI statistics that could be of the same 
> rich. DPI (PCEF) is available only on Mobile.
>
> I am not sure they have a pre-loaded template, but chances are good. 
> Just one problem: the discussion below was more about FBB, not MBB.
>
> Unfortunately, all off-line traffic engineering tools (I would not 
> mention 3 vendor’s names here) collect statistics only for MPLS LSPs. 
> That would not help here.
>
> One other big tool has a big collection of sampled cFlowd but it 
> refuses to let it out of a proprietary database.
>
> Staring from the fact that not all carriers collect sampled cFlowd 
> from all ports to general-purpose collector, then facing the problem 
> to aggregate it.
>
> *From:*v6ops [mailto:[email-masked] 
> <mailto:[email-masked]>] *On Behalf Of *JORDI PALET MARTINEZ
> *Sent:* Wednesday, March 31, 2021 11:42 AM
> And more important than that … this site only shows “number” of 
> websites, but it doesn’t show “how” much % of traffic those web sites 
> are delivering vs. % worldwide.
>
> This is very simple. We can make a poll and evaluate the results in 
> the list. We can find a way to make it anonymous (no need to indicate 
> your email or name). People could respond the poll without telling 
> what is the ASN/network, just be honest when responding. What do you 
> think Fred/Ron?
>
> Each operator or people having details of one or more networks, to 
> tell us how much traffic in your network is going to caches and CDNs, 
> you don’t need to indicate which ones, just totals (so include all the 
> big ones such as video services, social networks, or other well-know 
> that have IPv6-enabled).
>
> It doesn’t matter if you don’t offer IPv6 to your customers. If you 
> know that (for example), 85% of your traffic is towards those 
> services, we know that turning IPv6 on to your customers will turn 
> your % of IPv6 traffic towards that figure.
>
> Even if we ignore “smaller” sites, the % of traffic to them is 
> probably negligible, even if an “important” service for an specific 
> operator is not there. This can compensate somehow the % of IPv4 
> traffic to video sources from older (non-IPv6 enabled) smartTVs or STBs.
>
> Regards,
>
> Jordi
>
> @jordipalet
>
> El 31/3/21 9:03, "Vasilenko Eduard" <[email-masked] 
> <mailto:[email-masked]>> escribió:
>
> Just small good news:
>
> It has healthy 23% CAGR by 
> https://w3techs.com/technologies/history_overview/site_element/all 
> <https://w3techs.com/technologies/history_overview/site_element/all>
>
> *From:*v6ops [mailto:[email-masked] 
> <mailto:[email-masked]>] *On Behalf Of *Gyan Mishra
> *Sent:* Wednesday, March 31, 2021 9:00 AM
> *To:* JORDI PALET MARTINEZ 
> <jordi.palet=[email-masked] 
> <mailto:jordi.palet=[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>
> However let’s say this happened tomorrow but our web content and 
> traffic volume is still sitting steady at 15% IPv6 and 85% IPv4.
>
> We need to get all the web content to move to IPv6 and that’s an 
> problem of economics that we need to push the envelope on all web 
> content providers charge high for IPv4 premium $$ to incentivize 
> moving to IPv6 by forces of economy where money talks.
>
> Gyan
>
> On Tue, Mar 30, 2021 at 4:29 PM JORDI PALET MARTINEZ 
> <jordi.palet=[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I will say that the “long” and “unpredictable” time for IPv4aaS is
>     an advantage, because you “stop” provisioning IPv4 now, so it is
>     one less problem to worry about.
>
>     You’re not longer worried about “how” much usage of IPv4 is done,
>     except for a single thing: reducing the number of IPv4 addresses
>     in the NAT64 (for example in the case of 464XLAT). You could even
>     ignore that, but of course, it is good to reduce the number of
>     IPv4 addresses if they are not used, because you can either
>     transfer them and get some money back or use in other parts of the
>     network.
>
>     The question is: Do you prefer to ged rid off IPv4 as in many
>     parts of the network as possible sooner or later?
>
>     El 30/3/21 22:21, "v6ops en nombre de Gyan Mishra"
>     <[email-masked] <mailto:[email-masked]> en nombre
>     de [email-masked] <mailto:[email-masked]>> escribió:
>
>     On Tue, Mar 30, 2021 at 2:34 PM Yannis Nikolopoulos
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>     Gyan> I think to your POV there is a flip side as dual stack is
>     simple and easy cannot get any simpler than that, however the
>     downside is the process of deployment can be painfully slow but it
>     all depends. If you are provisioning 1000s of sites for dual stack
>     that still can be done with ZTP even with complex DMVPN or other
>     overlay topologies dual stacked still not difficult.  I think
>     whenever manual configuration comes into play and you have even a
>     100 sites or devices that can be painful and lengthy process.
>
>     Dual stack is less complexity but then you have IPv4  provisioning
>     and numbering plan so you could say that in itself is complex.
>
>     If it’s fixed broadband BNG or 4G/5G mobile the drawback as well
>     with dual stack is IPv4 addressing numbering plan but having to
>     maintain configuration for both IPv4 and IPv6 could be considered
>     complex, even though the dual stack process is as simple as it gets.
>
>     maintain IPv4AAS is a bigger factor as that could be decades and
>     it could be almost like a permanent solution.
>
>
>
>         [email-masked] <mailto:[email-masked]>
>     /Network Solutions Architect /
>
>     /Email [email-masked] <mailto:[email-masked]>/
>
>     /M 301 502-1347/
>
>     [email-masked] <mailto:[email-masked]>
>     http://www.theipv6company.com <http://www.theipv6company.com>
>     The IPv6 Company
>
>     [email-masked] <mailto:[email-masked]>
> /Network Solutions Architect /
>
> /Email [email-masked] <mailto:[email-masked]>/
>
> /M 301 502-1347/
>
>
> http://www.theipv6company.com <http://www.theipv6company.com>
> The IPv6 Company
>
> [email-masked] <mailto:[email-masked]> 
> http://www.theipv6company.com <http://www.theipv6company.com>
> The IPv6 Company
>

---

From: <[email-masked]>
Date: Wed, 31 Mar 2021 14:25:12 +0000

Hi,

from our experience the major challenge is not the network (we are Dual Stack for more than ten years now) but the services and the end devices the clients are running on. Even if large video/content providers support IPv6 that does not necessarily results in IPv6 end-to-end. In many cases devices like SmartTVs are not IPv6 enabled (e.g. if you use your laptop to stream Netflix transport will be IPv6 but if you use your Smart TV you will only see IPv4).

Regards

Nic

Von: v6ops <[email-masked]> Im Auftrag von Gyan Mishra
Gesendet: Mittwoch, 31. März 2021 08:00
An: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
Cc: [email-masked]
Betreff: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

Gyan

Gyan Mishra

M 301 502-1347

Gyan Mishra

M 301 502-1347

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 31 Mar 2021 17:14:04 +0200

Hi Eduard,

I’m not sure if I’ve not explained myself about this.

Since many years ago, I will say 100% of the key CDNs/caches are IPv6 enabled. Several of them in fact mandatorily must be IPv6 “connected” (so if an ISP or IX want to host it, must provide IPv6 addresses and connectivity to the CDN/cache). I believe the “mandatory support of IPv6” in order to allow hosting a CDN/Cache is true for Google and Facebook at least, but it is just on top of my head, so my memory could be failing.

Most of them enable IPv6 *by default* unless you manually turn it off, *even if your original content is not* IPv6 enabled.

That means that it is a conscious/deliberated decision to turn off IPv6 in a cache/CDN.

Of course, this decision is often only taken if there is some clear signs of incorrect behavior or impact, for example, because a bad IPv6 deployment inside of an ISP network, and it is disabled “only” towards that ISP, not globally.

There are several colleagues from CDNs in this list, so they can provide further inputs.

However, I did a quick search about the status and defaults of the top ones. Not all the info is clearly presented, but is a matter of digging more in those CDN providers blogs, etc., to find further info.

I’ve not used any specific order in this list, just randomly as they come to my mind:

https://support.cloudflare.com/hc/en-us/articles/229666767-Understanding-and-configuring-Cloudflare-s-IPv6-support

https://www.akamai.com/us/en/multimedia/documents/product-brief/ipv6-adaptation-product-brief.pdf

https://support.google.com/interconnect/answer/9058809?hl=en

https://netflixtechblog.com/enabling-support-for-ipv6-48a495d5196f

https://aws.amazon.com/es/about-aws/whats-new/2016/10/ipv6-support-for-cloudfront-waf-and-s3-transfer-acceleration/

https://www.cachefly.com/cachefly-is-ipv6-compatible/

https://s24.q4cdn.com/538403808/files/doc_news/Limelight-Networks-Automates-IPv6-Enablement-for-New-and-Existing-Customers-2012.pdf

https://techmonitor.ai/technology/networks/tata_communications_launches_global_cdn_service

https://www.codeinwp.com/blog/maxcdn-vs-cloudflare-vs-cloudfront-vs-akamai-edge-vs-fastly/

https://blog.sucuri.net/2016/09/ipv6-adoption.html

https://www.keycdn.com/blog/ipv6-support

https://www.verizondigitalmedia.com/blog/verizon-digital-media-services-announces-ipv6-compliance/

https://www.belugacdn.com/

https://azure.microsoft.com/en-us/updates/ipv6-for-azure-vms/

Saludos,

Jordi

@jordipalet

El 31/3/21 13:11, "v6ops en nombre de Vasilenko Eduard" <[email-masked] en nombre de [email-masked]> escribió:

Hi Jordi,

Eduard

Hi Eduard,

Regards,

Jordi

@jordipalet

Hi Jordi,

Eduard

Regards,

Jordi

@jordipalet

Just small good news:

Eduard

 

Gyan 

 

 

 

-- 

Gyan Mishra

M 301 502-1347

-- 

Gyan Mishra

M 301 502-1347

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 31 Mar 2021 17:18:22 +0200

Then, in your case, looking for the IPv4 traffic to the CDNs/caches/peers, we can easily investigate what, of your top traffic is not using IPv6 and then dig into the causes.

Regards,

Jordi

@jordipalet

El 31/3/21 16:06, "v6ops en nombre de Yannis Nikolopoulos" <[email-masked] en nombre de [email-masked]> escribió:

Hello,

I can't speak for other operators, but we use netflow and BGP enrichment to analyse our traffic and its fairly trivial to break down IPv6/IPv4 traffic going into / coming from CDNs/Caches/peers etc

regards,
Yannis

Hi Jordi,

Eduard

Hi Eduard,

Regards,

Jordi

@jordipalet

Hi Jordi,

Eduard

Regards,

Jordi

@jordipalet

Just small good news:

Eduard

 

Gyan 

 

 

 

-- 

Gyan Mishra

M 301 502-1347

-- 

Gyan Mishra

M 301 502-1347

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 31 Mar 2021 17:24:27 +0200

Agree, but smartTVs and STBs from the last couple of years or so, have IPv6 support, so having the CDNs/caches enabled for that, it will become a “natural” transition. Even a few of the older ones, may become updated, otherwise, at some point it will be replaced with new ones. Of course, this depends a lot on the country – richer countries often get this equipment replaced faster (bigger/better screen, 8K or 4K instead of 2K, etc.).

In fact, those older smartTVs are probably the reason in some cases we see ISPs with 75% of IPv6, and in other 85% (just random numbers, not saying it is a 10% difference).

Regards,

Jordi

@jordipalet

El 31/3/21 16:26, "[email-masked] en nombre de [email-masked]" <[email-masked] en nombre de [email-masked]> escribió:

Hi,

Regards

Nic

 

Gyan 

 

 

 

-- 

Gyan Mishra

M 301 502-1347

-- 

Gyan Mishra

M 301 502-1347

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 31 Mar 2021 17:29:27 +0200

Le 31/03/2021 à 16:25, [email-masked] a écrit :
> Hi,
> 
> from our experience the major challenge is not the network (we are 
> Dual Stack for more than ten years now) but the services and the end
>  devices the clients are running on. Even if large video/content 
> providers support IPv6 that does not necessarily results in IPv6 
> end-to-end. In many cases devices like SmartTVs are not IPv6 enabled
>  (e.g. if you use your laptop to stream Netflix transport will be 
> IPv6 but if you use your Smart TV you will only see IPv4).

I can agree.  My 3yr old smart tv does not have IPv6, so all its traffic
is IPv4.

Some recent Smart TVs do feature IPv6, including Samsung and Sony.
Those not on Android (e.g. Tizen OS for Samsung) do seem to support even
DHCPv6 clients.

A private report also tells that one would rather prefer to use IPv6 to
stream netflix rather than IPv4, whose paths are 'bufferbloated'.  One
can check how better netflix is on IPv6 than on IPv4 by looking with
https at fast.com.

This is not to say there are no problems, because there are still.  One
that concerns me is this /64 limit problem; this problem is also visible
with smart tvs in homes, just like it is visible with other IPv6 devices
in cars.

Alex

> 
> Regards
> 
> Nic
> 
> *Von:* v6ops <[email-masked]> *Im Auftrag von *Gyan Mishra 
> *Gesendet:* Mittwoch, 31. März 2021 08:00 *An:* JORDI PALET MARTINEZ
>  <jordi.palet=[email-masked]> *Cc:* [email-masked] 
> *Betreff:* Re: [v6ops] draft-vf-v6ops-ipv6-deployment
> 
> In theory if you flipped a switch and all fixed broadband and 
> wireless 4G/5G access layer providers all around the world banded 
> together and ditched CGN and turned up IPv4AAS and so now all 
> subscribers - all the billions of subscribers around the world are 
> now officially IPv6 only.
> 
> advantage, because you “stop” provisioning IPv4 now, so it is one 
> less problem to worry about.
> 
> except for a single thing: reducing the number of IPv4 addresses in 
> the NAT64 (for example in the case of 464XLAT). You could even ignore
> that, but of course, it is good to reduce the number of IPv4 
> addresses if they are not used, because you can either transfer them 
> and get some money back or use in other parts of the network.
> 
> The question is: Do you prefer to ged rid off IPv4 as in many parts 
> of the network as possible sooner or later?
> 
> [email-masked] <mailto:[email-masked]>> escribió:
> 
> whenever manual configuration comes into play and you have even a 100
> sites or devices that can be painful and lengthy process.
> 
> If it’s fixed broadband BNG or 4G/5G mobile the drawback as well with
> dual stack is IPv4 addressing numbering plan but having to maintain
> configuration for both IPv4 and IPv6 could be considered complex,
> even though the dual stack process is as simple as it gets.
> 
> maintain IPv4AAS is a bigger factor as that could be decades and it 
> could be almost like a permanent solution.
> 
> 
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 31 Mar 2021 16:01:49 +0000

Hi Jordi,
I was probably too pessimistic about the number of cases when CDN proxies from IPv6 to IPv4. I have read that CloudFlare makes it by default (Enterprise could switch off).
I do not believe that man enterprises have incentives to activate this functionality on CDN consciously – they probably do not care. But if it is by default – then they would probably did not touch it too.
It is interesting how many services (%) have been ordered from CDN providers with such proxy activated.
Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: Wednesday, March 31, 2021 6:14 PM
To: [email-masked]
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment

Hi Eduard,

Saludos,
Jordi
@jordipalet

El 31/3/21 13:11, "v6ops en nombre de Vasilenko Eduard" <[email-masked]<mailto:[email-masked]> en nombre de [email-masked]<mailto:[email-masked]>> escribió:

Hi Jordi,

Hi Eduard,

Regards,
Jordi
@jordipalet

Hi Jordi,

Regards,
Jordi
@jordipalet

Just small good news:

Gyan

Gyan Mishra

M 301 502-1347

Gyan Mishra

M 301 502-1347

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Apr 2021 09:05:21 +1300

Yannis,
> Yes, but CGN usually implies single stack, hence my comment.

That isn't clear to me. Maybe I am biased because of the model
described by https://tools.ietf.org/html/rfc6264.
(I'm definitely biased because of RFC1671 too ;-)

> been messing with IPv4aaS (LW4o6 in the past and MAP-E currently) for a 

Good stuff. My definition of dual-stack *from the user's point of view*
is that as long as both AF_INET and AF_INET6 work, i.e. the host can use
both A and AAAA records, the network is dual stack. The user doesn't
care how the ISP and the CE router delivers this.

    Brian

> .

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 31 Mar 2021 22:35:18 +0200

That's the point. My way to explain IPv6-only and IPv4aaS and a good IPv6 deployment in trainings is "you don't want to break anything at the client side (they should not notice anything different), so you need to keep dual-stack in the LANs as much as you can, and then use IPv6-only with IPv4aaS in the access network".

It is a matter of stating the "context" of the IPv6-only.

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

    Yannis,

        Brian