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 18:28 , james woodyatt wrote:

> Were RFC 4429 and I-D.ietf-6man-dad-proxy among the documents you read over the weekend?

I only read the introduction and problem statement of RFC 4429 and neither seemed to address my concerns, thus I skipped the rest. I just browsed through it a bit and I still fail to see that it addresses my concern; the fact that it mentions that the likeliness of a collision is tiny in practice is certainly good, but making a tiny change to existing RFCs to make it impossible will always be better IMHO.

I have not heard of I-D.ietf-6man-dad-proxy so far, so I just browsed over this one as well, however despite the fact that it is a draft, may never leave draft status, may not be implemented for years even if it will ever leave draft status, it does not seem to address my concerns either, but rather a problem related to the limited propagation of DAD traffic (this is for sure also a problem, but not in my scenario).

Maybe I was not able to express my concerns appropriately, after all I tried to express them as abstract as possible. Maybe I can explain them better if I try to explain them by example. Let's take the LAN network of a tiny company, for simplicity we assume that the WLAN network and the LAN network are bridged to make automatic device discovery work out of the box. This may not be a wise setup from a security perspective but I have seen such a setup far too often in my life to call it unrealistic. In such a network we will have four kind of hosts:

1) Static servers (e.g. a DNS server, a file server, a mail server, ...) and comparable devices (e.g. network printers). Those devices will usually have a static manual assigned IP address, since this simplifies hardware replacement and DNS management, as you usually want to have DNS entries for all of these hosts.

2) Static workstations, desktop computers that are permanently connected to the network and never leave the building. However those hosts are not turned on 24 hours a day, they are only running when they are in use, so from a network perspective they might come and go several times a day. Those hosts are "well known" and thus usually shall have a well known IP address and a DNS entry. To simplify administration they will receive their addresses via DHCP, that means a specific IP address has been reserved for each of them within the available address pools and they will always receive the same IP address each time they are turned back on and have to renew their previous lease. This way all management happens within central places: the DHCP and the DNS server.

3) Mobile workstations, notebooks that can also leave the building. Those are exactly like hosts of type (2), they might just join and leave the network more often, but anything I wrote for type (2) applies to them as well. They are also well known and thus their addresses are managed via DHCP.

4) Mobile devices, e.g. mobile phones or tablet devices. These devices are not necessarily well known and since they usually won't offer any important services to other hosts, it is not necessary that they have a static IP address or a DNS entry. For those devices it is sufficient and acceptable to create addresses via stateless address configuration. Some of these devices may not even support DHCPv6, since DHCPv6 is not widely supported at the moment (so far I have not seen DHCPv6 support in any MacOS X version for example), while any device with IPv6 support seems to also support stateless auto configuration.

If we ignore the existence of the privacy extension, I claim that the scheme above will be collision free. Devices of type (4) can only collide if global unique MAC addresses are manually overwritten or a vendor makes a mistake and accidentally reuses MAC addresses. DHCP and manual addresses will be selected appropriately to avoid collisions by network administrators and I fail to see how stateless addresses of devices of type (4) should ever collide with DHCP or manual addresses, if those will have up to 6 zero bytes in front, which is usually what admins want in the first place.

However, there is no way you can prevent devices of type (4) to use the privacy extension for stateless configuration, which would be no concert in general, if those addresses could never conflict with any other addresses mentioned above... but they can. The address might match exactly one of the reserved DHCP addresses and since the device of type (2) or (3) - lets name it DevX - might either be turned off or otherwise currently not connected to the network, DAD will not show any conflict. When DevX comes back while the temporary address is still in use, it will not be able to take the address that it is supposed to have and that will be offered to it by DHCP (if it even will be offered at all).

If you suggest that this is no problem, after all DevX will detect the conflict via DAD and can simply pick another address by any other means, you are not solving the problem. DevX is supposed to have its reserved DHCP address and the DNS entry for it is supposed to point to exactly this device. The offending device should have never been allowed to pick the conflicting address in the first place. This whole situation would have easily been avoidable by tightening the constrains of what qualifies as a legal temporary IPv6 address and what not.

Further when reading your mail, I got the impression that you are trying to add in security aspects to the mix, but I'm really not talking about security aspects. That a malicious attacker might intentionally configure one of the DHCP addresses manually to "take the place" of a workstation while this workstation is being away of the network was never part of my concern. This is a different scenario. My mail was never about protecting against an attack scenario where a host "steals" an IP  address of another host, but only about the fact that an device may "accidentally" steal it, without the device or its owner ever intending to do so.

Regards,
Markus