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

[Andrey Kostin <[e-mail]>]

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:[e-mail]] On Behalf Of Jen Linkova
> Sent: Tuesday, November 8, 2022 9:55 PM
> To: Ole Troan <[e-mail]>
> Cc: V6 Ops List <[e-mail]>
> 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 <[e-mail]> 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
>