Re: [v6ops] [Int-area] Still need to know what has changed.... Re: IPv10 draft (was Re: FW: v6ops - New Meeting Session Request for IETF 109 - IPv10)

[Vasilenko Eduard <[e-mail]>]

Hi all,

In my humble opinion: the best statistics is from APNIC, because it is collected from random Google Ads - representative for almost all world (except a few countries where Google Ads is not doing well for some reasons):
https://stats.labs.apnic.net/ipv6
It is very reach on detalization per country and per AS# (possible to translate to Carrier).

The next one is probably Google itself. Just keep in mind that is it is related only to google traffic:
http://www.google.com/intl/en/ipv6/statistics.html
Anyway, very representative too.

The next one is probably Akamai:
https://www.akamai.com/es/es/resources/our-thinking/state-of-the-internet-report/state-of-the-internet-ipv6-adoption-visualization.jsp
It is a little distorted (about 2-3% by country) from 2 previous, because more related to Enterprises (who has ordered CDN).

All give very close numbers per every country.

Eduard
> -----Original Message-----
> From: v6ops [mailto:[e-mail]] On Behalf Of Khaled Omar
> Sent: 25 сентября 2020 г. 17:03
> To: Ola Thoresen <[e-mail]>; [e-mail]
> Subject: Re: [v6ops] [Int-area] Still need to know what has changed.... Re: IPv10
> draft (was Re: FW: v6ops - New Meeting Session Request for IETF 109 - IPv10)
> 
> I agree with most of what you said, but regarding ACLs and firewalls, they will
> use the same configuration after IPv10 and then they can add more
> configuration if needed when there are different source or destination
> addresses.
> 
> Regarding the path, as mentioned, when ALL are updated (of course there will
> be a flag day) then everything will work in the best way and we will use both
> address spaces till full migration is accomplished.
> 
> Best Regards,
> 
> Khaled Omar
> 
> -----Original Message-----
> From: v6ops <[e-mail]> On Behalf Of Ola Thoresen
> Sent: Friday, September 25, 2020 3:54 PM
> To: [e-mail]
> Subject: Re: [v6ops] [Int-area] Still need to know what has changed.... Re: IPv10
> draft (was Re: FW: v6ops - New Meeting Session Request for IETF 109 - IPv10)
> 
> 
> On 25.09.2020 15:20, Khaled Omar wrote:
> >>> IPv6 is not held back by lack of support in hardware, software or operating
> systems.  IPv6 is held back by policy and lack of demand.
> > This is what we call "Migration" which requires user's dependence.
> 
> 
> For an enterprise _user_, nothing is needed. It is managed by the enterprises IT-
> department, and is either enabled or disabled by them.
> 
> For a home user, nothing is needed.  Their ISP just needs to support it, and it
> must be enabled in their CPE with some sane security policies.
> 
> And trust me. I have done multiple IPv4 -> Dual Stack "migrations" for both
> enterprises and ISPs.  No involvement of the end users is required.
> 
> But a LOT of work is required both in the enterprise IT department and at the
> ISPs to ensure that everything works as expected.
> 
> 
> >>> IPv6 is held back by policy in the big enterprises, that don't want to deal with
> another protocol.
> > That’s why IPv10 is needed, they have to do nothing about it, only keep using
> your IP version and that’s it.
> 
> No, they don't.
> 
> They need to enable this IPv10 protocol in their network, just as they need to
> enable IPv6 today.  And they need to be sure that ALL their back office systems
> support it, that all their firewalls, access lists, applications etc. are up to date
> with new source and destination addresses (since they can now be both IPv4 and
> IPv6).   And not only that.  Today, if you are dual stack enabled.  You need one
> access list for IPv4 -> IPv4 and one for IPv6 -> IPv6.  With your suggestion, you
> would ALSO need to update all policies and firewalls and access lists and
> whatnot with policies for IPv4 -> IPv6 and IPv6 -> IPv4 as well, because some
> hosts are suddenly talking to hosts that they should not be allowed to, using
> another protocol than they would previously do.
> 
> To me, this sounds like MORE work than to just going for dual stack in the first
> place.  So, no.  They can't just keep their IP-version.
> 
> And they still need to update all other systems, logg-parsers, monitoring
> applications, you name it, from one protocol (most likely
> IPv4 only) to two protocols.  IPv4 + IPv6.
> 
> 
> 
> >>> And it would still require a customer demand for the ISPs to add it.  If IPv4-
> only customers are not requesting IPv6 today - why would they start requesting
> "IPv10" tomorrow?
> > They will not request IPv10, they will have hosts support IPv10, this will not be
> accomplished by them but by OS developers.
> 
> It does not matter if my host has IPv10 activated, if my ISP does not route IPv10
> packets.  And it does not even matter if my ISP routes IPv10 packets, if
> somewhere along the path from source to destination, there is a single router
> that does not support this protocol.  So, yes.  Even if my OS has IPv10, I would
> have to request my ISP to enable it to be able to talk to IPv6 hosts.  And all their
> peers would have to enabled it.  And in that case, I can just as well ask my ISP to
> enable IPv6, as that is already a mature protocol that is well implemented in all
> OSes already.
> 
> Don't you see this simple thing?
> 
> The problem is not the address of the source or destination host.  The problem is
> all the hosts in between, which must be able to parse and understand this new
> protocol.  And all the package-mangling that is done in hardware and software
> along the path of a packet traversing the internet.
> 
> And _even_ if they all actually had the new protocol implemented in hardware
> and software (which in itself will take many, many years), you would STILL have
> the problem of the enterprises not wanting to deal with multiple protocols and
> of ISPs not wanting to turn in on for their customers because it might lead to
> more support requests, less security and added complexity, and we would
> basically be exactly where we are today with IPv6.
> 
> 
> Rgds,
> 
> /Ola (T)
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops