Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Dave Taht]

On Mon, Nov 21, 2022 at 4:05 PM David Conrad  wrote:
>
> Barry,
>
> On Nov 21, 2022, at 3:01 PM, b...@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-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[John Gilmore]

John Curran  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

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Fred Baker]

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

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[John Curran]

> On Nov 22, 2022, at 2:13 PM, Tom Beecher  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…

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Tom Beecher]

>
> 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  wrote:

>
>
> On Nov 22, 2022, at 1:19 PM, Joe Maimon  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...
>
>
>

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[John Curran]

> On Nov 22, 2022, at 1:19 PM, Joe Maimon  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...

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Joe Maimon]

John Curran wrote:



On Nov 22, 2022, at 9:09 AM, John Curran  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

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[John Curran]

> On Nov 22, 2022, at 9:09 AM, John Curran  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.

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[John Curran]

> On Nov 22, 2022, at 2:09 AM, Joe Maimon  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 - 

  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!) 
 

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Joe Maimon]

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

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Joe Maimon]

David Conrad wrote:

Barry,

On Nov 21, 2022, at 3:01 PM, b...@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

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Owen DeLong via NANOG]

Much of India operates this way today.

Owen


> On Nov 21, 2022, at 15:06, Rubens Kuhl  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: 
> Date: Mon, Nov 21, 2022 at 8:02 PM
> Subject: Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC
> To: NANOG 
> 
> 
> 
> 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 beec...@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  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 disabli

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[David Conrad]

Joe,

On Nov 21, 2022, at 4:30 PM, Joe Maimon  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



signature.asc
Description: Message signed with OpenPGP

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Joe Maimon]

David Conrad wrote:

Barry,

On Nov 21, 2022, at 3:01 PM, b...@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.ga21...@cisco.com/

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


Joe

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[David Conrad]

Barry,

On Nov 21, 2022, at 3:01 PM, b...@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



signature.asc
Description: Message signed with OpenPGP

Fwd: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Rubens Kuhl]

(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: 
Date: Mon, Nov 21, 2022 at 8:02 PM
Subject: Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC
To: NANOG 



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 beec...@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  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,
 > >>

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[bzs]

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

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Abraham Y. Chen]

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

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Tom Beecher]

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

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Abraham Y. Chen]

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

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Mark Tinka]

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.

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Rubens Kuhl]

On Sun, Nov 20, 2022 at 2:03 PM 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.

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

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Abraham Y. Chen]

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