Mailing List Archive

On 11/19/22 05:50, Abraham Y. Chen wrote:

> Dear Owen:
>
> 1) "... Africa ... They don’t really have a lot of alternatives. ...":
> Actually, there is, simple and in plain sight. Please have a look at
> the below IETF Draft:

It's most amusing, to me, how Africa needs to be told how to be...

Some folk just can't help themselves.

Mark.

Dear Mark:

0)  I am surprised at your apparently sarcastic opinion.

1)  The EzIP proposal as referenced by my last MSG is the result of an
in-depth system engineering effort. Since the resultant schemes do not
rely on any protocol development, IETF does not need be involved.
Especially, its first step of disabling one line of existing networking
program code empowers any party to begin deploying EzIP stealthily for
mitigating the IPv4 address pool depletion issues. Note that EzIP is a
generic solution applicable to everyone, not limited to Africa.

2)  Of course, constructive criticism is always appreciated. However,
unspecific comments that confuse and distract the readers only provide
dis-service to those disadvantaged population who are enduring the
handicaps of being the late-comers to the Internet.

Regards,


Abe (2022-11-20 12:02 EST)


On 2022-11-19 07:58, Mark Tinka wrote:
>
>
> On 11/19/22 05:50, Abraham Y. Chen wrote:
>
>> Dear Owen:
>>
>> 1) "... Africa ... They don’t really have a lot of alternatives.
>> ...": Actually, there is, simple and in plain sight. Please have a
>> look at the below IETF Draft:
>
> It's most amusing, to me, how Africa needs to be told how to be...
>
> Some folk just can't help themselves.
>
> Mark.



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

On Sun, Nov 20, 2022 at 2:03 PM Abraham Y. Chen <aychen@avinta.com> wrote:
>
> Dear Mark:
>
> 0) I am surprised at your apparently sarcastic opinion.
>
> 1) The EzIP proposal as referenced by my last MSG is the result of an
> in-depth system engineering effort. Since the resultant schemes do not
> rely on any protocol development, IETF does not need be involved.

If IETF does not need to be involved, why have you submitted 12
versions of your Internet draft to IETF ?
https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/

Rubens

On Fri, Nov 18, 2022 at 7:53 PM Abraham Y. Chen <aychen@avinta.com> wrote:

> Dear Owen:
>
> 1) "... Africa ... They don’t really have a lot of alternatives. ...":
> Actually, there is, simple and in plain sight. Please have a look at the
> below IETF Draft:
>
>
> https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space


Hi Abraham,

I know I'm not the sharpest tool in the shed, but I'm having some
trouble understanding the deployment model for EzIP. Perhaps you
could help clear it up for me?

A non-EzIP web server is only going to see the global destination
IP address and TCP port number as the unique session identifiers
for communication, so the vast amount of additional IP space you
postulate existing behind the SPR functionally collapses down into
the 64K TCP port range available today in traditional port-based NAT
setups. As long as the top 50 websites aren't EzIP-aware, there appears
to be no benefit for an ISP to deploy EzIP, because it doesn't actually
gain them anything beyond what existing CG-NAT devices already provide
as far as their web-browsing customer base is concerned. Most of their
communication will still be port-based-NAT, with all the headaches and
restrictions inherent in that.

And for the top 50 websites, there's a lot of expense and absolutely no
upside
involved in deploying EzIP. They don't care about how much IP space you
have
behind your NAT device, and whether it's uniquely identifiable within your
local
realm; it's not information they can access for tracking users, as they
don't know
what your internal mapping is, so they'll continue to rely on browser
cookies and
the like for tracking actual user sessions, regardless of the IP addressing
format
being used.

So, you've got a model where there's functionally almost no benefit to the
end user
until the major websites start deploying EzIP-aware infrastructure, and
there's
pretty much no incentive for major websites to spend money upgrading their
infrastructure to support EzIP, because it provides no additional benefit
for them.

This is pretty much exactly the same conundrum that IPv6 faced (and still
faces
today). I don't see why EzIP is any better than IPv6 or CG-NAT in terms of
solving
the IPv4 address shortage problem, and it seems to involve more expense for
web
providers, because it requires them to deploy additional SPR mapping
routers into
their infrastructure in order to use it, with essentially no additional
benefit.

Is there a piece to the picture I'm not understanding correctly?

Thanks!

Matt

If I had a dollar for every person who has lived their entire life in a
high-income western country (US, Canada, western Europe, etc) and has zero
personal experience in developing-nation telecom/ISP operations and their
unique operational requirements, yet thinks they've qualified to offer an
opinion on it...

People should go look at some of the WISPs in the Philippines for an
example of ISPs building last and middle mile infrastructure on extremely
limited budgets. Or really just about anywhere else where the residential
broadband market has households where the entire household monthly income
is the equivalent of $500 USD.



On Sat, 19 Nov 2022 at 04:59, Mark Tinka <mark@tinka.africa> wrote:

>
>
> On 11/19/22 05:50, Abraham Y. Chen wrote:
>
> > Dear Owen:
> >
> > 1) "... Africa ... They don’t really have a lot of alternatives. ...":
> > Actually, there is, simple and in plain sight. Please have a look at
> > the below IETF Draft:
>
> It's most amusing, to me, how Africa needs to be told how to be...
>
> Some folk just can't help themselves.
>
> Mark.
>

On 11/20/22 19:02, Abraham Y. Chen wrote:

> Dear Mark:
>
> 0)  I am surprised at your apparently sarcastic opinion.
>
> 1)  The EzIP proposal as referenced by my last MSG is the result of an
> in-depth system engineering effort. Since the resultant schemes do not
> rely on any protocol development, IETF does not need be involved.
> Especially, its first step of disabling one line of existing
> networking program code empowers any party to begin deploying EzIP
> stealthily for mitigating the IPv4 address pool depletion issues. Note
> that EzIP is a generic solution applicable to everyone, not limited to
> Africa.
>
> 2)  Of course, constructive criticism is always appreciated. However,
> unspecific comments that confuse and distract the readers only provide
> dis-service to those disadvantaged population who are enduring the
> handicaps of being the late-comers to the Internet.

My comment was not directed at you. Sorry.

I have nothing against the EzIP proposal. It just does not add any real
value in solving the IPv4 depletion problem for the amount of effort
required to implement it, in my view. I'd, rather, expend those
resources on IPv6, 464XLAT, e.t.c.

Mark.

>
> 1) "... Africa ... They don’t really have a lot of alternatives. ...":
> Actually, there is, simple and in plain sight. Please have a look at the
> below IETF Draft:
>
>
> https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space


For the benefit of anyone who may not understand, this is not an
'alternative'. This is an idea that was initially proposed by the authors
almost exactly 6 years ago. It's received almost no interest from
anyone involved in internet standards, and for various technical reasons ,
likely never will.

On Fri, Nov 18, 2022 at 10:52 PM Abraham Y. Chen <aychen@avinta.com> wrote:

> Dear Owen:
>
> 1) "... Africa ... They don’t really have a lot of alternatives. ...":
> Actually, there is, simple and in plain sight. Please have a look at the
> below IETF Draft:
>
>
> https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space
>
> 2) If this looks a bit too technical due to the nature of such a
> document, there is a distilled version that provides a bird-eye's view
> of the solution:
>
> https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
>
> 3) All of the above can start from making use of the 240/4 netblock as
> a reusable (by region / country) unicast IP address resources that could
> be accomplished by as simple as commenting out one line of the existing
> network router program code. I will be glad to go into the specifics if
> you can bring their attention to this almost mystic topic.
>
> Regards,
>
>
> Abe (2022-11-19 22:50 EST)
>
>
> On 2022-11-18 18:20, Owen DeLong via NANOG wrote:
> >
> >> On Nov 18, 2022, at 03:44, Joe Maimon <jmaimon@jmaimon.com> wrote:
> >>
> >>
> >>
> >> Mark Tinka wrote:
> >>>
> >>> On 11/17/22 19:55, Joe Maimon wrote:
> >>>
> >>>> You could instead use a /31.
> >>> We could, but many of our DIA customers have all manner of CPE's that
> may or may not support this. Having unique designs per customer does not
> scale well.
> >> its almost 2023. /31 support is easily mandatory. You should make it
> mandatory.
> > Much of Africa in 2023 runs on what the US put into the resale market in
> the late 1990s, tragically.
> >
> >> Its 2023, your folk should be able to handle addressing more advanced
> than from the 90s. And your betting the future on IPv6?
> > They don’t really have a lot of alternatives.
> >
> >>> To be honest, we'll keep using IPv4 for as long as we have it, and for
> as long as we can get it from AFRINIC. But it's not where we are betting
> the farm - that is for IPv6.
> > And yet you wonder why I consider AFRINIC’s artificial extension of the
> free pool through draconian austerity measures to be a global problem?
> >
> >> Its on Afrinic to try and preserve their pool if they wish to by doing
> things such as getting it across that progress in addressing efficiency is
> an important consideration in fulfilling requests for additional resources.
> > Instead of this, they’re mostly ignoring policy, implementing draconian
> restrictions on people getting space from the free pool, and buying into
> various forms of reality avoidance.
> >
> >> But see the crux above. If your RiR isnt frowning on such behavior then
> its poor strategy to implement it.
> > So far, AFRINIC has given a complete pass to Tinka’s organization and
> their documented excessive unused address space despite policy that
> prohibits them from doing so. However, AFRINIC management and board seem to
> have extreme difficulty with reading their governing documents in anything
> resembling a logical interpretation.
> >
> > Owen
> >
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
>

Dear Mark:

0) Thanks for the clarification. I understand. A short message through
the cyberspace, especially between parties who have never met can be
easily skewed. I am glad that I asked you, instead of taking it
negatively without raising my hand.

1) "...I'd, rather, expend those resources on IPv6, 464XLAT, e.t.c. ...
": Since EzIP is still being further refined, it may not be clear in our
documentation about how much work is required to get the IPv4 out of the
current depletion mode. As stated in Subsection 4.A. of the "Revamp The
Internet" whitepaper, all need be done is "Simply disable the existing
software codes that have been disabling the use of the 240/4 netblock."
In fact, we have found examples that this means commenting out one line
code that searches for then discards packets with 240/4 addressing. It
seems to me that there is no easier task than this.

https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

Regards,

Abe (2022-11-21 11:18 EST)



On 2022-11-20 23:56, Mark Tinka wrote:
>
>
> On 11/20/22 19:02, Abraham Y. Chen wrote:
>
>> Dear Mark:
>>
>> 0)  I am surprised at your apparently sarcastic opinion.
>>
>> 1)  The EzIP proposal as referenced by my last MSG is the result of
>> an in-depth system engineering effort. Since the resultant schemes do
>> not rely on any protocol development, IETF does not need be involved.
>> Especially, its first step of disabling one line of existing
>> networking program code empowers any party to begin deploying EzIP
>> stealthily for mitigating the IPv4 address pool depletion issues.
>> Note that EzIP is a generic solution applicable to everyone, not
>> limited to Africa.
>>
>> 2)  Of course, constructive criticism is always appreciated. However,
>> unspecific comments that confuse and distract the readers only
>> provide dis-service to those disadvantaged population who are
>> enduring the handicaps of being the late-comers to the Internet.
>
> My comment was not directed at you. Sorry.
>
> I have nothing against the EzIP proposal. It just does not add any
> real value in solving the IPv4 depletion problem for the amount of
> effort required to implement it, in my view. I'd, rather, expend those
> resources on IPv6, 464XLAT, e.t.c.
>
> Mark.
>


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

>
> As stated in Subsection 4.A. of the "Revamp The
> Internet" whitepaper, all need be done is "Simply disable the existing
> software codes that have been disabling the use of the 240/4 netblock."
>

Some friendly feedback. The phrase "all that needs to be done" , is
exceptionally reductive, and in the case of internet standards, also always
going to end up being wrong.

On Mon, Nov 21, 2022 at 11:19 AM Abraham Y. Chen <aychen@avinta.com> wrote:

> Dear Mark:
>
> 0) Thanks for the clarification. I understand. A short message through
> the cyberspace, especially between parties who have never met can be
> easily skewed. I am glad that I asked you, instead of taking it
> negatively without raising my hand.
>
> 1) "...I'd, rather, expend those resources on IPv6, 464XLAT, e.t.c. ...
> ": Since EzIP is still being further refined, it may not be clear in our
> documentation about how much work is required to get the IPv4 out of the
> current depletion mode. As stated in Subsection 4.A. of the "Revamp The
> Internet" whitepaper, all need be done is "Simply disable the existing
> software codes that have been disabling the use of the 240/4 netblock."
> In fact, we have found examples that this means commenting out one line
> code that searches for then discards packets with 240/4 addressing. It
> seems to me that there is no easier task than this.
>
> https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
>
> Regards,
>
> Abe (2022-11-21 11:18 EST)
>
>
>
> On 2022-11-20 23:56, Mark Tinka wrote:
> >
> >
> > On 11/20/22 19:02, Abraham Y. Chen wrote:
> >
> >> Dear Mark:
> >>
> >> 0) I am surprised at your apparently sarcastic opinion.
> >>
> >> 1) The EzIP proposal as referenced by my last MSG is the result of
> >> an in-depth system engineering effort. Since the resultant schemes do
> >> not rely on any protocol development, IETF does not need be involved.
> >> Especially, its first step of disabling one line of existing
> >> networking program code empowers any party to begin deploying EzIP
> >> stealthily for mitigating the IPv4 address pool depletion issues.
> >> Note that EzIP is a generic solution applicable to everyone, not
> >> limited to Africa.
> >>
> >> 2) Of course, constructive criticism is always appreciated. However,
> >> unspecific comments that confuse and distract the readers only
> >> provide dis-service to those disadvantaged population who are
> >> enduring the handicaps of being the late-comers to the Internet.
> >
> > My comment was not directed at you. Sorry.
> >
> > I have nothing against the EzIP proposal. It just does not add any
> > real value in solving the IPv4 depletion problem for the amount of
> > effort required to implement it, in my view. I'd, rather, expend those
> > resources on IPv6, 464XLAT, e.t.c.
> >
> > Mark.
> >
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
>

Dear Tom:

0) Thanks for your advice.

1) What I wrote was just informal online chatting. I was not attempting
to make a water-tight legal statement. The fact is, we have identified
at least one concise case of how this task could be done easily, as
reported in Appendix D of the EzIP IETF Draft. Although no references
have been published, I believe that colleagues on the IPv4 Unicast
Extensions Project have seen similar situations.  Even without the
latter, a "there exists one reference" should be sufficient to encourage
other software engineers to review their own work. They should question
the quality of their own programs if they are more complex, instead of
ridiculing the concise example on the table.

Regards,


Abe (2022-11-21 12:54 EST)


On 2022-11-21 12:00, Tom Beecher wrote:
>
> As stated in Subsection 4.A. of the "Revamp The
> Internet" whitepaper, all need be done is "Simply disable the existing
> software codes that have been disabling the use of the 240/4
> netblock."
>
>
> Some friendly feedback. The phrase "all that needs to be done" , is
> exceptionally reductive, and in the case of internet standards, also
> always going to end up being wrong.
>
> On Mon, Nov 21, 2022 at 11:19 AM Abraham Y. Chen <aychen@avinta.com>
> wrote:
>
> Dear Mark:
>
> 0) Thanks for the clarification. I understand. A short message
> through
> the cyberspace, especially between parties who have never met can be
> easily skewed. I am glad that I asked you, instead of taking it
> negatively without raising my hand.
>
> 1) "...I'd, rather, expend those resources on IPv6, 464XLAT,
> e.t.c. ...
> ": Since EzIP is still being further refined, it may not be clear
> in our
> documentation about how much work is required to get the IPv4 out
> of the
> current depletion mode. As stated in Subsection 4.A. of the
> "Revamp The
> Internet" whitepaper, all need be done is "Simply disable the
> existing
> software codes that have been disabling the use of the 240/4
> netblock."
> In fact, we have found examples that this means commenting out one
> line
> code that searches for then discards packets with 240/4
> addressing. It
> seems to me that there is no easier task than this.
>
> https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
>
> Regards,
>
> Abe (2022-11-21 11:18 EST)
>
>
>
> On 2022-11-20 23:56, Mark Tinka wrote:
> >
> >
> > On 11/20/22 19:02, Abraham Y. Chen wrote:
> >
> >> Dear Mark:
> >>
> >> 0)  I am surprised at your apparently sarcastic opinion.
> >>
> >> 1)  The EzIP proposal as referenced by my last MSG is the
> result of
> >> an in-depth system engineering effort. Since the resultant
> schemes do
> >> not rely on any protocol development, IETF does not need be
> involved.
> >> Especially, its first step of disabling one line of existing
> >> networking program code empowers any party to begin deploying EzIP
> >> stealthily for mitigating the IPv4 address pool depletion issues.
> >> Note that EzIP is a generic solution applicable to everyone, not
> >> limited to Africa.
> >>
> >> 2)  Of course, constructive criticism is always appreciated.
> However,
> >> unspecific comments that confuse and distract the readers only
> >> provide dis-service to those disadvantaged population who are
> >> enduring the handicaps of being the late-comers to the Internet.
> >
> > My comment was not directed at you. Sorry.
> >
> > I have nothing against the EzIP proposal. It just does not add any
> > real value in solving the IPv4 depletion problem for the amount of
> > effort required to implement it, in my view. I'd, rather, expend
> those
> > resources on IPv6, 464XLAT, e.t.c.
> >
> > Mark.
> >
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <http://www.avast.com>
>

My suggestion is ignore anyone who says it would be too difficult to
get people to adopt a change or take too long. Someone always says
that, a reasonable riposte is "what would be a reasonable number of
people / years?" Surely they must have some numbers in mind, no?

We've been trying to get people to adopt IPv6 widely for 30 years with
very limited success so perhaps that's a pretty time to shoot for, for
example. Anything less than 30 years would be an improvement.

I suppose some might leap on that as evidence of the above cautions
but it's really not. It's just being argumentative. It feels like a
reasonable argument pattern but it's not because it ignores why that
previous attempt mostly failed and tries to equate them (we failed for
30 years so therefore you will fail for 30 years???)

That said, what's needed is a working demo preferably within both a
simulation environment and live because the devil is always in the
details and the only way to vet that is by testing working code.

A mere proposal is of some value, one can glance at it and try to spot
any fatal flaws for example. But it's only a tiny step along the path.

However, that it might take a while to become adopted is, to me, like
saying forget trying to mitigate climate change, it'll take decades
and require hundreds of govts, thousands of industries, and billions
of people to change their behavior which is all true but hardly an
argument as to why not to try.

Aside: A pretty good rule of thumb with replacement technologies is
that something has to be 10x better than what it replaces to get wide
adoption. Ok maybe not 10, that's a figure of speech, but a lot, and
certainly not introduce impediments to its own adoption and use.

On November 21, 2022 at 12:00 beecher@beecher.cc (Tom Beecher) wrote:
> As stated in Subsection 4.A. of the "Revamp The
> Internet" whitepaper, all need be done is "Simply disable the existing
> software codes that have been disabling the use of the 240/4 netblock."
>
>
> Some friendly feedback. The phrase "all that needs to be done" , is
> exceptionally reductive, and in the?case of internet standards, also always
> going to end up being wrong.?
>
> On Mon, Nov 21, 2022 at 11:19 AM Abraham Y. Chen <aychen@avinta.com> wrote:
>
> Dear Mark:
>
> 0) Thanks for the clarification. I understand. A short message through
> the cyberspace, especially between parties who have never met can be
> easily skewed. I am glad that I asked you, instead of taking it
> negatively without raising my hand.
>
> 1) "...I'd, rather, expend those resources on IPv6, 464XLAT, e.t.c. ...
> ": Since EzIP is still being further refined, it may not be clear in our
> documentation about how much work is required to get the IPv4 out of the
> current depletion mode. As stated in Subsection 4.A. of the "Revamp The
> Internet" whitepaper, all need be done is "Simply disable the existing
> software codes that have been disabling the use of the 240/4 netblock."
> In fact, we have found examples that this means commenting out one line
> code that searches for then discards packets with 240/4 addressing. It
> seems to me that there is no easier task than this.
>
> https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
>
> Regards,
>
> Abe (2022-11-21 11:18 EST)
>
>
>
> On 2022-11-20 23:56, Mark Tinka wrote:
> >
> >
> > On 11/20/22 19:02, Abraham Y. Chen wrote:
> >
> >> Dear Mark:
> >>
> >> 0)? I am surprised at your apparently sarcastic opinion.
> >>
> >> 1)? The EzIP proposal as referenced by my last MSG is the result of
> >> an in-depth system engineering effort. Since the resultant schemes do
> >> not rely on any protocol development, IETF does not need be involved.
> >> Especially, its first step of disabling one line of existing
> >> networking program code empowers any party to begin deploying EzIP
> >> stealthily for mitigating the IPv4 address pool depletion issues.
> >> Note that EzIP is a generic solution applicable to everyone, not
> >> limited to Africa.
> >>
> >> 2)? Of course, constructive criticism is always appreciated. However,
> >> unspecific comments that confuse and distract the readers only
> >> provide dis-service to those disadvantaged population who are
> >> enduring the handicaps of being the late-comers to the Internet.
> >
> > My comment was not directed at you. Sorry.
> >
> > I have nothing against the EzIP proposal. It just does not add any
> > real value in solving the IPv4 depletion problem for the amount of
> > effort required to implement it, in my view. I'd, rather, expend those
> > resources on IPv6, 464XLAT, e.t.c.
> >
> > Mark.
> >
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
>

--
-Barry Shein

Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD
The World: Since 1989 | A Public Information Utility | *oo*

Barry,

On Nov 21, 2022, at 3:01 PM, bzs@theworld.com wrote:
> We've been trying to get people to adopt IPv6 widely for 30 years with very limited success

According to https://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone from ~0% to ~40% in 12 years. https://stats.labs.apnic.net/ipv6 has it around 30%. Given an Internet population of about 5B, this can (simplistically and wrongly) argued to mean 1.5-2B people are using IPv6. For a transition to a technology that the vast majority of people who pay the bills will neither notice nor care about, and for which the business case typically needs projection way past the normal quarterly focus of shareholders, that seems pretty successful to me.

But back to the latest proposal to rearrange deck chairs on the IPv4 Titanic, the fundamental and obvious flaw is the assertion of "commenting out one line code”. There isn’t “one line of code”. There are literally _billions_ of instances of “one line of code”, the vast majority of which need to be changed/deployed/tested with absolutely no business case to do so that isn’t better met with deploying IPv6+IPv4aaS. I believe this has been pointed out numerous times, but it falls on deaf ears, so the discussion gets a bit tedious.

Regards,
-drc

David Conrad wrote:
> Barry,
>
> On Nov 21, 2022, at 3:01 PM, bzs@theworld.com wrote:
>> We've been trying to get people to adopt IPv6 widely for 30 years
>> with very limited success
>
> According to https://www.google.com/intl/en/ipv6/statistics.html, it
> looks like we’ve gone from ~0% to ~40% in 12 years.
> https://stats.labs.apnic.net/ipv6 has it around 30%. Given an Internet
> population of about 5B, this can (simplistically and wrongly) argued
> to mean 1.5-2B people are using IPv6. For a transition to a technology
> that the vast majority of people who pay the bills will neither notice
> nor care about, and for which the business case typically needs
> projection way past the normal quarterly focus of shareholders, that
> seems pretty successful to me.
>
> But back to the latest proposal to rearrange deck chairs on the IPv4
> Titanic, the fundamental and obvious flaw is the assertion of
> "commenting out one line code”. There isn’t “one line of code”. There
> are literally _billions_ of instances of “one line of code”, the vast
> majority of which need to be changed/deployed/tested with absolutely
> no business case to do so that isn’t better met with deploying
> IPv6+IPv4aaS. I believe this has been pointed out numerous times, but
> it falls on deaf ears, so the discussion gets a bit tedious.
>
> Regards,
> -drc
>
Had the titanic stayed afloat some hours more, many more would have
survived and been rescued when assistance eventually arrived. So that
makes this a debate over whether this is deck chair re-arrangement or
something more meaningful.

As I and others have pointed out, it depends on how it is used. And
perhaps the attempt should be made regardless of knowing in advance
which it will be.

You assertion needs some back of the envelope numbers, which once
provided, I suspect will render your estimate grossly incorrect.

You can hardly attempt to convince anybody that 240/4 as unicast would
not be the more trivial change made in any of these products natural
life cycle points.

Especially as we have examples of what that type of effort might look
like. IGTFY and here

https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/

The burdensome position is ridiculous even more so when stated with a
straight face.

Joe

On 11/21/22 16:30, Joe Maimon wrote:

> You can hardly attempt to convince anybody that 240/4 as unicast would
> not be the more trivial change made in any of these products natural
> life cycle points.

One can and indeed some do attempt to do just that. The likelihood of
these attempts actually convincing those in a position to influence
change is what is in question.

IMNSHO, if such a proposal were to gain traction, by the time that gear
capable of using 240/4 as unicast were to be widely deployed,
IPv6-capable gear would be much more widely deployed.

META: Can whoever is doing so please stop creating new time-stamped
subject lines for the same topic? It makes things hard to follow.

--
Jay Hennigan - jay@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Joe,

On Nov 21, 2022, at 4:30 PM, Joe Maimon <jmaimon@jmaimon.com> wrote:
> As I and others have pointed out, it depends on how it is used.

Sure, and with enough thrust and an appropriate trajectory, pigs fly quite well, although the landing can get messy. With enough constraints, any problem becomes trivially solvable. Whether it is a useful problem to solve is the question.

> And perhaps the attempt should be made regardless of knowing in advance which it will be.

You’ll get no argument from me. In the past, I’ve suggested a Cloudflare 1.1.1.1-like experiment would provide useful data.

> You can hardly attempt to convince anybody that 240/4 as unicast would not be the more trivial change made in any of these products natural life cycle points.


How trivial would the change be in a product by a company that no longer exists or a product line that is no longer supported? Will Microsoft update all previous versions of Windows? Will the myriad of deployed embedded systems sitting forgotten in closets be updated? And if you’re going to the trouble to update those systems (in most cases, by simply throwing them away), why not upgrade to IPv6+IPv4aaS?

> Especially as we have examples of what that type of effort might look like.

Again, the issue isn’t fixing a bit of code in a known source tree. It is getting all the instantiations of that bit of code implemented, tested, and deployed across all the myriad supported and unsupported systems (both operational and management) that support 5 billion+ Internet users globally in a timeframe and for a cost that makes business sense.

Regards,
-drc

Much of India operates this way today.

Owen


> On Nov 21, 2022, at 15:06, Rubens Kuhl <rubensk@gmail.com> wrote:
>
> (forwarded to break thread since this is a different topic)
> What's the group's current thought on emergence or prevalence of
> IPv6-only hosts ? Will they exist soon, in some time or in a very long
> time?
>
>
> Rubens
>
>
> ---------- Forwarded message ---------
> From: <bzs@theworld.com>
> Date: Mon, Nov 21, 2022 at 8:02 PM
> Subject: Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC
> To: NANOG <nanog@nanog.org>
>
>
>
> My suggestion is ignore anyone who says it would be too difficult to
> get people to adopt a change or take too long. Someone always says
> that, a reasonable riposte is "what would be a reasonable number of
> people / years?" Surely they must have some numbers in mind, no?
>
> We've been trying to get people to adopt IPv6 widely for 30 years with
> very limited success so perhaps that's a pretty time to shoot for, for
> example. Anything less than 30 years would be an improvement.
>
> I suppose some might leap on that as evidence of the above cautions
> but it's really not. It's just being argumentative. It feels like a
> reasonable argument pattern but it's not because it ignores why that
> previous attempt mostly failed and tries to equate them (we failed for
> 30 years so therefore you will fail for 30 years???)
>
> That said, what's needed is a working demo preferably within both a
> simulation environment and live because the devil is always in the
> details and the only way to vet that is by testing working code.
>
> A mere proposal is of some value, one can glance at it and try to spot
> any fatal flaws for example. But it's only a tiny step along the path.
>
> However, that it might take a while to become adopted is, to me, like
> saying forget trying to mitigate climate change, it'll take decades
> and require hundreds of govts, thousands of industries, and billions
> of people to change their behavior which is all true but hardly an
> argument as to why not to try.
>
> Aside: A pretty good rule of thumb with replacement technologies is
> that something has to be 10x better than what it replaces to get wide
> adoption. Ok maybe not 10, that's a figure of speech, but a lot, and
> certainly not introduce impediments to its own adoption and use.
>
> On November 21, 2022 at 12:00 beecher@beecher.cc (Tom Beecher) wrote:
>> As stated in Subsection 4.A. of the "Revamp The
>> Internet" whitepaper, all need be done is "Simply disable the existing
>> software codes that have been disabling the use of the 240/4 netblock."
>>
>>
>> Some friendly feedback. The phrase "all that needs to be done" , is
>> exceptionally reductive, and in the case of internet standards, also always
>> going to end up being wrong.
>>
>> On Mon, Nov 21, 2022 at 11:19 AM Abraham Y. Chen <aychen@avinta.com> wrote:
>>
>> Dear Mark:
>>
>> 0) Thanks for the clarification. I understand. A short message through
>> the cyberspace, especially between parties who have never met can be
>> easily skewed. I am glad that I asked you, instead of taking it
>> negatively without raising my hand.
>>
>> 1) "...I'd, rather, expend those resources on IPv6, 464XLAT, e.t.c. ...
>> ": Since EzIP is still being further refined, it may not be clear in our
>> documentation about how much work is required to get the IPv4 out of the
>> current depletion mode. As stated in Subsection 4.A. of the "Revamp The
>> Internet" whitepaper, all need be done is "Simply disable the existing
>> software codes that have been disabling the use of the 240/4 netblock."
>> In fact, we have found examples that this means commenting out one line
>> code that searches for then discards packets with 240/4 addressing. It
>> seems to me that there is no easier task than this.
>>
>> https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
>>
>> Regards,
>>
>> Abe (2022-11-21 11:18 EST)
>>
>>
>>
>> On 2022-11-20 23:56, Mark Tinka wrote:
>>>
>>>
>>> On 11/20/22 19:02, Abraham Y. Chen wrote:
>>>
>>>> Dear Mark:
>>>>
>>>> 0) I am surprised at your apparently sarcastic opinion.
>>>>
>>>> 1) The EzIP proposal as referenced by my last MSG is the result of
>>>> an in-depth system engineering effort. Since the resultant schemes do
>>>> not rely on any protocol development, IETF does not need be involved.
>>>> Especially, its first step of disabling one line of existing
>>>> networking program code empowers any party to begin deploying EzIP
>>>> stealthily for mitigating the IPv4 address pool depletion issues.
>>>> Note that EzIP is a generic solution applicable to everyone, not
>>>> limited to Africa.
>>>>
>>>> 2) Of course, constructive criticism is always appreciated. However,
>>>> unspecific comments that confuse and distract the readers only
>>>> provide dis-service to those disadvantaged population who are
>>>> enduring the handicaps of being the late-comers to the Internet.
>>>
>>> My comment was not directed at you. Sorry.
>>>
>>> I have nothing against the EzIP proposal. It just does not add any
>>> real value in solving the IPv4 depletion problem for the amount of
>>> effort required to implement it, in my view. I'd, rather, expend those
>>> resources on IPv6, 464XLAT, e.t.c.
>>>
>>> Mark.
>>>
>>
>>
>> --
>> This email has been checked for viruses by Avast antivirus software.
>> www.avast.com
>>
>
> --
> -Barry Shein
>
> Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD
> The World: Since 1989 | A Public Information Utility | *oo*

David Conrad wrote:
> Barry,
>
> On Nov 21, 2022, at 3:01 PM, bzs@theworld.com wrote:
>> We've been trying to get people to adopt IPv6 widely for 30 years
>> with very limited success
>
> According to https://www.google.com/intl/en/ipv6/statistics.html, it
> looks like we’ve gone from ~0% to ~40% in 12 years.
> https://stats.labs.apnic.net/ipv6 has it around 30%. Given an Internet
> population of about 5B, this can (simplistically and wrongly) argued
> to mean 1.5-2B people are using IPv6. For a transition to a technology
> that the vast majority of people who pay the bills will neither notice
> nor care about, and for which the business case typically needs
> projection way past the normal quarterly focus of shareholders, that
> seems pretty successful to me.
>
> But back to the latest proposal to rearrange deck chairs on the IPv4
> Titanic, the fundamental and obvious flaw is the assertion of
> "commenting out one line code”. There isn’t “one line of code”. There
> are literally _billions_ of instances of “one line of code”, the vast
> majority of which need to be changed/deployed/tested with absolutely
> no business case to do so that isn’t better met with deploying
> IPv6+IPv4aaS. I believe this has been pointed out numerous times, but
> it falls on deaf ears, so the discussion gets a bit tedious.
>
> Regards,
> -drc
>
Re-replying. Changing the standards is not what is intended to drive
vendor changes. Userbase requests and projected needs do that.

The standards are not responsible for the business case. However, they
should not unreasonably impede it.

Joe

David Conrad wrote:
> How trivial would the change be in a product by a company that no
> longer exists or a product line that is no longer supported? Will
> Microsoft update all previous versions of Windows? Will the myriad of
> deployed embedded systems sitting forgotten in closets be updated? And
> if you’re going to the trouble to update those systems (in most cases,
> by simply throwing them away), why not upgrade to IPv6+IPv4aaS?
>> Especially as we have examples of what that type of effort might look like.
> Again, the issue isn’t fixing a bit of code in a known source tree. It is getting all the instantiations of that bit of code implemented, tested, and deployed across all the myriad supported and unsupported systems (both operational and management) that support 5 billion+ Internet users globally in a timeframe and for a cost that makes business sense.
>
> Regards,
> -drc


Lets agree to stop conflating the issue of products under active support
and refresh cycles with the issue of those that are obsolete and only
subject to attrition.

Two different problems areas entirely.

The former, yes it is trivial. An update in standards could yield rapid
results here.

The latter takes time. An update in standards could take years to bear
enough fruit. All the more reason it should have happened then, all the
more reason to let it happen now.

Joe

Jay Hennigan wrote:
> On 11/21/22 16:30, Joe Maimon wrote:
>

>
> IMNSHO, if such a proposal were to gain traction, by the time that
> gear capable of using 240/4 as unicast were to be widely deployed,
> IPv6-capable gear would be much more widely deployed.

Considering that is already the situation, whats your point?

>
> META: Can whoever is doing so please stop creating new time-stamped
> subject lines for the same topic? It makes things hard to follow.
>

> On Nov 22, 2022, at 2:09 AM, Joe Maimon <jmaimon@jmaimon.com> wrote:
>
> David Conrad wrote:
>>
>> Again, the issue isn’t fixing a bit of code in a known source tree. It is getting all the instantiations of that bit of code implemented, tested, and deployed across all the myriad supported and unsupported systems (both operational and management) that support 5 billion+ Internet users globally in a timeframe and for a cost that makes business sense.
>
> Lets agree to stop conflating the issue of products under active support and refresh cycles with the issue of those that are obsolete and only subject to attrition.

Joe -

<chuckle> Ah, if it were only that simple… service providers have a _huge_ amount of installed infrastructure, and it’s in various phases of support (i.e. can get new updates, or critical fixes only, or is self-maintained, etc.)

Vendors supporting 240/4 as general purpose space does not automatically equate to Internet infrastructure supporting 240/2, as it requires service providers to make conscious decisions to do maintenance on gear that may (in many cases) have been effectively frozen in terms of software updates that aren’t critical… customer installs and capacity upgrades almost always get first cut at resources, and so no, it is not just a case of updating the standards - even presuming that the provider has the equipment under software updates, availability of such doesn’t mean it will be installed. You are talking about a long period between standards update and actual deployment, and that’s presuming actively supported gear.

> The former, yes it is trivial. An update in standards could yield rapid results here.

Absolutely – but only if you are talking about an equally trivial network infrastructure or pure lab environment – otherwise, the standards change is the very _beginning_ of a lengthy process for network operators of any size.

You once again have avoided the question of interoperability during the transition period.

Interoperability isn’t insurmountable, but does take some investment of effort. One can imagine any number of techniques (e.g. flag day after which “production devices” on the Internet must support 240/4, or DNS resolver hacks that fail to return “A” records with 240/4 addresses unless a flag is set that says “we’re in the 240/4 routable Internet” [ick], etc., etc.) It doesn’t seem particularly hard to come up with some approaches to solve the interoperability problem, but completely ignoring it is not an answer (and makes it rather difficult to take your proposal seriously...)

Thanks,
/John

p.s. disclaimer: my views alone (little chance any one else would risk blame for them!)

> On Nov 22, 2022, at 9:09 AM, John Curran <jcurran@istaff.org> wrote:
> ...
> Interoperability isn’t insurmountable, but does take some investment of effort. One can imagine any number of techniques (e.g. flag day after which “production devices” on the Internet must support 240/4, or DNS resolver hacks that fail to return “A” records with 240/4 addresses unless a flag is set that says “we’re in the 240/4 routable Internet” [ick], etc., etc.) It doesn’t seem particularly hard to come up with some approaches to solve the interoperability problem, but completely ignoring it is not an answer (and makes it rather difficult to take your proposal seriously…)

Joe -

By the way, you shouldn’t feel particularly bad about skipping out on the interoperability requirement – anything involving interworking with the installed Internet is hard, and this is the same lesson that the IPv6 folks found out the hard way… I will confess that I was a member of the IETF's IPng Directorate and thus inherently complicit in that particular fiasco –

With IPv6, the first answer to interoperability was “let’s do tunnels between IPng islands”; i.e. helpful for lab environments but useless otherwise. We then declared that transition was a problem “to be solved later” but that shouldn’t get in the way of the declaration of IPng as the new IPv6. Finally, after failing to solve the problem, we reverted to “ships in the night”; i.e. IPv4 and IPv6 running in parallel on the same infrastructure – it works, but defeats the entire idea of IPv6 as a functional substitute for IPv4 for connecting new customers and infrastructure to the existing IPv4-based Internet (Luckily, the service provider industry that was growing most rapidly realized that they really needed IPv6, and they really needed transition solutions that allowed IPv6 to interoperate for IPv4 for new connections, and so we eventually saw real solutions such as 464xlat, ds-lite, etc.)

Maintaining interoperability with the existing base is hard - far harder than just “updating the standard” - but is absolutely essential if you want viable reuse of 240/4. Of course, it does raise the question of whether the total effort will be worth the purported gain, but that really can’t be assessed until there's some specification of the proposed solution for interoperability with the existing deployed devices that don’t know about the 240/4 change.

Thanks,
/John

p.s. Disclaimer(s): my views alone. Warning: may cause dizziness, headaches, or nausea.

John Curran wrote:
>
>> On Nov 22, 2022, at 9:09 AM, John Curran <jcurran@istaff.org> wrote:
>> ...
>> Interoperability isn’t insurmountable, but does take some investment
>> of effort. One can imagine any number of techniques (e.g. flag day
>> after which “production devices” on the Internet must support 240/4,
>> or DNS resolver hacks that fail to return “A” records with 240/4
>> addresses unless a flag is set that says “we’re in the 240/4 routable
>> Internet” [ick], etc., etc.) It doesn’t seem particularly hard to
>> come up with some approaches to solve the interoperability problem,
>> but completely ignoring it is not an answer (and makes it rather
>> difficult to take your proposal seriously…)
>
> Joe -
>
> By the way, you shouldn’t feel particularly bad about skipping out on
> the interoperability requirement – anything involving interworking
> with the installed Internet is hard, and this is the same lesson that
> the IPv6 folks found out the hard way… I will confess that I was a
> member of the IETF's IPng Directorate and thus inherently complicit in
> that particular fiasco –

John,

Flags days on the internet of today have proven to be of limited value.

Suppose complete interoperability is never actually solved. Why does
240/4 utilitarian value have to be binary? I think we should be trying
to discover these things instead of using them to handwave away any attempt.

The part I feel bad about is that I am actually un-involved in much of
anyway with the 240/4 or other ideas, my sole input has been to attempt
to encourage serious consideration and to rebut naysaying.

Yes, a standards update is only the beginning of a real effort, although
plenty has changed even without that.

Yes, there may and likely will be a large extent of interoperability and
usability challenges for quite some time, perhaps even enough time that
the issue becomes moot.

Yes, it may be insurmountable.

Yes, it may render 240/4 unusable and undesirable to the extent that it
has little contributory effect on IPv4.

However it may not and discouraging serious consideration is actually a
contributing factor preventing any such potential.

And to the extent that you and others have discussed and aired various
points of views and insights, I think I have had some success with my
efforts thus far.


>
> With IPv6, the first answer to interoperability was “let’s do tunnels
> between IPng islands”; i.e. helpful for lab environments but useless
> otherwise. We then declared that transition was a problem “to be
> solved later” but that shouldn’t get in the way of the declaration of
> IPng as the new IPv6. Finally, after failing to solve the problem, we
> reverted to “ships in the night”; i.e. IPv4 and IPv6 running in
> parallel on the same infrastructure – it works, but defeats the entire
> idea of IPv6 as a functional substitute for IPv4 for connecting new
> customers and infrastructure to the existing IPv4-based Internet
> (Luckily, the service provider industry that was growing most rapidly
> realized that they really needed IPv6, and they really needed
> transition solutions that allowed IPv6 to interoperate for IPv4 for
> new connections, and so we eventually saw real solutions such
> as 464xlat, ds-lite, etc.)

I feel there is some value for the internet record to contain as much as
possible real debate and consideration instead of group think,
short-sightedness, idealouges and top down approaches which may not look
pretty in hindsight. Such as contained in the much larger details of
your brief recap and that you and others have expanded upon here and
elsewhere in the past.

In other words, a loyal opposition.

>
> Maintaining interoperability with the existing base is hard - far
> harder than just “updating the standard” -
Without a standard update, there is a bit of a chicken and egg problem
with pursuing interoperability with any seriousness.

I think 100.64/10 was a missed opportunity to incentivize the industry
to pursue interoperability.

> but is absolutely essential if you want viable reuse of 240/4. Of
> course, it does raise the question of whether the total effort will be
> worth the purported gain, but that really can’t be assessed until
> there's some specification of the proposed solution for
> interoperability with the existing deployed devices that don’t know
> about the 240/4 change.
>
> Thanks,
> /John
>
> p.s. Disclaimer(s): my views alone. Warning: may cause dizziness,
> headaches, or nausea.
>
Best,

Joe

> On Nov 22, 2022, at 1:19 PM, Joe Maimon <jmaimon@jmaimon.com> wrote:
>
> John Curran wrote:
>>
>> By the way, you shouldn’t feel particularly bad about skipping out on the interoperability requirement – anything involving interworking with the installed Internet is hard, and this is the same lesson that the IPv6 folks found out the hard way… I will confess that I was a member of the IETF's IPng Directorate and thus inherently complicit in that particular fiasco –
>
> John,
>
> Flags days on the internet of today have proven to be of limited value.

Joe -

I am not suggesting a flag day for 240/4 (or any other particular approach) - merely noting that anyone who wishes to promote 240/4 has a wide range of options to consider when they decide to get serious and actually consider interoperability approaches.

> The part I feel bad about is that I am actually un-involved in much of anyway with the 240/4 or other ideas, my sole input has been to attempt to encourage serious consideration and to rebut naysaying.

Serious consideration requires a serious proposal - I don’t think we’ve seen one yet.

> Yes, a standards update is only the beginning of a real effort, although plenty has changed even without that.
>
> Yes, there may and likely will be a large extent of interoperability and usability challenges for quite some time, perhaps even enough time that the issue becomes moot.
>
> Yes, it may be insurmountable.
>
> Yes, it may render 240/4 unusable and undesirable to the extent that it has little contributory effect on IPv4.
>
> However it may not and discouraging serious consideration is actually a contributing factor preventing any such potential.

I certainly am not discouraging serious consideration… simply awaiting something sufficient complete to discuss.

(Saying that “this proposal likely will create interoperability and usability challenges – but let’s all talk about the merits of it while ignoring that detail for now” doesn’t cut it – I’ve seen that approach once before and hasn’t turned out particularly well for anyone involved…)

Best wishes,
/John

p.s. Disclaimer(s) - my views alone - please remember to have your arms and legs fully inside before the ride starts...

>
> Serious consideration requires a serious proposal - I don’t think we’ve
> seen one yet.
>

I would posit that draft-schoen-intarea-unicast-240-03 (
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/ ) should
be considered a serious proposal, in so much as what is proposing is the
most direct:

- Redesignate 240/4 from RESERVED - Future Use to be available for
allocation as 'standard' IPv4 addresses.

I personally disagree with their position, as does the IETF, so it doesn't
appear there will be any more movement on it, but I do believe that the
idea itself was serious.

Of course, I also agree with you that there have been plenty of un-serious
proposals floated too which don't really require discussion. :)

On Tue, Nov 22, 2022 at 1:48 PM John Curran <jcurran@istaff.org> wrote:

>
>
> On Nov 22, 2022, at 1:19 PM, Joe Maimon <jmaimon@jmaimon.com> wrote:
>
> John Curran wrote:
>
>
> By the way, you shouldn’t feel particularly bad about skipping out on the
> interoperability requirement – anything involving interworking with the
> installed Internet is hard, and this is the same lesson that the IPv6 folks
> found out the hard way… I will confess that I was a member of the IETF's
> IPng Directorate and thus inherently complicit in that particular fiasco –
>
>
> John,
>
> Flags days on the internet of today have proven to be of limited value.
>
>
> Joe -
>
> I am not suggesting a flag day for 240/4 (or any other particular
> approach) - merely noting that anyone who wishes to promote 240/4 has a
> wide range of options to consider when they decide to get serious and
> actually consider interoperability approaches.
>
> The part I feel bad about is that I am actually un-involved in much of
> anyway with the 240/4 or other ideas, my sole input has been to attempt to
> encourage serious consideration and to rebut naysaying.
>
>
> Serious consideration requires a serious proposal - I don’t think we’ve
> seen one yet.
>
> Yes, a standards update is only the beginning of a real effort, although
> plenty has changed even without that.
>
> Yes, there may and likely will be a large extent of interoperability and
> usability challenges for quite some time, perhaps even enough time that the
> issue becomes moot.
>
> Yes, it may be insurmountable.
>
> Yes, it may render 240/4 unusable and undesirable to the extent that it
> has little contributory effect on IPv4.
>
> However it may not and discouraging serious consideration is actually a
> contributing factor preventing any such potential.
>
>
> I certainly am not discouraging serious consideration… simply awaiting
> something sufficient complete to discuss.
>
> (Saying that “this proposal likely will create interoperability and
> usability challenges – but let’s all talk about the merits of it while
> ignoring that detail for now” doesn’t cut it – I’ve seen that approach once
> before and hasn’t turned out particularly well for anyone involved…)
>
> Best wishes,
> /John
>
> p.s. Disclaimer(s) - my views alone - please remember to have your arms
> and legs fully inside before the ride starts...
>
>
>

> On Nov 22, 2022, at 2:13 PM, Tom Beecher <beecher@beecher.cc> wrote:
>
>> Serious consideration requires a serious proposal - I don’t think we’ve seen one yet.
>
> I would posit that draft-schoen-intarea-unicast-240-03 ( https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/ ) should be considered a serious proposal, in so much as what is proposing is the most direct:
>
> - Redesignate 240/4 from RESERVED - Future Use to be available for allocation as 'standard' IPv4 addresses.
>
> I personally disagree with their position, as does the IETF, so it doesn't appear there will be any more movement on it, but I do believe that the idea itself was serious.

Tom -

Well, at least it is a readable and clear proposal, but again it lacks any meaningful treatment of interoperability – instead comparing the de-reservation and potential for future use of 240/4 with the various de-bogon efforts that were predominantly efforts to get long-time _already valid_ address space to be properly treated in the Internet –

Such a host might be inaccessible by some devices either on its local
network segment or elsewhere on the Internet, due to a combination of
host software limitations or reachability limitations in the network.
IPv4 unicast interoperability with 240/4 can be expected to improve
over time following the publication of this document. Before or
after allocations are eventually made within this range,
"debogonization" efforts for allocated ranges can improve
reachability to the whole address block. Similar efforts have
already been done by Cloudflare on 1.1.1.1 [Cloudflare], and by RIPE
Labs on 1/8 [RIPElabs18], 2a10::/12 [RIPElabs2a1012], and 128.0/16
[RIPElabs128016]. The Internet community can use network probing
with any of several measurement-oriented platforms to investigate how
usable these addresses are at any particular point in time, as well
as to localize medium-to-large-scale routing problems. (Examples are
described in [Huston], [NLNOGRing], and [Atlas].) Any network
operator to whom such addresses are made available by a future
allocation will have to examine the situation in detail to determine
how well its interoperability requirements will be met.

I.w. the suggestion that the utilization of 240/4 space will solely be an issue for the "operator to whom such addresses are made available “ to examine (with respect to their requirements) really completely ignores the fact that such address space utilized in the production Internet will experience unpredictable intermittent communication failures for years (if not decades) to come, and hence it an issue of concern for the entire operations community, not just those who may receive such allocations. Again, the IETF's host and router requirements documents has specified discard of these packets since the 90’s, so there needs to be a clear model for transition (rather than vague statements left to the reader)l that covers how network operators at both ends will know of the failure (and workarounds) when the use of these addresses results in failed communication. Absent such, I’m not sure why anyone should give consideration to this Internet draft– it can’t be safely deployed in the actual real-world Internet, making it more of a paper chimera than a serious proposal.

Thanks,
/John

p.s. Disclaimer(s): my views alone - any hazards seen in them may be much closer than they appear…

Dear Joe:

0) Allow me to share my understanding of the two topics that you brought up.

1) "... https://www.google.com/intl/en/ipv6/statistics.html, it looks
like we’ve gone from ~0% to ~40% in 12 years.... ":  Your numbers may be
deceiving.

  A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and
ratified on 2017-07-14. So, the IPv6 efforts have been quite a few years
more than your impression. That is, the IPv6 has been around over
quarter of a century.

  B. If you read closely, the statement  "The graph shows the
percentage of users that access Google over IPv6." above the graph
actually means "equipment readiness". That is, how many Google users
have IPv6 capable devices. This is similar as the APNIC statistics whose
title makes this clearer. However, having the capability does not mean
the owners are actually using it. Also, this is not general data, but
within the Google environment. Since Google is one of the stronger
promoters of the IPv6, this graph would be at best the cap of such data.

  C. The more meaningful data would be the global IPv6 traffic
statistics. Interestingly, they do not exist upon our extensive search.
(If you know of any, I would appreciate to receive a lead to such.) The
closest that we could find is % of IPv6 in AMS-IX traffic statistics
(see URL below). It is currently at about 5-6% and has been tapering off
to a growth of less than 0.1% per month recently, after a ramp-up period
in the past. (Similar saturation behavior can also be found in the above
Google graph.)

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

  D.  One interesting parameter behind the last one is that as an
Inter-eXchange operator, AMS-IX should see very similar percentage
traffic mix between IPv6 and IPv4. The low numbers from AMS-IX does not
support this viewpoint for matching with your observation. In addition,
traffic through IX is the overflow among backbone routers. A couple
years ago, there was a report that peering arrangements among backbone
routers for IPv6 were much less matured then IPv4, which meant that
AMS-IX should be getting more IPv6 traffic than the mix in the Internet
core. Interpreted in reverse, % of IPv6 in overall Internet traffic
should be less than what AMS-IX handles.

  E. This is a quite convoluted topic that we only scratched the
surface. They should not occupy the attention of colleagues on this
list. However, I am willing to provide more information to you off-line,
if you care for further discussion.

2)  "... https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/
...":  My basic training was in communication equipment hardware design.
I knew little about software beyond what I needed for my primary
assignment. Your example, however, reminds me of a programing course
that I took utilizing APL (A Programming Language) for circuit analysis,
optimization and synthesis. It was such a cryptic symbolic language that
classmates (mostly majored in EE hardware) were murmuring to express
their displeasure. One day we got a homework assignment to do something
relatively simple. Everyone struggled to write the code to do the job.
Although most of us did get working codes, they were pages long. The
shortest one was one full page. Upon reviewed all homework, the
professor smiled at us and told us to look for the solution section at
the end of the text book. It turned out to be the answer for a problem
in the next chapter to be covered. The code was only three lines long!
Although it did not have the codes for debugging purposes, it covered
all error messages expected. It was such a shocker that everyone quieted
down to focus on the subject for the rest of the semester. During my
first employment, we had the need to optimize circuit designs. Since I
was the only staff who knew about it, I ended up being the coordinator
between several hardware designers and the supporting programmer. From
that teaching, I am always looking for the most concise solution to an
issue, not being distracted or discouraged by the manifestation on the
surface.

https://en.wikipedia.org/wiki/APL_(programming_language)

3) Fast forward half a century, I am hoping that my "one-line code"
serves the purpose of "there exists" an example in proofing a
mathematical theorem for  inspiring software colleagues to review the
network codes in front of them for improvement, instead of presenting
such as a valid hurdle to progress.


Regards,


Abe (2022-11-24 03:53 EST)





On 2022-11-21 19:30, Joe Maimon wrote:
>
>
> David Conrad wrote:
>> Barry,
>>
>> On Nov 21, 2022, at 3:01 PM, bzs@theworld.com wrote:
>>> We've been trying to get people to adopt IPv6 widely for 30 years
>>> with very limited success
>>
>> According to https://www.google.com/intl/en/ipv6/statistics.html, it
>> looks like we’ve gone from ~0% to ~40% in 12 years.
>> https://stats.labs.apnic.net/ipv6 has it around 30%. Given an
>> Internet population of about 5B, this can (simplistically and
>> wrongly) argued to mean 1.5-2B people are using IPv6. For a
>> transition to a technology that the vast majority of people who pay
>> the bills will neither notice nor care about, and for which the
>> business case typically needs projection way past the normal
>> quarterly focus of shareholders, that seems pretty successful to me.
>>
>> But back to the latest proposal to rearrange deck chairs on the IPv4
>> Titanic, the fundamental and obvious flaw is the assertion of
>> "commenting out one line code”. There isn’t “one line of code”. There
>> are literally _billions_ of instances of “one line of code”, the vast
>> majority of which need to be changed/deployed/tested with absolutely
>> no business case to do so that isn’t better met with deploying
>> IPv6+IPv4aaS. I believe this has been pointed out numerous times, but
>> it falls on deaf ears, so the discussion gets a bit tedious.
>>
>> Regards,
>> -drc
>>
> Had the titanic stayed afloat some hours more, many more would have
> survived and been rescued when assistance eventually arrived. So that
> makes this a debate over whether this is deck chair re-arrangement or
> something more meaningful.
>
> As I and others have pointed out, it depends on how it is used. And
> perhaps the attempt should be made regardless of knowing in advance
> which it will be.
>
> You assertion needs some back of the envelope numbers, which once
> provided, I suspect will render your estimate grossly incorrect.
>
> You can hardly attempt to convince anybody that 240/4 as unicast would
> not be the more trivial change made in any of these products natural
> life cycle points.
>
> Especially as we have examples of what that type of effort might look
> like. IGTFY and here
>
> https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/
>
> The burdensome position is ridiculous even more so when stated with a
> straight face.
>
> Joe
>
>
>


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

Hi Abraham,
Let me clarify a little bit on statistics - I did an investigation last year.

Google and APNIC report very similar numbers. APNIC permits drilling down deep details. Then it is possible to understand that they see only 100M Chinese. China itself reports 0.5B IPv6 users. APNIC gives Internet population by country - it permits to construct proportion.
Hence, it is possible to conclude that we need to add 8% to Google (or APNIC) to get 48% of IPv6 preferred users worldwide. We would likely cross 50% this year.

I spent a decent time finding traffic statics. I have found one DPI vendor who has it. Unfortunately, they sell it for money.
ARCEP has got it for France and published it in their "Barometer". Almost 70% of application requests are possible to serve from IPv6.
Hence, 70%*48%=33.6%. We could claim that 1/3 of the traffic is IPv6 worldwide because France is typical.
My boss told me "No-No" for this logic. His example is China where we had reliable data for only 20% of application requests served on IPv6 (China has a very low IPv6 adoption by OTTs).
My response was: But India has a much better IPv6 adoption on the web server side. China and a few other countries are not representative. The majority are like France.
Unfortunately, we do not have per-country IPv6 adoption on the web server side.
OK. We could estimate 60% of the application readiness as a minimum. Then 60%*48%=28.8%.
Hence, we could claim that at least 1/4 of the worldwide traffic is IPv6.

IX data shows much low IPv6 adoption because the biggest OTTs have many caches installed directly on Carriers' sites.

Sorry for not the exact science. But it is all that I have. It is better than nothing.

PS: 60% of requests served by web servers does not mean "60% of servers". For servers themselves we have statistics - it is just 20%+. But it is for the biggest web resources.

Eduard
-----Original Message-----
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org] On Behalf Of Abraham Y. Chen
Sent: Thursday, November 24, 2022 11:53 AM
To: Joe Maimon <jmaimon@jmaimon.com>
Cc: NANOG <nanog@nanog.org>; bzs@theworld.com
Subject: Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC

Dear Joe:

0) Allow me to share my understanding of the two topics that you brought up.

1) "... https://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone from ~0% to ~40% in 12 years.... ":  Your numbers may be deceiving.

  A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and ratified on 2017-07-14. So, the IPv6 efforts have been quite a few years more than your impression. That is, the IPv6 has been around over quarter of a century.

  B. If you read closely, the statement  "The graph shows the percentage of users that access Google over IPv6." above the graph actually means "equipment readiness". That is, how many Google users have IPv6 capable devices. This is similar as the APNIC statistics whose title makes this clearer. However, having the capability does not mean the owners are actually using it. Also, this is not general data, but within the Google environment. Since Google is one of the stronger promoters of the IPv6, this graph would be at best the cap of such data.

  C. The more meaningful data would be the global IPv6 traffic statistics. Interestingly, they do not exist upon our extensive search.
(If you know of any, I would appreciate to receive a lead to such.) The closest that we could find is % of IPv6 in AMS-IX traffic statistics (see URL below). It is currently at about 5-6% and has been tapering off to a growth of less than 0.1% per month recently, after a ramp-up period in the past. (Similar saturation behavior can also be found in the above Google graph.)

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

  D.  One interesting parameter behind the last one is that as an Inter-eXchange operator, AMS-IX should see very similar percentage traffic mix between IPv6 and IPv4. The low numbers from AMS-IX does not support this viewpoint for matching with your observation. In addition, traffic through IX is the overflow among backbone routers. A couple years ago, there was a report that peering arrangements among backbone routers for IPv6 were much less matured then IPv4, which meant that AMS-IX should be getting more IPv6 traffic than the mix in the Internet core. Interpreted in reverse, % of IPv6 in overall Internet traffic should be less than what AMS-IX handles.

  E. This is a quite convoluted topic that we only scratched the surface. They should not occupy the attention of colleagues on this list. However, I am willing to provide more information to you off-line, if you care for further discussion.

2)  "... https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/
...":  My basic training was in communication equipment hardware design.
I knew little about software beyond what I needed for my primary assignment. Your example, however, reminds me of a programing course that I took utilizing APL (A Programming Language) for circuit analysis, optimization and synthesis. It was such a cryptic symbolic language that classmates (mostly majored in EE hardware) were murmuring to express their displeasure. One day we got a homework assignment to do something relatively simple. Everyone struggled to write the code to do the job.
Although most of us did get working codes, they were pages long. The shortest one was one full page. Upon reviewed all homework, the professor smiled at us and told us to look for the solution section at the end of the text book. It turned out to be the answer for a problem in the next chapter to be covered. The code was only three lines long!
Although it did not have the codes for debugging purposes, it covered all error messages expected. It was such a shocker that everyone quieted down to focus on the subject for the rest of the semester. During my first employment, we had the need to optimize circuit designs. Since I was the only staff who knew about it, I ended up being the coordinator between several hardware designers and the supporting programmer. From that teaching, I am always looking for the most concise solution to an issue, not being distracted or discouraged by the manifestation on the surface.

https://en.wikipedia.org/wiki/APL_(programming_language)

3) Fast forward half a century, I am hoping that my "one-line code"
serves the purpose of "there exists" an example in proofing a mathematical theorem for  inspiring software colleagues to review the network codes in front of them for improvement, instead of presenting such as a valid hurdle to progress.


Regards,


Abe (2022-11-24 03:53 EST)





On 2022-11-21 19:30, Joe Maimon wrote:
>
>
> David Conrad wrote:
>> Barry,
>>
>> On Nov 21, 2022, at 3:01 PM, bzs@theworld.com wrote:
>>> We've been trying to get people to adopt IPv6 widely for 30 years
>>> with very limited success
>>
>> According to https://www.google.com/intl/en/ipv6/statistics.html, it
>> looks like we’ve gone from ~0% to ~40% in 12 years.
>> https://stats.labs.apnic.net/ipv6 has it around 30%. Given an
>> Internet population of about 5B, this can (simplistically and
>> wrongly) argued to mean 1.5-2B people are using IPv6. For a
>> transition to a technology that the vast majority of people who pay
>> the bills will neither notice nor care about, and for which the
>> business case typically needs projection way past the normal
>> quarterly focus of shareholders, that seems pretty successful to me.
>>
>> But back to the latest proposal to rearrange deck chairs on the IPv4
>> Titanic, the fundamental and obvious flaw is the assertion of
>> "commenting out one line code”. There isn’t “one line of code”. There
>> are literally _billions_ of instances of “one line of code”, the vast
>> majority of which need to be changed/deployed/tested with absolutely
>> no business case to do so that isn’t better met with deploying
>> IPv6+IPv4aaS. I believe this has been pointed out numerous times, but
>> it falls on deaf ears, so the discussion gets a bit tedious.
>>
>> Regards,
>> -drc
>>
> Had the titanic stayed afloat some hours more, many more would have
> survived and been rescued when assistance eventually arrived. So that
> makes this a debate over whether this is deck chair re-arrangement or
> something more meaningful.
>
> As I and others have pointed out, it depends on how it is used. And
> perhaps the attempt should be made regardless of knowing in advance
> which it will be.
>
> You assertion needs some back of the envelope numbers, which once
> provided, I suspect will render your estimate grossly incorrect.
>
> You can hardly attempt to convince anybody that 240/4 as unicast would
> not be the more trivial change made in any of these products natural
> life cycle points.
>
> Especially as we have examples of what that type of effort might look
> like. IGTFY and here
>
> https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/
>
> The burdensome position is ridiculous even more so when stated with a
> straight face.
>
> Joe
>
>
>


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

Hello Abraham!

I believe your e-mail client (MUA) is splitting every message on a new
thread.
I'm not sure if it is happening with everyone, but using Gmail as MUA, it
isn't aggregating the mails on the same thread.

Cloud you please check the confs of your tool to avoid it?

Thanks in advance.

Em qui., 24 de nov. de 2022 às 05:56, Abraham Y. Chen <aychen@avinta.com>
escreveu:

> Dear Joe:
>
> 0) Allow me to share my understanding of the two topics that you brought
> up.
>
> 1) "... https://www.google.com/intl/en/ipv6/statistics.html, it looks
> like we’ve gone from ~0% to ~40% in 12 years.... ": Your numbers may be
> deceiving.
>
> A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and
> ratified on 2017-07-14. So, the IPv6 efforts have been quite a few years
> more than your impression. That is, the IPv6 has been around over
> quarter of a century.
>
> B. If you read closely, the statement "The graph shows the
> percentage of users that access Google over IPv6." above the graph
> actually means "equipment readiness". That is, how many Google users
> have IPv6 capable devices. This is similar as the APNIC statistics whose
> title makes this clearer. However, having the capability does not mean
> the owners are actually using it. Also, this is not general data, but
> within the Google environment. Since Google is one of the stronger
> promoters of the IPv6, this graph would be at best the cap of such data.
>
> C. The more meaningful data would be the global IPv6 traffic
> statistics. Interestingly, they do not exist upon our extensive search.
> (If you know of any, I would appreciate to receive a lead to such.) The
> closest that we could find is % of IPv6 in AMS-IX traffic statistics
> (see URL below). It is currently at about 5-6% and has been tapering off
> to a growth of less than 0.1% per month recently, after a ramp-up period
> in the past. (Similar saturation behavior can also be found in the above
> Google graph.)
>
> https://stats.ams-ix.net/sflow/ether_type.html
>
> D. One interesting parameter behind the last one is that as an
> Inter-eXchange operator, AMS-IX should see very similar percentage
> traffic mix between IPv6 and IPv4. The low numbers from AMS-IX does not
> support this viewpoint for matching with your observation. In addition,
> traffic through IX is the overflow among backbone routers. A couple
> years ago, there was a report that peering arrangements among backbone
> routers for IPv6 were much less matured then IPv4, which meant that
> AMS-IX should be getting more IPv6 traffic than the mix in the Internet
> core. Interpreted in reverse, % of IPv6 in overall Internet traffic
> should be less than what AMS-IX handles.
>
> E. This is a quite convoluted topic that we only scratched the
> surface. They should not occupy the attention of colleagues on this
> list. However, I am willing to provide more information to you off-line,
> if you care for further discussion.
>
> 2) "... https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/
> ...": My basic training was in communication equipment hardware design.
> I knew little about software beyond what I needed for my primary
> assignment. Your example, however, reminds me of a programing course
> that I took utilizing APL (A Programming Language) for circuit analysis,
> optimization and synthesis. It was such a cryptic symbolic language that
> classmates (mostly majored in EE hardware) were murmuring to express
> their displeasure. One day we got a homework assignment to do something
> relatively simple. Everyone struggled to write the code to do the job.
> Although most of us did get working codes, they were pages long. The
> shortest one was one full page. Upon reviewed all homework, the
> professor smiled at us and told us to look for the solution section at
> the end of the text book. It turned out to be the answer for a problem
> in the next chapter to be covered. The code was only three lines long!
> Although it did not have the codes for debugging purposes, it covered
> all error messages expected. It was such a shocker that everyone quieted
> down to focus on the subject for the rest of the semester. During my
> first employment, we had the need to optimize circuit designs. Since I
> was the only staff who knew about it, I ended up being the coordinator
> between several hardware designers and the supporting programmer. From
> that teaching, I am always looking for the most concise solution to an
> issue, not being distracted or discouraged by the manifestation on the
> surface.
>
> https://en.wikipedia.org/wiki/APL_(programming_language)
>
> 3) Fast forward half a century, I am hoping that my "one-line code"
> serves the purpose of "there exists" an example in proofing a
> mathematical theorem for inspiring software colleagues to review the
> network codes in front of them for improvement, instead of presenting
> such as a valid hurdle to progress.
>
>
> Regards,
>
>
> Abe (2022-11-24 03:53 EST)
>
>
>
>
>
> On 2022-11-21 19:30, Joe Maimon wrote:
> >
> >
> > David Conrad wrote:
> >> Barry,
> >>
> >> On Nov 21, 2022, at 3:01 PM, bzs@theworld.com wrote:
> >>> We've been trying to get people to adopt IPv6 widely for 30 years
> >>> with very limited success
> >>
> >> According to https://www.google.com/intl/en/ipv6/statistics.html, it
> >> looks like we’ve gone from ~0% to ~40% in 12 years.
> >> https://stats.labs.apnic.net/ipv6 has it around 30%. Given an
> >> Internet population of about 5B, this can (simplistically and
> >> wrongly) argued to mean 1.5-2B people are using IPv6. For a
> >> transition to a technology that the vast majority of people who pay
> >> the bills will neither notice nor care about, and for which the
> >> business case typically needs projection way past the normal
> >> quarterly focus of shareholders, that seems pretty successful to me.
> >>
> >> But back to the latest proposal to rearrange deck chairs on the IPv4
> >> Titanic, the fundamental and obvious flaw is the assertion of
> >> "commenting out one line code”. There isn’t “one line of code”. There
> >> are literally _billions_ of instances of “one line of code”, the vast
> >> majority of which need to be changed/deployed/tested with absolutely
> >> no business case to do so that isn’t better met with deploying
> >> IPv6+IPv4aaS. I believe this has been pointed out numerous times, but
> >> it falls on deaf ears, so the discussion gets a bit tedious.
> >>
> >> Regards,
> >> -drc
> >>
> > Had the titanic stayed afloat some hours more, many more would have
> > survived and been rescued when assistance eventually arrived. So that
> > makes this a debate over whether this is deck chair re-arrangement or
> > something more meaningful.
> >
> > As I and others have pointed out, it depends on how it is used. And
> > perhaps the attempt should be made regardless of knowing in advance
> > which it will be.
> >
> > You assertion needs some back of the envelope numbers, which once
> > provided, I suspect will render your estimate grossly incorrect.
> >
> > You can hardly attempt to convince anybody that 240/4 as unicast would
> > not be the more trivial change made in any of these products natural
> > life cycle points.
> >
> > Especially as we have examples of what that type of effort might look
> > like. IGTFY and here
> >
> > https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/
> >
> > The burdensome position is ridiculous even more so when stated with a
> > straight face.
> >
> > Joe
> >
> >
> >
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
>


--
Douglas Fernando Fischer
Engº de Controle e Automação

Hi, Eduard:

0) Thanks for sharing your research efforts.

1) Similar as your own experience, we also recognized the granularity
issue of the data in this particular type of statistics. Any data that
is based on a limited number of countries, regions, businesses, industry
segments, etc. will always be rebutted with a counter example of some
sort. So, we put more trust into those general service cases with
continuous reports for consistency, such as AMS-IX. If you know any
better sources, I would like to look into them.

Regards,


Abe (2022-11-24 11:59 EST)


On 2022-11-24 04:43, Vasilenko Eduard wrote:
> Hi Abraham,
> Let me clarify a little bit on statistics - I did an investigation last year.
>
> Google and APNIC report very similar numbers. APNIC permits drilling down deep details. Then it is possible to understand that they see only 100M Chinese. China itself reports 0.5B IPv6 users. APNIC gives Internet population by country - it permits to construct proportion.
> Hence, it is possible to conclude that we need to add 8% to Google (or APNIC) to get 48% of IPv6 preferred users worldwide. We would likely cross 50% this year.
>
> I spent a decent time finding traffic statics. I have found one DPI vendor who has it. Unfortunately, they sell it for money.
> ARCEP has got it for France and published it in their "Barometer". Almost 70% of application requests are possible to serve from IPv6.
> Hence, 70%*48%=33.6%. We could claim that 1/3 of the traffic is IPv6 worldwide because France is typical.
> My boss told me "No-No" for this logic. His example is China where we had reliable data for only 20% of application requests served on IPv6 (China has a very low IPv6 adoption by OTTs).
> My response was: But India has a much better IPv6 adoption on the web server side. China and a few other countries are not representative. The majority are like France.
> Unfortunately, we do not have per-country IPv6 adoption on the web server side.
> OK. We could estimate 60% of the application readiness as a minimum. Then 60%*48%=28.8%.
> Hence, we could claim that at least 1/4 of the worldwide traffic is IPv6.
>
> IX data shows much low IPv6 adoption because the biggest OTTs have many caches installed directly on Carriers' sites.
>
> Sorry for not the exact science. But it is all that I have. It is better than nothing.
>
> PS: 60% of requests served by web servers does not mean "60% of servers". For servers themselves we have statistics - it is just 20%+. But it is for the biggest web resources.
>
> Eduard
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org] On Behalf Of Abraham Y. Chen
> Sent: Thursday, November 24, 2022 11:53 AM
> To: Joe Maimon<jmaimon@jmaimon.com>
> Cc: NANOG<nanog@nanog.org>;bzs@theworld.com
> Subject: Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC
>
> Dear Joe:
>
> 0) Allow me to share my understanding of the two topics that you brought up.
>
> 1) "...https://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone from ~0% to ~40% in 12 years.... ":  Your numbers may be deceiving.
>
>   A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and ratified on 2017-07-14. So, the IPv6 efforts have been quite a few years more than your impression. That is, the IPv6 has been around over quarter of a century.
>
>   B. If you read closely, the statement  "The graph shows the percentage of users that access Google over IPv6." above the graph actually means "equipment readiness". That is, how many Google users have IPv6 capable devices. This is similar as the APNIC statistics whose title makes this clearer. However, having the capability does not mean the owners are actually using it. Also, this is not general data, but within the Google environment. Since Google is one of the stronger promoters of the IPv6, this graph would be at best the cap of such data.
>
>   C. The more meaningful data would be the global IPv6 traffic statistics. Interestingly, they do not exist upon our extensive search.
> (If you know of any, I would appreciate to receive a lead to such.) The closest that we could find is % of IPv6 in AMS-IX traffic statistics (see URL below). It is currently at about 5-6% and has been tapering off to a growth of less than 0.1% per month recently, after a ramp-up period in the past. (Similar saturation behavior can also be found in the above Google graph.)
>
> https://stats.ams-ix.net/sflow/ether_type.html
>
>   D.  One interesting parameter behind the last one is that as an Inter-eXchange operator, AMS-IX should see very similar percentage traffic mix between IPv6 and IPv4. The low numbers from AMS-IX does not support this viewpoint for matching with your observation. In addition, traffic through IX is the overflow among backbone routers. A couple years ago, there was a report that peering arrangements among backbone routers for IPv6 were much less matured then IPv4, which meant that AMS-IX should be getting more IPv6 traffic than the mix in the Internet core. Interpreted in reverse, % of IPv6 in overall Internet traffic should be less than what AMS-IX handles.
>
>   E. This is a quite convoluted topic that we only scratched the surface. They should not occupy the attention of colleagues on this list. However, I am willing to provide more information to you off-line, if you care for further discussion.
>
> 2)  "...https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/
> ...":  My basic training was in communication equipment hardware design.
> I knew little about software beyond what I needed for my primary assignment. Your example, however, reminds me of a programing course that I took utilizing APL (A Programming Language) for circuit analysis, optimization and synthesis. It was such a cryptic symbolic language that classmates (mostly majored in EE hardware) were murmuring to express their displeasure. One day we got a homework assignment to do something relatively simple. Everyone struggled to write the code to do the job.
> Although most of us did get working codes, they were pages long. The shortest one was one full page. Upon reviewed all homework, the professor smiled at us and told us to look for the solution section at the end of the text book. It turned out to be the answer for a problem in the next chapter to be covered. The code was only three lines long!
> Although it did not have the codes for debugging purposes, it covered all error messages expected. It was such a shocker that everyone quieted down to focus on the subject for the rest of the semester. During my first employment, we had the need to optimize circuit designs. Since I was the only staff who knew about it, I ended up being the coordinator between several hardware designers and the supporting programmer. From that teaching, I am always looking for the most concise solution to an issue, not being distracted or discouraged by the manifestation on the surface.
>
> https://en.wikipedia.org/wiki/APL_(programming_language)
>
> 3) Fast forward half a century, I am hoping that my "one-line code"
> serves the purpose of "there exists" an example in proofing a mathematical theorem for  inspiring software colleagues to review the network codes in front of them for improvement, instead of presenting such as a valid hurdle to progress.
>
>
> Regards,
>
>
> Abe (2022-11-24 03:53 EST)
>
>
>
>
>
> On 2022-11-21 19:30, Joe Maimon wrote:
>> David Conrad wrote:
>>> Barry,
>>>
>>> On Nov 21, 2022, at 3:01 PM,bzs@theworld.com wrote:
>>>> We've been trying to get people to adopt IPv6 widely for 30 years
>>>> with very limited success
>>> According tohttps://www.google.com/intl/en/ipv6/statistics.html, it
>>> looks like we’ve gone from ~0% to ~40% in 12 years.
>>> https://stats.labs.apnic.net/ipv6 has it around 30%. Given an
>>> Internet population of about 5B, this can (simplistically and
>>> wrongly) argued to mean 1.5-2B people are using IPv6. For a
>>> transition to a technology that the vast majority of people who pay
>>> the bills will neither notice nor care about, and for which the
>>> business case typically needs projection way past the normal
>>> quarterly focus of shareholders, that seems pretty successful to me.
>>>
>>> But back to the latest proposal to rearrange deck chairs on the IPv4
>>> Titanic, the fundamental and obvious flaw is the assertion of
>>> "commenting out one line code”. There isn’t “one line of code”. There
>>> are literally _billions_ of instances of “one line of code”, the vast
>>> majority of which need to be changed/deployed/tested with absolutely
>>> no business case to do so that isn’t better met with deploying
>>> IPv6+IPv4aaS. I believe this has been pointed out numerous times, but
>>> it falls on deaf ears, so the discussion gets a bit tedious.
>>>
>>> Regards,
>>> -drc
>>>
>> Had the titanic stayed afloat some hours more, many more would have
>> survived and been rescued when assistance eventually arrived. So that
>> makes this a debate over whether this is deck chair re-arrangement or
>> something more meaningful.
>>
>> As I and others have pointed out, it depends on how it is used. And
>> perhaps the attempt should be made regardless of knowing in advance
>> which it will be.
>>
>> You assertion needs some back of the envelope numbers, which once
>> provided, I suspect will render your estimate grossly incorrect.
>>
>> You can hardly attempt to convince anybody that 240/4 as unicast would
>> not be the more trivial change made in any of these products natural
>> life cycle points.
>>
>> Especially as we have examples of what that type of effort might look
>> like. IGTFY and here
>>
>> https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/
>>
>> The burdensome position is ridiculous even more so when stated with a
>> straight face.
>>
>> Joe
>>
>>
>>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
>


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

Hi Abe,

the problem is that the AMS-IX data only covers the public fabric, but
the peering connections between the big CDNs/clouds and the large ISPs
all happen on private dedicated circuits as it is so much traffic that
it does not make sense to run it over a public IX fabric (in addition to
local caches which dillute the stats even more). Thus that data you are
referring to is heavily biased and should not be used for this
generalized purpose.

Regards,
Chris

On 24.11.22 18:01, Abraham Y. Chen wrote:
> Hi, Eduard:
>
> 0) Thanks for sharing your research efforts.
>
> 1) Similar as your own experience, we also recognized the granularity
> issue of the data in this particular type of statistics. Any data that
> is based on a limited number of countries, regions, businesses,
> industry segments, etc. will always be rebutted with a counter example
> of some sort. So, we put more trust into those general service cases
> with continuous reports for consistency, such as AMS-IX. If you know
> any better sources, I would like to look into them.
>
> Regards,
>
>
> Abe (2022-11-24 11:59 EST)
>
>
> On 2022-11-24 04:43, Vasilenko Eduard wrote:
>> Hi Abraham,
>> Let me clarify a little bit on statistics - I did an investigation
>> last year.
>>
>> Google and APNIC report very similar numbers. APNIC permits drilling
>> down deep details. Then it is possible to understand that they see
>> only 100M Chinese. China itself reports 0.5B IPv6 users. APNIC gives
>> Internet population by country - it permits to construct proportion.
>> Hence, it is possible to conclude that we need to add 8% to Google
>> (or APNIC) to get 48% of IPv6 preferred users worldwide. We would
>> likely cross 50% this year.
>>
>> I spent a decent time finding traffic statics. I have found one DPI
>> vendor who has it. Unfortunately, they sell it for money.
>> ARCEP has got it for France and published it in their "Barometer".
>> Almost 70% of application requests are possible to serve from IPv6.
>> Hence, 70%*48%=33.6%. We could claim that 1/3 of the traffic is IPv6
>> worldwide because France is typical.
>> My boss told me "No-No" for this logic. His example is China where we
>> had reliable data for only 20% of application requests served on IPv6
>> (China has a very low IPv6 adoption by OTTs).
>> My response was: But India has a much better IPv6 adoption on the web
>> server side. China and a few other countries are not representative.
>> The majority are like France.
>> Unfortunately, we do not have per-country IPv6 adoption on the web
>> server side.
>> OK. We could estimate 60% of the application readiness as a minimum.
>> Then 60%*48%=28.8%.
>> Hence, we could claim that at least 1/4 of the worldwide traffic is
>> IPv6.
>>
>> IX data shows much low IPv6 adoption because the biggest OTTs have
>> many caches installed directly on Carriers' sites.
>>
>> Sorry for not the exact science. But it is all that I have. It is
>> better than nothing.
>>
>> PS: 60% of requests served by web servers does not mean "60% of
>> servers". For servers themselves we have statistics - it is just
>> 20%+. But it is for the biggest web resources.
>>
>> Eduard
>> -----Original Message-----
>> From: NANOG
>> [mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org] On
>> Behalf Of Abraham Y. Chen
>> Sent: Thursday, November 24, 2022 11:53 AM
>> To: Joe Maimon<jmaimon@jmaimon.com>
>> Cc: NANOG<nanog@nanog.org>;bzs@theworld.com
>> Subject: Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC
>>
>> Dear Joe:
>>
>> 0) Allow me to share my understanding of the two topics that you
>> brought up.
>>
>> 1) "...https://www.google.com/intl/en/ipv6/statistics.html, it looks
>> like we’ve gone from ~0% to ~40% in 12 years.... ":  Your numbers may
>> be deceiving.
>>
>>     A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and
>> ratified on 2017-07-14. So, the IPv6 efforts have been quite a few
>> years more than your impression. That is, the IPv6 has been around
>> over quarter of a century.
>>
>>     B. If you read closely, the statement  "The graph shows the
>> percentage of users that access Google over IPv6." above the graph
>> actually means "equipment readiness". That is, how many Google users
>> have IPv6 capable devices. This is similar as the APNIC statistics
>> whose title makes this clearer. However, having the capability does
>> not mean the owners are actually using it. Also, this is not general
>> data, but within the Google environment. Since Google is one of the
>> stronger promoters of the IPv6, this graph would be at best the cap
>> of such data.
>>
>>     C. The more meaningful data would be the global IPv6 traffic
>> statistics. Interestingly, they do not exist upon our extensive search.
>> (If you know of any, I would appreciate to receive a lead to such.)
>> The closest that we could find is % of IPv6 in AMS-IX traffic
>> statistics (see URL below). It is currently at about 5-6% and has
>> been tapering off to a growth of less than 0.1% per month recently,
>> after a ramp-up period in the past. (Similar saturation behavior can
>> also be found in the above Google graph.)
>>
>> https://stats.ams-ix.net/sflow/ether_type.html
>>
>>     D.  One interesting parameter behind the last one is that as an
>> Inter-eXchange operator, AMS-IX should see very similar percentage
>> traffic mix between IPv6 and IPv4. The low numbers from AMS-IX does
>> not support this viewpoint for matching with your observation. In
>> addition, traffic through IX is the overflow among backbone routers.
>> A couple years ago, there was a report that peering arrangements
>> among backbone routers for IPv6 were much less matured then IPv4,
>> which meant that AMS-IX should be getting more IPv6 traffic than the
>> mix in the Internet core. Interpreted in reverse, % of IPv6 in
>> overall Internet traffic should be less than what AMS-IX handles.
>>
>>     E. This is a quite convoluted topic that we only scratched the
>> surface. They should not occupy the attention of colleagues on this
>> list. However, I am willing to provide more information to you
>> off-line, if you care for further discussion.
>>
>> 2) "...https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/
>> ...":  My basic training was in communication equipment hardware design.
>> I knew little about software beyond what I needed for my primary
>> assignment. Your example, however, reminds me of a programing course
>> that I took utilizing APL (A Programming Language) for circuit
>> analysis, optimization and synthesis. It was such a cryptic symbolic
>> language that classmates (mostly majored in EE hardware) were
>> murmuring to express their displeasure. One day we got a homework
>> assignment to do something relatively simple. Everyone struggled to
>> write the code to do the job.
>> Although most of us did get working codes, they were pages long. The
>> shortest one was one full page. Upon reviewed all homework, the
>> professor smiled at us and told us to look for the solution section
>> at the end of the text book. It turned out to be the answer for a
>> problem in the next chapter to be covered. The code was only three
>> lines long!
>> Although it did not have the codes for debugging purposes, it covered
>> all error messages expected. It was such a shocker that everyone
>> quieted down to focus on the subject for the rest of the semester.
>> During my first employment, we had the need to optimize circuit
>> designs. Since I was the only staff who knew about it, I ended up
>> being the coordinator between several hardware designers and the
>> supporting programmer. From that teaching, I am always looking for
>> the most concise solution to an issue, not being distracted or
>> discouraged by the manifestation on the surface.
>>
>> https://en.wikipedia.org/wiki/APL_(programming_language)
>>
>> 3) Fast forward half a century, I am hoping that my "one-line code"
>> serves the purpose of "there exists" an example in proofing a
>> mathematical theorem for  inspiring software colleagues to review the
>> network codes in front of them for improvement, instead of presenting
>> such as a valid hurdle to progress.
>>
>>
>> Regards,
>>
>>
>> Abe (2022-11-24 03:53 EST)
>>
>>
>>
>>
>>
>> On 2022-11-21 19:30, Joe Maimon wrote:
>>> David Conrad wrote:
>>>> Barry,
>>>>
>>>> On Nov 21, 2022, at 3:01 PM,bzs@theworld.com  wrote:
>>>>> We've been trying to get people to adopt IPv6 widely for 30 years
>>>>> with very limited success
>>>> According tohttps://www.google.com/intl/en/ipv6/statistics.html, it
>>>> looks like we’ve gone from ~0% to ~40% in 12 years.
>>>> https://stats.labs.apnic.net/ipv6  has it around 30%. Given an
>>>> Internet population of about 5B, this can (simplistically and
>>>> wrongly) argued to mean 1.5-2B people are using IPv6. For a
>>>> transition to a technology that the vast majority of people who pay
>>>> the bills will neither notice nor care about, and for which the
>>>> business case typically needs projection way past the normal
>>>> quarterly focus of shareholders, that seems pretty successful to me.
>>>>
>>>> But back to the latest proposal to rearrange deck chairs on the IPv4
>>>> Titanic, the fundamental and obvious flaw is the assertion of
>>>> "commenting out one line code”. There isn’t “one line of code”. There
>>>> are literally _billions_ of instances of “one line of code”, the vast
>>>> majority of which need to be changed/deployed/tested with absolutely
>>>> no business case to do so that isn’t better met with deploying
>>>> IPv6+IPv4aaS. I believe this has been pointed out numerous times, but
>>>> it falls on deaf ears, so the discussion gets a bit tedious.
>>>>
>>>> Regards,
>>>> -drc
>>>>
>>> Had the titanic stayed afloat some hours more, many more would have
>>> survived and been rescued when assistance eventually arrived. So that
>>> makes this a debate over whether this is deck chair re-arrangement or
>>> something more meaningful.
>>>
>>> As I and others have pointed out, it depends on how it is used. And
>>> perhaps the attempt should be made regardless of knowing in advance
>>> which it will be.
>>>
>>> You assertion needs some back of the envelope numbers, which once
>>> provided, I suspect will render your estimate grossly incorrect.
>>>
>>> You can hardly attempt to convince anybody that 240/4 as unicast would
>>> not be the more trivial change made in any of these products natural
>>> life cycle points.
>>>
>>> Especially as we have examples of what that type of effort might look
>>> like. IGTFY and here
>>>
>>> https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/
>>>
>>> The burdensome position is ridiculous even more so when stated with a
>>> straight face.
>>>
>>> Joe
>>>
>>>
>>>
>> --
>> This email has been checked for viruses by Avast antivirus software.
>> www.avast.com
>>
>
>

> What's the group's current thought on emergence or prevalence of
> IPv6-only hosts ?

They aren’t needed; dual stack hosts will work just fine in a single stack network. When they’re needed, they will be normal but nobody will care.

Hi, Douglas:

0) Thanks for the feedback.

1)  I do not sort eMail with any tools. Other than important ones that
do I save a copy off the system as a document for long term reference, I
only flag those of substance for the keeps and allow the rest to
"expire" (I do house cleaning every three months or so.). Consequently,
I have no idea about the terminologies that you mentioned.

2)  My basic understanding is, an eMail in its entirety is the original
work of its composer / writer / sender. As such, a receiver is free to
do anything with it, but not to impose certain "rules" back onto the
writing. Through the years, eMail writing styles have diversified from
the business letter protocols that I knew so much that I had to develop
my own conventions of writing that enabled me to organize my eMails for
retrieval. They seem to be tolerated by most parties that communicated
with except NANOG. If you have certain clear rules that can pass my
"logistics" considerations, I will definitely learn and follow.

Regards,


Abe (2022-11-24 16:00 EST)



On 2022-11-24 06:51, Douglas Fischer wrote:
> Hello Abraham!
>
> I believe your e-mail client (MUA) is splitting every message on a new
> thread.
> I'm not sure if it is happening with everyone, but using Gmail as MUA,
> it isn't aggregating the mails on the same thread.
>
> Cloud you please check the confs of your tool to avoid it?
>
> Thanks in advance.
>
> Em qui., 24 de nov. de 2022 às 05:56, Abraham Y. Chen
> <aychen@avinta.com> escreveu:
>
> Dear Joe:
>
> 0) Allow me to share my understanding of the two topics that you
> brought up.
>
> 1) "... https://www.google.com/intl/en/ipv6/statistics.html, it looks
> like we’ve gone from ~0% to ~40% in 12 years.... ":  Your numbers
> may be
> deceiving.
>
>    A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and
> ratified on 2017-07-14. So, the IPv6 efforts have been quite a few
> years
> more than your impression. That is, the IPv6 has been around over
> quarter of a century.
>
>    B. If you read closely, the statement  "The graph shows the
> percentage of users that access Google over IPv6." above the graph
> actually means "equipment readiness". That is, how many Google users
> have IPv6 capable devices. This is similar as the APNIC statistics
> whose
> title makes this clearer. However, having the capability does not
> mean
> the owners are actually using it. Also, this is not general data, but
> within the Google environment. Since Google is one of the stronger
> promoters of the IPv6, this graph would be at best the cap of such
> data.
>
>    C. The more meaningful data would be the global IPv6 traffic
> statistics. Interestingly, they do not exist upon our extensive
> search.
> (If you know of any, I would appreciate to receive a lead to
> such.) The
> closest that we could find is % of IPv6 in AMS-IX traffic statistics
> (see URL below). It is currently at about 5-6% and has been
> tapering off
> to a growth of less than 0.1% per month recently, after a ramp-up
> period
> in the past. (Similar saturation behavior can also be found in the
> above
> Google graph.)
>
> https://stats.ams-ix.net/sflow/ether_type.html
>
>    D.  One interesting parameter behind the last one is that as an
> Inter-eXchange operator, AMS-IX should see very similar percentage
> traffic mix between IPv6 and IPv4. The low numbers from AMS-IX
> does not
> support this viewpoint for matching with your observation. In
> addition,
> traffic through IX is the overflow among backbone routers. A couple
> years ago, there was a report that peering arrangements among
> backbone
> routers for IPv6 were much less matured then IPv4, which meant that
> AMS-IX should be getting more IPv6 traffic than the mix in the
> Internet
> core. Interpreted in reverse, % of IPv6 in overall Internet traffic
> should be less than what AMS-IX handles.
>
>    E. This is a quite convoluted topic that we only scratched the
> surface. They should not occupy the attention of colleagues on this
> list. However, I am willing to provide more information to you
> off-line,
> if you care for further discussion.
>
> 2)  "...
> https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/
> ...":  My basic training was in communication equipment hardware
> design.
> I knew little about software beyond what I needed for my primary
> assignment. Your example, however, reminds me of a programing course
> that I took utilizing APL (A Programming Language) for circuit
> analysis,
> optimization and synthesis. It was such a cryptic symbolic
> language that
> classmates (mostly majored in EE hardware) were murmuring to express
> their displeasure. One day we got a homework assignment to do
> something
> relatively simple. Everyone struggled to write the code to do the
> job.
> Although most of us did get working codes, they were pages long. The
> shortest one was one full page. Upon reviewed all homework, the
> professor smiled at us and told us to look for the solution
> section at
> the end of the text book. It turned out to be the answer for a
> problem
> in the next chapter to be covered. The code was only three lines
> long!
> Although it did not have the codes for debugging purposes, it covered
> all error messages expected. It was such a shocker that everyone
> quieted
> down to focus on the subject for the rest of the semester. During my
> first employment, we had the need to optimize circuit designs.
> Since I
> was the only staff who knew about it, I ended up being the
> coordinator
> between several hardware designers and the supporting programmer.
> From
> that teaching, I am always looking for the most concise solution
> to an
> issue, not being distracted or discouraged by the manifestation on
> the
> surface.
>
> https://en.wikipedia.org/wiki/APL_(programming_language)
>
> 3) Fast forward half a century, I am hoping that my "one-line code"
> serves the purpose of "there exists" an example in proofing a
> mathematical theorem for  inspiring software colleagues to review the
> network codes in front of them for improvement, instead of presenting
> such as a valid hurdle to progress.
>
>
> Regards,
>
>
> Abe (2022-11-24 03:53 EST)
>
>
>
>
>
> On 2022-11-21 19:30, Joe Maimon wrote:
> >
> >
> > David Conrad wrote:
> >> Barry,
> >>
> >> On Nov 21, 2022, at 3:01 PM, bzs@theworld.com wrote:
> >>> We've been trying to get people to adopt IPv6 widely for 30 years
> >>> with very limited success
> >>
> >> According to
> https://www.google.com/intl/en/ipv6/statistics.html, it
> >> looks like we’ve gone from ~0% to ~40% in 12 years.
> >> https://stats.labs.apnic.net/ipv6 has it around 30%. Given an
> >> Internet population of about 5B, this can (simplistically and
> >> wrongly) argued to mean 1.5-2B people are using IPv6. For a
> >> transition to a technology that the vast majority of people who
> pay
> >> the bills will neither notice nor care about, and for which the
> >> business case typically needs projection way past the normal
> >> quarterly focus of shareholders, that seems pretty successful
> to me.
> >>
> >> But back to the latest proposal to rearrange deck chairs on the
> IPv4
> >> Titanic, the fundamental and obvious flaw is the assertion of
> >> "commenting out one line code”. There isn’t “one line of code”.
> There
> >> are literally _billions_ of instances of “one line of code”,
> the vast
> >> majority of which need to be changed/deployed/tested with
> absolutely
> >> no business case to do so that isn’t better met with deploying
> >> IPv6+IPv4aaS. I believe this has been pointed out numerous
> times, but
> >> it falls on deaf ears, so the discussion gets a bit tedious.
> >>
> >> Regards,
> >> -drc
> >>
> > Had the titanic stayed afloat some hours more, many more would have
> > survived and been rescued when assistance eventually arrived. So
> that
> > makes this a debate over whether this is deck chair
> re-arrangement or
> > something more meaningful.
> >
> > As I and others have pointed out, it depends on how it is used. And
> > perhaps the attempt should be made regardless of knowing in advance
> > which it will be.
> >
> > You assertion needs some back of the envelope numbers, which once
> > provided, I suspect will render your estimate grossly incorrect.
> >
> > You can hardly attempt to convince anybody that 240/4 as unicast
> would
> > not be the more trivial change made in any of these products
> natural
> > life cycle points.
> >
> > Especially as we have examples of what that type of effort might
> look
> > like. IGTFY and here
> >
> > https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/
> >
> > The burdensome position is ridiculous even more so when stated
> with a
> > straight face.
> >
> > Joe
> >
> >
> >
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <http://www.avast.com>
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação

Hi, Chris:

1) "... public fabric ... private dedicated circuits ... heavily biased
...":   You brought up an aspect that I have no knowledge about.
However, you did not clarify how IPv6 and IPv4 are treated differently
by these considerations which was the key parameter that we are trying
to sort out. Thanks.

Regards,

Abe (2022-11-24 15:40)


On 2022-11-24 12:23, Chris Welti wrote:
> Hi Abe,
>
> the problem is that the AMS-IX data only covers the public fabric, but
> the peering connections between the big CDNs/clouds and the large ISPs
> all happen on private dedicated circuits as it is so much traffic that
> it does not make sense to run it over a public IX fabric (in addition
> to local caches which dillute the stats even more). Thus that data you
> are referring to is heavily biased and should not be used for this
> generalized purpose.
>
> Regards,
> Chris
>
> On 24.11.22 18:01, Abraham Y. Chen wrote:
>> Hi, Eduard:
>>
>> 0) Thanks for sharing your research efforts.
>>
>> 1) Similar as your own experience, we also recognized the granularity
>> issue of the data in this particular type of statistics. Any data
>> that is based on a limited number of countries, regions, businesses,
>> industry segments, etc. will always be rebutted with a counter
>> example of some sort. So, we put more trust into those general
>> service cases with continuous reports for consistency, such as
>> AMS-IX. If you know any better sources, I would like to look into them.
>>
>> Regards,
>>
>>
>> Abe (2022-11-24 11:59 EST)
>>
>>
>> On 2022-11-24 04:43, Vasilenko Eduard wrote:
>>> Hi Abraham,
>>> Let me clarify a little bit on statistics - I did an investigation
>>> last year.
>>>
>>> Google and APNIC report very similar numbers. APNIC permits drilling
>>> down deep details. Then it is possible to understand that they see
>>> only 100M Chinese. China itself reports 0.5B IPv6 users. APNIC gives
>>> Internet population by country - it permits to construct proportion.
>>> Hence, it is possible to conclude that we need to add 8% to Google
>>> (or APNIC) to get 48% of IPv6 preferred users worldwide. We would
>>> likely cross 50% this year.
>>>
>>> I spent a decent time finding traffic statics. I have found one DPI
>>> vendor who has it. Unfortunately, they sell it for money.
>>> ARCEP has got it for France and published it in their "Barometer".
>>> Almost 70% of application requests are possible to serve from IPv6.
>>> Hence, 70%*48%=33.6%. We could claim that 1/3 of the traffic is IPv6
>>> worldwide because France is typical.
>>> My boss told me "No-No" for this logic. His example is China where
>>> we had reliable data for only 20% of application requests served on
>>> IPv6 (China has a very low IPv6 adoption by OTTs).
>>> My response was: But India has a much better IPv6 adoption on the
>>> web server side. China and a few other countries are not
>>> representative. The majority are like France.
>>> Unfortunately, we do not have per-country IPv6 adoption on the web
>>> server side.
>>> OK. We could estimate 60% of the application readiness as a minimum.
>>> Then 60%*48%=28.8%.
>>> Hence, we could claim that at least 1/4 of the worldwide traffic is
>>> IPv6.
>>>
>>> IX data shows much low IPv6 adoption because the biggest OTTs have
>>> many caches installed directly on Carriers' sites.
>>>
>>> Sorry for not the exact science. But it is all that I have. It is
>>> better than nothing.
>>>
>>> PS: 60% of requests served by web servers does not mean "60% of
>>> servers". For servers themselves we have statistics - it is just
>>> 20%+. But it is for the biggest web resources.
>>>
>>> Eduard
>>> -----Original Message-----
>>> From: NANOG
>>> [mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org] On
>>> Behalf Of Abraham Y. Chen
>>> Sent: Thursday, November 24, 2022 11:53 AM
>>> To: Joe Maimon<jmaimon@jmaimon.com>
>>> Cc: NANOG<nanog@nanog.org>;bzs@theworld.com
>>> Subject: Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC
>>>
>>> Dear Joe:
>>>
>>> 0) Allow me to share my understanding of the two topics that you
>>> brought up.
>>>
>>> 1) "...https://www.google.com/intl/en/ipv6/statistics.html, it looks
>>> like we’ve gone from ~0% to ~40% in 12 years.... ": Your numbers may
>>> be deceiving.
>>>
>>>     A. The IPv6 was introduced in 1995-12, launched on 2012-06-06
>>> and ratified on 2017-07-14. So, the IPv6 efforts have been quite a
>>> few years more than your impression. That is, the IPv6 has been
>>> around over quarter of a century.
>>>
>>>     B. If you read closely, the statement  "The graph shows the
>>> percentage of users that access Google over IPv6." above the graph
>>> actually means "equipment readiness". That is, how many Google users
>>> have IPv6 capable devices. This is similar as the APNIC statistics
>>> whose title makes this clearer. However, having the capability does
>>> not mean the owners are actually using it. Also, this is not general
>>> data, but within the Google environment. Since Google is one of the
>>> stronger promoters of the IPv6, this graph would be at best the cap
>>> of such data.
>>>
>>>     C. The more meaningful data would be the global IPv6 traffic
>>> statistics. Interestingly, they do not exist upon our extensive search.
>>> (If you know of any, I would appreciate to receive a lead to such.)
>>> The closest that we could find is % of IPv6 in AMS-IX traffic
>>> statistics (see URL below). It is currently at about 5-6% and has
>>> been tapering off to a growth of less than 0.1% per month recently,
>>> after a ramp-up period in the past. (Similar saturation behavior can
>>> also be found in the above Google graph.)
>>>
>>> https://stats.ams-ix.net/sflow/ether_type.html
>>>
>>>     D.  One interesting parameter behind the last one is that as an
>>> Inter-eXchange operator, AMS-IX should see very similar percentage
>>> traffic mix between IPv6 and IPv4. The low numbers from AMS-IX does
>>> not support this viewpoint for matching with your observation. In
>>> addition, traffic through IX is the overflow among backbone routers.
>>> A couple years ago, there was a report that peering arrangements
>>> among backbone routers for IPv6 were much less matured then IPv4,
>>> which meant that AMS-IX should be getting more IPv6 traffic than the
>>> mix in the Internet core. Interpreted in reverse, % of IPv6 in
>>> overall Internet traffic should be less than what AMS-IX handles.
>>>
>>>     E. This is a quite convoluted topic that we only scratched the
>>> surface. They should not occupy the attention of colleagues on this
>>> list. However, I am willing to provide more information to you
>>> off-line, if you care for further discussion.
>>>
>>> 2) "...https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/
>>> ...":  My basic training was in communication equipment hardware
>>> design.
>>> I knew little about software beyond what I needed for my primary
>>> assignment. Your example, however, reminds me of a programing course
>>> that I took utilizing APL (A Programming Language) for circuit
>>> analysis, optimization and synthesis. It was such a cryptic symbolic
>>> language that classmates (mostly majored in EE hardware) were
>>> murmuring to express their displeasure. One day we got a homework
>>> assignment to do something relatively simple. Everyone struggled to
>>> write the code to do the job.
>>> Although most of us did get working codes, they were pages long. The
>>> shortest one was one full page. Upon reviewed all homework, the
>>> professor smiled at us and told us to look for the solution section
>>> at the end of the text book. It turned out to be the answer for a
>>> problem in the next chapter to be covered. The code was only three
>>> lines long!
>>> Although it did not have the codes for debugging purposes, it
>>> covered all error messages expected. It was such a shocker that
>>> everyone quieted down to focus on the subject for the rest of the
>>> semester. During my first employment, we had the need to optimize
>>> circuit designs. Since I was the only staff who knew about it, I
>>> ended up being the coordinator between several hardware designers
>>> and the supporting programmer. From that teaching, I am always
>>> looking for the most concise solution to an issue, not being
>>> distracted or discouraged by the manifestation on the surface.
>>>
>>> https://en.wikipedia.org/wiki/APL_(programming_language)
>>>
>>> 3) Fast forward half a century, I am hoping that my "one-line code"
>>> serves the purpose of "there exists" an example in proofing a
>>> mathematical theorem for  inspiring software colleagues to review
>>> the network codes in front of them for improvement, instead of
>>> presenting such as a valid hurdle to progress.
>>>
>>>
>>> Regards,
>>>
>>>
>>> Abe (2022-11-24 03:53 EST)
>>>
>>>
>>>
>>>
>>>
>>> On 2022-11-21 19:30, Joe Maimon wrote:
>>>> David Conrad wrote:
>>>>> Barry,
>>>>>
>>>>> On Nov 21, 2022, at 3:01 PM,bzs@theworld.com wrote:
>>>>>> We've been trying to get people to adopt IPv6 widely for 30 years
>>>>>> with very limited success
>>>>> According tohttps://www.google.com/intl/en/ipv6/statistics.html, it
>>>>> looks like we’ve gone from ~0% to ~40% in 12 years.
>>>>> https://stats.labs.apnic.net/ipv6 has it around 30%. Given an
>>>>> Internet population of about 5B, this can (simplistically and
>>>>> wrongly) argued to mean 1.5-2B people are using IPv6. For a
>>>>> transition to a technology that the vast majority of people who pay
>>>>> the bills will neither notice nor care about, and for which the
>>>>> business case typically needs projection way past the normal
>>>>> quarterly focus of shareholders, that seems pretty successful to me.
>>>>>
>>>>> But back to the latest proposal to rearrange deck chairs on the IPv4
>>>>> Titanic, the fundamental and obvious flaw is the assertion of
>>>>> "commenting out one line code”. There isn’t “one line of code”. There
>>>>> are literally _billions_ of instances of “one line of code”, the vast
>>>>> majority of which need to be changed/deployed/tested with absolutely
>>>>> no business case to do so that isn’t better met with deploying
>>>>> IPv6+IPv4aaS. I believe this has been pointed out numerous times, but
>>>>> it falls on deaf ears, so the discussion gets a bit tedious.
>>>>>
>>>>> Regards,
>>>>> -drc
>>>>>
>>>> Had the titanic stayed afloat some hours more, many more would have
>>>> survived and been rescued when assistance eventually arrived. So that
>>>> makes this a debate over whether this is deck chair re-arrangement or
>>>> something more meaningful.
>>>>
>>>> As I and others have pointed out, it depends on how it is used. And
>>>> perhaps the attempt should be made regardless of knowing in advance
>>>> which it will be.
>>>>
>>>> You assertion needs some back of the envelope numbers, which once
>>>> provided, I suspect will render your estimate grossly incorrect.
>>>>
>>>> You can hardly attempt to convince anybody that 240/4 as unicast would
>>>> not be the more trivial change made in any of these products natural
>>>> life cycle points.
>>>>
>>>> Especially as we have examples of what that type of effort might look
>>>> like. IGTFY and here
>>>>
>>>> https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/
>>>>
>>>> The burdensome position is ridiculous even more so when stated with a
>>>> straight face.
>>>>
>>>> Joe
>>>>
>>>>
>>>>
>>> --
>>> This email has been checked for viruses by Avast antivirus software.
>>> www.avast.com
>>>
>>
>>

John Curran <jcurran@istaff.org> wrote:
>> https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/
>
> ... this Internet draft ... can't be safely deployed in the actual
> real-world Internet

The draft *has been* safely deployed in the actual real-world Internet.
It is in all Linux nodes since 2008, and all recent Cisco routers. We
know that this step is safe, because it was already done a decade ago,
and the Internet did not descend into flames (except on mailing lists
;-). The draft is just trying to help the paperwork catch up with the
implementations.

So it seems that John Curran was criticizing a strawman rather than the
draft above (which I co-authored). Perhaps the confusion is that John
thought that the draft would actually allocate 240/4 addresses to
end-users for end-user purposes. Doing that would be unsafe in today's
big Internet (though major squatters are already using these addresses
in private clouds, as RIPE and Google have documented). Allocating
these addresses would be far more controversial than just updating the
code in IPv4 implementations. Therefore, the draft doesn't do that.
Instead it would just clear out the cobwebs in implementations, which
would some years later, after more work, allow a responsible party to
make such allocations. John's suggestion that "it's unsafe to do this
safe change, because we don't yet know *when* some later change will be
safe" is simply incorrect.

Perhaps what the draft failed to explain is that "Merely implementing
unicast treatment of 240/4 addresses in routers and operating systems,
as this draft proposes, does not cause any interoperability issues.
Hundreds of millions of IPv4 nodes currently contain this unicast
treatment, and all are interoperating successfully with each other and
with non-updated nodes." We'll add something like that to the next
version.

John Gilmore
IPv4 Unicast Extensions Project

On Mon, Nov 21, 2022 at 4:05 PM David Conrad <drc@virtualized.org> wrote:
>
> Barry,
>
> On Nov 21, 2022, at 3:01 PM, bzs@theworld.com wrote:
>
> We've been trying to get people to adopt IPv6 widely for 30 years with very limited success
>
>
> According to https://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone from ~0% to ~40% in 12 years. https://stats.labs.apnic.net/ipv6 has it around 30%. Given an Internet population of about 5B, this can (simplistically and wrongly) argued to mean 1.5-2B people are using IPv6. For a transition to a technology that the vast majority of people who pay the bills will neither notice nor care about, and for which the business case typically needs projection way past the normal quarterly focus of shareholders, that seems pretty successful to me.
>
> But back to the latest proposal to rearrange deck chairs on the IPv4 Titanic, the fundamental and obvious flaw is the assertion of "commenting out one line code”. There isn’t “one line of code”. There are literally _billions_ of instances of “one line of code”, the vast majority of which need to be changed/deployed/tested with absolutely no business case to do so that isn’t better met with deploying IPv6+IPv4aaS. I believe this has been pointed out numerous times, but it falls on deaf ears, so the discussion gets a bit tedious.

I have been trying to steer clear of this debate this time around, but
since I'm the one that made that analogy to begin with...

There are now billions and billions of *non-instances* of this one
line of code, saving nanoseconds on every connection, since 2008 in
the case of 240/4 and 2018 in the case of 0/8 - and that savings
alone, I felt was worth it. No additional future use is required from
my perspective to have realized real economic value from these address
spaces.

It would be rather nice, if, over time, we pretty much agreed that
embedding an 1981 policy into future OS kernels and routers transport
mechanisms was silly.

Full stop. Can someone citing me about the non-wisdom of "delete 1
line of code from everything" try to explain why our OSes MUST
continue enforcing some distinction between 240/4 and 0/8 and the rest
of the known unicast internet?

...

To take the next step - towards some sort of allocation policy - is a
matter of years and years. The subject of current research is what
does trying to make it work, break? I regularly use 240 nowadays
myself where I am not sure where the rfc1918 space is... or on a vpn -
eating my dogfood - but I do think it would be a tragic waste if we
didn't make an effort to make them globally usable in the long run.

I also tend to be upset by the argument that "this must work
internet-wide, on everything, forever, and immediately", which of
course, doesn't apply to ipv6 either.

No, it just needs to work on islands with limited address space,
initially. Tunnels between forward thinking providers, perhaps.
Starlink could use it to address terminals if they wanted - they still
don't have ipv6 working worth a darn -

I've also said a lot, that "the prospect of a portion of the internet
completely immune to windows-born viruses and worms is really
pleasing..." and I get a lot of laughs from that, because it's true -
If you've been in the trenches, fighting those off for the last few
decades, knowing that *some* piece of your infrastructure couldn't be
subject to those sort of attacks from old or windows OSes is a relief.

Arguments for deploying ipv6 remain! There's no escaping ipv6, and I
spend a lot of time trying to convince ISPs nowadays to deploy that,
but *all* of the ones I'm presently working with still must provide
IPv4 space, and thus are deploying CGNAT more rapidly than ipv6. I
will keep trying to get ipv6 deployed at every chance I get! I'm very
happy to have finally got ipv6 trie support into libreqos.io a few
weeks ago - but the demand is all cgnat, and mpls and vlans and ipv4
tunnels - I'd love to find a customer to try out our new ipv6 support,
because despite trying for months, we don't have any, as yet.

Blatant plug: https://github.com/LibreQoE/LibreQoS/tree/main/v1.3#v13-ipv4--ipv6-beta

Anyway... some use of these new ipv4 address spaces is inevitable, and
I really do wish y'all cared more about nanoseconds,
here or there, or anywhere.

>
> Regards,
> -drc
>


--
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
Dave Täht CEO, TekLibre, LLC

> On 24 Nov 2022, at 19:53, Abraham Y. Chen <aychen@avinta.com> wrote:
>
> Dear Joe:
>
> 0) Allow me to share my understanding of the two topics that you brought up.
>
> 1) "... https://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone from ~0% to ~40% in 12 years.... ": Your numbers may be deceiving.
>
> A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and ratified on 2017-07-14. So, the IPv6 efforts have been quite a few years more than your impression. That is, the IPv6 has been around over quarter of a century.

Which doesn’t change that fact that the traffic to Google has gone from ~0% to 40% in 12 years. No one claimed that Google has been measuring IPv6 traffic since the very beginning nor does it really matter how long it has been since IPv6 was defined. What we are seeing is strong continuing growth in IPv6 usage where the S curve is a long way from flattening off.

> B. If you read closely, the statement "The graph shows the percentage of users that access Google over IPv6." above the graph actually means "equipment readiness". That is, how many Google users have IPv6 capable devices. This is similar as the APNIC statistics whose title makes this clearer. However, having the capability does not mean the owners are actually using it. Also, this is not general data, but within the Google environment. Since Google is one of the stronger promoters of the IPv6, this graph would be at best the cap of such data.

If you read it correctly Google is measuring actual traffic. Thats actual data flowing to and from Google's servers be it Gmail, YouTube, search traffic or anything else. It does mean that the owners of the devices are using IPv6.

> C. The more meaningful data would be the global IPv6 traffic statistics. Interestingly, they do not exist upon our extensive search. (If you know of any, I would appreciate to receive a lead to such.) The closest that we could find is % of IPv6 in AMS-IX traffic statistics (see URL below). It is currently at about 5-6% and has been tapering off to a growth of less than 0.1% per month recently, after a ramp-up period in the past. (Similar saturation behavior can also be found in the above Google graph.)
>
> https://stats.ams-ix.net/sflow/ether_type.html

What makes that “more meaningful” data. I just see different populations of users being measured. Google's data also shows businesses making at about 4% if you look at the weekly trends that show IPv6 usage spiking on the weekend as business users traffic drops off.

> D. One interesting parameter behind the last one is that as an Inter-eXchange operator, AMS-IX should see very similar percentage traffic mix between IPv6 and IPv4. The low numbers from AMS-IX does not support this viewpoint for matching with your observation. In addition, traffic through IX is the overflow among backbone routers. A couple years ago, there was a report that peering arrangements among backbone routers for IPv6 were much less matured then IPv4, which meant that AMS-IX should be getting more IPv6 traffic than the mix in the Internet core. Interpreted in reverse, % of IPv6 in overall Internet traffic should be less than what AMS-IX handles.
>
> E. This is a quite convoluted topic that we only scratched the surface. They should not occupy the attention of colleagues on this list. However, I am willing to provide more information to you off-line, if you care for further discussion.
>
> 2) "... https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/ ...": My basic training was in communication equipment hardware design. I knew little about software beyond what I needed for my primary assignment. Your example, however, reminds me of a programing course that I took utilizing APL (A Programming Language) for circuit analysis, optimization and synthesis. It was such a cryptic symbolic language that classmates (mostly majored in EE hardware) were murmuring to express their displeasure. One day we got a homework assignment to do something relatively simple. Everyone struggled to write the code to do the job. Although most of us did get working codes, they were pages long. The shortest one was one full page. Upon reviewed all homework, the professor smiled at us and told us to look for the solution section at the end of the text book. It turned out to be the answer for a problem in the next chapter to be covered. The code was only three lines long! Although it did not have the codes for debugging purposes, it covered all error messages expected. It was such a shocker that everyone quieted down to focus on the subject for the rest of the semester. During my first employment, we had the need to optimize circuit designs. Since I was the only staff who knew about it, I ended up being the coordinator between several hardware designers and the supporting programmer. From that teaching, I am always looking for the most concise solution to an issue, not being distracted or discouraged by the manifestation on the surface.
>
> https://en.wikipedia.org/wiki/APL_(programming_language)
>
> 3) Fast forward half a century, I am hoping that my "one-line code" serves the purpose of "there exists" an example in proofing a mathematical theorem for inspiring software colleagues to review the network codes in front of them for improvement, instead of presenting such as a valid hurdle to progress.
>
>
> Regards,
>
>
> Abe (2022-11-24 03:53 EST)
>
>
>
>
>
> On 2022-11-21 19:30, Joe Maimon wrote:
>>
>>
>> David Conrad wrote:
>>> Barry,
>>>
>>> On Nov 21, 2022, at 3:01 PM, bzs@theworld.com wrote:
>>>> We've been trying to get people to adopt IPv6 widely for 30 years with very limited success
>>>
>>> According to https://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone from ~0% to ~40% in 12 years. https://stats.labs.apnic.net/ipv6 has it around 30%. Given an Internet population of about 5B, this can (simplistically and wrongly) argued to mean 1.5-2B people are using IPv6. For a transition to a technology that the vast majority of people who pay the bills will neither notice nor care about, and for which the business case typically needs projection way past the normal quarterly focus of shareholders, that seems pretty successful to me.
>>>
>>> But back to the latest proposal to rearrange deck chairs on the IPv4 Titanic, the fundamental and obvious flaw is the assertion of "commenting out one line code”. There isn’t “one line of code”. There are literally _billions_ of instances of “one line of code”, the vast majority of which need to be changed/deployed/tested with absolutely no business case to do so that isn’t better met with deploying IPv6+IPv4aaS. I believe this has been pointed out numerous times, but it falls on deaf ears, so the discussion gets a bit tedious.
>>>
>>> Regards,
>>> -drc
>>>
>> Had the titanic stayed afloat some hours more, many more would have survived and been rescued when assistance eventually arrived. So that makes this a debate over whether this is deck chair re-arrangement or something more meaningful.
>>
>> As I and others have pointed out, it depends on how it is used. And perhaps the attempt should be made regardless of knowing in advance which it will be.
>>
>> You assertion needs some back of the envelope numbers, which once provided, I suspect will render your estimate grossly incorrect.
>>
>> You can hardly attempt to convince anybody that 240/4 as unicast would not be the more trivial change made in any of these products natural life cycle points.
>>
>> Especially as we have examples of what that type of effort might look like. IGTFY and here
>>
>> https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/
>>
>> The burdensome position is ridiculous even more so when stated with a straight face.
>>
>> Joe
>>
>>
>>
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Big OTTs installed caches all over the world.
Big OTTs support IPv6.
Hosts prefer IPv6.
Hence, traffic becomes IPv6 to big OTTs.
It is not visible for IXes. IXes statistics on IPv6 are not representative.
Ed/
-----Original Message-----
From: Abraham Y. Chen [mailto:aychen@avinta.com]
Sent: Sunday, November 27, 2022 12:35 AM
To: Chris Welti <chris.welti@switch.ch>
Cc: NANOG <nanog@nanog.org>; bzs@theworld.com; Vasilenko Eduard <vasilenko.eduard@huawei.com>
Subject: Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC

Hi, Chris:

1) "... public fabric ... private dedicated circuits ... heavily biased
...":   You brought up an aspect that I have no knowledge about.
However, you did not clarify how IPv6 and IPv4 are treated differently by these considerations which was the key parameter that we are trying to sort out. Thanks.

Regards,

Abe (2022-11-24 15:40)


On 2022-11-24 12:23, Chris Welti wrote:
> Hi Abe,
>
> the problem is that the AMS-IX data only covers the public fabric, but
> the peering connections between the big CDNs/clouds and the large ISPs
> all happen on private dedicated circuits as it is so much traffic that
> it does not make sense to run it over a public IX fabric (in addition
> to local caches which dillute the stats even more). Thus that data you
> are referring to is heavily biased and should not be used for this
> generalized purpose.
>
> Regards,
> Chris
>
> On 24.11.22 18:01, Abraham Y. Chen wrote:
>> Hi, Eduard:
>>
>> 0) Thanks for sharing your research efforts.
>>
>> 1) Similar as your own experience, we also recognized the granularity
>> issue of the data in this particular type of statistics. Any data
>> that is based on a limited number of countries, regions, businesses,
>> industry segments, etc. will always be rebutted with a counter
>> example of some sort. So, we put more trust into those general
>> service cases with continuous reports for consistency, such as
>> AMS-IX. If you know any better sources, I would like to look into them.
>>
>> Regards,
>>
>>
>> Abe (2022-11-24 11:59 EST)
>>
>>
>> On 2022-11-24 04:43, Vasilenko Eduard wrote:
>>> Hi Abraham,
>>> Let me clarify a little bit on statistics - I did an investigation
>>> last year.
>>>
>>> Google and APNIC report very similar numbers. APNIC permits drilling
>>> down deep details. Then it is possible to understand that they see
>>> only 100M Chinese. China itself reports 0.5B IPv6 users. APNIC gives
>>> Internet population by country - it permits to construct proportion.
>>> Hence, it is possible to conclude that we need to add 8% to Google
>>> (or APNIC) to get 48% of IPv6 preferred users worldwide. We would
>>> likely cross 50% this year.
>>>
>>> I spent a decent time finding traffic statics. I have found one DPI
>>> vendor who has it. Unfortunately, they sell it for money.
>>> ARCEP has got it for France and published it in their "Barometer".
>>> Almost 70% of application requests are possible to serve from IPv6.
>>> Hence, 70%*48%=33.6%. We could claim that 1/3 of the traffic is IPv6
>>> worldwide because France is typical.
>>> My boss told me "No-No" for this logic. His example is China where
>>> we had reliable data for only 20% of application requests served on
>>> IPv6 (China has a very low IPv6 adoption by OTTs).
>>> My response was: But India has a much better IPv6 adoption on the
>>> web server side. China and a few other countries are not
>>> representative. The majority are like France.
>>> Unfortunately, we do not have per-country IPv6 adoption on the web
>>> server side.
>>> OK. We could estimate 60% of the application readiness as a minimum.
>>> Then 60%*48%=28.8%.
>>> Hence, we could claim that at least 1/4 of the worldwide traffic is
>>> IPv6.
>>>
>>> IX data shows much low IPv6 adoption because the biggest OTTs have
>>> many caches installed directly on Carriers' sites.
>>>
>>> Sorry for not the exact science. But it is all that I have. It is
>>> better than nothing.
>>>
>>> PS: 60% of requests served by web servers does not mean "60% of
>>> servers". For servers themselves we have statistics - it is just
>>> 20%+. But it is for the biggest web resources.
>>>
>>> Eduard
>>> -----Original Message-----
>>> From: NANOG
>>> [mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org] On
>>> Behalf Of Abraham Y. Chen
>>> Sent: Thursday, November 24, 2022 11:53 AM
>>> To: Joe Maimon<jmaimon@jmaimon.com>
>>> Cc: NANOG<nanog@nanog.org>;bzs@theworld.com
>>> Subject: Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC
>>>
>>> Dear Joe:
>>>
>>> 0) Allow me to share my understanding of the two topics that you
>>> brought up.
>>>
>>> 1) "...https://www.google.com/intl/en/ipv6/statistics.html, it looks
>>> like we’ve gone from ~0% to ~40% in 12 years.... ": Your numbers may
>>> be deceiving.
>>>
>>>     A. The IPv6 was introduced in 1995-12, launched on 2012-06-06
>>> and ratified on 2017-07-14. So, the IPv6 efforts have been quite a
>>> few years more than your impression. That is, the IPv6 has been
>>> around over quarter of a century.
>>>
>>>     B. If you read closely, the statement  "The graph shows the
>>> percentage of users that access Google over IPv6." above the graph
>>> actually means "equipment readiness". That is, how many Google users
>>> have IPv6 capable devices. This is similar as the APNIC statistics
>>> whose title makes this clearer. However, having the capability does
>>> not mean the owners are actually using it. Also, this is not general
>>> data, but within the Google environment. Since Google is one of the
>>> stronger promoters of the IPv6, this graph would be at best the cap
>>> of such data.
>>>
>>>     C. The more meaningful data would be the global IPv6 traffic
>>> statistics. Interestingly, they do not exist upon our extensive search.
>>> (If you know of any, I would appreciate to receive a lead to such.)
>>> The closest that we could find is % of IPv6 in AMS-IX traffic
>>> statistics (see URL below). It is currently at about 5-6% and has
>>> been tapering off to a growth of less than 0.1% per month recently,
>>> after a ramp-up period in the past. (Similar saturation behavior can
>>> also be found in the above Google graph.)
>>>
>>> https://stats.ams-ix.net/sflow/ether_type.html
>>>
>>>     D.  One interesting parameter behind the last one is that as an
>>> Inter-eXchange operator, AMS-IX should see very similar percentage
>>> traffic mix between IPv6 and IPv4. The low numbers from AMS-IX does
>>> not support this viewpoint for matching with your observation. In
>>> addition, traffic through IX is the overflow among backbone routers.
>>> A couple years ago, there was a report that peering arrangements
>>> among backbone routers for IPv6 were much less matured then IPv4,
>>> which meant that AMS-IX should be getting more IPv6 traffic than the
>>> mix in the Internet core. Interpreted in reverse, % of IPv6 in
>>> overall Internet traffic should be less than what AMS-IX handles.
>>>
>>>     E. This is a quite convoluted topic that we only scratched the
>>> surface. They should not occupy the attention of colleagues on this
>>> list. However, I am willing to provide more information to you
>>> off-line, if you care for further discussion.
>>>
>>> 2)
>>> "...https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/
>>> ...":  My basic training was in communication equipment hardware
>>> design.
>>> I knew little about software beyond what I needed for my primary
>>> assignment. Your example, however, reminds me of a programing course
>>> that I took utilizing APL (A Programming Language) for circuit
>>> analysis, optimization and synthesis. It was such a cryptic symbolic
>>> language that classmates (mostly majored in EE hardware) were
>>> murmuring to express their displeasure. One day we got a homework
>>> assignment to do something relatively simple. Everyone struggled to
>>> write the code to do the job.
>>> Although most of us did get working codes, they were pages long. The
>>> shortest one was one full page. Upon reviewed all homework, the
>>> professor smiled at us and told us to look for the solution section
>>> at the end of the text book. It turned out to be the answer for a
>>> problem in the next chapter to be covered. The code was only three
>>> lines long!
>>> Although it did not have the codes for debugging purposes, it
>>> covered all error messages expected. It was such a shocker that
>>> everyone quieted down to focus on the subject for the rest of the
>>> semester. During my first employment, we had the need to optimize
>>> circuit designs. Since I was the only staff who knew about it, I
>>> ended up being the coordinator between several hardware designers
>>> and the supporting programmer. From that teaching, I am always
>>> looking for the most concise solution to an issue, not being
>>> distracted or discouraged by the manifestation on the surface.
>>>
>>> https://en.wikipedia.org/wiki/APL_(programming_language)
>>>
>>> 3) Fast forward half a century, I am hoping that my "one-line code"
>>> serves the purpose of "there exists" an example in proofing a
>>> mathematical theorem for  inspiring software colleagues to review
>>> the network codes in front of them for improvement, instead of
>>> presenting such as a valid hurdle to progress.
>>>
>>>
>>> Regards,
>>>
>>>
>>> Abe (2022-11-24 03:53 EST)
>>>
>>>
>>>
>>>
>>>
>>> On 2022-11-21 19:30, Joe Maimon wrote:
>>>> David Conrad wrote:
>>>>> Barry,
>>>>>
>>>>> On Nov 21, 2022, at 3:01 PM,bzs@theworld.com wrote:
>>>>>> We've been trying to get people to adopt IPv6 widely for 30 years
>>>>>> with very limited success
>>>>> According tohttps://www.google.com/intl/en/ipv6/statistics.html,
>>>>> it looks like we’ve gone from ~0% to ~40% in 12 years.
>>>>> https://stats.labs.apnic.net/ipv6 has it around 30%. Given an
>>>>> Internet population of about 5B, this can (simplistically and
>>>>> wrongly) argued to mean 1.5-2B people are using IPv6. For a
>>>>> transition to a technology that the vast majority of people who
>>>>> pay the bills will neither notice nor care about, and for which
>>>>> the business case typically needs projection way past the normal
>>>>> quarterly focus of shareholders, that seems pretty successful to me.
>>>>>
>>>>> But back to the latest proposal to rearrange deck chairs on the
>>>>> IPv4 Titanic, the fundamental and obvious flaw is the assertion of
>>>>> "commenting out one line code”. There isn’t “one line of code”.
>>>>> There are literally _billions_ of instances of “one line of code”,
>>>>> the vast majority of which need to be changed/deployed/tested with
>>>>> absolutely no business case to do so that isn’t better met with
>>>>> deploying
>>>>> IPv6+IPv4aaS. I believe this has been pointed out numerous times,
>>>>> IPv6+but
>>>>> it falls on deaf ears, so the discussion gets a bit tedious.
>>>>>
>>>>> Regards,
>>>>> -drc
>>>>>
>>>> Had the titanic stayed afloat some hours more, many more would have
>>>> survived and been rescued when assistance eventually arrived. So
>>>> that makes this a debate over whether this is deck chair
>>>> re-arrangement or something more meaningful.
>>>>
>>>> As I and others have pointed out, it depends on how it is used. And
>>>> perhaps the attempt should be made regardless of knowing in advance
>>>> which it will be.
>>>>
>>>> You assertion needs some back of the envelope numbers, which once
>>>> provided, I suspect will render your estimate grossly incorrect.
>>>>
>>>> You can hardly attempt to convince anybody that 240/4 as unicast
>>>> would not be the more trivial change made in any of these products
>>>> natural life cycle points.
>>>>
>>>> Especially as we have examples of what that type of effort might
>>>> look like. IGTFY and here
>>>>
>>>> https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/
>>>>
>>>> The burdensome position is ridiculous even more so when stated with
>>>> a straight face.
>>>>
>>>> Joe
>>>>
>>>>
>>>>
>>> --
>>> This email has been checked for viruses by Avast antivirus software.
>>> www.avast.com
>>>
>>
>>

Vasilenko Eduard via NANOG wrote:

> Big OTTs installed caches all over the world.
> Big OTTs support IPv6.

As large network operational cost to support IPv6 is
negligible for OTTs spending a lot more money at the
application layer, they may.

> Hosts prefer IPv6.

No.

As many retail ISPs can not afford operational cost of
IPv6, they are IPv4 only, which makes hosts served by
them IPv4 only.

Possible exceptions are ISPs offering price (not
necessarily value) added network services in
noncompetitive environment. But, end users suffer
from the added price.

Masataka Ohta

Dear Mark:

1) "... Google's data also shows businesses making at about 4% if you
look at the weekly trends that show IPv6 usage spiking on the weekend as
business users traffic drops off. ...": Perhaps the better
interpretation of this fluctuation is because the residential use (more
IPv6) of the Internet peaks up during the weekend, and holidays. In
fact, work from home during COVID-19 had a notable effect to this graph.
Along this line, you may enjoy reviewing the following article and
discussions:

https://circleid.com/posts/20190529_digging_into_ipv6_traffic_to_google_is_28_percent_deployment_limit/


Regards,


Abe (2022-12-03 18:40 EST)



On 2022-11-27 21:31, Mark Andrews wrote:
>> On 24 Nov 2022, at 19:53, Abraham Y. Chen<aychen@avinta.com> wrote:
>>
>> Dear Joe:
>>
>> 0) Allow me to share my understanding of the two topics that you brought up.
>>
>> 1) "...https://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone from ~0% to ~40% in 12 years.... ": Your numbers may be deceiving.
>>
>> A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and ratified on 2017-07-14. So, the IPv6 efforts have been quite a few years more than your impression. That is, the IPv6 has been around over quarter of a century.
> Which doesn’t change that fact that the traffic to Google has gone from ~0% to 40% in 12 years. No one claimed that Google has been measuring IPv6 traffic since the very beginning nor does it really matter how long it has been since IPv6 was defined. What we are seeing is strong continuing growth in IPv6 usage where the S curve is a long way from flattening off.
>
>> B. If you read closely, the statement "The graph shows the percentage of users that access Google over IPv6." above the graph actually means "equipment readiness". That is, how many Google users have IPv6 capable devices. This is similar as the APNIC statistics whose title makes this clearer. However, having the capability does not mean the owners are actually using it. Also, this is not general data, but within the Google environment. Since Google is one of the stronger promoters of the IPv6, this graph would be at best the cap of such data.
> If you read it correctly Google is measuring actual traffic. Thats actual data flowing to and from Google's servers be it Gmail, YouTube, search traffic or anything else. It does mean that the owners of the devices are using IPv6.
>
>> C. The more meaningful data would be the global IPv6 traffic statistics. Interestingly, they do not exist upon our extensive search. (If you know of any, I would appreciate to receive a lead to such.) The closest that we could find is % of IPv6 in AMS-IX traffic statistics (see URL below). It is currently at about 5-6% and has been tapering off to a growth of less than 0.1% per month recently, after a ramp-up period in the past. (Similar saturation behavior can also be found in the above Google graph.)
>>
>> https://stats.ams-ix.net/sflow/ether_type.html
> What makes that “more meaningful” data. I just see different populations of users being measured. Google's data also shows businesses making at about 4% if you look at the weekly trends that show IPv6 usage spiking on the weekend as business users traffic drops off.
>
>> D. One interesting parameter behind the last one is that as an Inter-eXchange operator, AMS-IX should see very similar percentage traffic mix between IPv6 and IPv4. The low numbers from AMS-IX does not support this viewpoint for matching with your observation. In addition, traffic through IX is the overflow among backbone routers. A couple years ago, there was a report that peering arrangements among backbone routers for IPv6 were much less matured then IPv4, which meant that AMS-IX should be getting more IPv6 traffic than the mix in the Internet core. Interpreted in reverse, % of IPv6 in overall Internet traffic should be less than what AMS-IX handles.
>>
>> E. This is a quite convoluted topic that we only scratched the surface. They should not occupy the attention of colleagues on this list. However, I am willing to provide more information to you off-line, if you care for further discussion.
>>
>> 2) "...https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/ ...": My basic training was in communication equipment hardware design. I knew little about software beyond what I needed for my primary assignment. Your example, however, reminds me of a programing course that I took utilizing APL (A Programming Language) for circuit analysis, optimization and synthesis. It was such a cryptic symbolic language that classmates (mostly majored in EE hardware) were murmuring to express their displeasure. One day we got a homework assignment to do something relatively simple. Everyone struggled to write the code to do the job. Although most of us did get working codes, they were pages long. The shortest one was one full page. Upon reviewed all homework, the professor smiled at us and told us to look for the solution section at the end of the text book. It turned out to be the answer for a problem in the next chapter to be covered. The code was only three lines long! Although it did not have the codes for debugging purposes, it covered all error messages expected. It was such a shocker that everyone quieted down to focus on the subject for the rest of the semester. During my first employment, we had the need to optimize circuit designs. Since I was the only staff who knew about it, I ended up being the coordinator between several hardware designers and the supporting programmer. From that teaching, I am always looking for the most concise solution to an issue, not being distracted or discouraged by the manifestation on the surface.
>>
>> https://en.wikipedia.org/wiki/APL_(programming_language)
>>
>> 3) Fast forward half a century, I am hoping that my "one-line code" serves the purpose of "there exists" an example in proofing a mathematical theorem for inspiring software colleagues to review the network codes in front of them for improvement, instead of presenting such as a valid hurdle to progress.
>>
>>
>> Regards,
>>
>>
>> Abe (2022-11-24 03:53 EST)
>>
>>
>>
>>
>>
>> On 2022-11-21 19:30, Joe Maimon wrote:
>>> David Conrad wrote:
>>>> Barry,
>>>>
>>>> On Nov 21, 2022, at 3:01 PM,bzs@theworld.com wrote:
>>>>> We've been trying to get people to adopt IPv6 widely for 30 years with very limited success
>>>> According tohttps://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone from ~0% to ~40% in 12 years.https://stats.labs.apnic.net/ipv6 has it around 30%. Given an Internet population of about 5B, this can (simplistically and wrongly) argued to mean 1.5-2B people are using IPv6. For a transition to a technology that the vast majority of people who pay the bills will neither notice nor care about, and for which the business case typically needs projection way past the normal quarterly focus of shareholders, that seems pretty successful to me.
>>>>
>>>> But back to the latest proposal to rearrange deck chairs on the IPv4 Titanic, the fundamental and obvious flaw is the assertion of "commenting out one line code”. There isn’t “one line of code”. There are literally _billions_ of instances of “one line of code”, the vast majority of which need to be changed/deployed/tested with absolutely no business case to do so that isn’t better met with deploying IPv6+IPv4aaS. I believe this has been pointed out numerous times, but it falls on deaf ears, so the discussion gets a bit tedious.
>>>>
>>>> Regards,
>>>> -drc
>>>>
>>> Had the titanic stayed afloat some hours more, many more would have survived and been rescued when assistance eventually arrived. So that makes this a debate over whether this is deck chair re-arrangement or something more meaningful.
>>>
>>> As I and others have pointed out, it depends on how it is used. And perhaps the attempt should be made regardless of knowing in advance which it will be.
>>>
>>> You assertion needs some back of the envelope numbers, which once provided, I suspect will render your estimate grossly incorrect.
>>>
>>> You can hardly attempt to convince anybody that 240/4 as unicast would not be the more trivial change made in any of these products natural life cycle points.
>>>
>>> Especially as we have examples of what that type of effort might look like. IGTFY and here
>>>
>>> https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/
>>>
>>> The burdensome position is ridiculous even more so when stated with a straight face.
>>>
>>> Joe
>>>
>>>
>>>
>> --
>> This email has been checked for viruses by Avast antivirus software.
>> www.avast.com