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

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

Hello Jen

We learn from our mistakes… what you point out below is the proof that we tried and know from experience that it’s a bad idea.

Bottom line is that without any information the middle box doing LRU has a chance to kill silently and address that the host formed for the long run but is not using for the most part. Turned out to be a bad idea like anything else the middle box will do blindly.

Only the host knows how to use its address budget and which address can be deprecated. But with ND there’s no signal that the address was deprecated and the network retains a useless though costly state.

 With RFC 8505 the host deregisters one address and can register a new one. No wasted resource, guaranteed service, appropriate lifetime.

We need to deprecate SLAAC on any sizable network and leave it to small unmanaged cases like Starbucks.


Regards,

Pascal

> Le 10 nov. 2022 à 15:09, Jen Linkova <[e-mail]> a écrit :
> 
> On Fri, Nov 11, 2022 at 1:28 AM Eric Levy- Abegnoli (elevyabe)
> <elevyabe=[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.
> 
>> 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 ;)
> 
>> 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]> 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]
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
> -- 
> SY, Jen Linkova aka Furry
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops