Re: [v6ops] The bottom is /112

[Bob Hinden <[e-mail]>]

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


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