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

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 01 Apr 2021 12:25:01 +0200

I think even if it IPv6 was not enabled by default, many enterprises will choose to enable it (so yes, they have incentives), because it is no extra cost for them and no implications in their own backend. Kind of “I get IPv4+IPv6 for the same price, and I don’t need to, at the time being, setup IPv6 in my own DC/network, so why not? If it fails for whatever reason, I can always come back and disable it”.

Saludos,

Jordi

@jordipalet

El 31/3/21 18:02, "v6ops en nombre de Vasilenko Eduard" <[email-masked] en nombre de [email-masked]> escribió:

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,

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,

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,

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,

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 usJ

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

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:

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.  

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.

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:

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

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.  

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

-- 

Gyan Mishra

Network Solutions Architect 

Email [email-masked]

M 301 502-1347

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

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

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

-- 

Gyan Mishra

Network Solutions Architect 

Email [email-masked]

M 301 502-1347

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

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

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

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

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

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

**********************************************
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: Yannis Nikolopoulos <[email-masked]>
Date: Thu, 1 Apr 2021 18:22:55 +0300

Hello Brian,

On 3/31/21 11:05 PM, Brian E Carpenter wrote:
> Yannis,
> On 31-Mar-21 20:25, Yannis Nikolopoulos wrote:
>>
>> On 3/30/21 11:18 PM, Brian E Carpenter wrote:
>>> On 31-Mar-21 07:33, Yannis Nikolopoulos wrote:
>>> 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.
> That isn't clear to me. Maybe I am biased because of the model
> described by https://tools.ietf.org/html/rfc6264.

well, 6264 (combined with the immaturity of lw4o6) was the inspiration 
we needed to rethink our NAT444 a few years back, so thank you :)

regards,
Yannis
>      Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 01 Apr 2021 19:07:25 +0200

Hi Yannis,

When you say inmaturity of lw4o6, do you mean that something in the protocol is broken, lack of support from vendors or something else?

Regards,
Jordi
@jordipalet

El 1/4/21 17:23, "v6ops en nombre de Yannis Nikolopoulos" <[email-masked] en nombre de [email-masked]> escribió:

    Hello Brian,

    regards,
    Yannis

---

From: Gert Doering <[email-masked]>
Date: Fri, 2 Apr 2021 14:46:21 +0200

Hi,

On Wed, Mar 31, 2021 at 11:10:29AM +0000, 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.

Uh, no?  CDNs typically decouple frontend protocol from backend protocol.

Especially if the content is cached anyway, why should it be relevant
where it came from?

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: Yannis Nikolopoulos <[email-masked]>
Date: Fri, 2 Apr 2021 18:11:11 +0300

Hi Jordi,

> When you say inmaturity of lw4o6, do you mean that something in the protocol is broken, lack of support from vendors or something else?

as I've written in the past, we had performance issues with our lwaftr 
and the vendor was reluctant to continue (much needed) dev/ment because 
of lack of interest from other ISPs. I would imagine that things haven't 
improved much during the past 3 years :(

regards,
Yannis

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 3 Apr 2021 09:22:32 +1300

> Uh, no?  CDNs typically decouple frontend protocol from backend protocol.

Sure, but the site can *request* dual stack or IPv4-only.
> Especially if the content is cached anyway, why should it be relevant

Doesn't streaming often bypass the CDN?

   Brian

---

From: Gert Doering <[email-masked]>
Date: Sat, 3 Apr 2021 11:44:16 +0200

Hi,

> Sure, but the site can *request* dual stack or IPv4-only.

True.  This was more about what I read in the statement above "if the
origin site is IPv4-only, the CDN cannot be dual-stacked" (which is not
correct).

> Doesn't streaming often bypass the CDN?

Dunno.  For popular content, caching makes sense.  For "live" streaming,
having a close-to-the user multiplexer makes lots of sense.

For "nobody ever watches this show", caching might not be very useful,
so bypassing the CDN might make sense if you know that beforehand...

Classical "is it beneficial to cache this?" CS problem :-)

Gert Doering
        -- NetMaster

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 04 Apr 2021 10:40:34 +0200

Hi Yannis,

I've no doubt that you explained it before, I just missed it.

However, I'm aware of a couple of lw4o6 deployments that worded fine (I will try to see if I could convince the people involved in speaking up in the list, as I'm not sure the info is public yet). So, I'm guessing that it is something related to one specific vendor. I think we all know that sometimes, good protocols have bad implementations

Regards,
Jordi
@jordipalet

El 2/4/21 17:11, "v6ops en nombre de Yannis Nikolopoulos" <[email-masked] en nombre de [email-masked]> escribió:

    Hi Jordi,

    regards,
    Yannis

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 04 Apr 2021 10:42:32 +0200

Hi Brian,

The point is that a few of the CDNs, by default, turn on dual-stack even if the original content is only available with IPv4.
 
Regards,
Jordi
@jordipalet

El 2/4/21 22:23, "v6ops en nombre de Brian E Carpenter" <[email-masked] en nombre de [email-masked]> escribió:

       Brian

---

From: Yannis Nikolopoulos <[email-masked]>
Date: Mon, 5 Apr 2021 21:54:18 +0300

Jordi,

it was vendor-related but the decision was purely commercial (hence the 
dissapointment). I wish I could name the technical people involved as 
they did a remarkable job on the implementation

regrds,
Yannis

---

From: Fred Baker <[email-masked]>
Date: Tue, 6 Apr 2021 00:13:34 -0700

Thanks. To be perfectly honest, I'd be far more impressed if the CGI link contained an IPv6 address :-) But I take it this is intended as input to draft-vf-v6ops-ipv6-deployment?

> On Mar 22, 2021, at 11:21 PM, hsyu <[email-masked]> wrote:
> 
> 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,
> 
> 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
>

---

From: Fred Baker <[email-masked]>
Date: Tue, 6 Apr 2021 01:15:08 -0700

I would suggest sending as a liaison to the working group. That way we can have a discussion about it and give you concrete feedback.

I personally agree to review the proposed TR-181 update.

> On Mar 29, 2021, at 8:11 AM, STARK, BARBARA H <[email-masked]> wrote:
> 
> 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

---

From: hsyu <[email-masked]>
Date: Tue, 6 Apr 2021 16:20:49 +0800

Hi, Fred,

Sorry for being late, this is the IPv6 access link：

http://[240e:eb:8001:e00::62]:8080/cgi-bin/generate

Haisheng Yu(Johnson)

[email-masked]

签名由
网易邮箱大师
定制

On 4/6/2021 15:13，Fred Baker<[email-masked]> wrote：

Hi Paolo,

Best regards.

Haisheng Yu(Johnson)
[email-masked]
签名由 网易邮箱大师 定制

Thanks!
Dhruv

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 06 Apr 2021 10:48:15 +0200

It doesn’t work for me … it may be that PMTUD is filtered?

El 6/4/21 10:22, "v6ops en nombre de hsyu" <[email-masked] en nombre de [email-masked]> escribió:

Hi, Fred,

Haisheng Yu(Johnson)
[email-masked]
签名由 网易邮箱大师 定制 

Hi Paolo,

Best regards.

Haisheng Yu(Johnson)
[email-masked]
签名由 网易邮箱大师 定制

Thanks!
Dhruv

---

From: Gabor LENCSE <[email-masked]>
Date: Tue, 6 Apr 2021 11:11:46 +0200

It does not work for me, either. I tried it using Firefox under Windows 
10. It gave me the following error message:

The connection has timed out

The server at 240e:eb:8001:e00::62 is taking too long to respond.

     The site could be temporarily unavailable or too busy. Try again in 
a few moments.
     If you are unable to load any pages, check your computer’s network 
connection.
     If your computer or network is protected by a firewall or proxy, 
make sure that Firefox is permitted to access the Web.

I have checked my basic IPv6 connectivity to the server as follows:

C:\Users\Gabor Lencse>ping 240e:eb:8001:e00::62

Pinging 240e:eb:8001:e00::62 with 32 bytes of data:
Reply from 240e:eb:8001:e00::62: time=419ms
Reply from 240e:eb:8001:e00::62: time=419ms
Reply from 240e:eb:8001:e00::62: time=433ms
Reply from 240e:eb:8001:e00::62: time=416ms

Ping statistics for 240e:eb:8001:e00::62:
     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
     Minimum = 416ms, Maximum = 433ms, Average = 421ms

Best regards,

Gábor

On 4/6/2021 10:48 AM, JORDI PALET MARTINEZ wrote:
> El 6/4/21 10:22, "v6ops en nombre de hsyu" <[email-masked] 
> <mailto:[email-masked]> en nombre de [email-masked] 
> <mailto:[email-masked]>> escribió:
>
> Hi, Fred,
>
> *Haisheng Yu(Johnson)*
> 签名由 网易邮箱大师 <https://mail.163.com/dashi/dlpro.html?from=mail81> 
> 定制
>
> On 4/6/2021 15:13，Fred Baker<[email-masked]> 
> <mailto:[email-masked]> wrote：
>
>     Thanks. To be perfectly honest, I'd be far more impressed if the
>     CGI link contained an IPv6 address :-) But I take it this is
>     intended as input to draft-vf-v6ops-ipv6-deployment?
>
>         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.
>
>
> _______________________________________________ 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: hsyu <[email-masked]>
Date: Tue, 6 Apr 2021 17:40:54 +0800

Because of the firewall, the previous link cannot be accessed. The following link has passed my test without any problems.

http://[240e:eb:8001:e00::62]:8000/cgi-bin/generate

Haisheng Yu(Johnson)

[email-masked]

签名由
网易邮箱大师
定制

On 4/6/2021 16:48，JORDI PALET MARTINEZ<jordi.palet=[email-masked]> wrote：

Hi, Fred,

Haisheng Yu(Johnson)

[email-masked]

签名由 网易邮箱大师 定制

Hi Paolo,

Best regards.

Haisheng Yu(Johnson)
[email-masked]
签名由 网易邮箱大师 定制

Thanks!
Dhruv

IPv4 is over

The IPv6 Company

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 06 Apr 2021 11:57:06 +0200

Yes, this works, tks!

Anyway, I’m still of the opinion that we should use as much as possible DNS instead of literals :-)

Regards,

Jordi

@jordipalet

El 6/4/21 11:43, "v6ops en nombre de hsyu" <[email-masked] en nombre de [email-masked]> escribió:

Haisheng Yu(Johnson)
[email-masked]
签名由 网易邮箱大师 定制 

 

Hi, Fred,

Haisheng Yu(Johnson)
[email-masked]
签名由 网易邮箱大师 定制 

Hi Paolo,

Best regards.

Haisheng Yu(Johnson)
[email-masked]
签名由 网易邮箱大师 定制

Thanks!
Dhruv

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 6 Apr 2021 12:57:26 +0200

Le 06/04/2021 à 11:40, hsyu a écrit :
> Because of the firewall, the previous link cannot be accessed. The 
> following link has passed my test without any problems.
> 

Works for me, from an IPv6-only computer.  I can browse ok.

There is still a problem in that my mail reader (thunderbird) does not 
make clickable that URL containing an IPv6 address, but copy-pasting the 
address works ok.

I wonder how is the ::62 part of the address generated - manually?

(btw, is it probably normal, for the moment, that http://www.cfiec.net/ 
does not work on IPv6?)

Alex

> 
> 	
> 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> 
> 
> On 4/6/2021 16:48，JORDI PALET 
> MARTINEZ<jordi.palet=[email-masked]> 
> <mailto:jordi.palet=[email-masked]> wrote：
> 
>     签名由 网易邮箱大师
>     <https://mail.163.com/dashi/dlpro.html?from=mail81> 定制
> 
>             [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.
> 
> 
>     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: Tue, 6 Apr 2021 12:58:43 +0200

> possible DNS instead of literals :-)

That opinion tells a lot to the mail software writers, I would suppose.
  Should they make the URLs containing an IP address clickable or not.

Alex

> 
> Regards,
> 
> Jordi
> 
> @jordipalet
> 
> El 6/4/21 11:43, "v6ops en nombre de hsyu" <[email-masked] 
> 签名由 网易邮箱大师 <https://mail.163.com/dashi/dlpro.html?from=mail81> 定制
> 
> 签名由 网易邮箱大师 <https://mail.163.com/dashi/dlpro.html?from=mail81> 定制
> 
> Thanks. To be perfectly honest, I'd be far more impressed if the CGI
> link contained an IPv6 address :-) But I take it this is intended as
> input to draft-vf-v6ops-ipv6-deployment?
> 
> 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,
> 
> 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.
> 
> 
> includes large enterprises and relies on DNS, mail, external 
> website. Also, see Eric's site - 
> Thanks! Dhruv
> ********************************************** IPv4 is over Are you
> ready for the new Internet ? http://www.theipv6company.com The IPv6
> Company
> 
> ********************************************** IPv4 is over Are you
> ready for the new Internet ? http://www.theipv6company.com The IPv6
> Company
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 6 Apr 2021 13:05:56 +0200

It deserves too to be on https rather than http :-)

Alex

---

From: Gert Doering <[email-masked]>
Date: Tue, 6 Apr 2021 20:07:47 +0200

Hi,

On Tue, Apr 06, 2021 at 12:58:43PM +0200, Alexandre Petrescu wrote:
> > Anyway, I???m still of the opinion that we should use as much as
> > possible DNS instead of literals :-)
> 

Nobody should ever be using URLs with literal IP addresses in them,
outside private testing.

Gert Doering
        -- NetMaster

---

From: Fred Baker <[email-masked]>
Date: Wed, 7 Apr 2021 00:33:34 -0700

> On Apr 6, 2021, at 1:48 AM, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
> 

I see 100% data loss from that address.