<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Pretty sure Bill is well aware of the size of v4 and v6 space.. and the market dynamics.</div><div dir="ltr"><br></div><div dir="ltr"><a href="https://icannwiki.org/Bill_Manning">https://icannwiki.org/Bill_Manning</a><br></div><div dir="ltr"><a href="https://datatracker.ietf.org/person/Bill%20Manning">https://datatracker.ietf.org/person/Bill%20Manning</a><br></div><div dir="ltr"><br></div><div>I mean, he literally wrote the memo on variable length subnetting:  <a href="https://tools.ietf.org/html/rfc1878">https://tools.ietf.org/html/rfc1878</a></div><div><br></div><div>and the size is not actually the point. </div><div><br></div><div>Over the last 40 years a lot of decisions were made and there are sunk costs no matter what.  Once upon a time there was an alternative proposed, that would have put everything not RFC 1918 in LAN's and left the equivalent of RFC1918 as WAN/interconnect space.   My guess is, even at that time you had people who didn't want to return space/renumber.  We don't know how it would have changed things, or the ramifications (logs, dos attacks, calea, etc) but it would have been different, and it's an interesting thought experiment.  </div><div><br></div><div>Whatever we choose, then, now in the future, there will always be resistance to change</div><div>Sunk costs. <br></div><div>Time.<br></div><div>Effort.</div><div>Learning curve</div><div>Return on investment.</div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 19, 2019 at 1:50 PM Cynthia Revström <<a href="mailto:me@cynthia.re">me@cynthia.re</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>In fact a single /64 is not 2^32 more addresses but rather 2^32 times the total IPv4 address space.</div><div><br></div><div>The total IPv4 address space is 4 294 967 296.</div><div>An IPv6 /64 is 4 294 967 296 times 4 294 967 296 addresses.</div><div><br></div><div>- Cynthia<br></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 19, 2019 at 7:33 PM <<a href="mailto:hostmaster@uneedus.com" target="_blank">hostmaster@uneedus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Nor to me.  A single /64 IPv6 subnet which is the standard LAN assignment <br>
has 2^32 more addresses than the TOTAL IPv4 space. While unused IPv4 space <br>
is being sold and pressed into use, and other space belonging to others <br>
like <a href="http://11.0.0.0/8" rel="noreferrer" target="_blank">11.0.0.0/8</a> and <a href="http://30.0.0.0/8" rel="noreferrer" target="_blank">30.0.0.0/8</a> is being used for private space, eventually <br>
the sheer growth of the Internet and networks will get to the point that <br>
even this will not be enough.<br>
<br>
Seventeen /8's were assigned to RIR's in 2010, the year before IANA <br>
exhaustion happened. That was 1/13 of the total space available.<br>
<br>
I have no doubt had space existed in the last eight full years since <br>
exhaustion that at least another 136 /8's would have been consumed at that <br>
same seventeen per year rate, maybe more.<br>
<br>
While those with legacy elements in their network that prevents these <br>
operators from easily adopting IPv6, my guess these operators are but a <br>
very small fraction of the total, and likely already has enough IPv4 <br>
already in use. I understand legacy, as I still have IPX netware on my <br>
network for a software program for Adult Basic Education.  This is because <br>
the current COTS software goes no lower than 8th grade, and we still have <br>
a need to go below that grade. Workstations are booted off of floppies <br>
(more legacy) to access the local Netware Server (controlled by KVM) <br>
instead of the more modern stuff. Might make the workstations dual boot in <br>
the next cycle, as the next generation of machines to be passed down to <br>
the learning labs do not have floppies. Also, voicemail computers running <br>
DOS.  We do use ip based KVM switches (less the "M", unused in DOS) for <br>
remote control, and dos based packet drivers and old ISA network cards for <br>
remote drive access for backup.  Even with all this old stuff, we have <br>
been doing IPv6 since 2007 due to a Federal requirement to do so.<br>
<br>
The "IPv4 Market" is not sustainable in the longer run, and my guess is <br>
that in another 8 years that the price for IPv4 address will finally rise <br>
to the point that it will be cheaper for most operators to adopt IPv6, <br>
rather than pay the higher market cost to buy IPv4 from someone else.  Of <br>
course, some early adopters of IPv6 will take advantage of this increase <br>
in market rate by selling off most of their unused IPv4 addresses. I also <br>
believe that starting first with residential customers, the assigning of a <br>
global IPv4 address will become an extra cost option, and maybe some that <br>
are really bold will make access to IPv4 an extra cost service, making <br>
IPv6 only service their lowest cost tier.<br>
<br>
Of course, when we reach such a tipping point and the majority of <br>
providers are pushing bits mostly using IPv6, market forces will then <br>
start taking the price of IPv4 back downward.  At the same time some <br>
networks might limit or even eliminate support for IPv4 completely. Some <br>
like Facebook are already completely IPv6 except at the edge.<br>
<br>
There are still those that seem to be hanging on for some other protocol <br>
other than IPv6. The reality is that development of IPv6 took over ten <br>
years, and there will not be any time to develop something else.<br>
<br>
While IPv6 is not perfect, it is at least as useable as IPv4 and been <br>
available in most OS's and routers since 2000 or so.  If one wants to hack <br>
their OS in order to use 127/8 and 240/4 just to gain a few addresses that <br>
is just a fraction of a normal IPv6 single LAN allocation of /64 go ahead. <br>
However, it will still be likely that you will still at some point be <br>
forced to use IPv6 when networks start turning down IPv4 support and your <br>
network needs access to these other networks.<br>
<br>
Albert Erdmann<br>
Network Administrator<br>
Paradise On Line Inc.<br>
<br>
On Sun, 19 May 2019, Cynthia Revström wrote:<br>
<br>
> I have no clue what your point is but an IPv6 /32 is 2^96 IP addresses. The<br>
> total possible IPv4 address space is 2^32<br>
><br>
> So your point doesn't make much sense to me.<br>
><br>
> - Cynthia<br>
><br>
> On Sun, May 19, 2019 at 5:54 AM william manning <<a href="mailto:chinese.apricot@gmail.com" target="_blank">chinese.apricot@gmail.com</a>><br>
> wrote:<br>
><br>
>> ok, so you don't like the "use <a href="http://127.0.0.0/8" rel="noreferrer" target="_blank">127.0.0.0/8</a>" proposal. fine.<br>
>> RFC 1918 space is too small.  fine.<br>
>> IPv6 is too hard. fine.<br>
>><br>
>> Shortly after discussions started on RF 1918, I proposed the following:<br>
>><br>
>> Since NAT exists, direct peering on a global scale will be fairly<br>
>> restrictive, one should consider inverting RFC 1918.  Use those addresses<br>
>> strictly and only for global interconnection/peering.<br>
>><br>
>> This would free up all other IPv4 space to sit behind your NAT and usable<br>
>> in your enterprise networks.  Thats almost an entire IPv6 /32 of space for<br>
>> everyone, without having to migrate to IPv6.<br>
>><br>
>> Problem solved.<br>
>><br>
>> Your welcome.<br>
>><br>
>> /Wm<br>
>> _______________________________________________<br>
>> ARIN-PPML<br>
>> You are receiving this message because you are subscribed to<br>
>> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
>> Unsubscribe or manage your mailing list subscription at:<br>
>> <a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
>> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
>><br>
>_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div>