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

[Nick Hilliard <[e-mail]>]

Lorenzo Colitti wrote on 09/11/2022 13:41:
> Running a DHCPv6-only network can prevent hosts from using more than X 
> addresses, where X is decided by the DHCPv6 server. But that just moves 
> the problem, it doesn't solve it.

I don't have a clear picture of what you're suggesting here. If you're 
looking for a way to solve a resource supply constraint, the normal way 
of approaching resource constraint situations is for resource suppliers 
to allocate in a reasonable way and consumers to handle failure 
gracefully.  I.e. management process on both sides.

SLAAC makes this problematic because it lacks any mechanism to manage 
resources on the supply side, due to its design philosophy.

If you want to dismiss partial management approaches (for example, dhcp) 
as a way to merely move the problem, but not solve it, then you're kinda 
suggesting that there's a solution to this resource allocation 
constraint which doesn't involve compromise on the part of the client. I 
guess we all want a pony.

Other solutions might be to build a new tlv into ND which restricts the 
number of addresses that a client can assign locally. Won't be 
implemented for legacy clients, but maybe if ChromeOS implemented 
support, then it would catch on?

NAT will work fine, as you suggest.

Does ChromeOS have an exception handler for the situation where it 
attempts to configure extra addresses, but this fails, or that if it 
succeeds, that these IP addresses only have limited connectivity?

Perhaps document that ChromeOS needs X addresses per instance, and make 
it clear to the client / network operator that the network 
infrastructure needs to be able to support an appropriate level of 
resourcing?

Nick