Re: Why has RFC 4941 been designed in such a way, that it might cause address conflicts?

[Markus Hanauska <[e-mail]>]

On 2011-03-16, at 11:27 , Philip Homburg wrote:

> You look up the MAC address for that IPv6 address and then block the MAC
> address on your switches. Problem solved.

Sure, that will work. However, that means I have to invest time and work to solve a problem, that would have easily been avoidable by a tiny standard change and that did not arise because anyone made a mistake, it just has been recklessly accepted by the standard creators, because it seemed unlikely. And this is a lot of work, since I cannot block it globally, but I have to work my way through all our managed switches and I will get a problem on some parts of the network, where unmanaged switches are used, which I might have to reboot after blocking to flush their address cache.

> You can slightly better than that. For wired connections, you can look up
> to which port the offending system is connected, and with an up-to-date cable
> plan you can also find it.

Still I have to work my way through all managed switches and if connected to an unmanaged switch, I can only take down the switch at a whole.

At the moment, I'm rather considering to choose a smaller address prefix than /64 for the network, which will disable stateless addresses entirely (even on devices that don't listen to the A flag in RA messages) and only use DHCPv6 which solves all my worries. Of course that means only Windows and Linux hosts can be added to the network for the time being since MacOS X has no DHCPv6 support, so bad luck for those. If all DHCPv6 clients support obtaining two IPs via DHCP, one "normal" IP and one temporary, to avoid that they are traceable from outside is questionable, but I'm investigating to solve this issue by having the border router perform random IPv6 NATing for the LAN, where for every internal address a random external address is being created and used whenever packets leave our network.

Best regards,
Markus