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