> On Sep 11, 2021, at 23:23 , Steven Ryerse <[email protected]> 
> wrote:
> 
> In the 1970's when I was going to high school they told us we would run out 
> of oil by the end of the 1990's.  Maybe that was possible then - based on the 
> then known oil reserves - if no more reserves were found.  Its 2021 now and 
> we know we didn't run out of oil in the 90's, and in fact have found huge 
> amounts of new oil reserves around the world - that if used wisely will last 
> for a long time.  

Indeed… And due to existing uses, likely will outlast the habitability of the 
planet by mankind if we don’t change our uses.

> Now I assume there is still a limit on how much oil mankind can find on this 
> earth and we could eventually run out depending on how fast we use whatever 
> exists.  However, it is likely that we will never actually run out of oil, 
> because if it truly becomes scarce then the price will go up.  As time goes 
> on and as oil becomes more and more scarce, the price will keep going up and 
> up - until eventually the price will become so high and prohibitive that 
> mankind will turn to other cheaper sources of energy because of the super 
> high price that oil will cost then.  

A big part of the reason we haven’t run out yet and aren’t ripping through what 
we know exists is that we’ve developed the technology to synthesize 
petroleum-equivalent products from biomass. (e.g. biodiesel, synthetic motor 
oils, PLA, etc.)

> I'm not exactly sure what the price has to rise to before mankind switches to 
> other forms of energy.  I paid $75 to fill up my pickup truck today.  If it 
> cost $200 to fill your car/truck or $500 or $1000 or more - would that make 
> most of us switch to something else?  $200 maybe or maybe not - $500 or $1000 
> or more - probably most of us will switch to whatever cost less than the then 
> very high price of oil.  Certainly at $1000 or more per tank full of gas, the 
> buyers for oil would mostly disappear since they switched to using something 
> cheaper - and thus we never actually used up all of the oil reserves that 
> exists on the earth.  

I think the switch at this point will be driven (is being driven) not by 
economic costs of obtaining and consuming oil, but by the need to reduce carbon 
emissions if we wish to continue living on earth.

> So in real life we won't actually end up running out of oil.  Whatever 
> humankind switches to for energy will have to be manageable and accessible 
> just like oil has been.  It is still not clear what the particular energy 
> source will be that replaces oil.  

It’s pretty clear that it’s going to be a migration to electricity as a primary 
energy technology and a migration away from petroleum based sources for 
generating electricity towards a combination of renewables including solar, 
wind, probably some nuclear for the foreseeable future, and possibly some clean 
hydrogen based sources. Battery technologies are continuing to improve rapidly, 
increasing storage density, efficiency, and reliability (which is the main 
advantage in petro fuels over electricity, the easy high-density storage).

> So we have Ipv4 which is the energy currently running most of our internet.  
> IPv4 has a known total of IP addresses.  The reserves of unused IPv4 are 
> spread around the planet in an inefficient and uneven manner.  Every day more 
> and more IPv4 addresses are put to work running services on the Internet 
> which is slowly making them more scarce.  As the price rises over time per 
> IPv4 address on the open market, a lot of this inefficient and uneven spread 
> of IPv4 addresses will even out somewhat via the open market.  This will keep 
> the price reasonably low for awhile ($75 Per tank full) but as these IPv4 
> addresses become more scarce the price will slowly climb until the day comes 
> where they become very expensive by todays standards ($500 per tank full) and 
> at some point ($1000 per tank full or more) and the organizations wanting to 
> add more services to the Internet will look for a cheaper alternative.  

It truly depends on how you define most at this point… In terms of addresses 
deployed, IPv6 has surpassed IPv4 some years back. In terms of traffic mix, 
IPv6 exceeds 60% in many environments today. In terms of total content sites 
available, yes, IPv6 is still in the minority. In terms of eyeballs, IPv4 has 
more because there aren’t very many IPv6-only eyeballs yet, but the (admittedly 
slim) majority of eyeballs have IPv6 capabilities at this time.

> So it is likely that we may never actually run out of IPv4 addresses 
> (especially because of the uneven spread of them).  The cost per address as 
> it increases and becomes expensive and prohibitive will eventually drive 
> organizations that want to add even more services to the Internet, to look 
> for alternative IP energy to run those Internet services on.  The new IP 
> energy will have to be manageable and accessible just like IPv4 has been.  It 
> is still not clear what the particular IP energy source will be that replaces 
> IPv4. 

Arguably, we already have run out of IPv4 addresses, but unlike petrochemicals 
which are a consumption item, unless you’re a snow-shoe spammer, IPv4 addresses 
aren’t consumed in the process of usage. IPv4 addresses can continue to be used 
as long as there are hosts to put them on and they can continue to be moved 
around to different hosts using ever more painful and expensive ways to share 
them among multiple hosts.

> Certainly IPv6 is a leading possibility and it may end up actually being the 
> new IP energy that mankind embraces for future Internet services because it 
> has had a head start.  However, some smart engineer(s) somewhere working in a 
> garage (Steve Jobs and Steve Wozniak) may very well develop an IPv4 
> compatible protocol that can be used along with IPv4 making the transition 
> away from IPv4 easier and less costly - and if that happens maybe we end up 
> with IPv8.  

It’s not only the current leading possibility, it’s currently the only viable 
alternative on the table.

Before you buy into the idea of an IPv8, I suggest you research the name “Jim 
Flemming”.

In order to be IPv4-compatible, you need to find a way to put an address that 
can represent at least 32 billion unique host addresses into a 32-bit field.

NAT sort of pretends to do this by using some arbitrary fraction of the TCP/UDP 
Port numbers to effectively extend the address bits. The problem is that this 
ONLY works effectively with protocols that have ports or something like it and 
it fails miserably with lots of things that used to be convenient. It makes 
development and testing far more expensive and worse, the expectation that all 
end-user networks are structured in that particular way creates an environment 
where software developers make really bad choices based on that assumption. 

As a glaring example, Philips Hue assumes that they can identify hosts on the 
same network as one of their lighting control bridges by mapping the public IP 
address. They literally assume that all hosts on the same network share a 
single public IP address. This assumption (heavily baked into their code on 
both server and client side) leads to multiple problems:

        1.      They need an entirely different solution to cope with networks 
that don’t NAT, and thus
                they’ve avoided adding IPv6 capabilities to their product 
because it’s “hard”.

        2.      They break utterly in situations where the network has multiple 
public addresses,
                whether a lack of NAT (such as is my situation), or an 
environment where the
                NAT pool includes more than one address that could be selected 
at egress.

        3.      Everyone behind the same CGN is assumed to be in the same 
household. I’ll
                leave the consideration of the security implications of this 
particular gem as
                an exercise for the reader… Hint: NOT GOOD.

In short, lots of smart people have tried to figure out how to put 48 bits of 
data in a 32 bit field and so far, the results have been fairly universally 
“that doesn’t work.”.

Hence, we built an incompatible protocol with as much backwards-looking 
capability as made sense to put into it.

For example, an IPv6-only application can easily work in an IPv4-only, 
IPv6-only, or Dual-stack environment so long as it accepts (sane operating 
systems) or sets (BSD-based operating systems)
the socket option IPV6_V6ONLY=false.

At that point, the OS takes care of all the heavy lifting and IPv4 connections 
look to the application just like IPv6 connections, but the addresses are of 
the form ::ffff:aabb:ccdd where a, b, c, d are
the hexadecimal values of the octets in the IP address. In fact, in text 
representation, most OS’s present these as ::ffff:192.0.2.1 for reader 
convenience. Inside the system, of course, it’s still just
a string of 128 0s and 1s. The conversion to hex or any other format is just 
that, a display convenience.

> Frequently what I read in this forum from some members makes me feel like I 
> am back in high school being told we will run out of IPv4 (oil) very soon.  
> As we approached "Exhaustion" there was a steady drumbeat of various members 
> wanting to update policies to somehow "save" IPv4 from running out. Some 
> policies were changed to try and slow the run out but we still reached the 
> point of "Exhaustion" (end of the 1990's) and its now 2021 and guess what - 
> we haven't run out of IPv4.  This was easily predictable and some members 
> shared exactly this perspective in this forum and were largely ignored for a 
> long time.  Now the free market has taken over like it ALWAYS does and the 
> reserves of IPv4 that were always there - have been slowly coming to market 
> in one way or another as the scarcity of IPv4 is slowly increasing. This will 
> continue and the price of IPv4 (oil) will slowly rise.  I suspect just like 
> the oil predictions in the 70's, IPv4 may still have a long way to go before 
> it is replaced with a new IP energy (2030's?, 2040's?, 2050's? or possibly 
> later?). The other possibility of new Internet energy happening sooner is a 
> killer Internet app that eats up IPv4 addresses so fast that the cost per 
> address rises much faster than it is doing now.  VisiCalc and then Word 
> Perfect were the killer apps that cemented PC usage throughout corporate 
> America, Microsoft Exchange was the Killer app that cemented Microsoft 
> Windows Server as the de facto server standard for corporate America, and so 
> on.  

Yes, this is still commonplace in AFRINIC as a matter of fact. There’s a large 
faction that does not understand that keeping addresses on the shelf in the 
registry doesn’t extend the viability of IPv4, it just preserves the duration 
of the free pool creating the illusion of longevity while actually creating an 
artificially early runout because those who need addresses are not able to get 
them.

> This is why I have always advocated for furthering the Internet by making it 
> reasonably easy and inexpensive for organizations to get IPv4 resources, 
> especially small organizations.  My policy proposal several years ago to 
> allow any organization in the ARIN region to easily get a /24 was shot down - 
> or at least not supported by the members of this community and forum.  For 
> those that think we should have switched to IPv6 (new energy) by now, 
> "saving" the Internet from "Exhaustion" has actually had the opposite effect 
> of delaying the day that IPv6 might take over as the new Internet energy. So 
> not supporting my policy proposal to make /24 easy to get (we should still do 
> it) as well as not supporting other members that promoted reasonable easier 
> access to IPv4 resources have had the effect of delaying the day IPv6 might 
> take over as the Internet energy.  Should we really have a limit on the size 
> of an IPv4 block that ARIN can assign if the need can be demonstrated?  

Agreed. While I didn’t support that particular proposal, it wasn’t to preserve 
IPv4 in the free pool, it was because I felt it had other flaws that would lead 
to fraud.

Owen

_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.

Reply via email to