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

["Eric Levy- Abegnoli (elevyabe)" <[e-mail]>]

Hi Jen,
@@EL in line.

On Fri, Nov 11, 2022 at 1:28 AM Eric Levy- Abegnoli (elevyabe)
<elevyabe=[e-mail]<mailto:[e-mail]>> wrote:

The minimum requirement (draft says 20) is definitely not a good idea, as it depends so much on use cases. The value could easily vary from 2 (datacenter, dhcp assigned addresses, 1 LL, one global) to thousands (RFC4389 proxy on the path to the limiting device).

Indeed the actual number does depend on the specific case. The default
value should, IMHO, work for the majority of devices.
I chose '20'  because of RFC7934, but I'm flexible.
I didn't want to really repeat what RFC7934 already said but let's
look at the very minimal numbers for an ordinary host:

- one link-local
- two global (privacy + stable)
- one 464XLAT address.
So it's 4.

That number jumps to 5 when the privacy addresses are rotated.
When I'm doing a graceful remunering, replacing /64 assigned for the
subnet, it would be 7.
Depending on how long the device keeps the addresses in the cache (a
day? a week?) it could see multiple privacy addresses.
So I'd say we shouldn't be recommending anything less than 10 anyway.
@@EL. Well, if you take the case of a VM in a datacenter, one LL and one global are just enough.
No privacy needed there. In fact a VM trying to use more would be a sign of malfunction.
So 2 here is enough in this case. The network of course is sized accordingly.
Don’t take me wrong, I am not trying to generalize, I know many use cases, including  in the DC where you need more. But what I am trying to say is that you can’t come up with any arbitrary number that will work for all use cases, whether a min or a max

That is another thing which is a very bad idea: LRU. These limiting devices are not routers in the vast majority of cases, they are switches (including wireless controllers and APs). This is because they need to sit as close as possible to the offending device.
Typically, these devices can see multicast packets (DAD is the only one that is guaranteed to happen, sort-of…), not unicast.  SAVI switches entirely rely on DAD for instance. Punting unicast ND packets, and even worse data packets to the CPU of a switch so that it can figure out which addresses are LRU may be quite problematic to say the least.  LRU with just DAD would be a joke, as it only tells you when the entry was created. A crystal ball would be better in my opinion.

Well, I'm reading
https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-5/config-guide/b_cg85/ipv6.html
"At any given time, only eight IPv6 addresses are supported per
client. When the ninth IPv6 address is encountered, the controller
removes the oldest stale entry and accommodates the latest one."

So at least one vendor does smth like that already ;)
@@EL Some vendor may have tried very hard to make it work ☺ But the truth is, without the visibility on data traffic (which switches will not do), trying to do LRU is pure speculation. Typically, switches might probe, but probing a temporary address is counter-productive: the device will respond even if it is not the current one, and it will move up in the LRU list!
Only the device knows. It could do the DHCP release that we discuss at DHC, or the ND de-register: I understand “some vendors” don’t like the ND registration approach, but maybe de-registering an address would be acceptable?
Eric

The rest of the draft is fine: logging, configuring, all good common sense. Is it worth a draft? I don’t think so.

The motivation for this is that, based on my discussion with the
vendors, they need some guidance on what the default value should be,
Indeed, I can go and talk to various vendors 1:1, but I might fail
reaching some ;)

A draft that would establish any sort of two way communications between the host and the network would be a lot more valuable.

Please come to the v6ops@ session tomorrow, I'll talk about it.

On Tue, Nov 8, 2022 at 2:13 PM Ole Troan <otroan=[e-mail]<mailto:[e-mail]>> wrote:

A requirement like that would be perfectly fine in an RFQ. Less so in an RFC.



Ok, so then let's see *what* would be acceptable to put into an RFC.



The draft says that the hardware must allow the operator to configure the limits that the network places on the hosts, and should do something reasonable when the limit is hit, such as drop the address that was used least recently. I don't see how any of these statements can be controversial and it makes sense for them to be in an RFC. These hosts do exist (example: ChromeOS), and if a network operator (example: Jen) wants to support them, then it should be possible to do so.

The draft also says that if the network does not allow enough addresses per client for current implementations, those implementations will experience user-visible outages. As I see it, that's simply a fact (those implementations do exist, and they do fail), so I don't see how it could be controversial.



The thing that there doesn't seem to be consensus on is whether the IETF can/should place a minimum requirement on the number of addresses.



Did I miss something?

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



--
SY, Jen Linkova aka Furry