Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Owen DeLong via NANOG]

> On Jan 14, 2024, at 19:50, Abraham Y. Chen  wrote:
> 
> Hi, Ryan:
> 
> 1) " ... it accounts for 40% of the traffic at Google.   ":
> 
> Perhaps you were referring to the following?
> 
> https://www.google.com/intl/en/ipv6/statistics.html

> 
> 2)If so, your quotation is correct, except there are some hidden stories 
> below the surface:
> 
> A.When you Google for it with key words "IPv6 Traffic Google", the 
> first hit shows "IPv6 Adoption" that lead to the above. So, strictly 
> speaking, it is not traffic data that you are looking at.

Correct, that graph shows fraction of google unique end points that have IPv6 
capability. It does not reflect traffic at all.

> B.Above the actual graph, you will find statements, such as "  ...  
> the availability of IPv6 connectivity among Google users. " So, legally, 
> the graph is correct on its own right, but may not be exactly what you 
> thought. Reader be aware!

Correct… I do not know of a graph showing traffic as a percentage for google.

> It implies that the graph the IPv6 capability (equipment readiness) of 
> Google users, not necessarily the actual traffic they generate. The two do 
> not equate to each other.

No, it shows actual IPv6 reachable, not equipment capability. Likely there is 
some relatively close degree of correlation between fraction of users and 
fraction of traffic, but you are correct that they are independent numbers. 
It’s entirely possible, I suppose, that that 45% of endpoints  reachable via 
IPv6 represents 10% of Google traffic and doesn’t really use Google very much 
at all. OTOH, it’s equally likely that 45% of end points is actually 
responsible for 90% of Google traffic. I doubt that either of these extremes is 
likely, however.

In many ways, however, the fact that 45% of eyeball endpoints have IPv6 
reachability is much more meaningful than whatever random fraction of traffic 
they happen to represent.

>  
> 3)However, the above did seem to support what was generally said in the 
> public. Until, we found an interesting ongoing (the only one of such resource 
> that is updated about every ten minutes) statistics by AMS-IX (AMSterdam 
> Internet eXchange) :
> 
> https://stats.ams-ix.net/sflow/ipv6.html   
> 
> https://stats.ams-ix.net/sflow/ether_type.html
> a
> The second URL shows that IPv6 accounts for approximately 5.7% of the 
> overall Internet traffic that AMS-IX sees today. If one traces back through 
> the archived data, the earlier numbers were even much lower. In fact, those 
> graphs looked meaningless, because there was hardly any visible trace colored 
> for IPv6. This has been going on for at least the last one decade. So, it 
> could not be an error.

This isn’t a surprise since the vast majority of Google’s (and most other 
content providers) traffic is delivered via private network interconnect and 
not on public peering points.

> 4)We contacted AMS-IX for a possible explanation of the obvious 
> discrepancy. They politely referred us to our own ISPs. This triggered our 
> curiosity. We decided that we needed to find the full world-wide IPv6 traffic 
> data.
> 
> 5)There was an annual world-wide Internet traffic statistics and forecast 
> published by Cisco that stopped after 2017 (see URL below to the last issue). 
> We contacted Cisco in 2020 and got an eMail confirmation.
> 
> 
> https://cloud.report/Resources/Whitepapers/eea79d9b-9fe3-4018-86c6-3d1df813d3b8_white-paper-c11-741490.pdf

If you dig deeper on that, you’ll find that their data is purely estimated 
based on very limited collection.

> 6)However, there has never been any equivalent publication for the IPv6 
> by itself that we could locate.

There is an interesting bit of data from Akamai in this post:
https://www.akamai.com/blog/trends/10-years-since-world-ipv6-launch#:~:text=Akamai%27s%20IPv6%20traffic%20levels%20and%20client%20base=As%20of%20May%202022%2C%20Akamai%27s,years%20ago%20in%20February%202020.

Which reports that 2022 Akamai IPv6 traffic was over 41Tbps, up from just over 
1Gbps in 2012.

While IPv4 has grown in that same 10 years, I doubt that it has grown 
4,100,000% in that same 10 years.

> 7)In search for a possible explanation of the discrepancy between Pts. 1) 
> & 3), we came across the following article. In brief, it reported that the 
> Peering agreements among Internet backbone providers were less settled for 
> IPv6 than IPv4. Thus, higher percentage of IPv6 traffic than that of IPv4 
> should have been directed through the IXs (Internet eXchanges), such as 
> AMS-IX.
> 
> https://www.theregister.com/2018/08/28/ipv6_peering_squabbles/

1. This is largely untrue today. Most IPv6 capable networks that peer on a 
public exchange with another IPv6 capable network set up sessions for v4 and v6 
at the same time.

2. There’s a much more plausible explanation… Most of the big eyeball networks 
and most of the big content providers don’t 

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Michael Thomas]

On 1/15/24 11:02 PM, Saku Ytti wrote:

On Mon, 15 Jan 2024 at 21:08, Michael Thomas  wrote:


An ipv4 free network would be nice, but is hardly needed. There will
always be a long tail of ipv4 and so what? You deal with it at your

I mean Internet free DFZ, so that everyone is not forced to maintain
two stacks at extra cost, fragility and time. Any protocols at the
inside networks are fine, as long as you're meeting the Internet with
IPv6-only stack. I'm sure there are CLNS, IPX, AppleTalk etc networks
there, but that doesn't impose a cost to everyone wanting to play.

Um, so what? There is lots of cruft the world over that would be better 
if it finally died. Somehow we keep on. It's just a cost of doing 
business. If mobile operators can support it with their millions or even 
billions of customers, I think everybody else can too. It's not like 
ipv4 address depletion is a static problem either -- it's only going to 
get worse as time goes on so it's what's really driving opex where v6 is 
pretty much a one-off investment in comparison i'd think.


Mike

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Saku Ytti]

On Mon, 15 Jan 2024 at 21:08, Michael Thomas  wrote:

> An ipv4 free network would be nice, but is hardly needed. There will
> always be a long tail of ipv4 and so what? You deal with it at your

I mean Internet free DFZ, so that everyone is not forced to maintain
two stacks at extra cost, fragility and time. Any protocols at the
inside networks are fine, as long as you're meeting the Internet with
IPv6-only stack. I'm sure there are CLNS, IPX, AppleTalk etc networks
there, but that doesn't impose a cost to everyone wanting to play.

-- 
  ++ytti

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Michael Thomas]

On 1/15/24 12:26 AM, Saku Ytti wrote:

On Mon, 15 Jan 2024 at 10:05, jordi.palet--- via NANOG  wrote:


In actual customer deployments I see the same levels, even up to 85% of IPv6 
traffic. It basically depends on the usage of the caches and the % of 
residential vs corporate customers.

You think you are contributing to the IPv6 cause, by explaining how
positive the situation is. But in reality you are damaging it greatly,
because you're not communicating that we are not on a path to IPv4
free Internet. If we had been on such a path, we would have been IPv4
free for more than a decade. And unless we admit we are not on that
path, we will not work to get on that path.

An ipv4 free network would be nice, but is hardly needed. There will 
always be a long tail of ipv4 and so what? You deal with it at your 
borders as a piece of non-recurring engineering and that is that. The 
mobile operators model seems to be working pretty well for them and 
seems likely that it is an opex cost down for them since they don't have 
to run two networks internally nor deal with the cost of ipv4 subnets 
(or at least not as much? not sure how it exactly works). Worrying about 
whether ipv4 will ever go away misses the point, imo.


Mike

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Michael Thomas]

On 1/15/24 12:56 AM, jordi.palet--- via NANOG wrote:
No, I’m not saying that. I’m saying "in actual deployments", which 
doesn’t mean that everyone is deploying, we are missing many ISPs, we 
are missing many enterprises.


I don't think what's going on internally with enterprise needs to change 
much if they just gatewayed to a v6 upstream instead of v4 at the border 
if they were given that option. The problem has always been with ISP's 
and routers. When v6 first started to percolate (early 90's) i looked at 
it for my embedded OS and the projects that used it and didn't figure it 
would take much effort to implement it. So for hosts i really don't 
think that was a roadblock. But if hosts don't have something upstream 
to sink v6 traffic and especially to access the public internet there's 
not much incentive to implement it or deploy it. ISP's used the excuse 
that routers didn't implement it which was definitely a huge problem but 
as it turns out it was still an excuse since a lot has changed in the 
last 20 years and still rollout continues at a glacial pace.


I think one of the more encouraging trends are ISP's and enterprises 
switching over to v6 internally as a cost saving measure to not run a 
dual network. Aren't Comcast and Facebook examples?


It's sort of disturbing that there are still people on this list that 
want to relitigate something that happened 30 years ago. that reeks of 
religion not tech. By all means, set up CGNAT's in a pique.


Mike

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Christopher Hawker]

I strongly disagree that IPv6 is very much an afterthought.

A perfect example is that in Australia, our largest mobile network provider
Telstra, has completely moved to IPv6 single-stack on their mobile network
for pre-paid and post-paid customers. Russell Langton made the announcement
in February 2020 that Telstra was making the transition and they have since
completed this transition. T-Mobile US also went single-stack back in 2014.
India, with a population of 1.43 billion people (accounting for 17% of the
world's population, sits at 81.24% capable, 80.71% preferred.

With a global rate of 36.49% IPv6 capable and 35.61% IPv6 preferred, we
still have a long way to go however our current achievements to-date should
be commended.

Regards,
Christopher Hawker

Links:
https://lists.ausnog.net/pipermail/ausnog/2020-February/043869.html
https://www.internetsociety.org/deploy360/2014/case-study-t-mobile-us-goes-ipv6-only-using-464xlat/
https://stats.labs.apnic.net/ipv6

On Mon, 15 Jan 2024 at 20:09, Saku Ytti  wrote:

> On Mon, 15 Jan 2024 at 10:59, jordi.palet--- via NANOG 
> wrote:
>
> > No, I’m not saying that. I’m saying "in actual deployments", which
> doesn’t mean that everyone is deploying, we are missing many ISPs, we are
> missing many enterprises.
>
> Because of low entropy of A-B pairs in bps volume, seeing massive
> amounts of IPv6 in IPv6 enabled networks is not indicative of IPv6
> success. I don't disagree with your assertion, I just think it's
> damaging, because readers without context will form an idea that
> things are going smoothly.  We should rightly be in panic mode and
> forget all the IPv4 extension crap and start thinking how do we ensure
> IPv6 happens and how do we ensure we get back to single stack
> Internet.
>
> IPv6 is very much an afterthought, a 2nd class citizen today. You can
> deploy new features and software without IPv6, and it's fine. IPv6 can
> be broken, and it's not an all-hands-on-deck problem, no one is
> calling.
>
> --
>   ++ytti
>

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Saku Ytti]

On Mon, 15 Jan 2024 at 10:59, jordi.palet--- via NANOG  wrote:

> No, I’m not saying that. I’m saying "in actual deployments", which doesn’t 
> mean that everyone is deploying, we are missing many ISPs, we are missing 
> many enterprises.

Because of low entropy of A-B pairs in bps volume, seeing massive
amounts of IPv6 in IPv6 enabled networks is not indicative of IPv6
success. I don't disagree with your assertion, I just think it's
damaging, because readers without context will form an idea that
things are going smoothly.  We should rightly be in panic mode and
forget all the IPv4 extension crap and start thinking how do we ensure
IPv6 happens and how do we ensure we get back to single stack
Internet.

IPv6 is very much an afterthought, a 2nd class citizen today. You can
deploy new features and software without IPv6, and it's fine. IPv6 can
be broken, and it's not an all-hands-on-deck problem, no one is
calling.

-- 
  ++ytti

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[jordi.palet--- via NANOG]

No, I’m not saying that. I’m saying "in actual deployments", which doesn’t mean 
that everyone is deploying, we are missing many ISPs, we are missing many 
enterprises.

Saludos,
Jordi

@jordipalet


> El 15 ene 2024, a las 9:26, Saku Ytti  escribió:
> 
> On Mon, 15 Jan 2024 at 10:05, jordi.palet--- via NANOG  
> wrote:
> 
>> In actual customer deployments I see the same levels, even up to 85% of IPv6 
>> traffic. It basically depends on the usage of the caches and the % of 
>> residential vs corporate customers.
> 
> You think you are contributing to the IPv6 cause, by explaining how
> positive the situation is. But in reality you are damaging it greatly,
> because you're not communicating that we are not on a path to IPv4
> free Internet. If we had been on such a path, we would have been IPv4
> free for more than a decade. And unless we admit we are not on that
> path, we will not work to get on that path.
> 
> -- 
>  ++ytti



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

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Saku Ytti]

On Mon, 15 Jan 2024 at 10:05, jordi.palet--- via NANOG  wrote:

> In actual customer deployments I see the same levels, even up to 85% of IPv6 
> traffic. It basically depends on the usage of the caches and the % of 
> residential vs corporate customers.

You think you are contributing to the IPv6 cause, by explaining how
positive the situation is. But in reality you are damaging it greatly,
because you're not communicating that we are not on a path to IPv4
free Internet. If we had been on such a path, we would have been IPv4
free for more than a decade. And unless we admit we are not on that
path, we will not work to get on that path.

-- 
  ++ytti

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[jordi.palet--- via NANOG]

All those measurements are missing the amount of traffic in the caches located 
at the ISPs.

For each download passing thru AMSIX, there are thousands of multiples of that 
download (videos, music, documents, static contents, OS updates, etc.) flowing 
to thousands of customers. In some cases is even hundreds of thousands, or even 
millions.

There is not an easy way to measure IPv6 traffic, unless it is done at the ISP 
level, and if you as, to ISPs that have deployed IPv6, they will tell you 
different numbers. For example, T-Mobile already explained a few years ago in 
v6ops that they were having over 75% of IPv6 traffic, 24% in the NAT64 and 1% 
in the CLAT+NAT64.

In actual customer deployments I see the same levels, even up to 85% of IPv6 
traffic. It basically depends on the usage of the caches and the % of 
residential vs corporate customers.

Regards,
Jordi

@jordipalet


> El 15 ene 2024, a las 7:50, Saku Ytti  escribió:
> 
> On Mon, 15 Jan 2024 at 06:18, Forrest Christian (List Account) 
> mailto:li...@packetflux.com>> wrote:
> 
>> If 50٪ of the servers and 50% of the clients can do IPv6, the amount of IPv6 
>> traffic will be around 25% since both ends have to do IPv6.
> 
> This assumes cosmological principle applies to the Internet, but Internet 
> traffic is not uniformly distributed.
> 
> It is entirely possible, and even reasonable, that AMSIX ~5% and GOOG 40% are 
> bps shares, and both are correct. Because AMSIX sees large entropy between 
> A-B end-points, GOOG sees very low entropy, it being always the B. 
> 
> Certain tier1 transit network could see traffic being >50% IPv6 between two 
> specific pops, so great IPv6 adoption? Except it was a single CDN sending 
> traffic from them to them, if you'd exclude that CDN flows between the pop, 
> the IPv6 traffic share was low single digit percentage. 
> 
> I am not saying IPv6 traffic is not increasing, I am saying that we are not 
> doing any favours to anyone, pretending we are on-track and that this will 
> happen, and that there are organic drivers which will ensure we are going to 
> end up with IPV6-only Internet.
> 
> --
>   ++ytti



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

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Saku Ytti]

On Mon, 15 Jan 2024 at 06:18, Forrest Christian (List Account) <
li...@packetflux.com> wrote:

If 50٪ of the servers and 50% of the clients can do IPv6, the amount of
> IPv6 traffic will be around 25% since both ends have to do IPv6.
>

This assumes cosmological principle applies to the Internet, but Internet
traffic is not uniformly distributed.

It is entirely possible, and even reasonable, that AMSIX ~5% and GOOG 40%
are bps shares, and both are correct. Because AMSIX sees large entropy
between A-B end-points, GOOG sees very low entropy, it being always the B.

Certain tier1 transit network could see traffic being >50% IPv6 between two
specific pops, so great IPv6 adoption? Except it was a single CDN sending
traffic from them to them, if you'd exclude that CDN flows between the pop,
the IPv6 traffic share was low single digit percentage.

I am not saying IPv6 traffic is not increasing, I am saying that we are not
doing any favours to anyone, pretending we are on-track and that this will
happen, and that there are organic drivers which will ensure we are going
to end up with IPV6-only Internet.

-- 
  ++ytti

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Forrest Christian (List Account)]

If 50٪ of the servers and 50% of the clients can do IPv6, the amount of
IPv6 traffic will be around 25% since both ends have to do IPv6.

If you're running an IPv6 enabled server you'll see 50% of your traffic as
IPv6 in the above scenario.   Likewise, if you are on an IPv6 connected
client, then you'll also see 50٪ of your traffic as IPv6.

Note that if your adoption rates are lower, say 30% and 40%, your IPv6
traffic will be lower..  around 12% in the 30/40٪ scenario.

Cloudflare has an interesting analysis.
https://blog.cloudflare.com/ipv6-from-dns-pov#:~:text=IPv6%20Adoption%20on%20the%20Server%20Side,-The%20following%20graph=IPv6%20adoption%20by%20servers%20is,what%20was%20observed%20for%20clients
.

On Sun, Jan 14, 2024, 8:51 PM Abraham Y. Chen  wrote:

> Hi, Ryan:
>
> 1) " ... it accounts for 40% of the traffic at Google.   ":
>
> Perhaps you were referring to the following?
>
> https://www.google.com/intl/en/ipv6/statistics.html
>
> 2)If so, your quotation is correct, except there are some hidden
> stories below the surface:
>
> A.When you Google for it with key words "IPv6 Traffic Google", the
> first hit shows "IPv6 *Adoption*" that lead to the above. So, strictly
> speaking, it is *not traffic *data that you are looking at.
>
> B.Above the actual graph, you will find statements, such as "
> ...  the *availability of IPv6 connectivity* among Google users. "
> So, legally, the graph is correct on its own right, but may not be exactly
> what you thought. Reader be aware!
>
> It implies that the graph the IPv6 capability (equipment readiness) of
> Google users, not necessarily the actual traffic they generate. The two do
> not equate to each other.
>
> 3)However, the above did seem to support what was generally said in
> the public. Until, we found an interesting ongoing (the only one of such
> resource that is updated about every ten minutes) statistics by AMS-IX
> (AMSterdam Internet eXchange) :
>
> https://stats.ams-ix.net/sflow/ipv6.html
>
> https://stats.ams-ix.net/sflow/ether_type.html
> a
> The second URL shows that IPv6 accounts for approximately 5.7% of the
> overall Internet traffic that AMS-IX sees today. If one traces back through
> the archived data, the earlier numbers were even much lower. In fact, those
> graphs looked meaningless, because there was hardly any visible trace
> colored for IPv6. This has been going on for at least the last one decade.
> So, it could not be an error.
>
> 4)We contacted AMS-IX for a possible explanation of the obvious
> discrepancy. They politely referred us to our own ISPs. This triggered our
> curiosity. We decided that we needed to find the full world-wide IPv6
> traffic data.
>
> 5)There was an annual world-wide Internet traffic statistics and
> forecast published by Cisco that stopped after 2017 (see URL below to the
> last issue). We contacted Cisco in 2020 and got an eMail confirmation.
>
>
> https://cloud.report/Resources/Whitepapers/eea79d9b-9fe3-4018-86c6-3d1df813d3b8_white-paper-c11-741490.pdf
>
> 6)However, there has never been any equivalent publication for the
> IPv6 by itself that we could locate.
>
> 7)In search for a possible explanation of the discrepancy between Pts.
> 1) & 3), we came across the following article. In brief, it reported that
> the Peering agreements among Internet backbone providers were less settled
> for IPv6 than IPv4. Thus, higher percentage of IPv6 traffic than that of
> IPv4 should have been directed through the IXs (Internet eXchanges), such
> as AMS-IX.
>
> https://www.theregister.com/2018/08/28/ipv6_peering_squabbles/
>
> 8)The conclusion of Pt. 7) furthered our puzzlement, because it was
> opposite to what we were hoping for. That is, the roughly 5.7% IPv6 traffic
> that AMS-IX sees implies that within the overall Internet, the IPv6 traffic
> should be even less than 5.7%, not as high as Google's 40+% (Adoption)
> rate. Since we did not have the resources to further the research on this
> topic, we saved the above summary to share with anyone interested in
> pursuing for a better understanding. It will be much appreciated, if you
> could share your insights of this topic.
>
> Regards,
>
>
> Abe (2024-01-14 22:49 EST)
>
>
>
>
> On 2024-01-12 09:20, Ryan Hamel wrote:
>
> Abraham,
>
> It has existed for many years, already supported on many devices, does
> not require NAT, address space is plentiful, does not require additional
> proposals, and it accounts for 40% of the traffic at Google.
>
> Ryan
>
> --
> *From:* Abraham Y. Chen  
> *Sent:* Friday, January 12, 2024 3:45:32

IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

Hi, Ryan:

1) " ... it accounts for 40% of the traffic at Google.   ":

    Perhaps you were referring to the following?

https://www.google.com/intl/en/ipv6/statistics.html

2)    If so, your quotation is correct, except there are some hidden 
stories below the surface:


    A.    When you Google for it with key words "IPv6 Traffic Google", 
the first hit shows "IPv6 *_/Adoption/_*" that lead to the above. So, 
strictly speaking, it is _/*not traffic */_data that you are looking at.


    B.    Above the actual graph, you will find statements, such as " 
... the *_/availability of IPv6 connectivity/_*_/**/_among Google users. 
" So, legally, the graph is correct on its own right, but may not be 
exactly what you thought. Reader be aware!


    It implies that the graph the IPv6 capability (equipment readiness) 
of Google users, not necessarily the actual traffic they generate. The 
two do not equate to each other.
3)    However, the above did seem to support what was generally said in 
the public. Until, we found an interesting ongoing (the only one of such 
resource that is updated about every ten minutes) statistics by AMS-IX 
(AMSterdam Internet eXchange) :


https://stats.ams-ix.net/sflow/ipv6.html

https://stats.ams-ix.net/sflow/ether_type.html
a
    The second URL shows that IPv6 accounts for approximately 5.7% of 
the overall Internet traffic that AMS-IX sees today. If one traces back 
through the archived data, the earlier numbers were even much lower. In 
fact, those graphs looked meaningless, because there was hardly any 
visible trace colored for IPv6. This has been going on for at least the 
last one decade. So, it could not be an error.


4)    We contacted AMS-IX for a possible explanation of the obvious 
discrepancy. They politely referred us to our own ISPs. This triggered 
our curiosity. We decided that we needed to find the full world-wide 
IPv6 traffic data.


5)    There was an annual world-wide Internet traffic statistics and 
forecast published by Cisco that stopped after 2017 (see URL below to 
the last issue). We contacted Cisco in 2020 and got an eMail confirmation.


https://cloud.report/Resources/Whitepapers/eea79d9b-9fe3-4018-86c6-3d1df813d3b8_white-paper-c11-741490.pdf

6)    However, there has never been any equivalent publication for the 
IPv6 by itself that we could locate.


7)    In search for a possible explanation of the discrepancy between 
Pts. 1) & 3), we came across the following article. In brief, it 
reported that the Peering agreements among Internet backbone providers 
were less settled for IPv6 than IPv4. Thus, higher percentage of IPv6 
traffic than that of IPv4 should have been directed through the IXs 
(Internet eXchanges), such as AMS-IX.


https://www.theregister.com/2018/08/28/ipv6_peering_squabbles/

8)    The conclusion of Pt. 7) furthered our puzzlement, because it was 
opposite to what we were hoping for. That is, the roughly 5.7% IPv6 
traffic that AMS-IX sees implies that within the overall Internet, the 
IPv6 traffic should be even less than 5.7%, not as high as Google's 40+% 
(Adoption) rate. Since we did not have the resources to further the 
research on this topic, we saved the above summary to share with anyone 
interested in pursuing for a better understanding. It will be much 
appreciated, if you could share your insights of this topic.


Regards,


Abe (2024-01-14 22:49 EST)




On 2024-01-12 09:20, Ryan Hamel wrote:

Abraham,

It has existed for many years, already supported on many devices, does 
not require NAT, address space is plentiful, does not require 
additional proposals, and it accounts for 40% of the traffic at Google.


Ryan


*From:* Abraham Y. Chen 
*Sent:* Friday, January 12, 2024 3:45:32 AM
*To:* Ryan Hamel 
*Cc:* nanog@nanog.org ; Michael Butler 
; Chen, Abraham Y. 
*Subject:* IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 
address block



Caution: This is an external email and may be malicious. Please take 
care when clicking links or opening attachments.



Hi, Ryan:

1)   " ...  Save yourself the time and effort on this and implement 
IPv6.    ":


    What is your selling point?


Regards,


Abe (2024-01-12 06:44)





--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Oliver O'Boyle]

Thank you, everyone, for your responses.

Abe, I appreciate your enthisam but it is obvious you are not interested in
collaboration. You are singularly-minded and trollish.

I am assigning your email address to my spam filters. I will not see any
future communication from you.

O.


On Sat, Jan 13, 2024, 4:13 p.m. Abraham Y. Chen  wrote:

> Hi, Seth:
>
> 0)Thanks for bringing up this pair of Drafts.
>
> 1)While I believe your "IPv4 Unicast Extension" team carried on with
> the first, Avinta got accidentally exposed to the second. After analyzed
> the hurdle it faced in adding on to RFC1918, the EzIP Project is now
> focusing on enhancing CG-NAT by expanding  RFC6598.
>
> Regards,
>
>
> Abe (2024-01-13 16:08)
>
> On 2024-01-12 14:45, Seth David Schoen wrote:
>
> Michael Thomas writes:
>
>
> I wonder if the right thing to do is to create a standards track RFC that
> makes the experimental space officially an add on to rfc 1918. If it works
> for you, great, if not your problem. It would at least stop all of these
> recurring arguments that we could salvage it for public use when the
> knowability of whether it could work is zero.
>
> In 2008 there were two proposals
> https://datatracker.ietf.org/doc/draft-fuller-240space/https://datatracker.ietf.org/doc/draft-wilson-class-e/
>
> where the former was agnostic about how we would eventually be able to
> use 240/4, and the latter designated it as RFC 1918-style private space.
> Unfortunately, neither proposal was adopted as an RFC then, so we lost a
> lot of time in which more vendors and operators could have made more
> significant progress on its usability.
>
>
>
>
> 
> Virus-free.www.avast.com
> 
> <#m_2842409467345373561_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

Hi, Seth:

0)    Thanks for bringing up this pair of Drafts.

1)    While I believe your "IPv4 Unicast Extension" team carried on with 
the first, Avinta got accidentally exposed to the second. After analyzed 
the hurdle it faced in adding on to RFC1918, the EzIP Project is now 
focusing on enhancing CG-NAT by expanding  RFC6598.


Regards,


Abe (2024-01-13 16:08)

On 2024-01-12 14:45, Seth David Schoen wrote:

Michael Thomas writes:


I wonder if the right thing to do is to create a standards track RFC that
makes the experimental space officially an add on to rfc 1918. If it works
for you, great, if not your problem. It would at least stop all of these
recurring arguments that we could salvage it for public use when the
knowability of whether it could work is zero.

In 2008 there were two proposals

https://datatracker.ietf.org/doc/draft-fuller-240space/
https://datatracker.ietf.org/doc/draft-wilson-class-e/

where the former was agnostic about how we would eventually be able to
use 240/4, and the latter designated it as RFC 1918-style private space.
Unfortunately, neither proposal was adopted as an RFC then, so we lost a
lot of time in which more vendors and operators could have made more
significant progress on its usability.




--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Michael Thomas]

On 1/12/24 11:54 AM, Darrel Lewis wrote:

On Jan 12, 2024, at 11:47 AM, Seth David Schoen  wrote:

Michael Thomas writes:


I wonder if the right thing to do is to create a standards track RFC that
makes the experimental space officially an add on to rfc 1918. If it works
for you, great, if not your problem. It would at least stop all of these
recurring arguments that we could salvage it for public use when the
knowability of whether it could work is zero.

In 2008 there were two proposals

https://datatracker.ietf.org/doc/draft-fuller-240space/
https://datatracker.ietf.org/doc/draft-wilson-class-e/

where the former was agnostic about how we would eventually be able to
use 240/4, and the latter designated it as RFC 1918-style private space.
Unfortunately, neither proposal was adopted as an RFC then, so we lost a
lot of time in which more vendors and operators could have made more
significant progress on its usability.

Well, we were supposed to all be using IPv6 (only) by now, and making 240/4 
useable was just going to slow that process down.

IMHO, this is what you get when religion is mixed with engineering.


But it wouldn't be globally routable so it wouldn't change much. I'm not 
even sure it would change much on the ground for CGNAT deployment? You 
still need enough public addresses to service the load. It might make it 
easier than partitioning your internal net into multiple 10/8 but on the 
other hand you need to make certain your internal net still works with 
240/4.


I'm mostly throwing this out there as a way to shut down these kinds of 
discussions.


Mike

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Darrel Lewis]

> On Jan 12, 2024, at 11:47 AM, Seth David Schoen  wrote:
> 
> Michael Thomas writes:
> 
>> I wonder if the right thing to do is to create a standards track RFC that
>> makes the experimental space officially an add on to rfc 1918. If it works
>> for you, great, if not your problem. It would at least stop all of these
>> recurring arguments that we could salvage it for public use when the
>> knowability of whether it could work is zero.
> 
> In 2008 there were two proposals
> 
> https://datatracker.ietf.org/doc/draft-fuller-240space/
> https://datatracker.ietf.org/doc/draft-wilson-class-e/
> 
> where the former was agnostic about how we would eventually be able to
> use 240/4, and the latter designated it as RFC 1918-style private space.
> Unfortunately, neither proposal was adopted as an RFC then, so we lost a
> lot of time in which more vendors and operators could have made more
> significant progress on its usability.

Well, we were supposed to all be using IPv6 (only) by now, and making 240/4 
useable was just going to slow that process down.   

IMHO, this is what you get when religion is mixed with engineering.

-Darrel

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Seth David Schoen]

Michael Thomas writes:

> I wonder if the right thing to do is to create a standards track RFC that
> makes the experimental space officially an add on to rfc 1918. If it works
> for you, great, if not your problem. It would at least stop all of these
> recurring arguments that we could salvage it for public use when the
> knowability of whether it could work is zero.

In 2008 there were two proposals

https://datatracker.ietf.org/doc/draft-fuller-240space/
https://datatracker.ietf.org/doc/draft-wilson-class-e/

where the former was agnostic about how we would eventually be able to
use 240/4, and the latter designated it as RFC 1918-style private space.
Unfortunately, neither proposal was adopted as an RFC then, so we lost a
lot of time in which more vendors and operators could have made more
significant progress on its usability.

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Michael Thomas]

On 1/12/24 8:45 AM, Owen DeLong via NANOG wrote:
Frankly, I care less. No matter how you use whatever IPv4 space you 
attempt to cajole into whatever new form of degraded service, the 
simple fact remains. IPv4 is a degraded technology that only continues 
to get worse over time. NAT was bad. CGNAT is even worse (and 
tragically does nothing to eliminate consumer NAT, just layers more 
disaster on top of the existing mess).


The only currently available end to end peer to peer technology, for 
better or worse, is IPv6. Despite its naysayers, it is a proven 
technology that has been shouldering a significant fraction of 
internet traffic for many years now and that fraction continues to grow.


You simply can’t make IPv4 adequate and more hackers to extend its 
life merely expands the amount of pain and suffering we must endure 
before it is finally retired.


I wonder if the right thing to do is to create a standards track RFC 
that makes the experimental space officially an add on to rfc 1918. If 
it works for you, great, if not your problem. It would at least stop all 
of these recurring arguments that we could salvage it for public use 
when the knowability of whether it could work is zero.


Mike

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[borg]

I could NOT agree more. Even tho, I am IPv6 phobic, let IPv4 go away.
At least, make it go away from mainstream commercial Internet.
90% users do NOT care about it. They want to browse web, watch movies
or play games. They can do it using IPv6.
I cant wait :) more IPv4 address space for people like me and our projects.


-- Original message --

From: Owen DeLong via NANOG 
To: Abraham Y. Chen 
Cc: "Chen, Abraham Y." , nanog@nanog.org
Subject: Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address
block
Date: Fri, 12 Jan 2024 08:45:22 -0800

Frankly, I care less. No matter how you use whatever IPv4 space you
attempt to cajole into whatever new form of degraded service, the simple
fact remains. IPv4 is a degraded technology that only continues to get
worse over time. NAT was bad. CGNAT is even worse (and tragically does
nothing to eliminate consumer NAT, just layers more disaster on top of
the existing mess). 

The only currently available end to end peer to peer technology, for
better or worse, is IPv6. Despite its naysayers, it is a proven
technology that has been shouldering a significant fraction of internet
traffic for many years now and that fraction continues to grow.

You simply can˙˙t make IPv4 adequate and more hackers to extend its life
merely expands the amount of pain and suffering we must endure before it
is finally retired. 

Owen


  On Jan 12, 2024, at 03:46, Abraham Y. Chen
   wrote:

  ˙˙ Hi, Ryan:

1)   " ...  Save yourself the time and effort on this and implement
IPv6.":

What is your selling point?


Regards,


Abe (2024-01-12 06:44)




2024-01-11 12:39, Ryan Hamel wrote:
  Abraham,

You're arguing semantics instead of the actual
point. Residential customers want Internet access, not
intranet access. Again, VRFs are plentiful and so are CG-NAT
firewall appliances or servers to run those VMs.

Save yourself the time and effort on this and implement IPv6.

Ryan


From: NANOG  on
behalf of Abraham Y. Chen 
Sent: Thursday, January 11, 2024 9:24:18 AM
To: Michael Butler 
Cc: nanog@nanog.org 
Subject: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4
address block


Caution: This is an external email and may be malicious.
Please take care when clicking links or opening attachments.

Hi, Michael:

1)" ... While you may be able to get packets from point A
to B in a private setting, using them might also be .. a
challenge. ...   ":

EzIP uses 240/4 netblock only within the RAN (Regional
Area Network) as "Private" address, not "publicly" routable,
according to the conventional Internet definition. This is
actually the same as how 100.64/10 is used within CG-NAT. 

2)However, this might be where the confusion comes from.
With the geographical area coverage so much bigger, an RAN is
effectively a public network. To mesh the two for
consistency, we defined everything related to 240/4 as
"Semi-Public" to distinguish this new layer of networking
facility from the current public / private separation. That
is, the CG-NAT routers will become SPRs (Semi-Public Routers)
in EzIP's RAN, once the 240/4 is deployed.

Hope this helps,


Abe (2024-01-11 12:21)
 


On 2024-01-10 10:45, Michael Butler via NANOG wrote:
  On 1/10/24 10:12, Tom Beecher wrote:
Karim-

Please be cautious about this advice,
and understand the full context.

240/4 is still classified as RESERVED
space. While you would certainly be
able to use it on internal networks
if your equipment supports it, you
cannot use it as publicly routable
space. There have been many proposals
over the years to reclassify 240/4,
but that has not happened, and is
unlikely to at any point in the
foreseeable future.


  While you may be able to get packets from point A
  to B in a private setting, using them might also
  be .. a challenge.

  There's a whole bunch of software out there that
  makes certain assumptions about allowable ranges.
  That is, they've been compiled with a header that
  defines ..

  #define IN_BADCLASS(i)(((in_addr_t)(i) &
  0xf000) == 0xf000)

  Michael



[icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]
Virus-free.www.avast.com

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Owen DeLong via NANOG]

Frankly, I care less. No matter how you use whatever IPv4 space you attempt to cajole into whatever new form of degraded service, the simple fact remains. IPv4 is a degraded technology that only continues to get worse over time. NAT was bad. CGNAT is even worse (and tragically does nothing to eliminate consumer NAT, just layers more disaster on top of the existing mess). The only currently available end to end peer to peer technology, for better or worse, is IPv6. Despite its naysayers, it is a proven technology that has been shouldering a significant fraction of internet traffic for many years now and that fraction continues to grow.You simply can’t make IPv4 adequate and more hackers to extend its life merely expands the amount of pain and suffering we must endure before it is finally retired. OwenOn Jan 12, 2024, at 03:46, Abraham Y. Chen  wrote:

  

  
  
Hi, Ryan:

   
1)   " ...  Save
yourself the time and effort on this and implement IPv6.    ":

   
    What is your selling
point?

  

  
Regards,

  

  
Abe (2024-01-12 06:44)









2024-01-11 12:39, Ryan Hamel wrote:


  
  Abraham,
  
  
  You're arguing semantics instead of the actual
point. Residential
  customers want Internet access, not intranet access.
Again, VRFs are plentiful and so are CG-NAT firewall appliances
or servers to run those VMs. 
  
  
  Save yourself the time and effort on this and
implement IPv6.
  


Ryan
  
  

From:
  NANOG 
  on behalf of Abraham Y. Chen 
  Sent: Thursday, January 11, 2024 9:24:18 AM
  To: Michael Butler 
  Cc: nanog@nanog.org 
  Subject: Where to Use 240/4 Re:
  202401100645.AYC Re: IPv4 address block



  

  
  
  
Caution:
  This is an external email and may be malicious. Please
  take care when clicking links or opening attachments.

  

  



  Hi, Michael:
  

  1)    " ... While
  you may be able to get packets from point A to B in a
  private setting, using them might also be .. a challenge.
  ...   ":
  

      EzIP uses
  240/4 netblock only within the RAN (Regional Area Network)
as "Private" address, not "publicly" routable, according to the
  conventional Internet definition. This is actually the
  same as how 100.64/10 is used within CG-NAT. 
  

  2)    However,
  this might be where the confusion comes from. With the
  geographical area coverage so much bigger, an RAN is
  effectively a public network. To mesh the two for
  consistency, we defined everything related to 240/4 as
  "Semi-Public" to distinguish this new layer of networking
  facility from the current public / private separation.
  That is, the CG-NAT routers will become SPRs (Semi-Public
  Routers) in EzIP's RAN, once the 240/4 is deployed.

  

  Hope this helps,
  

  

  Abe (2024-01-11
  12:21)
  
   
  
  
  
  
  
  On 2024-01-10 10:45, Michael
Butler via NANOG wrote:
  
  On 1/10/24 10:12, Tom Beecher wrote: 
Karim- 
  
  Please be cautious about this advice, and understand the
  full context. 
  
  240/4 is still classified as RESERVED space. While you
  would certainly be able to use it on internal networks if
  your equipment supports it, you cannot use it as
  publicly routable space. There have been many proposals
  over the years to reclassify 240/4, but that has not
  happened, and is unlikely to at any point in the
  foreseeable future. 


While you may be able to get packets from point A to B in a
private setting, using them might also be .. a challenge. 

There's a whole bunch of software out there that makes
certain assumptions about allowable ranges. That is, they've
been compiled with a header that defines .. 

#define IN_BADCLASS(i)    (((in_addr_t)(i) & 0xf000)
== 0xf000) 

Michael 

  
  
  
 

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Ryan Hamel]

Abraham,

It has existed for many years, already supported on many devices, does not 
require NAT, address space is plentiful, does not require additional proposals, 
and it accounts for 40% of the traffic at Google.

Ryan


From: Abraham Y. Chen 
Sent: Friday, January 12, 2024 3:45:32 AM
To: Ryan Hamel 
Cc: nanog@nanog.org ; Michael Butler 
; Chen, Abraham Y. 
Subject: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address 
block

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

Hi, Ryan:

1)   " ...  Save yourself the time and effort on this and implement IPv6.":

What is your selling point?


Regards,


Abe (2024-01-12 06:44)




2024-01-11 12:39, Ryan Hamel wrote:
Abraham,

You're arguing semantics instead of the actual point. Residential customers 
want Internet access, not intranet access. Again, VRFs are plentiful and so are 
CG-NAT firewall appliances or servers to run those VMs.

Save yourself the time and effort on this and implement IPv6.

Ryan


From: NANOG 
<mailto:nanog-bounces+ryan=rkhtech@nanog.org>
 on behalf of Abraham Y. Chen <mailto:ayc...@avinta.com>
Sent: Thursday, January 11, 2024 9:24:18 AM
To: Michael Butler 
<mailto:i...@protected-networks.net>
Cc: nanog@nanog.org<mailto:nanog@nanog.org> 
<mailto:nanog@nanog.org>
Subject: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block


Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

Hi, Michael:

1)" ... While you may be able to get packets from point A to B in a private 
setting, using them might also be .. a challenge. ...   ":

EzIP uses 240/4 netblock only within the RAN (Regional Area Network) as 
"Private" address, not "publicly" routable, according to the conventional 
Internet definition. This is actually the same as how 100.64/10 is used within 
CG-NAT.

2)However, this might be where the confusion comes from. With the 
geographical area coverage so much bigger, an RAN is effectively a public 
network. To mesh the two for consistency, we defined everything related to 
240/4 as "Semi-Public" to distinguish this new layer of networking facility 
from the current public / private separation. That is, the CG-NAT routers will 
become SPRs (Semi-Public Routers) in EzIP's RAN, once the 240/4 is deployed.

Hope this helps,


Abe (2024-01-11 12:21)



On 2024-01-10 10:45, Michael Butler via NANOG wrote:
On 1/10/24 10:12, Tom Beecher wrote:
Karim-

Please be cautious about this advice, and understand the full context.

240/4 is still classified as RESERVED space. While you would certainly be able 
to use it on internal networks if your equipment supports it, you cannot use it 
as publicly routable space. There have been many proposals over the years to 
reclassify 240/4, but that has not happened, and is unlikely to at any point in 
the foreseeable future.

While you may be able to get packets from point A to B in a private setting, 
using them might also be .. a challenge.

There's a whole bunch of software out there that makes certain assumptions 
about allowable ranges. That is, they've been compiled with a header that 
defines ..

#define IN_BADCLASS(i)(((in_addr_t)(i) & 0xf000) == 0xf000)

Michael



[https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
  
Virus-free.www.avast.com<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>

IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

Hi, Ryan:

1)   " ...  Save yourself the time and effort on this and implement 
IPv6.    ":


    What is your selling point?


Regards,


Abe (2024-01-12 06:44)




2024-01-11 12:39, Ryan Hamel wrote:

Abraham,

You're arguing semantics instead of the actual point. Residential 
customers want Internet access, not intranet access. Again, VRFs are 
plentiful and so are CG-NAT firewall appliances or servers to run 
those VMs.


Save yourself the time and effort on this and implement IPv6.

Ryan


*From:* NANOG  on behalf of 
Abraham Y. Chen 

*Sent:* Thursday, January 11, 2024 9:24:18 AM
*To:* Michael Butler 
*Cc:* nanog@nanog.org 
*Subject:* Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block



Caution: This is an external email and may be malicious. Please take 
care when clicking links or opening attachments.



Hi, Michael:

1)    " ... While you may be able to get packets from point A to B in 
a private setting, using them might also be .. a challenge. ...   ":


    EzIP uses 240/4 netblock only within the RAN (Regional Area 
Network) as "Private" address, not "publicly" routable, according to 
the conventional Internet definition. This is actually the same as how 
100.64/10 is used within CG-NAT.


2)    However, this might be where the confusion comes from. With the 
geographical area coverage so much bigger, an RAN is effectively a 
public network. To mesh the two for consistency, we defined everything 
related to 240/4 as "Semi-Public" to distinguish this new layer of 
networking facility from the current public / private separation. That 
is, the CG-NAT routers will become SPRs (Semi-Public Routers) in 
EzIP's RAN, once the 240/4 is deployed.


Hope this helps,


Abe (2024-01-11 12:21)



On 2024-01-10 10:45, Michael Butler via NANOG wrote:

On 1/10/24 10:12, Tom Beecher wrote:

Karim-

Please be cautious about this advice, and understand the full context.

240/4 is still classified as RESERVED space. While you would 
certainly be able to use it on internal networks if your equipment 
supports it, you cannot use it as publicly routable space. There 
have been many proposals over the years to reclassify 240/4, but 
that has not happened, and is unlikely to at any point in the 
foreseeable future.


While you may be able to get packets from point A to B in a private 
setting, using them might also be .. a challenge.


There's a whole bunch of software out there that makes certain 
assumptions about allowable ranges. That is, they've been compiled 
with a header that defines ..


#define IN_BADCLASS(i)    (((in_addr_t)(i) & 0xf000) == 0xf000)

Michael




 
	Virus-free.www.avast.com 
 







--
This email has been checked for viruses by Avast antivirus software.
www.avast.com