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

From: Markus Hanauska <[email-masked]>
Date: Mon, 14 Mar 2011 13:00:11 +0100

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".

I assume you are all familiar with all those RFCs in question, thus I don't want to bore you more than necessary, but I have to go into greater detail to make sure my concern is correctly understood. Assuming that you plan address distribution according to the 64/64 rule of RFC 4291, using 64 bit network ID and 64 bit host ID, there are 4 major ways how to distribute the addresses:

A) Manually - definitely necessary for routers and most likely a good idea for permanent services (DNS-, mail-, file-servers, etc.)

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

You can pick either scheme above or you can pick multiple at the same time. The second case implies that all these four schemes must peacefully coexist within the same network at the same time, and exactly this is *NOT* the case. Let me explain my concerns to you:

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).

Adding (C) to the mix is no problem either, but only if you are aware of some border cases that are to be avoided. In most cases (C) means (C1) or (C3) and that means no conflicts are to be expected, since (C1)+(C3) have addresses which have the "u"-bit set to indicate global uniqueness, while this bit is never set in cases (A) and (B) - this is the original intention behind "inverting" the bit according to the RFC. 

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. 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. This leaves only (C4) addresses that might potentially conflict with cases (A) and (B) and this is easily to be avoided by making sure network admins never manually assign local hardware identifiers where the vendor ID (the first three bytes of the identifier) are all zero. Not that it would be forbidden to do so, but considering the case of potential conflicts, it is just not advisable and also avoidable.

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 existing 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.

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).

I think we can safely ignore any security aspects here, since an attacker can always manually assign any address to any interface he likes, possibly using a manipulated IPv6 implementation that will simply never perform DAD. If someone wants to create address collisions by intention, there is no easy way to stop him and there are other standards that deal with host authentication. I'm only concerned about the fact that a couple of address deployment schemes that were designed to be simple and to ease the life of all network admins and home users, were not designed to always peacefully coexist within a single network, where hosts might come and go any time. Has this issue really been intentionally ignored, because given 2^64 addresses, the likeliness of a collision was seen as too unlikely to ever take place in real-life?

Regards,
Markus Hanauska

---

From: Philip Homburg <[email-masked]>
Date: Tue, 15 Mar 2011 16:58:04 +0100

In your letter dated Mon, 14 Mar 2011 13:00:11 +0100 you wrote:
>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.

I think the answer is that is statistically very unlikely that on a single
subnet, a 64-bit random number will ever be equal to any address manually
configured in DHCP.

Is is far more likely that by accident to ethernet cards have the same MAC
address than that a true 64-bit random number will collide with another number
out of a relatively small set.

---

From: james woodyatt <[email-masked]>
Date: Tue, 15 Mar 2011 10:28:07 -0700

On Mar 14, 2011, at 05:00 , Markus Hanauska wrote:
> 
> [...] 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? [...]

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

In general, you cannot prevent address conflict simply by reserving interface identifier patterns according to a strict plan.  No plan ever survives its initial encounter with the enemy.  Address conflicts MUST be dynamically resolved by protocol action, and protocols can fail when packets are lost.  Retransmits help reduce failure rates, but failure cannot ever be made logically impossible.  (There is math for that claim.)

Duplicate Address Detection (DAD) is the mechanism by which address conflicts are resolved in IPv6.  If you set DupAddrDetectTransmits to zero on an interface where DAD is required to prevent address conflicts, then the network isn't required to work properly when you do that.  If the subscriber aggregation network by which you're connecting a mobile node to the Internet requires a DAD proxy to prevent address conflicts, and the DAD proxy is malfunctional, then you can expect damaged network service as a result.  There is nothing special about RFC 4941 temporary addresses or RFC 3972 cryptographic addresses in this regard.

Plan accordingly and stay calm.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Markus Hanauska <[email-masked]>
Date: Tue, 15 Mar 2011 19:04:48 +0100

> subnet, a 64-bit random number will ever be equal to any address manually

I'd say this entirely depends on how the (usually pseudo-) random number has been created. No RFC says it is forbidden to choose a random IPv6 address by simply picking a number between 1-255 and pad all the bits to the left with zeros. It may not be very advisable to do that, but it is not disallowed either. If there was a rule like I suggested ("the first three bytes must not be zero"), such an address would be forbidden, of course.

> out of a relatively small set.

See above, choosing a "very poor" random number makes this scenario very likely and no RFC demands that "good" random numbers must be chosen, nor does any of them define what "good" means in this context. A random number with 3 zero bytes in a row is probably "not good", but can nonetheless be considered random.

How would two ethernet cards have the same MAC address, unless it has been manually configured? Doesn't globally unique mean "globally unique" anymore?

Regards,
Markus

---

From: Philip Homburg <[email-masked]>
Date: Tue, 15 Mar 2011 19:27:44 +0100

In your letter dated Tue, 15 Mar 2011 19:04:48 +0100 you wrote:
>> I think the answer is that is statistically very unlikely that on a =
>single
>> subnet, a 64-bit random number will ever be equal to any address =
>manually
>> configured in DHCP.
>
>I'd say this entirely depends on how the (usually pseudo-) random number =
>has been created. No RFC says it is forbidden to choose a random IPv6 =
>address by simply picking a number between 1-255 and pad all the bits to =
>the left with zeros. It may not be very advisable to do that, but it is =
>not disallowed either. 

Yes, it is possible that some junior programmer doesn't know how to generate
a 64-bit random number. Hopefully people will figure out that some device is
broken in that regard and get the manufacturer to fix it.

But there is an easy fix for you. What if you put something in those
bytes? If you come up with a number that relates to just your
organisation, then it is very unlikely that a broken random number generator
will generate exactly that pattern.

If you just need stable addresses, then you can also put your own random
numbers in DHCP. 

>How would two ethernet cards have the same MAC address, unless it has =
>been manually configured? Doesn't globally unique mean "globally unique" =
>anymore?

No, it never did. That's the problem. From manufacturing defects (a batch
of cards all with the same ethernet address), small mistakes (a manufacturer
reusing a range) to companies that doen't know how it works and just use
some random vendor id, to cards that can just be jumpered to look some
other vendor's cards because that is what the software expects.

---

From: Markus Hanauska <[email-masked]>
Date: Tue, 15 Mar 2011 20:11:54 +0100

> 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

---

From: Markus Hanauska <[email-masked]>
Date: Tue, 15 Mar 2011 20:27:32 +0100

> If you just need stable addresses, then you can also put your own random

Of course everything will be fine if you exclusively use DHCPv6. You can have a pool with addresses for well known devices, so the same device always gets the same address from the pool, while all other devices get addresses from another pool that are more or less random.

However, there are devices that support IPv6 and stateless auto-configuration, possibly even the privacy extension, but not DHCPv6. And if a device supports both, there is no way to force the device to use DHCP; if it is "nice" it may listen to the RA managed flag, but does the RFC say that it must listen to this flag and that users may not override this flag, by configuration their device to always generate stateless addresses? Not as far as I can see and the meaning of this flag is not exactly defined (this flag does not imply DHCP, it could also imply a different protocol or manual configuration only) and I saw that even deprecation of the flag has been discussed publicly.

I just thought it would be nice if DHCP, manual configuration and stateless auto-configuration can always play together nicely within the same network, even when privacy extension is being used. Without privacy extension this is pretty much the case, except for MAC address conflicts like you mentioned previously, but when privacy extension enters the game (and don't get me wrong, I think privacy extension is a good thing and it is important that such an extension exists) this is not guaranteed any longer.

Regards,
Markus

---

From: james woodyatt <[email-masked]>
Date: Tue, 15 Mar 2011 13:35:54 -0700

On Mar 15, 2011, at 12:11 , Markus Hanauska wrote:
> 
> [...] but making a tiny change to existing RFCs to make it impossible will always be better IMHO

Let me try again... there is no "tiny change" to existing RFCs that can make it *impossible* for address conflicts to arise.  The best we can do is to reduce the probability of address conflicts from arising inadvertently under normal usage scenarios.

You seem to think that by reserving certain IID patterns for use with different address configuration schemes, we could have more than *optimism* that DAD will succeed, c.f. RFC 4429, that we could be *certain*.  No such determinism is possible.  EUI-48 and EUI-64 addresses with global uniqueness flags are not always globally unique because factories make errors.  Cryptographic and privacy addresses can collide in rare circumstances.  Most importantly, because it's the most frequent cause of error, manual configuration procedures are-- sing it with me-- prone to manual error, including but not limited to humans inappropriately loading addresses that conflict with otherwise automatically configured addresses on the network.

No certainty is possible.  Duplicate Address Detection (DAD) is your last best hope for civilization.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Mar 2011 11:54:30 +1300

On 2011-03-16 09:35, james woodyatt wrote:
...
> No certainty is possible.  Duplicate Address Detection (DAD) is your last best hope for civilization.

If you'll excuse an anecdote, while I was living in Geneva I was regularly
amused when the shiny new information screens in the shiny new buses
would display the Windows IPv4 duplicate address warning instead of
the next bus stop. Even so, the Geneva bus service hasn't come to an end.

My point? The probability of a duplicate address in an IPv6 subnet is
many orders of magnitude less than it is in IPv4. Like 1 in 2^63
instead of 1 in 2^8.

This is just too remote a probability to worry about.

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Wed, 16 Mar 2011 00:00:53 +0100

In your letter dated Tue, 15 Mar 2011 20:27:32 +0100 you wrote:
>> If you just need stable addresses, then you can also put your own >random
>> numbers in DHCP. 
>
>I just thought it would be nice if DHCP, manual configuration and >stateless auto-configuration can always play together nicely within the >same network, even when privacy extension is being used. Without privacy >extension this is pretty much the case, except for MAC address conflicts >like you mentioned previously, but when privacy extension enters the >game (and don't get me wrong, I think privacy extension is a good thing >and it is important that such an extension exists) this is not >guaranteed any longer.

What I was trying to say in the above quote is this: if you assign an
interface identifier to a host like this: ::0CB5:C04C:F5FD:DCCA then
there is no way that broken random number generator in a host will ever 
come up with that same value.
 
So just put those random numbers in DHCPv6, forward and reverse DNS, etc.

It doesn't really matter if a host uses both automatic configuration and
DHCP. It just means that it has more IPv6 addresses, which no problem. And
that reverse DNS may not work. Which may or may not be a problem.

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 16 Mar 2011 10:08:09 +0100 (CET)

> 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

---

From: Markus Hanauska <[email-masked]>
Date: Wed, 16 Mar 2011 10:47:45 +0100

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

How will this help a network admin, when the system log says, that a server that is supposed to have a certain fixed IP or a DHCP client, that is also supposed to have a certain fixed IP (however, one assigned by DHCP) cannot obtain this IP, because some other host with privacy extension enabled is currently using this IP by plain coincident? How can you resolve that problem? Running around the building and asking all people with non-DHCP devices to please temporarily disconnect of the network? Assigning a different IP to the server or the DHCP device does not resolve the problem at all, because those are supposed to have a certain IP and not any IP. Assigning a different IP to the stateless device would work, but how can you know which of the maybe 100 stateless devices on the network is the device that captured the IP?

Best regards,
Markus

---

From: Sander Steffann <[email-masked]>
Date: Wed, 16 Mar 2011 11:05:40 +0100

Hi,

> How will this help a network admin, when the system log says, that a server that is supposed to have a certain fixed IP or a DHCP client, that is also supposed to have a certain fixed IP (however, one assigned by DHCP) cannot obtain this IP, because some other host with privacy extension enabled is currently using this IP by plain coincident?

The chance of this happening is *very* *very* small. I would worry more about people choosing such an IP address intentionally to cause trouble...
Sander

---

From: Philip Homburg <[email-masked]>
Date: Wed, 16 Mar 2011 11:27:29 +0100

In your letter dated Wed, 16 Mar 2011 10:47:45 +0100 you wrote:
>How will this help a network admin, when the system log says, that a server th
>at is supposed to have a certain fixed IP or a DHCP client, that is also suppo
>sed to have a certain fixed IP (however, one assigned by DHCP) cannot obtain t
>his IP, because some other host with privacy extension enabled is currently us
>ing this IP by plain coincident? How can you resolve that problem? Running aro
>und the building and asking all people with non-DHCP devices to please tempora
>rily disconnect of the network? 

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

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.

For wireless, you want EAP anyhow, so you can just look up which user account
was used and then contact that user.

---

From: Markus Hanauska <[email-masked]>
Date: Wed, 16 Mar 2011 11:37:35 +0100

On 2011-03-16, at 11:05 , Sander Steffann wrote:

> The chance of this happening is *very* *very* small.

The chances that a MD5 hash of any data will ever be exactly zero (all octets are zero) is ridiculous tiny. It is probably so extremely unlikely that the world would rather be destroyed by a meteor tomorrow than this is ever going to happen. Still IPv6 implementations verify that the output of the MD5 hash function is not exactly zero when creating a temporary address as suggested by RFC 4941 (I verified this by source code). The scenario that I described is much more likely than a MD5 of zero, but here no code exists to prevent it.

> I would worry more about people choosing such an IP address intentionally to cause trouble...

That would rather be security issue, since why would anyone do that, unless he's doing it by intention? And if someone does that by intention, he's probably planing to do something evil.

Best regards,
Markus

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 16 Mar 2011 11:45:21 +0100 (CET)

On Wed, 16 Mar 2011, Markus Hanauska wrote:

> How will this help a network admin, when the system log says, that a 
> server that is supposed to have a certain fixed IP or a DHCP client, 
> that is also supposed to have a certain fixed IP (however, one assigned 
> by DHCP) cannot obtain this IP, because some other host with privacy 
> extension enabled is currently using this IP by plain coincident? How 
> can you resolve that problem? Running around the building and asking all 
> people with non-DHCP devices to please temporarily disconnect of the 
> network? Assigning a different IP to the server or the DHCP device does 
> not resolve the problem at all, because those are supposed to have a 
> certain IP and not any IP. Assigning a different IP to the stateless 
> device would work, but how can you know which of the maybe 100 stateless 
> devices on the network is the device that captured the IP?

The servers are "always" working. Newcomers cannot hijack their addresses 
since DAD will fail for them....

Best Regards,
 		Janos Mohacsi

---

From: Markus Hanauska <[email-masked]>
Date: Wed, 16 Mar 2011 11:48:55 +0100

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

---

From: Markus Hanauska <[email-masked]>
Date: Wed, 16 Mar 2011 11:51:58 +0100

On 2011-03-16, at 11:45 , Mohacsi Janos wrote:

> The servers are "always" working. Newcomers cannot hijack their addresses since DAD will fail for them....

Maybe on your network, but on our network some servers are only working at certain office times or when they are needed. Some "servers" are no servers in the classical sense, they are servers by "software" (they offer a certain service via a well know protocol at a well known port), not by "hardware" (they might not even be computers in the classical sense).

Best regards,
Markus

---

From: Markus Hanauska <[email-masked]>
Date: Wed, 16 Mar 2011 12:06:36 +0100

> 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.

> 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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 16 Mar 2011 16:15:40 +0100

In your previous mail you wrote:

   The chances that a MD5 hash of any data will ever be exactly zero
   (all octets are zero) is ridiculous tiny.

=> yes, I offer a free beer to you if you find one for the next
IETF meeting.

Regards

[email-masked]

---

From: Brian Haley <[email-masked]>
Date: Wed, 16 Mar 2011 12:52:00 -0400

> 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 ma…

But you have to be able to do this anyways, because someone *is* going to
configure a system wrong and cause big problems, you can't assume an RFC
will protect you.  It's even extremely easy to disable DAD and manually
configure an address on a lot of systems - what will you do then?  If you
can't secure the configuration on a host, and you can't typically, you
have to do it in the infrastructure where you *do* control everything.

If I had $1 for every time I had to track-down a system configured as
a default IPv6 router and sending bogus advertisements out, well, I'd have
about $10 :)  That's what happens when people google 'ipv6 configuration'
and blindly cut/paste commands...

-Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 20 Mar 2011 09:27:09 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
james woodyatt
Sent: Tuesday, March 15, 2011 1:28 PM
To: Markus Hanauska
Cc: [email-masked]
Subject: Re: Why has RFC 4941 been designed in such a way,that it might
cause address conflicts?

>Duplicate Address Detection (DAD) is the mechanism by which address
conflicts are resolved in IPv6.  

DAD as per RFC 4862 does not resolve conflicts but detects the
conflicts.  See section 5.4.5 which punts a duplicate detected event to
the admin of the network to deal with.

>If you set DupAddrDetectTransmits to zero on an interface where DAD is
required to prevent address conflicts, then the network isn't required
to work properly when you do that.  If the subscriber >aggregation
network by which you're connecting a mobile node to the Internet
requires a DAD proxy to prevent address conflicts, and the DAD proxy is
malfunctional, then you can expect damaged network >service as a result.

Speaking of a mobile network (cellular) where it does make sense to set
DupAddrDetectTransmits to zero since the hosts use p2p and hosts use the
Modified EUI-64 format for Interface Identifier (IID) - see RFC 2472.
Modified EUI-64 uses a global token to generate the IID and thus the IID
is likely to be unique. 

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 20 Mar 2011 17:00:29 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian E Carpenter
Sent: Tuesday, March 15, 2011 6:55 PM
To: james woodyatt
Cc: [email-masked]
Subject: Re: Why has RFC 4941 been designed in such a way, that it might
causeaddress conflicts?

>This is just too remote a probability to worry about.

In a recent IPv6 CE Router Interop in the U.S. during mid-February 2011
where such home routers were tested in a cable broadband network IPv6
link-local addresses were found to be duplicate.  My guess is that the
Interop network had 2-30 IPv6 nodes.  Two different CE routers with
different mac-addresses created the same IPv6 link-local address.  I
don't have logs from the problem but the problem can only be one of two
things.  Either the CE did not generate its IPv6 link-local address
using EUI-64 or the CE did but the CE has a bug in the code to generate
an IPv6 link-local address using the EUI-64 format that uses the
mac-address of the CE.  The CE routers are consumer devices that will
deploy with no console.  So what admin of the network will see the CE
reporting to the CE console a DAD failure for the IPv6 link-local
address?   The SP serving this home is also clueless as to what
happened!  

Stuff happens.  Others on this thread have reported they want to secure
their IPv6 networks.  We should collect a list of all issues operators
of networks and other folks are reporting and see if the existing
protocols are not able to help, let's see what else we can do.

Hemant

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Mar 2011 11:48:55 +1300

On 2011-03-21 11:00, Hemant Singh (shemant) wrote:
> Stuff happens.  

Yes, and paradoxically this illustrates my point. Passing a law that
addresses shall not conflict, or shall only conflict with a probability
of 1 in 2^63, is beside the point.

Others on this thread have reported they want to secure
> protocols are not able to help, let's see what else we can do.

Good idea, where's the wiki?

    Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 20 Mar 2011 17:50:02 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hemant Singh (shemant)
Sent: Sunday, March 20, 2011 6:00 PM
To: Brian E Carpenter; james woodyatt
Cc: [email-masked]
Subject: RE: Why has RFC 4941 been designed in such a way,that it might
causeaddress conflicts?

>My guess is that the Interop network had 2-30 IPv6 nodes.  

Sorry for the typo.  Replace "2-30 IPv6 nodes" with "20-30 IPv6 nodes".

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 20 Mar 2011 18:09:27 -0500

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Sunday, March 20, 2011 6:49 PM
To: Hemant Singh (shemant)
Cc: james woodyatt; [email-masked]
Subject: Re: Why has RFC 4941 been designed in such a way, that it might causeaddress conflicts?

>Good idea, where's the wiki?

Ah, none that I know of.  Also, I am only catching up to 6man email this weekend being busy in the week with v6ops emails.  If a wiki does not exist for such issues, we could start one.  Since our cable IPv6 home devices such as cable modems and IPv6 CE Routers (standalone or combined inside a modem) are assumed to provide no console, we have specified use of a DAD Proxy at the first-hop IPv6 router.  This first-hop router is also the access concentrator (a CMTS - Cable Modem Termination System) for cable broadband.  Note since the cable network is an end-to-end IP network, it is easier for cable to specify support for DAD Proxy at the CMTS.  DSL which is not end-to-end at the IP layer has more issues to deal with.  The reason is that a SP has console access to the CMTS and if the CMTS supports a DAD Proxy, the SP at least knows which home the failure has occurred in and take some action.  Without the CMTS supporting DAD proxy, the DAD failure for a modem or CE festers for an error with the modem or CE dead in the water.   Of course, the home customer would call the SP in such a situation but it's better for the SP to be proactive to catch the error before any home user calls.  

It's also interesting that even when the SP has detected a DAD Duplicate, what does the SP do besides shutting down one of the two nodes that clashed for the same IPv6 link-local address.  

Thanks,

Hemant

---

From: Timothy Winters <[email-masked]>
Date: Mon, 21 Mar 2011 11:18:44 -0400

Hello,
	The UNH-IOL has made a white paper from the event available on the IPv6 homepage.  As Hemant stated there were issues discovered around DAD and the need for it.

Regards,
Tim

On Mar 20, 2011, at 7:09 PM, Hemant Singh (shemant) wrote:

> Ah, none that I know of.  Also, I am only catching up to 6man email this weekend being busy in the week with v6ops emails.  If a wiki does not exist for such issues, we could start one.  Since our cable IPv6 home devices such as cable modems and IPv6 CE Routers (standalone or combined inside a modem) are assumed to provide no console, we have specified use of a DAD Proxy at the first-hop IPv6 router.  This first-hop router is also the access concentrator (a CMTS - Cable Modem Termination System) for cable broadband.  Note since the cable network is an end-to-end IP network, it is easier for cable to specify support for DAD Proxy at the CMTS.  DSL which is not end-to-end at the IP layer has more issues to deal with.  The reason is that a SP has console access to the CMTS and if the CMTS supports a DAD Proxy, the SP at least knows which home the failure has occurred in and take some action.  Without the CMTS supporting DAD proxy, the DAD failure for a modem or CE festers for an
>  error with the modem or CE dead in the water.   Of course, the home customer would call the SP in such a situation but it's better for the SP to be proactive to catch the error before any home user calls.  
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------