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

["Pascal Thubert (pthubert)" <[e-mail]>]

Le 9 nov. 2022 à 13:42, Lorenzo Colitti <lorenzo=[e-mail]> a écrit :


On Tue, Nov 8, 2022 at 12:47 PM Ole Troan <otroan=[e-mail]<mailto:[e-mail]>> wrote:
> It is not about address assignment mechanisms. You'd hit the same
> issue if you configure addresses statically.

You are pointing out fundamental issues with SLAAC. There is no negotiation with the network nor any signal available (apart from DAD) to tell the host that it has exhausted the number of addresses available.
This is better in DHCP.

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. Right now, there are implementations that use 7-9 addresses because they think they need them. What should those implementations do instead? Use NAT instead?

I agree that would be violent. But can those applications get different ranges of ports for instance ?



Also host implementations do not have a way to relinquish addresses, so resource management becomes unnecessarily complicated on the network side.

You can keep increasing limits on the state tables, but since this is easily attackable (there are also software bugs where stacks unwittingly gone wild in assigning addresses to themselves) it is like peeing in your pants to keep warm.

This is easy to address: implement LRU plus a limit of X IPv6 addresses per device/MAC. I'd guess that many implementations already do this.

LRU is not necessarily your friend. It only works if the old address is really not used anymore. Which SLAAC does not tell.

All the best

Pascal


_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops