Re: [v6ops] The bottom is /112

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

OK, that was cheating: citing an RFC the day before it was published ;-).

Regards
   Brian

On 24-Nov-20 09:23, Brian E Carpenter wrote:
> 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
>