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

[Mohacsi Janos <[e-mail]>]

On Mon, 14 Mar 2011, Markus Hanauska wrote:

> Since IPv6 plays an increasingly prominent role in planing network environments, I spent most of the weekend to think about IPv6 distribution strategies for our company and my home Internet connection, re-reading most of the important RFCs and I came across a serious address deployment issue that seems to not be addressed by any of them. I searched the Internet, since I could not believe nobody every came across that issue, but after reading over 100 web pages and over 50 papers regarding IPv6 address deployment, this issue either has not been discovered up to now or has been intentionally ignored. I must admit, the issue is highly unlikely to ever cause a problem in real life scenarios, but as a programmer there is a huge difference between "impossible" and "highly unlikely", and I definitely prefer "impossible".
>
> B) DHCPv6 according to RFC 3315 - either randomly distribute addresses from available pools or possibly even reserve certain addresses for certain hosts by MAC address.
>
> C) Stateless Address Autoconfiguration according to RFC 4862 - currently the auto configuration scheme supported by most operating systems and devices. This major case has four important major sub-cases that people tend to ignore in general (there are some more minor sub-cases, but I'd like to ignore those here as well):
>
> 	C1) Device has a globally unique EU-/MAC-48 identifier
> 	C2) Device has NO globally unique EU-/MAC-48 identifier, but one manually assigned by a network admin
> 	C3) Device has a globally unique EU-64 identifier
> 	C4) Device has no globally unique EU-64 identifier, but one manually assigned by a network admin
>
> D) Stateless Address Autoconfiguration with Privacy Extension according to RFC 4941

I think D) is still C) but IID is generated randomly.

>
> Mixing (A) and (B) shouldn't be a problem, just like in case of IPv4 
> admins only have to make sure that the manual addresses never overlap 
> any DHCP address pool; this should be easily enforceable. E.g. reserve 
> <prefix>::1 to <prefix>::FF (sorry for using upper case hex, it just 
> reads better on my screen) for manual assignment (254 addresses) and 
> <prefix>::100 to <prefix>::FF:FFFF as DHCP pool (over 16 mio DHCP 
> addresses).

This assignment is overly restictive.

>
> What most people tend to ignore are the cases (C2) and (C4), where the 
> "u" bit will not be set after inverting it and those cases are not plain 
> hypothetical, I have seen them in real-life more than once.

Can you desctibe the environment you encountered such a setup?

> There exists 
> still no problem in case of (C2), since FFFE will be added to the 
> address and network admins are thus advised to not choose manual and 
> DHCP address ranges in such a way, that they might ever have FFFE at the 
> same position.

In DHCP address assignment you should not use range with u bit 1.

>
> So far all these standards peacefully coexist with each other... 
> however, case (D) does not. Case (D) can conflict with all other cases, 
> except the cases (C1) and (C3). And that even though a tiny modification 
> of RFC 4941 could entirely avoid this issue. A modification that would 
> lead to maybe four lines of code in most IPv6 implementations out there. 
> All that was necessary was adding the rule, that those random addresses 
> must never start with three zero bytes and the address generation 
> process must be repeated if such an address is generated on the first 
> attempt. I must admit, an MD5 hash where the first three byte are all 
> zero is rather unlikely but it is not impossible; unless someone can 
> prove to me mathematically, that given the possible input data, such an 
> outcome is absolutely impossible. However, bear in mind that the RFC 
> does not require the usage of MD5, it only suggests it and even if it is 
> impossible for MD5, who can guarantee it will be impossible for all 
> other e xisting hash functions in the world that will ever be used for 
> IPv6 address generation? I don't think I have to explain here how case 
> (D) can conflict with all the other cases, since the address is 
> unpredictable, any result is possible. And bear in mind, that other RFCs 
> even mention cases where a device might create its 64 bit host ID 
> entirely "random"; which is even worse than using a hash function.

You ususally add privacy enhanced addresses next to other addresses. The 
other addresses still exist in case of Duplicate Addrees scenario.

>
> I know what people will probably reply up to this point: No conflict can 
> ever arise, duplicate address detection (DAD) is going to prevent that. 
> And here is my reply: How is DAD preventing this problem if the device 
> with the conflicting address in question is not connected to the network 
> the moment DAD is performed? E.g. the address of type (D) conflicts with 
> a DHCP address (very unlikely, but possible), a DHCP address that has 
> been reserved for a certain mobile device, which currently is not 
> connected to the network. DAD will not see any conflict and assign the 
> IP to some other device. If now the mobile device is added to the 
> network, it cannot obtain its reserved DHCP address. Of course the same 
> is true for server with an manually assigned IP address that is only 
> turned on at certain times of the day for example. And the same problem 
> arises for a mobile device with a manual assigned interface ID as in 
> cases (C2) or (C4).



Yes. DAD can fail, and you system log you will see.

Best Regards,
 		Janos Mohacsi