[afnog] A heads up on a nasty IPv6 bug

[Andrew Alston]

The original theory (this was out of Cisco’s deployment guide, which now, having learnt a bit more, I realise was talking nonsense) had to do with clients disconnecting and reconnecting and override of old entries.

One thing we are finding (and thanks to Jan who pointed this out to me as well), is that Dynamic V6 on the mass market creates problems.

Particularly if you are doing a DHCPv6-PD and then grabbing a segment of the PD to assign to the LAN interface which in turn does RA.  Because if the client reconnects and gets a new DHCPv6-PD segment, and the RA then changes towards the client, the client ends up with two v6 subnets and two gateways until the RA expires, and this breaks things on a number of platforms. (And also ends up with certain large content providers seeing breakage and blacklisting recursives as a result lol)

The general consensus that I’m seeing elsewhere is that when doing v6 to the mass market, static is better and full of far less problems, and that’s what we’re switching to now with a provisioning system, so v6 prefix to every client will be static.

Andrew


From: Mark Tinka <mark.tinka at seacom.mu>
Date: Sunday, 14 August 2016 at 3:49 PM
To: Andrew Alston <Andrew.Alston at liquidtelecom.com>, "afnog at afnog.org" <afnog at afnog.org>
Subject: Re: [afnog] A heads up on a nasty IPv6 bug


On 14/Aug/16 12:09, Andrew Alston wrote:
Hi Guys,

Figured I’d share this because someone might run into the issue I did last night and after how long it took to figure out what was going on, rather give people a heads up.

Under Cisco IOS-XR 5.3.3 AND under 6.0.2 (though the documentation on the bug explicitly states its fixed in 6.0.2, its NOT), do not, under any circumstances, run ipv6 nd router-preference high anywhere.

That's a nasty bug.

I've only ran ND Router Preference in LAN scenarios, to avoid situations where Windows Vista and Windows 7 clients automatically enabled 6-to-4, and claimed to be the authoritative default gateway for the LAN.

The solution ended up being pointless as there was no way to fully guarantee that the true router was the one with the highest preference for the LAN.

The ultimate solution for this is RA Guard, which I believe now has reasonable support on decent Ethernet switches in the wild.

I'm curious, though, why you'd need this on a point-to-point link, where the remote side (CPE) may not be setup to announce ND RA's back to the BNG.

Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.afnog.org/pipermail/afnog/attachments/20160814/0759acc8/attachment.html>