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

[Gyan Mishra <[e-mail]>]

Jordi

I am not sure if all RIRs for example ARIN if it or others are as liberal
as RIPE.

Gyan

On Thu, Nov 19, 2020 at 8:38 AM Gyan Mishra <[e-mail]> wrote:

>
> Thanks Jordi!
>
> That solves one problem but does not solve the 64share v2 issue as we have
> to still modify
> RFC 4861 for mobile to accept shorter prefix.
>
> Thanks
>
> Gyan
>
> On Thu, Nov 19, 2020 at 8:01 AM JORDI PALET MARTINEZ <jordi.palet=
> [e-mail]> wrote:
>
>> 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
>> <https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml>*
>>
>>
>>
>>
>>
>>
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions Architect *
>>
>>
>>
>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g> *Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g>
>>
>>
>>
>> _______________________________________________ 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.
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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