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!

On Thu, Nov 19, 2020 at 9:55 AM JORDI PALET MARTINEZ <jordi.palet=
[e-mail]> wrote:

> Every RIR has their own policies, but in general they match very closely
> (I tried very hard doing that thru policy proposals when it was making
> sense, and this was the case for IPv6 initial and subsequent allocations).
>
>
>
> As explained a few emails ago … in general I will say that you only have a
> problem in LACNIC and AFRINIC if you don’t have your services there, or at
> least the majority of those services.
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 19/11/20 15:16, "v6ops en nombre de Gyan Mishra" <
> [e-mail] en nombre de [e-mail]> escribió:
>
>
>
> 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 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>
>
>
>
> --
>
> <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