Re: [v6ops] new draft: draft-gont-v6ops-slaac-issues-with-duplicate-macs

[Mattia Rossi <[e-mail]>]

Am 17.10.2012 14:47, schrieb James M Keller:
> On 10/16/2012 3:54 PM, Mark Smith wrote:
>> I haven't read it thoroughly, however a few general comments to get
>> the ball rolling: - duplicate MAC addresses (by hardware vendors) are
>> generally much rarer than the draft suggests. I haven't ever come
>> across them in 20 or so years of dealing with ethernet, and I've only
>> heard very few first hand accounts of them being encountered. From
>> what I've heard, they've been accidents by vendors, e.g. server bios
>> installs at the factory that didn't increment MAC addresses on each
>> new install.
> This has become more of an issue of late with virtual hosting systems
> generating MAC addresses for VM NICs and then moving images between
> environments and ending up with a collision vs physical hardware
> burned-in-addresses.
>
I can agree on that, MAC duplication happens quite often with 
duplication of VM's.
Although you'd probably experience Ethernet issues before you come to 
the IPv6 SLAAC issues in most of those situations. Depends on how the 
network's segmented of course.
See section 5.4.5 in RFC 4862:

"In this case, the IP address duplication probably means duplicate 
hardware addresses are in use, and trying to recover from it by 
configuring another IP address will not result in a usable network. In 
fact, it probably makes things worse by creating problems that are 
harder to diagnose than just disabling network operation on the 
interface; the user will see a partially working network where some 
things work, and other things do not. "

So this is already in contrast with the draft.

Additionally I disagree on the point that RFC 4862 doesn't say what to 
do on DAD, as it states:

5.4 Duplicate Address Detection
[snip]
If the address is derived from an interface identifier, a new identifier 
will need to be assigned to the interface, or all IP addresses for the 
interface will need to be manually configured.
[snap]

It says that a new identifier needs to be assigned. Doesn't say how, but 
it does say it has to.

So, I think the behaviour of DAD described in this draft is actually 
correct. If this poses a problem we should think about rewriting section 
5.4 of RFC 4862 and update the RFC, otherwise we end up with two quite 
contrasting standards.

Mat