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

[bzs]

I'm not opposed to making 240/4 unicast but I'd agree it wouldn't
solve much globally.

Nonetheless it might help for example some new org which can't get an
IPv4 allocation (or not sufficient.) They may really need to do both
IPv4 and IPv6 for example.

(ok, here we go, point by point alternatives, we've heard them all ok,
imagine there exists ONE worthy applicant for whom the alternatives
won't work or put them at some unfair disadvantage.)

But why bother solving any of this when we have stats!

1. Those stats aren't really that compelling, we have a bifurcated
protocol space w/ maybe/arguably 40% at IPv6 after many years of
trying.

2. I'm too lazy to hunt it down but how much of that IPv6 penetration
are mobile phones and similar endpoints, captive devices with
zeroconfig? Ok who cares if they are, but...

3. Even if we agree for the sake of argument that the net is roughly
50/50 v4/v6 that still means we're dependent on things like CGNAT and
dual-stack and various other hacks which are needed to navigate this
dual protocol universe which one could argue is PRECISELY what we
didn't want back in the pre-IPv6 days.

For example we might have lived up to the original idea of an internet
and supported DECNET and CHAOSNET and SNA and XNS etc etc etc because
we're heterogeneous, we're an INTERnet!

But we didn't because in practice that stinks even if in theory it's
as simple as getting them to float their protocols on IP directly or
encapsulate them over IP or similar. Just set the IP protocol bits and
to quote Jackie Gleason "awa we go!" Or similar (I think DECNET
went for DECNET over TCP but lo I wander.)

It works, many have done it, and it always stinks.

The devil was in the details like getting enough experts around to
debug problems in your TCP/IP net and your XNS/IP or whatever
nets. And the duplication and/or expansion of equipment etc.

But that's where we are w/ IPv4/IPv6 and we think it's ok because we
slowly backed up into this mess all the while saying just think about
the rabbits Lennie (i.e., one day this will all be IPv6.)

So mere penetration is more than a little deceptive.

Granted there may be no great solution tho some proposals in the area
of (perhaps dynamically) federating the address space are at least
interesting in concept.

But I guess my point is let's not discourage those who are trying, the
problem is real.

-- 
-Barry Shein

Software Tool & Die| b...@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*

Re: Alternative Re: ipv4/25s and above

[Joe Maimon]

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.

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: 202211210951.AYC

[Lincoln Dale]

>
> > As someone who has been involved in the deployment of network gear
> > into class E space (extensively, for our own internal reasons, which
> > doesn't preclude public use of class E), "largely supported" !=
> > "universally supported".
> >
> > There remains hardware devices that blackhole class E traffic, for
> > which there is no fix. https://seclists.org/nanog/2021/Nov/272 is
> > where I list one of them. There are many, many other devices where we
> > have seen interesting behavior, some of which has been fixed, some of
> > which has not.
>
> And I am sure you would agree that un-reserving a decade ago would have
> more than likely resulted in a greatly improved situation now. Along the
> lines that doing so now could still result in a greatly improved
> situation a decade hence. Should we still need it.
>

It may well have helped (a decade ago) past-tense, but it isn't the reality
of today.

I've pointed out there is a non-zero number of existing devices, OSs,
things baked into silicon, even widely used BGP stacks today, that can't
currently use class E, and some of them will never be able to.
You seem to be suggesting that class E could be opened up as valid public
IPv4 space. My experience is that it would not be usable public IPv4
address space any time soon, if ever.

I'm not arguing that unreserving it today may address some of that. But it
will never address all of it.


cheers,

lincoln.


>

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

[John Curran]

> On Nov 21, 2022, at 11:12 PM, Joe Maimon  wrote:
> 
> John Curran wrote:
>> ..
>> That may (or may not) lead to you experiencing what you consider reasonable 
>> support costs for your customers, but as we all know, everyone else has 
>> customers who are the other ends of those connections who will call their 
>> ISP’s customer support line trying to figure out why they can’t get your 
>> customer (or can only get there intermittently) – so it appears that your 
>> proposed use of de-reserved and repurposed class E space has some real 
>> interesting implications about imputed support burdens on everyone else – if 
>> indeed the intended use case is includes providing connectivity to the 
>> public Internet.
>> 
>> If you’re not proposing public Internet use, and rather just within your own 
>> administrative domain, then feel free to do – talk to your vendors, get them 
>> to support it, and turn it on. As you already noted, we really don’t 
>> centrally decide how everyone runs their own network – so using it locally 
>> is fine since it doesn’t presume others will diagnose connection problems 
>> with your customer traffic that quite reasonably is categorized as invalid.
>> 
>> Thanks,
>> /John
>> 
>> p.s. Disclaimer:  my views alone. Note: contents may be hot - use caution 
>> when opening.
>> 
>> 
> 
> Right now the gossiped growing use of 240/4 in private and non standardized 
> fashions jeopardizes any potential use of it just as much as the factors you 
> describe.

Joe - 

That may be the case - I have no data either way, but it would not be 
surprising if some folks were paying very careful attention to their vendor 
support of 240/4 routing so that they can use this address space in a private 
context.  

However, I still have not heard any reasonable explanation for how connections 
using de-reserved 240/4 space in a public scope will be operationally viable, 
given that there will always be devices which do not forward such packets…  

> In either event, my main point of contention is in the lack of willingness 
> for serious and prudent consideration. Such as along the lines of what you 
> have brought up.

You have an opportunity now - please explain how such connections will not pose 
an operations nightmare for the rest of the public Internet – it is not at all 
apparent how such is avoided if 240/4 is changed from reserved to general 
purpose (if that’s what you are suggesting that we should be doing.) 

Of course the other alternative is what Abe has been suggesting (repeatedly):  
note that it is _not_ using 240/4 for general purpose address space, but rather 
for their "Adaptive IPv4 Address Space” 
 
mapping protocol.  It seems to suffer from the same assumption of unmolested 
240/4 transit in the public Internet (despite the current specification of such 
addresses as invalid) but then adds some further complication…   something akin 
to CG-NAT but with their new EZ-IP protocol and “semi-public routers” as 
gateways doing the address mapping function. 

I am all for serious discussion of either of these interesting proposals, but 
if we’re going to seriously discuss such being deployed in the real-world then 
it had best start with the question of how they will handle the current 
Internet which frequently drops packets containing 240/4 addresses as invalid 
and will be doing so in places for many years to come.  The upgrades in the 
real world to address that invalid-drop situation will take quite a while to 
happen (and note that time starts only after there’s an actual consensus for 
change in this regard), so  – just as it was with IPv6 – it's incumbent on 
those proposing change to explain how interoperability occurs during the 
transition period. 

Thanks,
/John

p.s.   Disclaimer(s):  my views alone - this message made from 100% recycled 
electrons. 

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: 202211210951.AYC

[Joe Maimon]

Lincoln Dale wrote:
On Tue, Nov 22, 2022 at 11:20 AM Joe Maimon > wrote:


Indeed that is exactly what has been happening since the initial
proposals regarding 240/4. To the extent that it is now largely
supported or available across a wide variety of gear, much of it not
even modern in any way.


As someone who has been involved in the deployment of network gear 
into class E space (extensively, for our own internal reasons, which 
doesn't preclude public use of class E), "largely supported" != 
"universally supported".


There remains hardware devices that blackhole class E traffic, for 
which there is no fix. https://seclists.org/nanog/2021/Nov/272 is 
where I list one of them. There are many, many other devices where we 
have seen interesting behavior, some of which has been fixed, some of 
which has not.



cheers,

lincoln.




And I am sure you would agree that un-reserving a decade ago would have 
more than likely resulted in a greatly improved situation now. Along the 
lines that doing so now could still result in a greatly improved 
situation a decade hence. Should we still need it.


Joe

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

[Joe Maimon]

Eric Kuhnke wrote:

Assume the following theoretical scenario:

You have a large number of existing RIPE, ARIN, APNIC ASes which will 
take any ipv4 resources they can get. They're all on waiting lists or 
have been informed no new blocks will be forthcoming.


240/4 is something like 256 million IPs.

Let's say that the global benevolent ipv4 dictator decides that each 
ISP, MNO or other waiting list entity gets a single /16, one time only.


That's 64,000 IPs per corporate entity. Not actually very large at all 
on the scale of regional mid sized operators with 300,000 last mile 
broadband subscribers, or mobile network operators, nevermind 
top-10-size DOCSIS3/GPON/DSL last mile operators that have many dozens 
of millions of customers. One /16 is a tiny drop in the bucket 
compared to the demand for IP space for indivudual-customer DHCP pool 
usage by an ISP the size of Astound or a South Korean GPON operator or 
similar.


That's 4000 entities which each get their one time /16 and then 240/4 
is entirely exhausted.


Unrealistic?  Halve it so that each network operator waiting for IP 
space reources gets one/ 17, one time only, I would still bet good 
money that there's 8000 ASes out there that right now would happily 
take their "free "single /17 , and you'd still have immediate complete 
exhaustion of 240/8.



Right now the IPv4 scarcity is a barrier of entry to new entities and a 
major speedbump in basic growth to small entities.


So my constraint has much wider, lasting and meaningful impact than 
either of your thought exercises which essentially involve how to enable 
existing entities to resume business as usual for some amount of time. I 
am sure there many other much more meaningful ways to consider using 
240/4 than that.


New IPv4 resources to go towards addressing customers in the same 
fashion as was done ten years ago, I wouldn't bother with 240/4 for that 
either.


Best,

Joe

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

[Joe Maimon]

John Curran wrote:



On Nov 21, 2022, at 7:18 PM, Joe Maimon  wrote:
… Further, presentment of options in this fashion presumes that we 
have some ability to control or decide how engineering efforts across 
the entirety of the internet should be spent.


Joe -

In the snippet above you allude to a very important aspect of the 
Internet that is rather germane to this discussion – ii.e. that we 
really don’t really have any "ability to control or decide how 
engineering efforts across the entirety of the internet should be 
spent” –, but then you don’t really work through what that fact means 
for realistic outcomes of class E space re-utilization…



True



As you alluded to, we really don’t have any "ability to control or 
decide how engineering efforts across the entirety of the internet 
should be spent”, and the practical implications of this fact is that 
there will always be many devices out there in production that will 
not pass IP packets with class E addresses in them…   (just as there’s 
always going to be some devices, somewhere that don’t know about IPv6.)
To what extent will this be? And to what extent could it have been had 
this been seriously considered dozen+ years ago? We wont really know 
until we can get serious about it.


Of course, the difference is that with IPv6 we can attempt a 
connection and then fall back to IPv4, and further that devices out 
there either support and are configured for IPv6 routing, or they are 
not - networks rather quickly learn not to announce (via routing & 
DNS) IPv6 connectivity for devices without it actually being in place 
and operational or having solid IPv4 fall-back and relying fast 
fallback/happy eyeballs.


This is a very fair point. Or perhaps we can have reverse happy eyeballs 
for IPv4 fallling back to sub-optimal auto-tunneled IPv6?


With your using repurposed class E address space in the headers, your 
customers with such addresses are rather unlikely to ever know why a 
connection won’t establish – or why existing connections sometime fail 
mid-stream – as it only takes a single non-conforming device along the 
ever-changing path through any number of network operators to 
resulting in the silent drop of that packet.


I am not that sure about silent, presumably traceroute will be just as 
(un)usable.


That may (or may not) lead to you experiencing what you consider 
reasonable support costs for your customers, but as we all know, 
everyone else has customers who are the other ends of those 
connections who will call their ISP’s customer support line trying to 
figure out why they can’t get your customer (or can only get there 
intermittently) – so it appears that your proposed use of de-reserved 
and repurposed class E space has some real interesting implications 
about imputed support burdens on everyone else – if indeed the 
intended use case is includes providing connectivity to the public 
Internet.


If you’re not proposing public Internet use, and rather just within 
your own administrative domain, then feel free to do – talk to your 
vendors, get them to support it, and turn it on. As you already noted, 
we really don’t centrally decide how everyone runs their own network – 
so using it locally is fine since it doesn’t presume others will 
diagnose connection problems with your customer traffic that quite 
reasonably is categorized as invalid.


Thanks,
/John

p.s. Disclaimer:  my views alone. Note: contents may be hot - use 
caution when opening.





Right now the gossiped growing use of 240/4 in private and non 
standardized fashions jeopardizes any potential use of it just as much 
as the factors you describe.


In either event, my main point of contention is in the lack of 
willingness for serious and prudent consideration. Such as along the 
lines of what you have brought up.


So thank you.

Best,

Joe

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

[Abraham Y. Chen]

Dear Eric:

1)  " ... expecting the vast amount of legacy ipv4-only equipment out 
there in the world that is 10, 15, 20 years old to magically become 
compatible with the use of 240/4 in the global routing table ... ":    
It is apparent that you do not recognize a few unorthodox EzIP 
characteristics. For example:


   A. The activation of 240/4 netblocks is very scalable. It can be as 
small as starting from a residential home as evidenced by our initial 
realization of this technique via expanding the address pool by 256 
folds utilizing 192.168.K/24, or as big as or even multiple of 100.64/4 
netblocks that have been deployed all over the places for CG-NAT.


  B. Since the enhancement to use 240/4 is from the last-mile equipment 
and up, equipment capable of the program change can be enhanced without 
coordinating with any router nearby. In fact, they can continue to 
communicate through the originally established setup. This is a 
selective incremental process. There is no requirement to upgrade them 
all at the same time, such as what happened to IPv6. (I hope that you 
would not tell me that the routers whose programs were modified to 
handle the 100.64/4 netblocks for CG-NAT operation only about one decade 
ago are now too old to accept 240/4.)


  C. Once a router is enhanced to use 240/4, its original capability 
set continues with the addition of end-to-end connectivity within an 
area served by that router. No other routers would know about this change.


  D. This gives incentives to other regions to upgrade at their own 
paces, respectively. Note that we are talking about a generic program 
enhancement which can be downloaded to routers of the same model series 
through maintenance update cycles. So, we should not be discouraged by 
counting how many total routers are out there.


  E. Since the first phase of the EzIP deployment is to enhance CG-NAT, 
there is no expansion of global routing table.


2) "... directly analogous to building sand castles on the beach when 
the tide is obviously coming in. ":  This is the same as "the train has 
left the station" metaphor that we were told when we first started to 
look into this issue. So, we decided that our work was just for academic 
fun. As time went on, however, we learned that the Dual-Stack 
configuration was not just necessary but also going to last for a long 
time. Recently, we even heard (see the APNIC blog below as an example) 
that the IPv4 to IP6 transition may never end. So, I believe that it 
would be prudent for everyone to focus on improving his/her preferred 
version. There is no more reason to waste energy in discrediting the 
other camp's efforts.


The transition to IPv6: Are we there yet?

https://blog.apnic.net/2022/05/04/the-transition-to-ipv6-are-we-there-yet/

3)  " ... Trying to extend the use of ipv4 space resources for a few 
more years ...  ":  Unlike other proposals that we are aware of, EzIP is 
an enhancement to RF6598 which applies to CG-NAT that is a hierarchical 
network. Following such a configuration, the manageable public IPv4 pool 
is extended to roughly 983MB addresses (see the last paragraph of 
Sub-Section 2.1 in the EzIP Draft). Administrated in the traditional 
communication system identification discipline and supplemented by 
RFC1918 netblocks, this resources can last for a really long time.



Regards,


Abe (2022-11-21 22:59 EST)



On 2022-11-21 17:04, Eric Kuhnke wrote:
Quite simply, expecting the vast amount of legacy ipv4-only equipment 
out there in the world that is 10, 15, 20 years old to magically 
become compatible with the use of 240/4 in the global routing table is 
a non viable solution. It is not a financial reality for many small to 
medium sized ISPs in lower income countries.


The amount of time and effort that would be required to implement your 
proposal is much better spent on ipv6 implementation and various forms 
of improved cgnat.


Trying to extend the use of ipv4 space resources for a few more years 
is directly analogous to building sand castles on the beach when the 
tide is obviously coming in.





On Mon, 21 Nov 2022 at 07:29, Abraham Y. Chen  wrote:

Dear Eric:

0) Your opinion by itself is very valid and much appreciate.
However, it
is from a very remotely related perspective. That is, you are
looking at
the financial disadvantage of the less developed regions. What I am
talking about is the generic issue of communication system address
management that applies across the board. This subject is normally
designed by system planners. The result is given to the product
development engineers who usually do not have enough knowledge to
question it.

1)  The IPv4 address pool depletion issue was caused by the poor
"resources management" concepts. In this case, the insistence on the
Internet addressing should be flat (instead of hierarchical) led
to the
quick depletion of the finite sized 32-bit pool. The f

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

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

[Lincoln Dale]

On Tue, Nov 22, 2022 at 11:20 AM Joe Maimon  wrote:

> Indeed that is exactly what has been happening since the initial
> proposals regarding 240/4. To the extent that it is now largely
> supported or available across a wide variety of gear, much of it not
> even modern in any way.
>

As someone who has been involved in the deployment of network gear into
class E space (extensively, for our own internal reasons, which doesn't
preclude public use of class E), "largely supported" != "universally
supported".

There remains hardware devices that blackhole class E traffic, for which
there is no fix. https://seclists.org/nanog/2021/Nov/272 is where I list
one of them. There are many, many other devices where we have seen
interesting behavior, some of which has been fixed, some of which has not.


cheers,

lincoln.

>
>

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

[John Curran]

> On Nov 21, 2022, at 7:18 PM, Joe Maimon  wrote:
> … Further, presentment of options in this fashion presumes that we have some 
> ability to control or decide how engineering efforts across the entirety of 
> the internet should be spent.

Joe - 

In the snippet above you allude to a very important aspect of the Internet that 
is rather germane to this discussion – ii.e. that we really don’t really have 
any "ability to control or decide how engineering efforts across the entirety 
of the internet should be spent” –, but then you don’t really work through what 
that fact means for realistic outcomes of class E space re-utilization…

First, I want to be really clear:  I don’t particular care one way or the other 
regarding the proposal to “de-reserve” 240/4… I don't run a network (nor has 
the ARIN community discussed the matter and directed that ARIN take a position 
either way.)  However, I do think the operator community should be thinking 
hard about how such de-reserving and redefinition into general purpose space 
will impact the Internet operations community and whether such space can 
realistically ever be utilized in production manner in the public Internet. 

As you alluded to, we really don’t have any "ability to control or decide how 
engineering efforts across the entirety of the internet should be spent”, and 
the practical implications of this fact is that there will always be many 
devices out there in production that will not pass IP packets with class E 
addresses in them…   (just as there’s always going to be some devices, 
somewhere that don’t know about IPv6.)

Of course, the difference is that with IPv6 we can attempt a connection and 
then fall back to IPv4, and further that devices out there either support and 
are configured for IPv6 routing, or they are not - networks rather quickly 
learn not to announce (via routing & DNS) IPv6 connectivity for devices without 
it actually being in place and operational or having solid IPv4 fall-back and 
relying fast fallback/happy eyeballs. 

With your using repurposed class E address space in the headers, your customers 
with such addresses are rather unlikely to ever know why a connection won’t 
establish – or why existing connections sometime fail mid-stream – as it only 
takes a single non-conforming device along the ever-changing path through any 
number of network operators to resulting in the silent drop of that packet.  
That may (or may not) lead to you experiencing what you consider reasonable 
support costs for your customers, but as we all know, everyone else has 
customers who are the other ends of those connections who will call their ISP’s 
customer support line trying to figure out why they can’t get your customer (or 
can only get there intermittently) – so it appears that your proposed use of 
de-reserved and repurposed class E space has some real interesting implications 
about imputed support burdens on everyone else – if indeed the intended use 
case is includes providing connectivity to the public Internet.   

If you’re not proposing public Internet use, and rather just within your own 
administrative domain, then feel free to do – talk to your vendors, get them to 
support it, and turn it on.   As you already noted, we really don’t centrally 
decide how everyone runs their own network – so using it locally is fine since 
it doesn’t presume others will diagnose connection problems with your customer 
traffic that quite reasonably is categorized as invalid. 

Thanks,
/John

p.s. Disclaimer:  my views alone. Note: contents may be hot - use caution when 
opening. 

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

[Jay Hennigan]

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 - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

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

[Eric Kuhnke]

Assume the following theoretical scenario:

You have a large number of existing RIPE, ARIN, APNIC ASes which will take
any ipv4 resources they can get. They're all on waiting lists or have been
informed no new blocks will be forthcoming.

240/4 is something like 256 million IPs.

Let's say that the global benevolent ipv4 dictator decides that each ISP,
MNO or other waiting list entity gets a single /16, one time only.

That's 64,000 IPs per corporate entity. Not actually very large at all on
the scale of regional mid sized operators with 300,000 last mile broadband
subscribers, or mobile network operators, nevermind top-10-size
DOCSIS3/GPON/DSL last mile operators that have many dozens of millions of
customers. One /16 is a tiny drop in the bucket compared to the demand for
IP space for indivudual-customer DHCP pool usage by an ISP the size of
Astound or a South Korean GPON operator or similar.

That's 4000 entities which each get their one time /16 and then 240/4 is
entirely exhausted.

Unrealistic?  Halve it so that each network operator waiting for IP space
reources gets one/ 17, one time only, I would still bet good money that
there's 8000 ASes out there that right now would happily take their "free
"single /17 , and you'd still have immediate complete exhaustion of 240/8.







On Mon, 21 Nov 2022 at 16:33, Joe Maimon  wrote:

>
>
> Eric Kuhnke wrote:
> > In a theoretical scenario where somebody was global benevolent
> > dictator of ipv4 space, even applying a policy which limited block
> > size to a few /14 per ISP, it would be possible to exhaust 240/4/in
> > one week/ if they handed out /14 sized pieces to every existing last
> > mile LTE network operator with 5+ million customers globally. It is
> > not a long term solution or even a good medium term solution.
> >
> To to the LM LTE Operator with 5+ mill. customer globally, it is not.
> Agreed. Also, I think they have already sorted themselves out
> sufficiently in a variety of ways. I am not concerned with them, at all.
>
> Which is why I did not offer that as an example of useful constraint.
> Re-run your projections with what I actually discussed, I think you will
> have a different conclusion.
>
> Joe
>

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

[John Curran]

On Nov 21, 2022, at 7:18 PM, Joe Maimon  wrote:
...
It’s only taking that long because of this attitude.

Of course, Joe, that attitude might also be cited of IPv6 deployment laggards!  
;-)  i.e., the mumbling of those in the periphery of Internet regarding why 
they’re not doing IPv6...

(It's not an issue for those closer to high-growth areas – e.g.  mobile and 
consumer broadband – as IPv6 has become the default with many of them for their 
new connections –  
 )

FYI,
/John

John Curran
President and CEO
American Registry for Internet Numbers

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

[Joe Maimon]

Eric Kuhnke wrote:
In a theoretical scenario where somebody was global benevolent 
dictator of ipv4 space, even applying a policy which limited block 
size to a few /14 per ISP, it would be possible to exhaust 240/4/in 
one week/ if they handed out /14 sized pieces to every existing last 
mile LTE network operator with 5+ million customers globally. It is 
not a long term solution or even a good medium term solution.


To to the LM LTE Operator with 5+ mill. customer globally, it is not. 
Agreed. Also, I think they have already sorted themselves out 
sufficiently in a variety of ways. I am not concerned with them, at all.


Which is why I did not offer that as an example of useful constraint. 
Re-run your projections with what I actually discussed, I think you will 
have a different conclusion.


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

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: 202211210951.AYC

[Eric Kuhnke]

In a theoretical scenario where somebody was global benevolent dictator of
ipv4 space, even applying a policy which limited block size to a few /14
per ISP, it would be possible to exhaust 240/4* in one week* if they handed
out /14 sized pieces to every existing last mile LTE network operator with
5+ million customers globally. It is not a long term solution or even a
good medium term solution.

On Mon, 21 Nov 2022 at 16:19, Joe Maimon  wrote:

> Eric,
>
> I appreciate your willingness to actual consider this rationally.
>
> Every facet of this debate has been fully aired on this forum (and
> others), numerous times.
>
> Allow me to pick it apart again. Apologies to those who are ad nausem.
>
> Eric Kuhnke wrote:
> > Option A) Spend engineering time and equipment purchases to implement
> > 240/4 as unicast globally. At present consumption rates and based on
> > the number of entities in ARIN, RIPE, APNIC regions that could
> > *immediately* take /18 to /16 sized blocks of it, please quantify
> > exactly how many years this amount of "new" IP space you predict to be
> > useful before once again reaching ipv4 exhaustion. End result: Problem
> > not solved. Thus my analogy of building a sand castle while the tide
> > is coming in.
> >
> > Option B) Spend engineering time and equipment purchases (yes, very
> > possibly much more time and more costly) to implement ipv6.
>
> This is know a false dichotomy. There is no actual reason to believe
> that any effort on option A detracts from available effort of option B.
> And when you purchase your new gear, or update the software, with its
> many many lines of code changes, it is not unreasonable to expect that
> at least some might be IPv4 related and that the removal of restriction
> on 240/4 would be the more trivial of those.
>
> Indeed that is exactly what has been happening since the initial
> proposals regarding 240/4. To the extent that it is now largely
> supported or available across a wide variety of gear, much of it not
> even modern in any way.
>
> Further, presentment of options in this fashion presumes that we have
> some ability to control or decide how engineering efforts across the
> entirety of the internet should be spent.
>
> Respectively, amusing and alarming.
>
> To be clear, the only thing preventing the Internet in freely organizing
> its own efforts is the unwillingness of curmudgeons to remove the
> reserved status in this particular instance.
>
> As no-one is requesting that you (or others of this persuasion) lend
> their personal efforts, your concern on the budgeting of efforts is out
> of place and worse, of dictatorial bend.
>
> For the sake of argument, ignoring above, presuming our control over the
> internet engineering efforts et al.
>
> Were I to propose to you that 240/4 be utilized only for new or existing
> organizations with less than /20 total resources or some other useful
> constraint, it would be easy to see that 240/4 would last a very long
> time and potentially have quite a significant impact.
>
> Earlier in this thread I contrasted a reduction from 12 to 1 of ip
> address consumption per new customer, depending on the practices
> employed by the service provider. As you can see, consumption rate is
> actually quite flexible, even now, today.
>
> So the answer to your question is it depends how freely it is handed
> out. Certainly not very long if it is business as usual prior to runout.
> Potentially much longer if not.
>
> And in a nod to your concern over effort expenditure, but even more so,
> conscious of 240/4 being the 32bit space last big easy gasp, I would be
> a strong proponent that it NOT be.
>
> However, even if it were, what exactly are we saving it for, if not for
> use by those who need it?
>
> Or is it to be a hedge over some eventuality where IPv6 has failed to
> the point of abandonment? I might actually respect that position, even
> as I doubt (and fear and hope against) such an eventualities actual
> occurrence.
>
> The more galling aspect of the 240/4 wars is that "it will take too long
> and then Ipv6 will be deployed" crowd that managed to stifle it
> initially continue to reuse that line again, in essence blase self
> perpetuation.
>
> Its only taking that long because of this attitude.
>
> Joe
>
>
>

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

[Joe Maimon]

Eric,

I appreciate your willingness to actual consider this rationally.

Every facet of this debate has been fully aired on this forum (and 
others), numerous times.


Allow me to pick it apart again. Apologies to those who are ad nausem.

Eric Kuhnke wrote:
Option A) Spend engineering time and equipment purchases to implement 
240/4 as unicast globally. At present consumption rates and based on 
the number of entities in ARIN, RIPE, APNIC regions that could 
*immediately* take /18 to /16 sized blocks of it, please quantify 
exactly how many years this amount of "new" IP space you predict to be 
useful before once again reaching ipv4 exhaustion. End result: Problem 
not solved. Thus my analogy of building a sand castle while the tide 
is coming in.


Option B) Spend engineering time and equipment purchases (yes, very 
possibly much more time and more costly) to implement ipv6.


This is know a false dichotomy. There is no actual reason to believe 
that any effort on option A detracts from available effort of option B. 
And when you purchase your new gear, or update the software, with its 
many many lines of code changes, it is not unreasonable to expect that 
at least some might be IPv4 related and that the removal of restriction 
on 240/4 would be the more trivial of those.


Indeed that is exactly what has been happening since the initial 
proposals regarding 240/4. To the extent that it is now largely 
supported or available across a wide variety of gear, much of it not 
even modern in any way.


Further, presentment of options in this fashion presumes that we have 
some ability to control or decide how engineering efforts across the 
entirety of the internet should be spent.


Respectively, amusing and alarming.

To be clear, the only thing preventing the Internet in freely organizing 
its own efforts is the unwillingness of curmudgeons to remove the 
reserved status in this particular instance.


As no-one is requesting that you (or others of this persuasion) lend 
their personal efforts, your concern on the budgeting of efforts is out 
of place and worse, of dictatorial bend.


For the sake of argument, ignoring above, presuming our control over the 
internet engineering efforts et al.


Were I to propose to you that 240/4 be utilized only for new or existing 
organizations with less than /20 total resources or some other useful 
constraint, it would be easy to see that 240/4 would last a very long 
time and potentially have quite a significant impact.


Earlier in this thread I contrasted a reduction from 12 to 1 of ip 
address consumption per new customer, depending on the practices 
employed by the service provider. As you can see, consumption rate is 
actually quite flexible, even now, today.


So the answer to your question is it depends how freely it is handed 
out. Certainly not very long if it is business as usual prior to runout. 
Potentially much longer if not.


And in a nod to your concern over effort expenditure, but even more so, 
conscious of 240/4 being the 32bit space last big easy gasp, I would be 
a strong proponent that it NOT be.


However, even if it were, what exactly are we saving it for, if not for 
use by those who need it?


Or is it to be a hedge over some eventuality where IPv6 has failed to 
the point of abandonment? I might actually respect that position, even 
as I doubt (and fear and hope against) such an eventualities actual 
occurrence.


The more galling aspect of the 240/4 wars is that "it will take too long 
and then Ipv6 will be deployed" crowd that managed to stifle it 
initially continue to reuse that line again, in essence blase self 
perpetuation.


Its only taking that long because of this attitude.

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

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

[Tom Beecher]

This is basically exactly what has come out of the IETF for this and
similar ideas.

I doubt it will ever stop them from being put forth though.

On Mon, Nov 21, 2022 at 6:39 PM Eric Kuhnke  wrote:

> Option A) Spend engineering time and equipment purchases to implement
> 240/4 as unicast globally. At present consumption rates and based on the
> number of entities in ARIN, RIPE, APNIC regions that could *immediately*
> take /18 to /16 sized blocks of it, please quantify exactly how many years
> this amount of "new" IP space you predict to be useful before once again
> reaching ipv4 exhaustion. End result: Problem not solved. Thus my analogy
> of building a sand castle while the tide is coming in.
>
> Option B) Spend engineering time and equipment purchases (yes, very
> possibly much more time and more costly) to implement ipv6.
>
>
> Even if option B is much more costly and time consuming, the end result
> will be much better.
>
>
>
> On Mon, 21 Nov 2022 at 14:48, Joe Maimon  wrote:
>
>>
>>
>> Eric Kuhnke wrote:
>> > Quite simply, expecting the vast amount of legacy ipv4-only equipment
>> > out there in the world that is 10, 15, 20 years old to magically
>> > become compatible with the use of 240/4 in the global routing table is
>> > a non viable solution. It is not a financial reality for many small to
>> > medium sized ISPs in lower income countries.
>> >
>> > The amount of time and effort that would be required to implement your
>> > proposal is much better spent on ipv6 implementation and various forms
>> > of improved cgnat.
>>
>> In specific focus on 240/4
>>
>> Simultaneously claiming that enabling 240/4 as unicast involves
>> difficulty that in comparison makes IPv6 (and then you add in CGNAT!)
>> somehow more achievable is ridiculous.
>>
>> Regardless of the exact scenario.
>>
>> Joe
>>
>>
>>

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

[Tom Beecher]

>
> 1)  As requested, please be specific and speak only for yourself. So
> that we can carry on a professional dialog meaningfully.
>

I will start by citing one of my own responses to you :

https://mailman.nanog.org/pipermail/nanog/2022-March/218291.html

I do not leave a loose end to any  technical
> discussion with substance.
>

With the utmost amount of respect, you do.

Many people on this list have provided specific , technical issues with
your proposal. Others have commented on non-technical, but practical
considerations. In all cases, you have simply handwaved them away or not
commented on them further.



On Mon, Nov 21, 2022 at 5:16 PM Abraham Y. Chen  wrote:

> Dear Tom:
>
> 1)  As requested, please be specific and speak only for yourself. So
> that we can carry on a professional dialog meaningfully.
>
> 2) Hint: I signed up to NANOG.org only early this year. So, whatever you
> have in mind might be from somewhere else. In addition, even though I do
> not have good memory, I do not leave a loose end to any  technical
> discussion with substance. The revisions of the EzIP documentation have
> always been improving the presentation style for easing the reader's
> efforts, not about modifying our basic scheme. So, you need to be clear
> about the topics that you are referring to. Thanks.
>
> Regards,
>
>
> Abe (2022-11-21 17:16 EST)
>
>
>
> On 2022-11-21 13:23, Tom Beecher wrote:
> >
> > 1) "... for various technical reasons , ...":  Please give a couple
> > examples, and be specific preferably using expressions that
> colleagues
> > on this forum can understand.
> >
> >
> > Myself and multiple others provided specific technical rebuttals to
> > the proposal in the past on this list.
> >
> >
> >
> > On Mon, Nov 21, 2022 at 12:29 PM Abraham Y. Chen 
> > wrote:
> >
> > Dear Tom:
> >
> > 1) "... for various technical reasons , ...":  Please give a couple
> > examples, and be specific preferably using expressions that
> > colleagues
> > on this forum can understand.
> >
> > Thanks,
> >
> >
> > Abe (2022-11-21 12:29 EST)
> >
> >
> >
> >
> > On 2022-11-21 10:44, Tom Beecher wrote:
> > >
> > > 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
> > 
> > > 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
> >  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 ma

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

[Eric Kuhnke]

Option A) Spend engineering time and equipment purchases to implement 240/4
as unicast globally. At present consumption rates and based on the number
of entities in ARIN, RIPE, APNIC regions that could *immediately* take /18
to /16 sized blocks of it, please quantify exactly how many years this
amount of "new" IP space you predict to be useful before once again
reaching ipv4 exhaustion. End result: Problem not solved. Thus my analogy
of building a sand castle while the tide is coming in.

Option B) Spend engineering time and equipment purchases (yes, very
possibly much more time and more costly) to implement ipv6.


Even if option B is much more costly and time consuming, the end result
will be much better.



On Mon, 21 Nov 2022 at 14:48, Joe Maimon  wrote:

>
>
> Eric Kuhnke wrote:
> > Quite simply, expecting the vast amount of legacy ipv4-only equipment
> > out there in the world that is 10, 15, 20 years old to magically
> > become compatible with the use of 240/4 in the global routing table is
> > a non viable solution. It is not a financial reality for many small to
> > medium sized ISPs in lower income countries.
> >
> > The amount of time and effort that would be required to implement your
> > proposal is much better spent on ipv6 implementation and various forms
> > of improved cgnat.
>
> In specific focus on 240/4
>
> Simultaneously claiming that enabling 240/4 as unicast involves
> difficulty that in comparison makes IPv6 (and then you add in CGNAT!)
> somehow more achievable is ridiculous.
>
> Regardless of the exact scenario.
>
> Joe
>
>
>

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

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: 202211210951.AYC

[Joe Maimon]

Eric Kuhnke wrote:
Quite simply, expecting the vast amount of legacy ipv4-only equipment 
out there in the world that is 10, 15, 20 years old to magically 
become compatible with the use of 240/4 in the global routing table is 
a non viable solution. It is not a financial reality for many small to 
medium sized ISPs in lower income countries.


The amount of time and effort that would be required to implement your 
proposal is much better spent on ipv6 implementation and various forms 
of improved cgnat.


In specific focus on 240/4

Simultaneously claiming that enabling 240/4 as unicast involves 
difficulty that in comparison makes IPv6 (and then you add in CGNAT!) 
somehow more achievable is ridiculous.


Regardless of the exact scenario.

Joe

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

[Abraham Y. Chen]

Dear Tom:

1)  As requested, please be specific and speak only for yourself. So 
that we can carry on a professional dialog meaningfully.


2) Hint: I signed up to NANOG.org only early this year. So, whatever you 
have in mind might be from somewhere else. In addition, even though I do 
not have good memory, I do not leave a loose end to any  technical 
discussion with substance. The revisions of the EzIP documentation have 
always been improving the presentation style for easing the reader's 
efforts, not about modifying our basic scheme. So, you need to be clear 
about the topics that you are referring to. Thanks.


Regards,


Abe (2022-11-21 17:16 EST)



On 2022-11-21 13:23, Tom Beecher wrote:


1) "... for various technical reasons , ...":  Please give a couple
examples, and be specific preferably using expressions that colleagues
on this forum can understand.


Myself and multiple others provided specific technical rebuttals to 
the proposal in the past on this list.




On Mon, Nov 21, 2022 at 12:29 PM Abraham Y. Chen  
wrote:


Dear Tom:

1) "... for various technical reasons , ...":  Please give a couple
examples, and be specific preferably using expressions that
colleagues
on this forum can understand.

Thanks,


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




On 2022-11-21 10:44, Tom Beecher wrote:
>
>     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

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

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

[Eric Kuhnke]

Quite simply, expecting the vast amount of legacy ipv4-only equipment out
there in the world that is 10, 15, 20 years old to magically become
compatible with the use of 240/4 in the global routing table is a non
viable solution. It is not a financial reality for many small to medium
sized ISPs in lower income countries.

The amount of time and effort that would be required to implement your
proposal is much better spent on ipv6 implementation and various forms of
improved cgnat.

Trying to extend the use of ipv4 space resources for a few more years is
directly analogous to building sand castles on the beach when the tide is
obviously coming in.




On Mon, 21 Nov 2022 at 07:29, Abraham Y. Chen  wrote:

> Dear Eric:
>
> 0) Your opinion by itself is very valid and much appreciate. However, it
> is from a very remotely related perspective. That is, you are looking at
> the financial disadvantage of the less developed regions. What I am
> talking about is the generic issue of communication system address
> management that applies across the board. This subject is normally
> designed by system planners. The result is given to the product
> development engineers who usually do not have enough knowledge to
> question it.
>
> 1)  The IPv4 address pool depletion issue was caused by the poor
> "resources management" concepts. In this case, the insistence on the
> Internet addressing should be flat (instead of hierarchical) led to the
> quick depletion of the finite sized 32-bit pool. The fact is that the
> current prevalent CDN (Content Delivery Network) business model based on
> CG-NAT configuration is a clear hierarchical network, anyway. All what
> EzIP proposes is to make it explicit and universal for improving the
> performance.
>
> 2)  To create a viable hierarchical network with depleted address pool
> like IPv4 was practically an impossible task. Fortunately, the 240/4
> netblock is available because it was "reserved for future use" ever
> since 1981-09, yet no clear application cases could be found. So, this
> is a natural resources that will benefit everyone without reference to
> financial status, although the developing regions can benefit more by
> utilizing it to leap frog out of the current disadvantaged situations.
>
> Hope this explanation makes sense to you.
>
>
> Regards,
>
>
> Abe (2022-11-21 10:29 EST)
>
>
>
>
> On 2022-11-20 17:56, Eric Kuhnke wrote:
> > 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  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
>

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

[Tom Beecher]

>
> 1) "... for various technical reasons , ...":  Please give a couple
> examples, and be specific preferably using expressions that colleagues
> on this forum can understand.
>

Myself and multiple others provided specific technical rebuttals to the
proposal in the past on this list.



On Mon, Nov 21, 2022 at 12:29 PM Abraham Y. Chen  wrote:

> Dear Tom:
>
> 1) "... for various technical reasons , ...":  Please give a couple
> examples, and be specific preferably using expressions that colleagues
> on this forum can understand.
>
> Thanks,
>
>
> Abe (2022-11-21 12:29 EST)
>
>
>
>
> On 2022-11-21 10:44, Tom Beecher wrote:
> >
> > 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 
> > 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 
> 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 
> >
>
>

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: 202211211223.AYC

[Abraham Y. Chen]

Dear Tom:

1) "... for various technical reasons , ...":  Please give a couple 
examples, and be specific preferably using expressions that colleagues 
on this forum can understand.


Thanks,


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




On 2022-11-21 10:44, Tom Beecher wrote:


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

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

[Tom Beecher]

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

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

[Abraham Y. Chen]

Dear Eric:

0) Your opinion by itself is very valid and much appreciate. However, it 
is from a very remotely related perspective. That is, you are looking at 
the financial disadvantage of the less developed regions. What I am 
talking about is the generic issue of communication system address 
management that applies across the board. This subject is normally 
designed by system planners. The result is given to the product 
development engineers who usually do not have enough knowledge to 
question it.


1)  The IPv4 address pool depletion issue was caused by the poor 
"resources management" concepts. In this case, the insistence on the 
Internet addressing should be flat (instead of hierarchical) led to the 
quick depletion of the finite sized 32-bit pool. The fact is that the 
current prevalent CDN (Content Delivery Network) business model based on 
CG-NAT configuration is a clear hierarchical network, anyway. All what 
EzIP proposes is to make it explicit and universal for improving the 
performance.


2)  To create a viable hierarchical network with depleted address pool 
like IPv4 was practically an impossible task. Fortunately, the 240/4 
netblock is available because it was "reserved for future use" ever 
since 1981-09, yet no clear application cases could be found. So, this 
is a natural resources that will benefit everyone without reference to 
financial status, although the developing regions can benefit more by 
utilizing it to leap frog out of the current disadvantaged situations.


Hope this explanation makes sense to you.


Regards,


Abe (2022-11-21 10:29 EST)




On 2022-11-20 17:56, Eric Kuhnke wrote:
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  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

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

[Abraham Y. Chen]

Dear Mathew:

0) Thanks for raising a very valid observation. Your line of reasoning 
and conclusion including the conundrum that IPv6 faces do conform with 
my understanding of the current Internet conventions and practices. 
However, this is only following the track that most people have been 
conditioned into. If one practices "think out of the box" while 
examining EzIP, as marketers frequently like to say, you may come to a 
totally different perspective. That is, if you do not mind to flip a few 
coins along the way, even though individually may seem insignificant by 
itself, the accumulated effect can change the story. Allow me to go 
through the analysis that helped us to solidify the EzIP plan.


1) What you identified was a serious hurdle that stumbled us for quite 
awhile after we initially worked out the scheme of making use of the 
long-reserved 240/4 netblock to expand the publicly assignable IPv4 
pool. It turned out that being a novice to the Internet, we tried too 
hard by trapping ourselves into literally attempting to achieve the 
end-to-end connectivity as well, immediately. By approaching the issue 
via the "Divide and Conquer" principle, the latest EzIP deployment 
strategy has been broken into two phases. The first is basic (obvious 
necessity) and straightforward. The second is optional (since it is more 
than the current Internet capable of) and requiring some efforts. 
However, both bypass the "top 50 websites" issue that you are concerned 
with. In a nutshell, they will never see EzIP, if they do not intend to 
be involved.


2)  The above is hard to visualize if you followed the bulk of the EzIP 
IETF Draft because its initial intent was to present the full EzIP 
technique and configuration for the long term which may not be 
universally needed based on our latest analysis. If you start reading 
the EzIP Draft from Appendix F and on that were added upon our 
realization of the above trade-off, you will get the sense that the "top 
50 websites" are not necessarily part of the considerations. This is 
because the RAN (Regional Area Network) which is architecturally the 
same as an existing CG-NAT "module" (pardon me for not knowing the 
correct terminology of an area served by a 100.64/10 netblock), but much 
(64 times) larger. Consequently, a RAN can be self-contained for all 
practical purposes and collectively behave as a Sub-Internet. That is, 
the port translation at the highest level of a CG-NAT module does not 
need be disturbed upon the address transition. Similarly, the "Revamp 
The Internet" whitepaper was written after we realized this two-phase 
approach. So, it focused only on phase one.


3)  The first phase of EzIP deployment will be only replacing the 
100.64/4 netblock of RFC6598 with the 240/4 netblock. This process can 
be achieved by just activating the use of the 240/4 netblock by the 
existing networking equipment. (This could be as simple as disabling one 
line of the code in a networking program that has been disabling the use 
of the 240/4 addresses.) The CG-NAT operations will not be perturbed. 
Since this transition will be confined within a RAN (replacing a few 
CG-NAT modules), the operation of distributed caching proxies used by 
the "top 50 websites" to support the CDN (Content Delivery Network) 
business configuration remain the same. So, the "top 50 websites" would 
not sense any changes due to EzIP deployment. One important benefit of 
this step is that static addresses may now be administrated to 
streamline daily operations that harden the defense against cyber 
intrusions.


4)  Once the above is done, there is a practical intermediate phase 
before attempting the worldwide end-to-end connectivity which has been 
elusive for the existing Internet. That is, since each RAN can be fairly 
large (Even without making use of private netblocks from RFC1918, each 
240/4 can serve an area with the population as big as Tokyo Metro or 
over 75% of smaller countries around the world.), subscribers within 
each RAN can begin to enjoy end-to-end connectivity such as direct eMail 
exchanges. This is equivalent to domestic postal mails and telephony 
calls which are what ordinary citizens would care about most of the 
time, anyway. At this phase, no new capability is offered across RAN 
boundaries. Current eMail facility (which is by store and forward 
anyway) and similar will continue for such needs.


5)  Next, if anyone really cares for exchange messages directly with 
someone remote (beyond the local RAN), the full EzIP header format will 
be utilized (Remember the dial-up modem supported direct PC connections 
via international phone calls over the worldwide PSTN?). Still, the "top 
50 websites" can continue their operations unaffected, unless they want 
to be more directly interacting with individuals in such activities.


6) Since the root of each RAN is connected to the Internet core via a 
public IPv4 address channel, the former can be regarded as a