Re: [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

[JORDI PALET MARTINEZ <[e-mail]>]

The right way to resolve this is very simple.

 

Go to your RIR (ARIN I guess) “ARIN I want to provide a /48 for each of my subscribers, so I need a subsequent allocation, following the section 6.5.3. (Subsequent Allocation to LIRs) of the Number Resource Policy Manual, and this is my justification …”.

 

Done!

 

https://www.arin.net/participate/policy/nrpm/#6-5-3-subsequent-allocations-to-lirs

 

Regards,

Jordi

@jordipalet

 

 

 

El 19/11/20 13:26, "v6ops en nombre de Gyan Mishra" <[e-mail] en nombre de [e-mail]> escribió:

 

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

 

 

 

Gyan Mishra

Network Solutions Architect 

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

 

_______________________________________________ v6ops mailing list [e-mail] https://www.ietf.org/mailman/listinfo/v6ops 



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.