Re: [v6ops] The bottom is /112

[Alexandre Petrescu <[e-mail]>]

Le 23/11/2020 à 10:03, Pascal Thubert (pthubert) a écrit :
> 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.

Fair enough.  It would work up to a point.

I note that I dont think RFC7278 '64share' uses anycast.

And, like 64share, I dont think 'backbone router' would support multiple
/64s in a vehicle; or a /64 on WiFi plus a another /64 on the USB ifaces
of a 3GPP-connected smartphone.

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

If pursuing, one would consider adding a reference to this RFC8929
method 'backbone router' to the problem statement draft of Variable
SLAAC.  Because in there we also list '64share'.

Alex

> 
> 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
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list [e-mail] Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>