On 2-aug-2005, at 15:41, Tony Hain wrote:
I choose not to try to get to the mic, but on the debated
requirement point
3; why is there a belief that the DHCP relay information is correctly
configured if the simpler set of 2 bits is improperly configured?
I think a case can be made for the notion that most routers and most
networks don't implement the bits today, so seeing MO==00 doesn't
really authoratively say there is no DHCP service, but just that the
routers operate in a default configuration.
So it would be useful to redefine MO==00 to mean "no opinion" and
come up with a new value that indicates authoritative information
that DHCPv6 is unavailable and/or shouldn't be used.
I agree that point 1 & 3 are in direct conflict and that 1 is the real
requirement.
In the scenario above that wouldn't be the case.
(Having DHCPv6=Y/unknown/DHCPv6=N also increases the likelihood that
OS vendors will be prepared to enable DHCPv6 when MO==00 by default,
they may / hopefully will not want to do this if there is no other
way to indicate the absence of DHCPv6 servers.)
Hosts should never try to outguess the specific instructions from the
router...
Agree, especially in this case where it leads to continuous extra
multicast traffic (don't forget that multicast takes up much more
bandwidth than unicast on wifi, a reason why we should think twice
about draft-pashby-ipv6-network-discovery-00.txt).
This means that even the case of M & O clear without a prefix
should not result in a DHCP request. This only invites rouge DHCP
servers as
a DOS attack. One valid case for M & O clear without a prefix would
be a
router retracting the delegated prefix when the link associated
with that
prefix fails. When all such upstream links fail there should be no
prefix
unless the network manager has configured a ULA prefix. The lack of
a prefix
is not a configuration error,
I believe it is: the router is still advertising itself as a router,
implying it can reach the rest of the world. This is harmful. (I
think there is a need to study the permutations of different prefix
and RA timeouts and their effects, I'll bring that up in v6ops.)
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
