On Tue, Aug 02, 2005 at 11:20:11PM +0200, Iljitsch van Beijnum wrote: > 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.
This sounds like a good suggestion to me. > 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 believe they should indicate whether DHCPv6 is available or not (possibly also stateful/stateless). Clients should then generally not do DHCP when they are told it isn't available (in particular with the "no opinion" option, there shouldn't be a need to try). If clients are told DHCP is available they could still choose not to use DHCP based on the client configuration, type of client etc. I don't want the bits to tell clients to do or not do DHCP request, because on a link there may be some clients that should not do DHCP at all, while others that need DHCP to function. > >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.) Without the "no info", vendors may have to set the default to say DHCP is available. I would rather see "no info". Stig > >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 > [email protected] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
