Re: Over-utilisation of v6 neighbour slots
I've noticed that my ipv6 is about 1ms faster than ipv4 consistently in measurements. I doubt that is enough faster to make a difference in most transactions so they would be equally preferred. Jared Mauch On Nov 1, 2013, at 3:46 PM, Erik Kline e...@google.com wrote: It looks like you would basically need to penalize IPv4 in order get your IPv6 ROI, *if* all your customers ever do is surf the web using Safari on recent Macs to do so.
Re: Over-utilisation of v6 neighbour slots
On 03/11/2013 16:30, Jared Mauch wrote: I've noticed that my ipv6 is about 1ms faster than ipv4 consistently in measurements. I doubt that is enough faster to make a difference in most transactions so they would be equally preferred. Interestingly, that last time I timed the IPv4 versys IPv6 latency - from myself to www.google.com - I saw a clear bias in favour of IPv4, of about 2ms. Having just re-timed it, they're pretty much dead-on the same. Presumably my upstream and/or google have rejigged things in the meantime.
Re: Over-utilisation of v6 neighbour slots
Hi Erik, Looking at our data, looking at an IPv6 FTTH deployment's dedicated resolvers, averaging over 7 days, I'm seeing: Safari + 10.6 = ~89% IPv6 native preference Safari + 10.7 = ~38% IPv6 native preference (somewhat lower sample set) Safari + 10.8 = ~39% IPv6 native preference Safari + 10.9 = ~47% IPv6 native preference This hasn't been rigorously reviewed, of course. Perhaps Mavericks is a bit better, but not much... :-( Sander
Re: Over-utilisation of v6 neighbour slots
Erik - do different versions of Safari have any impact (I don't have a clue about where HE is actually implemented and whether the version of Safari makes a difference)? - Ralph On Nov 1, 2013, at 2:25 PM 11/1/13, Eric Vyncke (evyncke) evyn...@cisco.com wrote: Interesting to see the confirmation of OS roll-out impact -Original Message- From: ipv6-ops-bounces+evyncke=cisco@lists.cluenet.de [mailto:ipv6- ops-bounces+evyncke=cisco@lists.cluenet.de] On Behalf Of Sander Steffann Sent: vendredi 1 novembre 2013 19:17 To: Erik Kline Cc: IPv6 Ops list Subject: Re: Over-utilisation of v6 neighbour slots Hi Erik, Looking at our data, looking at an IPv6 FTTH deployment's dedicated resolvers, averaging over 7 days, I'm seeing: Safari + 10.6 = ~89% IPv6 native preference Safari + 10.7 = ~38% IPv6 native preference (somewhat lower sample set) Safari + 10.8 = ~39% IPv6 native preference Safari + 10.9 = ~47% IPv6 native preference This hasn't been rigorously reviewed, of course. Perhaps Mavericks is a bit better, but not much... :-( Sander
Re: Over-utilisation of v6 neighbour slots
On Nov 1, 2013, at 3:46 PM 11/1/13, Erik Kline e...@google.com wrote: I'm not sure what you mean by impact. Sorry for the lack of clarity. You answered my question - the different behaviors are strictly correlated to the version of OS 10 and are independent of the version of Safari. - Ralph Different OS versions do seem to behave differently. I think 10.7 is when the dueling connections implementation was introduced, and it did drop Safari's IPv6 native preference by basically half. And if you think about it, in a perfect network where IPv4 and IPv6 have identical performance each would likely only be used ~50% of the time. It looks like you would basically need to penalize IPv4 in order get your IPv6 ROI, *if* all your customers ever do is surf the web using Safari on recent Macs to do so. The total impact of an HE implementation is obviously in proportion to its use for web traffic. Let me revise the numbers for this sample network. I was including measurements where the client may not have asked for any s, so let me restrict my numbers just to measurements where s were requested. That's what I get for not waiting to have my stats-diving be peer reviewed (different timezone, etc). Once more, with feeling!, and I'm sure Lorenzo and correct me later on. [All MSIE] no HE, later versions do a simple reachability check ~once 96% IPv6 native preference 7ms average extra latency [All Chrome] HE: 300ms lead for IPv6 then fallback to IPv4 83% IPv6 native preference 1.5ms average latency improvement over IPv4 [All Safari + 10.6] I think no HE? (it's been so long...) 97.5% IPv6 native preference 0ms average latency delta between IPv4 and IPv6 [All Safari + 10.7,10.8, and 10.9] HE: strict connection racing, at one point A record requested first, I believe 48% IPv6 native preference 9ms average latency improvement over IPv4 (by design, working as intended, etc.) So the HE implementation does matter. In this particular sample network I'm guessing that there may be about an extra 7-8 ms for IPv6 requests to Google (this is end-to-end, so the sources of latency could be multiple including whether or not the interconnect paths for IPv4 and IPv6 are the same). Lastly, I am attaching an old slide from a measurements presentation we gave at the V6 World Congress in Paris in the very beginning of this year wherein I attempted to graphically illustrate the effect of different HE implementations. Finicky Eyeballs.png
Re: Over-utilisation of v6 neighbour slots
On 10/28/2013 10:49 PM, Lorenzo Colitti wrote: On Tue, Oct 29, 2013 at 6:53 AM, Phil Mayers p.may...@imperial.ac.uk mailto:p.may...@imperial.ac.uk wrote: I wanted to follow up on this. Some folks from Cisco kindly contacted me off-list, and correctly guessed that a large number of the IPv6 neighbour entries were in state STALE, and pointed me to the relatively new: ipv6 nd cache expire seconds ...interface-level command. This wasn't in the IOS train we were running until relatively recently, so I hadn't seen it before. I wonder what the designers were thinking when they did the original implementation. Without this option, a box with enough client churn could run out of neighbour cache entries even if all the clients are perfectly behaved. Perhaps they didn't think of it because it doesn't happen in IPv4 due to a) much fewer addresses on a given box due to scarcity and b) ARP has timeouts. Probably not scarcity in 1918 world, but I think you hit the nail on the head with arp has timeouts. :) Doug
Re: Over-utilisation of v6 neighbour slots
On 21/10/13 20:35, Phil Mayers wrote: Specifically, our Cisco 6500/sup720 ran out of IPv6 FIB slots, as num_routes + num_neighs exceeded 32k (the default IPv4/IPv6 TCAM split on this platform being 192k/32k). I wanted to follow up on this. Some folks from Cisco kindly contacted me off-list, and correctly guessed that a large number of the IPv6 neighbour entries were in state STALE, and pointed me to the relatively new: ipv6 nd cache expire seconds ...interface-level command. This wasn't in the IOS train we were running until relatively recently, so I hadn't seen it before. Having applied this, we saw a sharp drop in v6 neighbour count, although it didn't seem to take effect on existing entries - I was able to force it by flapping the interface and refreshing all the neighbours. The entries seem to expire after ipv6 nd cache expire + ipv6 nd reachable-time i.e. I see a max age in the neighbour table of 24 minutes for parameter values of 1200 and 30 (in seconds and milliseconds) respectively. There are also a bunch of newer per-interface ND commands (per-IF ND cache size limits, for example) that could help with resource exhaustion, so people on Cisco gear should take a look.
Re: Over-utilisation of v6 neighbour slots
On Fri, Oct 25, 2013 at 11:55:05AM +0200, Andrew Yourtchenko wrote: rantI presume that those who want ultimate privacy have inspected their browsers to not do evercookies[1], removed any features in their browsers identifying them via the fingerprint, and ensured that the call-home feature of their favourite operating system and the apps is deactivated, as well as taking care that they manually reconfigure the new mac address on each new connection. /rant Excellent point. Identification via IP address is the least point of concern to me (as long as the host part doesn't use a GUID of course). But making a lot of fuzz about prefix randomization like some German ISPs do in the press nicely distracts from the real powerful identification methods you mentioned - which are widely used. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Re: Over-utilisation of v6 neighbour slots
On 10/25/13, Tim Chown t...@ecs.soton.ac.uk wrote: On 22 Oct 2013, at 06:03, Eric Vyncke (evyncke) evyn...@cisco.com wrote: IMHO iOS obviously implemented the first part but not the second part ;-) But, the rapid rate of new RFC 4941 addresses for iOS has another impact because network devices cannot anymore limit the number of IPv6 addresses per MAC address in order to prevent a local DoS. Yes, thanks for breaking our IPv6 network with that one in your FHS implementation Eric :) That's in 7.2 WLC only which you hopefully do not run by now. The 7.3+ does the cleanup of the stale entries above a threshold, that do not answer the DAD probes. rantI presume that those who want ultimate privacy have inspected their browsers to not do evercookies[1], removed any features in their browsers identifying them via the fingerprint, and ensured that the call-home feature of their favourite operating system and the apps is deactivated, as well as taking care that they manually reconfigure the new mac address on each new connection. /rant [1] http://samy.pl/evercookie/ --a
Re: Over-utilisation of v6 neighbour slots
Hi Andrew and list, Andrew Yourtchenko ayour...@gmail.com writes: rant ok, I'll bite: I presume that those who want ultimate privacy have inspected their browsers to not do evercookies[1], Yuck. Good thing only the Internet thing needs this, not e-mail. Oh, wait... Anyway, there are things on the Internet beyond HTTP/s and HTML... removed any features in their browsers identifying them via the fingerprint, Actually, there *are* people doing this... However, pointing at somebody else screwing up as badly as oneself doesn't help any. With IPv6 we've had a rare occasion to deal with this problem properly at the network layer; if anybody tries to replace the HTTP/s and HTML combo with some new design, I sure hope they will address their side of the problem, too, so the problem might be solved there in as little as 20+ years... and ensured that the call-home feature of their favourite operating system and the apps is deactivated, Same issue, only worse. Within the IETF/W3C and similar, there's some sort of chance that they at least understand the issues involved here. Chances are getting slimmer with OS vendors, worse with browser developers/vendors, and next to null (for \epsilon 0) with apps developers/vendors. as well as taking care that they manually reconfigure the new mac address on each new connection. /rant Come on, you know that this is unfair. The MAC address is only visible on-link (except through EUI64-based IIDs), so the damage here is severely restricted, especially in an environment that is seriously subnetted. If we wanted to do this properly, why not switch from Ethernet to PPPoE all the way---with PPP there are no MAC addresses, and on pointopoint links we could use 0:0:0:0:0:1 for the router/RAS and 0:0:0:0:0:2 for the end device in all cases... Cheers, Benedikt PS: Sarcasm markup left as an exercise to the so inclined reader. -- Business Grade IPv6 Consulting, Training, Projects Stepladder IT Training+Consulting GmbH Benedikt Stockebrand Fichardstr. 38, 60322 Frankfurt/Main Dipl.-Inform./Geschäftsführer HRB 94202, Registergericht Frankfurt/M cont...@stepladder-it.com http://www.stepladder-it.com/ +49 (0) 69 - 247 512 362 http://www.benedikt-stockebrand.de/+49 (0) 177 - 41 73 985 Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet. No spam, no unsolicited sales calls, no telephone surveys, please. Calls may be recorded for legal purposes.
Re: rant Re: Over-utilisation of v6 neighbour slots
Hi Andrew and list, Andrew Yourtchenko ayour...@gmail.com writes: I've tweaked the subject, so the folks can filter it out if needed, given that the discussion is way above L4 :-) good move, thanks. Anyway, there are things on the Internet beyond HTTP/s and HTML... True. FTP active mode. It's immortal. :-) ...because it doesn't support cookies:-) [Fingerprinting at various protocol layers] The problem I think did not really exist at the time IPv6 was defined - so it is not fair to say we have had an occasion. Bad choice of words on my side: s/occasion/opportunity/ Let me rephrase my statement: IPv6 had the chance to start over from scratch (within the boundaries of the network layer and the socket API, that is). HTTP/s and HTML never had that. (Nor had SMTP, IMAP, DNS and a host of other protocols.) And now it is http://xkcd.com/927/. Tricky. The good news here is that the protocol version field in the IP header is only 4 bits wide---we won't see more than 16 different IP versions around:-) If we wanted to do this properly, why not switch from Ethernet to PPPoE all the way--- This has triggered my fantasy to go far and wild enough that even I considered that the result does not belong to a mail on the technical list, so I instead edited it into a little fiction piece, which I hope you might find entertaining: http://stdio.be/blog/2013-10-25-One-completely-random-passage-of-thought/ Andrew, take it easy on the coffee...maybe switch to something healthier, like methylated spirit or so. On a more serious note: Some of the approaches you mention would be rather exciting at least from an academic point of view, but they would force us start over with an entirely new network stack. Considering the time it took IPv6 to come to (some sort of) speed and our age, we would unlikely live long enough to see this happen... Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform.http://www.stepladder-it.com/
Re: Over-utilisation of v6 neighbour slots
Hi Phil and list, Phil Mayers p.may...@imperial.ac.uk writes: Shrug. People have them (in quantity) because they're cost effective and did a mix of stuff that no other box did, that it turns out a lot of people wanted, and in most cases tolerably well. the problem here is that with mobile devices getting increasingly popular, the design of the supervisor engine is outdated. So I agree with James that we have to cope with, where we is the entire industry, including the router vendors. In my opintion the problem here is not so much Apple, but Cisco. While I understand that CAM/TCAM is painfully expensive in hardware, in the long run increasing its size is the way to go. On the Cisco side, the 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). Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform.http://www.stepladder-it.com/
Re: Over-utilisation of v6 neighbour slots
Benedikt Stockebrand b...@stepladder-it.com writes: 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). Interesting excercise for anyone with more time than TCAM: Implement segmentation for IPv6, assuming that renumbering Just Works for any WiFI device, while keeping the oversized L2 domain for IPv4. Bjørn
Re: Over-utilisation of v6 neighbour slots
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. On devices where the FIB is a relatively fast-but-inflexible architecture - like TCAM - good sizing decisions at design time need to be married with smart algorithms at runtime (i.e. partition TCAM dynamically not statically at reboot!). Sup720 doesn't do well in both categories! 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. 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. And it provides negligible - perhaps zero - improvement in privacy. 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. 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. I understand that CAM/TCAM is painfully expensive in hardware, in the long run increasing its size is the way to go. On the Cisco side, the 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. 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. That said, we are pondering moving the wireless routing off onto dedicated devices - anyone got any recommendations? ;o) Cheers. Phil
Re: Over-utilisation of v6 neighbour slots
Oops... Benedikt Stockebrand b...@stepladder-it.com writes: Hmm, I wonder how that scales. CAM/TCAM is of AC(1) complexity, which is what RAM can't do---trees, tries and whatnot in RAM have AC(n) complexity. make that AC(0) and AC(1), respectively. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform.http://www.stepladder-it.com/
Re: Over-utilisation of v6 neighbour slots
Anyway, the users will have to pay for that. Too bad users of !AAPL have to subsidize those decisions. Time for an AAPL user NAT tax? :) Interesting idea. Put AAPL-OUI's IPv4-traffic in lousy-queue in the BNG? :} Or generally, help IPv6 out a little by adding general IPv4-(latency)-tax? /M signature.asc Description: This is a digitally signed message part
Re: Over-utilisation of v6 neighbour slots
On Thu, Oct 24, 2013 at 03:14:52PM +0200, Martin Millnert wrote: Anyway, the users will have to pay for that. Too bad users of !AAPL have to subsidize those decisions. Time for an AAPL user NAT tax? :) Interesting idea. Put AAPL-OUI's IPv4-traffic in lousy-queue in the BNG? :} Nah. The problem is that the AFTR doesn't see Ethernet MACs, so you cannot really distinguish AAPL traffic from others. Otherwise you could delay SYNs from AAPL devices by a certain amount. Or generally, help IPv6 out a little by adding general IPv4-(latency)-tax? That would punish the innocent majority. Anyway, we had this discussion before: http://lists.cluenet.de/pipermail/ipv6-ops/2012-June/007060.html Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Re: Over-utilisation of v6 neighbour slots
On Thu, 24 Oct 2013, Tore Anderson wrote: I'd like an option to rotate my privacy address for every TCP session. Considering that DAD needs a couple of seconds to complete before a new privacy address is usable, I bet you'd change your mind about pretty quickly... (Well, I suppose happy eyeballs might prevent the user experience from becoming a total disaster.) Nah, just pre-provision a number of privacy addresses and stay ahead of the demand. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross
Re: Over-utilisation of v6 neighbour slots
On 22 Oct 2013, at 06:03, Eric Vyncke (evyncke) evyn...@cisco.com wrote: IMHO iOS obviously implemented the first part but not the second part ;-) But, the rapid rate of new RFC 4941 addresses for iOS has another impact because network devices cannot anymore limit the number of IPv6 addresses per MAC address in order to prevent a local DoS. Yes, thanks for breaking our IPv6 network with that one in your FHS implementation Eric :) Tim
Re: Over-utilisation of v6 neighbour slots
On 22/10/2013 17:18, Sam Wilson wrote: It's stuff like this that makes me think it's *still* not time to offer a general v6 service. generally, the sup720 is not a good edge device for third party L3 services due to rate limiter issues. Nick
Re: Over-utilisation of v6 neighbour slots
On 22 Oct 2013, at 06:03, Eric Vyncke (evyncke) wrote: But, the rapid rate of new RFC 4941 addresses for iOS has another impact because network devices cannot anymore limit the number of IPv6 addresses per MAC address in order to prevent a local DoS. So, either you disable SLAAC and rely on stateful DHCPv6 (but then Android is not happy) or use aggressive time to clean the ND cache... ... with the attendant difficulty in tracing systems that might be doing Bad Things. We have a mixture of Sup2Ts and Sup720s and we don't (yet) have v6 enabled on most of them. It's stuff like this that makes me think it's *still* not time to offer a general v6 service. Sam -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Re: Over-utilisation of v6 neighbour slots
On 22/10/13 10:18, Sam Wilson wrote: On 22 Oct 2013, at 06:03, Eric Vyncke (evyncke) wrote: But, the rapid rate of new RFC 4941 addresses for iOS has another impact because network devices cannot anymore limit the number of IPv6 addresses per MAC address in order to prevent a local DoS. So, either you disable SLAAC and rely on stateful DHCPv6 (but then Android is not happy) or use aggressive time to clean the ND cache... ... with the attendant difficulty in tracing systems that might be doing Bad Things. We have a mixture of Sup2Ts and Sup720s and we don't (yet) have v6 enabled on most of them. It's stuff like this that makes me think it's *still* not time to offer a general v6 service. I disagree - and since I'm the one who posted about the problem, I call dibs on getting to decide how serious it is ;o) We offer a general IPv6 service, and we've had very few real problems. It is NOT as hard as people make out, and if you wait until every last problem is solved, you'll be waiting forever. You'll also be missing out on the opportunity to learn about issues early and influence your vendors and your own future purchases in appropriate ways. Hold off on IPv6 is something I would recommend to my competitors...
Re: Over-utilisation of v6 neighbour slots
Hi Phil, 1. Has anyone else run into this sort of thing (neighbour table exhaustion) and what kind of approach did you take to solving or ameliorating it? DHCPv6? We run to the same problem as well. Not on wireless network, but on large Ethernet campus. The problem is, that we are stacking several switches to one virtual. The benefits are great, but the problem is that the cache size is not combination of the physical switches size, but is the size of one physical switch. This is understandable, but you will face the same problem as on the wireless network - cache exhaustion. Decreasing the exhaustion time was the first solution, but than we have to move several VLANs to another switch, to load balance the caches. 2. Does anyone know if Apple (and other vendors) understand the negative consequences of their aggressive rotation of IPv6 privacy addresses, and are going to address it? Probably not, because Windows behaviour is the same. Not so aggresive, but this is because of personal computers are used in different way than mobile phones. 3. Does anyone know if any equipment vendors have more intelligent strategies for handling this kind of situation - LRU expiry of v6 neighbours at 90% util rather than self-destructing FIB overflow, for example ;o) The HP/H3C we are using will deny creation of a new record which is also quite bad. Everythink works for already connected clients but new clients fail. It's great for throubleshooting. [We're aware the sup720 is old, but it seems like this could be an issue even for more recent devices at sufficient scale] Absolutely, we tested switches of several vendors and the problem is the same. The cache size for IPv6 is always smaller than IPv4 cache size and this is a problem, because even in the perfect use case, you need twice as big IPv6 cache as IPv4 - link local + global addresses. Regards, Matej smime.p7s Description: S/MIME Cryptographic Signature
Re: Over-utilisation of v6 neighbour slots
On Oct 22, 2013, at 3:18 AM, Phil Mayers p.may...@imperial.ac.uk wrote: On 10/22/2013 04:56 AM, Doug Barton wrote: Has anyone communicated directly with the Apple folks on this issue? How would one even *do* that? I unicasted this offline to someone I know at Apple: hopefully she can get attention from the right people. David Barak
Over-utilisation of v6 neighbour slots
All, We ran into an interesting issue on our wireless network today, caused mainly by the known behaviour of Apple clients in generating fresh privacy addresses every time there's a power sleep/wake state change (i.e. a lot) combined with a non-default NS/ND config on our side. Specifically, our Cisco 6500/sup720 ran out of IPv6 FIB slots, as num_routes + num_neighs exceeded 32k (the default IPv4/IPv6 TCAM split on this platform being 192k/32k). This was probably exacerbated by longer-than-default NS cache timeouts on our part, recommended in response to CPU issues we faced as discussed here: http://www.gossamer-threads.com/lists/cisco/nsp/161344 To combat the issue I cranked the nd reachable-time down from 900 to 300 seconds and re-carved the TCAM to give 64k IPv6 and reloaded, but it was all most troubling. To give an idea why, some stats: 10576 distinct MAC addresses with 1+ global IPv6 addresses 29610 IPv6 addresses (not including LL) 25.3% of hosts with = 4 v6 address 17299 IPv6 addresses consumed by that 25.3% That is, ~25% of hosts consuming ~59% of the addresses in-use. OUIs for the MAC addresses in question were almost entirely Apple. Distribution was: frequencyrel. cum. 14651 43.98% 43.98% *** 22084 19.70% 63.68% *** 31164 11.01% 74.69% *** 4 729 6.89% 81.58% ** 5 560 5.30% 86.88% * 6 387 3.66% 90.54% * 7 276 2.61% 93.14% 8 206 1.95% 95.09% 9 177 1.67% 96.77% 10 120 1.13% 97.90% 11 70 0.66% 98.56% 12 50 0.47% 99.04% 13 26 0.25% 99.28% 14 29 0.27% 99.56% 15 16 0.15% 99.71% 16 13 0.12% 99.83% 17 9 0.09% 99.91% 18 5 0.05% 99.96% 19 1 0.01% 99.97% 20 2 0.02% 99.99% 24 1 0.01% 100.00% Some questions: 1. Has anyone else run into this sort of thing (neighbour table exhaustion) and what kind of approach did you take to solving or ameliorating it? DHCPv6? 2. Does anyone know if Apple (and other vendors) understand the negative consequences of their aggressive rotation of IPv6 privacy addresses, and are going to address it? 3. Does anyone know if any equipment vendors have more intelligent strategies for handling this kind of situation - LRU expiry of v6 neighbours at 90% util rather than self-destructing FIB overflow, for example ;o) [We're aware the sup720 is old, but it seems like this could be an issue even for more recent devices at sufficient scale] Cheers, Phil
Re: Over-utilisation of v6 neighbour slots
On Oct 21, 2013, at 3:35 PM, Phil Mayers p.may...@imperial.ac.uk wrote: Some questions: Another question: 4. Does Apple's approach to IPv6 privacy addresses properly support the intent of privacy addresses? My tentative answer is, Yes, and we need to learn to cope. James R. Cutler james.cut...@consultant.com
Re: Over-utilisation of v6 neighbour slots
On 21/10/2013 21:19, Cutler James R wrote: 4. Does Apple's approach to IPv6 privacy addresses properly support the intent of privacy addresses? My tentative answer is, Yes, and we need to learn to cope. The general approach perhaps, but the rollover timing is way, way too aggressive IMO. It should be on a timer, not driven by PHY wake events. Even 300 seconds would be an improvement over the behaviour we're seeing. As to we need to learn to cope - lots of networks have huge amounts of capital investment which can't just be ripped out and replaced overnight because Apple have decided to be aggressive with address rollovers. If the main outcome is for FIB-pressured sites to disable IPv6 on OUIs registered to Apple, it's a retrograde step ;o) Maybe we need a neigbour un-advert ICMPv6 message that the old addresses could be torn down with.
Re: Over-utilisation of v6 neighbour slots
Has anyone communicated directly with the Apple folks on this issue? Doug On 10/21/2013 01:37 PM, Phil Mayers wrote: On 21/10/2013 21:19, Cutler James R wrote: 4. Does Apple's approach to IPv6 privacy addresses properly support the intent of privacy addresses? My tentative answer is, Yes, and we need to learn to cope. The general approach perhaps, but the rollover timing is way, way too aggressive IMO. It should be on a timer, not driven by PHY wake events. Even 300 seconds would be an improvement over the behaviour we're seeing. As to we need to learn to cope - lots of networks have huge amounts of capital investment which can't just be ripped out and replaced overnight because Apple have decided to be aggressive with address rollovers. If the main outcome is for FIB-pressured sites to disable IPv6 on OUIs registered to Apple, it's a retrograde step ;o) Maybe we need a neigbour un-advert ICMPv6 message that the old addresses could be torn down with.
