Re: [v6ops] The bottom is /112

[Gyan Mishra <[e-mail]>]

On Thu, Nov 19, 2020 at 6:02 PM Bob Hinden <[e-mail]> wrote:

> Brian,
>
> > On Nov 19, 2020, at 2:49 PM, Brian E Carpenter <
> [e-mail]> wrote:
> >
> > And if we had left the boundary at /80, as it was in 1995 (RFC1884),
> would you now be arguing for /96, since in that case 3GPP would have
> settled on /80?
> >
> > Sorry, but this is exactly and precisely a 16-bit jump in the race to
> the bottom. And it breaks all existing SLAAC hosts on the way.
> >
> > The problem here is caused by 3GPP, but a solution like Cameron's should
> work for everybody with minimal changes.
>
> +100
>
> Either something like Cameron’s draft or a very minimal DHCPv6 PD
> implementation that can run in a 3GPP environment.   It doesn’t need to be
> a full DHCPv6 server.
>
> Bob


    Gyan> One possible non technical factor is that Android which as of
2019 statistical data below holds 87% of the global mobile market share and
Apple 13% and Android is continuing to climb in 2020.   Android adamantly
refuses to change its position on support of DHCPv6.  I think that really
shackles 3GPP carriers from supporting DHCPv6 is close to 100% of all
mobile handsets won’t support it.

https://www.statista.com/statistics/272307/market-share-forecast-for-smartphone-operating-systems/

>
>
>
> >
> > Regards
> >   Brian
> >
> > On 20-Nov-20 11:03, Gyan Mishra wrote:
> >>
> >>
> >> On Thu, Nov 19, 2020 at 10:33 AM <[e-mail] <mailto:
> [e-mail]>> wrote:
> >>
> >>
> >>
> >>> On 19 Nov 2020, at 14:58, Gyan Mishra <[e-mail] <mailto:
> [e-mail]>> wrote:
> >>>
> >>> You would need a new option. It would likely be useful for the
> requesting router to indicate interest in the option. Even hinting at what
> prefix size it was expecting.
> >>> Now can you explain to me again the reasons why this approach is
> better than using the existing DHPCv6 protocol packets?
> >>>
> >>>      3GPP gateway does not support DHCPv6
> >>
> >>    3GPP gateway doesn't support new option. What's your point?
> >>
> >>
> >>
> >>     The point of the v6ops presentation and this email thread is how to
> “extend a /64” in the 3GPP use case  in slide 1 of the deck you compiled a
> list of options and of the two I had highlighted in red were the 64share v2
> Cameron’s option and the variable slaac option.  So on the call this
> morning Lorenzo shot down 64share v2 shorter prefix option as even if the
> 3GPP architecture was updated to support longer prefixes and even is the
> 3GPP gateway was able to send a shorter prefix with A flag not set, all
> mobile devices per Lorenzo’s point would be broken as they would not accept
> the shorter let’s say /56 prefix to build the slaac 128 bit address.  So
> the bottom line is the 64share v2 won’t work unless we update RFC 4291 and
> remove the 64 bit boundary.
> >>
> >>  So we are back to square uno - no viable solution
> >>
> >>  So now we had thrown out the longer >64 due to race to bottom worries
> which I and others believe is Fud and as described in slide 10 of the v6ops
> “race to the bottom slide”.
> >>
> >> So a happy medium /80 fixed boundary I came up with that I think solves
> a lot of the issue and not just the 3GPP initial segmentation of downstream
> devices problem statement.
> >>
> >> Since we have to update RFC 4291 for 64share v2 to work anyways to
> allow for shorter prefixes, why not instead create a new bottom at /80
> giving 16 bits more of prefix length and shrinking the IID down to 48
> bits.  Doing so you would not even have to update the 3GPP architecture as
> I don’t know if that would fly or not.  Also this solves a few other
> problems at the same time.
> >>
> >>
> >> As I mentioned in the v6ops deck presented that vlsm 0 to 128 is
> mainstream for operators for static addressing on router and switch
> infrastructure and dhcpv6 subnets longer prefixes for network
> infrastructure appliance clusters, NFV/VNF virtualization and server
> farms.  On host subnets where there is a chance of mix of slaac hosts with
> dhcpv6  devices the prefix length is stuck at /64.  So on these mix
> addressing host subnets we cannot do longer prefixes following our ND cache
> hard limit mantra to prevent ND cache exhaustion issues as described in RFC
> 6164.
> >>
> >> So with the /80 new fixed boundary shifting prefix length 16 bits
> longer and shortening the IID by 16 bits gives resolved the 3GPP issue
> which 64share can work as is and subtending to downstream devices will now
> work as a /64 is now equivalent to a /48 with 64k /80s.  Also BCP-690 for
> broadband not all operators have adopted the shorter prefix lengths /56 or
> /48 recommendations  and now that’s not an issue as the /64 would now
> suffice.
> >>
> >> From an operators perspective that gain allows at least for 3GPP
> massive growth and subtending with a single /64 allows the operators such
> as Verizon with massive subscriber base worldwide can stay with current
> allocations and don’t have to ask for /10.
> >>
> >> As 5G gets rolled out with Enhanced VPN framework and Network slicing
> paradigm, the demand for shorter blocks and wearable multiple /48 will be
> our new reality.
> >>
> >> Making that 16 bit shift now to /80 making a /64 the new /48 will give
> broadband and 3GPP subscribers a ton of space to subtending their networks
> we would be set for the future.  Especially with IOT the demand for
> subtending will continue to grow astronomically.
> >>
> >> Also IANA does not have to get start in allocating the other /3 and
> other available blocks.
> >>
> >> Lots of problems being solved here with a fixed /80 new boundary.
> >>
> >> Also with the existing random IID generation schemes which we have
> tested on Linux kernel can do longer prefixes using RFC 4941 privacy
> extension or RFC 7217 stable IID.
> <https://www.google.com/maps/search/ivacy+extension+or+RFC+7217+stable+IID.?entry=gmail&source=g>
> >>
> >> Win-Win for all.
> >>
> >>    Ole
> >>
> >> --
> >>
> >> <http://www.verizon.com/>
> >>
> >> *Gyan Mishra*
> >>
> >> /Network Solutions A//rchitect /
> >>
> >> /M 301 502-1347
> >> 13101 Columbia Pike
> >> /Silver Spring, MD
> >>
> >>
> >>
> >> _______________________________________________
> >> v6ops mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/v6ops
> >>
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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