Over-utilisation of v6 neighbour slots

[Phil Mayers]

On 24/10/2013 10:59, Benedikt Stockebrand wrote:

>> And it provides negligible - perhaps zero - improvement in privacy.
>
> Sorry, but I disagree on that.  While you may be right when it comes to

Ah, I was unclear:

Privacy addresses are fine - no problem with them.

What I meant is that the specific strategy Apple devices seem to be 
using to re-generate them - on link-up - provides little or no benefit 
*above* a per-link & time-based rollover.

>> I assert that rolling the address on a timer, not on power/link
>> activity, is the intent of the RFCs, and the desired behaviour, and
>> that Apple are doing the wrong thing here.
>
> This is too simple: If I want to avoid people/devices being tracked when
> moving from one link to another, then I need to use a new temporary

Sorry, again I was unclear: of course the strategy needs to be more 
involved than just a global timer. Clearly address rollover needs to be 
per-link - probably per prefix&link.

> As a substitute for the SSID, the IP address(es) of the router(s) could
> be used to check if a device connects to the same link again.  But then,
> this doesn't provide any crypto protection, so it can be used to spoof
> things.

Or just per prefix, as seen in the RAs, which are present on every link.

Specific strategies for determining the domain within which a privacy 
address is valid for a specific time are many and varied.

>
>> In the long run, a move to RAM-based trie lookups seems to be the way
>> to go for FIBs, for the superior power use characteristics if nothing
>> else.
>
> Somebody from the hardware implementers correct me, but this should be
> both difficult to implement and is likely too slow.  You don't use
> CAM/TCAM unless you are really desperate for speed.

There are already high-speed devices using RAM for FIB e.g. Juniper Trio 
chipset uses RLDRAM.