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