Over-utilisation of v6 neighbour slots

[Benedikt Stockebrand]

Phil Mayers <p.mayers at imperial.ac.uk> writes:

> On 10/24/2013 08:18 AM, Benedikt Stockebrand wrote:
>> In my opintion the problem here is not so much Apple, but Cisco.  While
>
> Well, I think there's more than one problem.
>
> Certainly fixed-size (and relatively small) FIBs in Cisco-land are a
> problem. [...]

Another question is: Why use *T*CAM from the FIB, rather than
conventional CAM dedicated to ND and/or ARP?

> It is only relatively recently that TCAM-based platforms have started
> to grow in terms of FIB size - sup2T still comes in the same sizes as
> sup720, but the new 6880 has bigger.

Don't say they're not learning at Cisco...

> But even if you forget completely about the FIB-size issue, I *still*
> assert that Apple's v6 privacy address behaviour is idiotic. For those
> of us who log v6->MAC mappings into SQL, it balloons the logging
> requirements. It loads IPv6 FHS implementations.

Yes, this is partly a problem with Apple's implementation.  But then,
considering that at least some people have recently decided that privacy
on the Internet may be more of a concern than they thought so far, this
is partly a side effect of the problem that these concerns have been
ignored by the IT industry for too long.

And making it difficult/expensive for people logging things they
shouldn't really log unfortunately also makes it expensive for those who
should.

> And it provides negligible - perhaps zero - improvement in privacy.

Sorry, but I disagree on that.  While you may be right when it comes to
web based stuff, you may be right, but if we're talking about mobile VPN
users being tracked from some somewhere upstream for example you are
not.

> I've observed Apple devices powering up, generating a random IPv6
> address, NEVER USING IT, then powering it down and losing it, at
> intervals of tens of seconds. That's just asinine.

So, what should they actually do?  Seriously, getting this right isn't
as easy as it may seem:

> 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
address whenever I switch between links.  A simple timer will make a
fast-moving device trackable, effectively thwarting the entire purpose
of the privacy extensions.

What *could* be done in the special case of WiFi is to keep an address
when re-establishing a connection to a given SSID.  The downside of that
approach however is that it relies on a specific feature of a single
link layer technology---Ethernet doesn't have an SSID, so it doesn't
work there.

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.

> 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.

It may be fast enough for WiFi with its limited overall bandwidth, but
it won't scale to backplane speeds in a switched network.

>> quick workaround may be a reliable expiration mechanism.  On your side,
>> maybe some further segmentation can help to spread the load over
>> multiple routers (yes, I know that's frequently not an option on WiFi).
>
> ...as is the case here.

I was afraid so...

> That said, we are pondering moving the wireless routing off onto
> dedicated devices

Go for it.  WiFi is by its very nature different than wired/switched
link layers, so running both on the same hardware all to often creates
problems like the ones you have.

> - anyone got any recommendations? ;o)

No, but you know what to look for in the specs:-)


Cheers,

    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Benedikt Stockebrand, Dipl.-Inform.        http://www.stepladder-it.com/