[v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso

[Gyan Mishra <[e-mail]>]

v6ops preso - "race to bottom slide" slightly modified - new proposal for
new /80 bottom so that we could actually make multiple /48s I mean /64s
actually wearable.

A /64 would be the new /48 as we shifted the IID by 16 bits shorter &
making the prefix 16 bits longer.


/64 = current Bottom fixed based on 64 bit IID.

/48 = 64k /64s - Due to current 3GPP architecture limitation we cannot dole
out shorter prefixes via 64share v2 even that Cameron proposed.  Also with
the RA PD style trickery w/o A bit set as Lorenzo mentioned the host would
not accept the shorter prefix as it is expecting a 64 bit prefix from the
3GPP gateway.


Why /48's wearable is not possible today for 2 reasons:

1. Large providers such as Verizon subscribers = 150M not including
broadband and /24 equates to 16M /48 way short and /20 even 160M but large
providers as Verizon's of the world need to scale to 1B or 7B.

2. 64share v2 even if 3GPP arch allowed shorter prefixes /56 or even /48,
RFC 4291 would have to change the 64 bit fixed boundary requirement for any
handset to accept shorter prefix.  So we are stuck and 64 share v2 is not
possible w/o RFC 4291 changing.


What if we made the new fixed bottom a /80 meaning.  So that would
essentially be the new bottom that ISPs cannot race any further since the
standard would be fixed at the new /80 bottom just as its fixed at the /64
bottom.  We just gave ourselves 16 bits to play with.


64 share v2 - Allocate /64 as it does today and that would basically be
equivalent to a /48 allocation. Nice!

*/80 = New bottom => Problem solved *

*/64 = 64k /80s - wearable - so now both 3GPP and broadband  providers
problem solved for segmentation*

*/64 Current bottom*

*/48 = 64k /64s*

As far as SLAAC goes we would modify RFC 4291 to allow for longer prefixes
up to /80.  I think while we are changing RFC 4291 I think it would make
sense to allow for shorter prefixes maybe to any length or fix a a value
that makes sense for shorter then /64.  So in the future if 3GPP can be
updated for shorter prefixes we could give out shorter as well which would
be a ton of prefixes.

However, I think if we made the new bottom a /80, in reality the end site
allocation would be equivalent to a /48 so would not have to allow slaac
really to allow for shorter then /64.


Although as they say - never say never.."when you build - they will come"


SLAAC would use random IID generation schemes to generate the shorter 48
bit IID via RFC 4941 or stable IID RFC 7217.


>From a privacy perspective for broadband users we would still have 48 bit
IID which in the scheme of things as the double edged sword for operators &
law enforcement scanning I think the address correlation attacks I think
the 48 bits random IID for privacy extension, I think we would be in good
shape.


This also solves the day 1 VLSM issue as well for mixed host static, dhcpv6
& slaac as now we can have longer prefixes up  to /80.


This may solve some of the aviation issues that Fred Templin is working on
as well.


Also with Network Slicing to be mainstream with 5G  and proliferation of
IoT devices I can see end user allocations growing very quickly


AND = "NO RACE TO BOTTOM" possible even  as we would fix the new boundary
at "/80" as the new bottom so you cannot race down any further. Would be no
different then the /64 boundary but now getting a 16 bit bonus out of the
deal.


IANA now does not have to dig into unallocating more ::/3s for larger
allocations - see Slide 10 from v6ops preso below


Slide 10 in v6 ops preso

One of the reasons why 6MAN has deferred removing the 64 bit boundary is
due to the  ISP “race to the bottom” fear that we are at the bottom giving
out /64 to mobile handsets that ISP’s will in theory do what history has
shown us what was done with IPv4 where due to address depletion issues and
issues with overlapping address space ISP’s made the broadband standard to
dole out /32 WAN IP which is NAT port overloaded outside wan interface.
NAT as well as CGNAT have solved issues with IPv4 shortage and overlapping
ranges allowing overlapping ranges to co-exist with NAT as well as now
ISP’s due to the risk of IPv4 address depletion made the standard a /32 WAN
IP with NAT port overloaded via PAT (Port Address translation) with private
192.168.1.0/24 subnet for SOHO hosts.

IPv6 on the other hand does not have any risk of address depletion so you
cannot compare what history has told us with IPv4 to IPv6 and there is no
other data point to be had.

On the other side of the spectrum with 64share we are looking now at
shorter prefixes and maybe an idea of creating and RFC 6177bis that allows
a /48 per human per mobile device.  Is that possible ???

https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

2000::/3 GUI

IAIA <=>RIR <=> ISP <=> End user Allocation

RIR allocations to Service Providers:



For the massive block allocations for ISPs is it tiered like this

/32 - General Starting point for ISP allocation

/24-26 - Medium to Large

/19-20 - Exceptions and rare



Since allocations are done blockwize and not linearly you have to account
for future growth so generally over allocate for growth next 20 years.  So
with that the much larger allocations.



With that being said let's say for a typical large ISP /24 - that would
yield 16M /48s.  That still is small since most large ISPs like, we Verizon
we want to scale to a billion as right now we have 150M and that's just
domestic not worldwide.  Safe best for large ISPs is we want to scale to
the number of humans on the planet so 7 Billion is a good number.  Also
that does not account for broadband.  So for Verizon as an example /48  per
human is not possible.



I think /48 per user site is sensible for the much smaller ISPS with few
million subscriber base  but I think an impossibility at least for the
larger Verizon size ISP’s.  Looking on IAIA allocation link I don't see too
many RIRs getting a /12.

*https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml
<https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml>*




<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD