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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
