[arin-ppml] how to get a v6 /32 of v4 address space

Cynthia Revström me at cynthia.re
Sun May 19 13:49:50 EDT 2019


In fact a single /64 is not 2^32 more addresses but rather 2^32 times the
total IPv4 address space.

The total IPv4 address space is 4 294 967 296.
An IPv6 /64 is 4 294 967 296 times 4 294 967 296 addresses.

- Cynthia


On Sun, May 19, 2019 at 7:33 PM <hostmaster at uneedus.com> wrote:

> Nor to me.  A single /64 IPv6 subnet which is the standard LAN assignment
> has 2^32 more addresses than the TOTAL IPv4 space. While unused IPv4 space
> is being sold and pressed into use, and other space belonging to others
> like 11.0.0.0/8 and 30.0.0.0/8 is being used for private space,
> eventually
> the sheer growth of the Internet and networks will get to the point that
> even this will not be enough.
>
> Seventeen /8's were assigned to RIR's in 2010, the year before IANA
> exhaustion happened. That was 1/13 of the total space available.
>
> I have no doubt had space existed in the last eight full years since
> exhaustion that at least another 136 /8's would have been consumed at that
> same seventeen per year rate, maybe more.
>
> While those with legacy elements in their network that prevents these
> operators from easily adopting IPv6, my guess these operators are but a
> very small fraction of the total, and likely already has enough IPv4
> already in use. I understand legacy, as I still have IPX netware on my
> network for a software program for Adult Basic Education.  This is because
> the current COTS software goes no lower than 8th grade, and we still have
> a need to go below that grade. Workstations are booted off of floppies
> (more legacy) to access the local Netware Server (controlled by KVM)
> instead of the more modern stuff. Might make the workstations dual boot in
> the next cycle, as the next generation of machines to be passed down to
> the learning labs do not have floppies. Also, voicemail computers running
> DOS.  We do use ip based KVM switches (less the "M", unused in DOS) for
> remote control, and dos based packet drivers and old ISA network cards for
> remote drive access for backup.  Even with all this old stuff, we have
> been doing IPv6 since 2007 due to a Federal requirement to do so.
>
> The "IPv4 Market" is not sustainable in the longer run, and my guess is
> that in another 8 years that the price for IPv4 address will finally rise
> to the point that it will be cheaper for most operators to adopt IPv6,
> rather than pay the higher market cost to buy IPv4 from someone else.  Of
> course, some early adopters of IPv6 will take advantage of this increase
> in market rate by selling off most of their unused IPv4 addresses. I also
> believe that starting first with residential customers, the assigning of a
> global IPv4 address will become an extra cost option, and maybe some that
> are really bold will make access to IPv4 an extra cost service, making
> IPv6 only service their lowest cost tier.
>
> Of course, when we reach such a tipping point and the majority of
> providers are pushing bits mostly using IPv6, market forces will then
> start taking the price of IPv4 back downward.  At the same time some
> networks might limit or even eliminate support for IPv4 completely. Some
> like Facebook are already completely IPv6 except at the edge.
>
> There are still those that seem to be hanging on for some other protocol
> other than IPv6. The reality is that development of IPv6 took over ten
> years, and there will not be any time to develop something else.
>
> While IPv6 is not perfect, it is at least as useable as IPv4 and been
> available in most OS's and routers since 2000 or so.  If one wants to hack
> their OS in order to use 127/8 and 240/4 just to gain a few addresses that
> is just a fraction of a normal IPv6 single LAN allocation of /64 go ahead.
> However, it will still be likely that you will still at some point be
> forced to use IPv6 when networks start turning down IPv4 support and your
> network needs access to these other networks.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
> On Sun, 19 May 2019, Cynthia Revström wrote:
>
> > I have no clue what your point is but an IPv6 /32 is 2^96 IP addresses.
> The
> > total possible IPv4 address space is 2^32
> >
> > So your point doesn't make much sense to me.
> >
> > - Cynthia
> >
> > On Sun, May 19, 2019 at 5:54 AM william manning <
> chinese.apricot at gmail.com>
> > wrote:
> >
> >> ok, so you don't like the "use 127.0.0.0/8" proposal. fine.
> >> RFC 1918 space is too small.  fine.
> >> IPv6 is too hard. fine.
> >>
> >> Shortly after discussions started on RF 1918, I proposed the following:
> >>
> >> Since NAT exists, direct peering on a global scale will be fairly
> >> restrictive, one should consider inverting RFC 1918.  Use those
> addresses
> >> strictly and only for global interconnection/peering.
> >>
> >> This would free up all other IPv4 space to sit behind your NAT and
> usable
> >> in your enterprise networks.  Thats almost an entire IPv6 /32 of space
> for
> >> everyone, without having to migrate to IPv6.
> >>
> >> Problem solved.
> >>
> >> Your welcome.
> >>
> >> /Wm
> >> _______________________________________________
> >> ARIN-PPML
> >> You are receiving this message because you are subscribed to
> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> https://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> >>
> >_______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20190519/d4ed04a9/attachment.htm>


More information about the ARIN-PPML mailing list