On 1-jun-2005, at 18:24, Iljitsch van Beijnum wrote: [always cool following up on your on posts...]
Because I fell in the middle of this discussion, and there seems to be a rather substantial disconnect between my views and those of many others, I decided to read up on earlier posts a bit.
I must say that I'm somewhat concerned by what I saw. A prevalent position was "let the administrators figure it out, this isn't the IETF's business".
I strongly disagree here. We're talking about AUTOconfiguration here. Obviously, administrators should always be free to configure their networks in any way that pleases them. However, in order for good things to happen AUTOMATICALLY, it's necessary that administrators can predict the default out of the box behavior of hosts, so that they can set up their equipment to make those hosts work well in their network.
The fundamental issue here is the question whether it's ok to ALWAYS do DHCPv6. I don't think that the position that this is the case is a reasonable one, because:
- it wastes bandwidth which is harmful in bandwidth and/or power constrained environments - it makes it impossible to get consistent behavior from a set of hosts that include hosts that do implement DHCPv6 and hosts that don't implement DHCPv6 - it allows the introduction of rogue DHCPv6 servers in otherwise secure environments (rogue DHCP servers are a big problem in ad-hoc IPv4 networks) - it makes it harder to contain the bad effects of incorrectly operating DHCPv6 servers (I believe it's very easy for DHCPv6 servers to assign addresses that are inconsistent with router configurations and thus not routable)
So if doing DHCPv6 in all cases isn't acceptable, we clearly need very specific guidelines about when DHCPv6 MAY or SHOULD be used and when it MUST NOT be used.
We desperately need to avoid the situation where people are forced to filter out DHCPv6 packets because it's the only way from stopping hosts from doing DHCPv6 out of the box.
Note that any comparison to DHCP in IPv4 is meaningless as there is no stateless autoconfiguration in IPv4. DHCP is ubiquitous in IPv4, but it's almost inconceivable that it will attain the same status in IPv6. This means the protocol has to know when to bow out gracefully.
In the mean time, the dhc working group has come up with two variations of DHCPv6 which aren't interoperable: the stateful version that uses Solicit messages, and the stateless version that uses Information-Request messages. It is obviously harmful to have a network that only has servers that support the stateful variant and then have hosts that only use the stateless variant, or the other way around. The situation where both variants are executed simultaneously, or when one is tried first and the other afterwards, are also problematic because of unnecessary extra bandwidth use or additional delays. Mandating that servers forever support both variations is probably the least harmful solution, but it's still less than optimal.
Clear guidelines about which DHCPv6 variation MUST be used in which situation is clearly beneficial here.
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
