Re: [v6ops] The bottom is /112

[Brian E Carpenter <[e-mail]>]

I've had several guesses but RFC 8929 still puzzles me :-)

Regards
   Brian

On 23-Nov-20 22:03, Pascal Thubert (pthubert) wrote:
> Hello Brian
> 
> Please note that RFC 8929 would work there too -that's proxy ND with the backbone on the Wi-Fi link and the wireless access on the 3GPP link-, used in the routing proxy mode - that's when the links are not bridgeable-..
> Basically the phone as a routing proxy installs host (connected) routes towards the 3GPP link for the addresses present there, and defends those addresses over the Wi-Fi Link.
> On paper the result is similar to RFC 7278, but the method is a bit different since internally it relies on ND proxy as opposed to anycast. Arguably the phone would self-assign another global address on the Wi-Fi link, if it cares to have one at all on that link.
> Bottom line is yes, I agree we should consider the applicability of what we have before we start breaking things down.
> 
> Keep safe;
> 
> Pascal
> 
>> -----Original Message-----
>> From: v6ops <[e-mail]> On Behalf Of Brian E Carpenter
>> Sent: jeudi 19 novembre 2020 23:50
>> To: Gyan Mishra <[e-mail]>; [e-mail]
>> Cc: IPv6 Operations <[e-mail]>; 6MAN <[e-mail]>; JORDI PALET
>> MARTINEZ <jordi.palet=[e-mail]>
>> Subject: Re: [v6ops] The bottom is /112
>>
>> 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.
>>
>> 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