[IPv6]Re: Working Group Last Call for <draft-ietf-6man-pio-pflag>

[Erik Kline <[e-mail]>]

>
>
> > I get that /64 makes you uncomfortable (presumably due to concerns about
> address wastage?) but is there actually a rational concern here about IPv6
> address space usage? If there is, should we start thinking about changing
> cellular networks to use prefixes longer than /64? And if not, then why
> should other types of networks be more constrained?
>
> My argument is about being future-proof when we don't know what the future
> will be. Will what we decide now hinder the deployment of 4000::/3 in some
> way?
>

<no hats>

Without seeking any information about RIR-specific allocations to their
requestors, it appears that the IANA "IPv6 Global Unicast Address
Assignments
<https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml>"
registry lends itself to a few observations:

[1] 2000::/4 is not yet completely handed out (2d00::/8 and 2e00::/7 still
unallocated)

[2] 3000::/4 is completely untouched (except for one /16, reserved for
legacy ${SHENANIGANS})

[3] 4000::/3 is completely untouched (except for one /8, reserved for
different ${SHENANIGANS})

[4] There's a long way to go before we get near the f000::/4 space, where
things start to get busy again (vis. "IANA IPv6 Special-Purpose Address
Registry
<https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml>
")

In units of /3, I make it out that we have 6000::/3, 8000::/3, a000::/3,
and c000::/3 (plus e000::/4) left to try to correct any mistakes, assuming
we can identify and learn from them.

* Apologies for weekend-brain if I've misread/miscalculated things here.
-ek