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

[Markus Hanauska <[e-mail]>]

On 2011-03-15, at 21:35 , james woodyatt wrote:

> Let me try again... there is no "tiny change" to existing RFCs that can make it *impossible* for address conflicts to arise.

This seems an rather odd reasoning to me; it's like saying "An algorithm, that solves only one specific problem, is bad because the world is full of so many other problems it doesn't solve". I'm not in particular worried about conflicts between two devices that use both some kind of stateless address configuration (by interface ID, privacy extension, or both), since those devices will only create stateless addresses while they are connected to the network and thus DAD will work to detect those conflicts and devices are able to do whatever they wish to resolve them; e.g. just picking another random address. Since it doesn't really matter for stateless devices which IP they'll have, picking one IP seems as good as picking any other IP IMO. My main concern always has been that stateless devices might conflict with IP ranges that are reserved by the network admin for DHCP clients and manually configured servers. And to avoid this scenario, a single sentence and at most 4 lines of code in implementations would be enough already. I cannot understand what would be so bad about limiting the address range of the privacy extension in such a way, that a *tiny* fraction of it is reserved to create a "safety-zone" which admins can use for static or DHCP pool addresses. After all RFC 4941 already does that:

"Compare the generated identifier against a list of reserved interface identifiers [...]"
	- RFC 4941 - 3.2.1

And as an example the reserved anycast addresses of RFC 2526 are explicitly mentioned. All that I was asking was why such a reserved address range has not been created for admins that need static addresses on the network (manually assigned or assigned by DHCPv6), however, the devices that will use them are not permanently connected to the network and thus DAD will simply *not work*. DAD can only prevent that there will ever be an address conflict, but it does not prevent a device from *accidentally* picking an address (and that is important, I'm not worried about intentionally picking one) that has been reserved for another device currently not connected to the network. It's great that I will get informed when such a conflict arises, but how should I resolve it? Assigning a different static IP to the device (again, manually or by DHCP) resolves the IP address conflict, but may still prevent proper operation of the network, since now the server or other device in question won't have the IP it is supposed to have and other devices may rely on that IP.

For EUI/MAC-48 such a safety zone exists implicitly, for EUI-64 addresses it only exists if the u bit is set (and is not set for the static or DHCP addresses), but that should almost always be the case; despite that this won't be an issue on most networks as long as network ethernet network adapters have 48-bit addresses and in networks where EUI-64 is already in use today neither DHCP nor manual assigned addresses are in use.

> EUI-48 and EUI-64 addresses with global uniqueness flags are not always globally unique because factories make errors.

Yes, I got that point, but this is nothing I'm worried about. These are conflicts that will prevent one device joining the network because another device with the same EUI is already on the network; an in that case assigning a different IP also won't resolve the conflict, since the devices would still conflict on layer 2, which is probably even worse than a conflict on layer 3. The tiny change I suggested would not solve this problem, well, but it will still solve the problem I'm worried about.

> manual configuration procedures are-- sing it with me-- prone to manual error

Yes, it certainly is. If I mess up the manual configuration, it's my fault and there is nobody to blame but myself. And it will also be me who has to fix the mess. However, if standards, that are supposed to cooperate and automatically work on my behalf, mess up the configuration, who can I blame then and who is going to fix it? Further saying "Don't do something that can go wrong if you make a mistake" seems another odd reasoning, since pretty much everything you do can go wrong if you make mistakes and by that reasoning I better stop touching my computer right away.

Best regards,
Markus