Re: [v6ops] Fwd: New Version Notification for draft-linkova-v6ops-ipmaclimi-00.txt

On 14-Nov-22 06:44, Vasilenko Eduard wrote:
> If the network has limits Then hosts should adapt to the limits (not vice versa).
> It is needed to know the limits to adapt. DHCP could inform about the limit, but SLAAC could not.

It could. There is a Reserved2 field in a PIO that could be redefined
to indicate a maximum number of addresses allowed per host under a
given prefix.

    Brian

> 
> The number of virtual things per hardware instance would be always restricted.
> If the best AP would support 200 IP per MAC then it is still possible to run containers and stretch even that.
> 
> DHCP could impose different limits per different links. Hence, if APs' different segment has different restrictions then DHCP would impose different limits.
> If the particular link has APs with different restrictions then indeed DHCP should be configured to limit on the smallest.
> Ed/
> -----Original Message-----
> From: Andrey Kostin [mailto:ankost@podolsk.ru]
> Sent: Friday, November 11, 2022 9:15 PM
> To: V6 Ops List <v6ops@ietf.org>
> Cc: Jen Linkova <furry13@gmail.com>; Ole Troan <otroan@employees.org>; Vasilenko Eduard <vasilenko.eduard@huawei.com>
> Subject: Re: [v6ops] Fwd: New Version Notification for draft-linkova-v6ops-ipmaclimi-00.txt
> 
> Vasilenko Eduard писал(а) 2022-11-08 13:58:
>> N+1 allocation should fail.
>> But the network and host should be aware of it (in sync).
>>
>>> Or do we want NAT66?
>> No. DHCP in this case.
> 
> What if the underlying access network has access points from multiple vendors and they have different limits that are lower than allowed by DHCP?
> 
> The problem Jen is trying to point out is not an addressing problem and not related either to SLAAC, DHCP or static assignment. Looks like some comments pronounce SLAAC guilty in described issue and try to use this statements to push DHCP vs SLAAC dispute. This is not the case. This is an operational problem caused by lack of common practice and agreement between vendors. And that is exactly what Jen is trying to solve. She is requesting to make underlying networks equipment's behavior deterministic and provide troubleshooting capabilities by creating log messages.
> 
> Regarding limits, in some networks big number of IPs per host can be absolutely appropriate and necessary, in others there may be stricter limits and this is also a real use case. We all understand that everything is a resource and cost some money. Let's allow network owners decide what's reasonable for them and what's not. Like Bill Gates said that 640K of RAM will be always enough. Although now we are used to have a lot more memory in our computers and servers, but it's still expensive and each admin can choose how much he/she can afford.
> So, in situations where host wants more addresses then allowed, some mechanism should exist to make this limit less painful and predictive.
> DHCP is one way for it, but it can't prevent creation of multiple link-local or ULA addresses and it can hit ND cache limit even for addresses legally assigned via DHCP. So it can't be considered as a solution.
> For replacement technique for me it looks simpler just to rely on ND cache expiration timers in the same way how it works for MAC tables.
> Some vendors can develop more sophisticated features similar to MAC security to differentiate their products from the base level. Eventually a user who tries to use more addresses than allowed should realize that there is a limit and shut down some interfaces/VMs/containers/etc to obey network rules.
> 
> Kind regards,
> Andrey
> 
>> Ed/
>> -----Original Message-----
>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jen Linkova
>> Sent: Tuesday, November 8, 2022 9:55 PM
>> To: Ole Troan <otroan@employees.org>
>> Cc: V6 Ops List <v6ops@ietf.org>
>> Subject: Re: [v6ops] Fwd: New Version Notification for
>> draft-linkova-v6ops-ipmaclimi-00.txt
>>
>> On Wed, Nov 9, 2022 at 1:12 AM Ole Troan <otroan@employees.org> wrote:
>>>> Fact #1: my devices need to have 7-10 IPv6 addresses.
>>>
>>> In the network you operate, that may be a fact.
>>> In other networks other rules.
>>>
>>> A requirement like that would be perfectly fine in an RFQ. Less so in
>>> an RFC.
>>
>> What I'm struggling to understand from this thread is: what's the
>> device supposed to do if it needs N addresses and the network only
>> agrees to provide N-1?
>> Shall the application fail? How is it better than the situation we
>> have now?
>> Or do we want NAT66?
>>
>>
>> --
>> SY, Jen Linkova aka Furry
>>
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops