Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt

[Alexandre Petrescu <[e-mail]>]

Le 04/11/2020 à 09:45, [e-mail] a écrit :
> Gyan,
>
>> Are there any of the problems/use-cases that cannot be solved by assigning a shorter prefix than /64 to the end-user networks?
>>
>>     Gyan> The issue here with 4G providers to be able to force providers to go with a shorter prefix is impossible and similar to the issue we see with the v6ops flash renumbering issue and even in light of BCOP RIPE-690 that broadband operator’s PD allocations is /64 and not /56 as recommended in BCOP and due to the impact of flash renumbering events we are now changing the VL PL to short timers to age our the stale prefix during a renumbering event.  So the standard on 4G and as it is the same standard for 5G handsets allocation, a /64, and 4G and even 5G operators for mobile handset provisioning do not plan to make it a shorter prefix.  So either customers end up suffering with flash renumbering events or you update the standard.  Same issue we are faced with here with wireless providers and forcing them to dole out shorter prefix.
> I don't understand the coupling you make between the 64 bit boundary and flash renumbering.
>
>> Fixed 5G replacement for broadband I mentioned, not to be confused with 5G mobile handset, would follow BCOP RIPE-690 and I believe will go in with larger allocation like a /56 or larger.  So the fixed 5G network slicing how it comes into play as a value proposition and massive benefit to customers, is it can now have the front haul 5G to tower and back haul tower to core now be provisioned to the fixed 5G with a normal BAU slice template for normal traffic and at the same time separate slices for special Enhanced VPN over SRv6 core SR-TE steered with dedicated resources and traffic  isolation and special QoS prioritization for applications such as IOT, E911 emergency services, or utilities etc.
>>
>> https://www.internetsociety.org/blog/2017/10/ipv6-prefix-assignment-bcop-published-ripe-690/
> OK, so the problem is:
> "How do you connect an end-user network with multiple links to a provider who only allocates a /64 to the site.".
>
> There is a conundrum here. A reason for the 64-bit boundary is that it forces the provider to give at least a /64.
> That design decision seems to have had the intended effect. You don't see any providers assigning less address space than the /64.
>
> If we were to relax that limitation, then there is a fear that providers will start assigning fewer addresses to end-users. Down to a single address like we see in IPv4.
>
> The conundrum then is:
> How do we ensure providers allocate at least a /64 of address space to end-users, and at the same time allow end-users to extend a network with only a /64 assigned to it.


I want to not forget to If there is a future version of this draft then 
I want to make sure to add the problem of "Race to the Bottom" in the 
Variable SLAAC Problem Statement draft.

We could also try to answer how one could make sure the providers 
allocates _at least_ a /64 to an end user.  I think there is an RFC for 
that, that we might cite.  And a RIPE note too.

Alex

>
> Answer that and we can make progress.
>
> Best regards,
> Ole