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]>]

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