Ralph Droms (rdroms) writes: > -----Original Message----- > From: Soliman, Hesham [mailto:hsoliman@xxxxxxxxxxxx] [...] > > 4.2 router advertisement > > > > - "Note: If neither M nor O flags are set this indicates that no > > information is available via DHCPv6." > > > > This means that the responding router always knows if DHCPv6 is > > definitely available or definitely not available. Is there any > > possibility that the responding router might not know? > > => I don't think so. It should always know. > > It's a network config and admin issue. The router doesn't "learn" or "know" if DHCPv6 is available; rather, the router is explicitly configured by the network admin to advertise the availability of DHCPv6 to hosts. Presumably, the netowkr admin knows whether DHCPv6 is available and configures the router appropriately. True, but at least in my own implementation experience, I've found this to be a bit too brittle. There's no easy way to make sure that the configuration works out correctly. If you happen to have a monolithic implementation, you might be able to cause the "enable DHCPv6 server" configuration knob to turn these bits automagically so there are no inconsistencies. However, for those of us with more flexible environments, or for deployments where the DHCPv6 server is not itself a router, rationalizing the configuration is infeasible, and it becomes yet another error-prone task for humans. If the administrator enables a DHCPv6 server, he must remember to update the routers with the corresponding prefixes as well. If he forgets, then he ends up in a strange state: hosts that don't happen to hear those routers "right away" (MAX_RTR_SOLICITATIONS) at interface configuration time may end up running DHCPv6 and working as he expected, because they briefly enter the "no routers" state. Hosts that do happen to hear these bits will fail to run DHCPv6 at all. The results are inconsistent. (Unrelated issues such as STP port blocking can cause this to happen more often than might otherwise be expected.) If he shuts down the DHCPv6 server and clears the RA bits, those hosts that once heard the "use DHCPv6" bits will continue to run DHCPv6 indefinitely, regardless of the setting of these bits. Nothing in the protocol stops them from looking for a server. Worse still, there's no real guarantee that the authority in charge of administering "routers" is the same as the authority in charge of "DHCP" administration on a given network. It's good if that's true, and the document seems to assume it tacitly, but these sorts of things sometimes end up on opposite sides of an administrative divide. Even more strangely, if the DHCPv6 server is handing out only configuration information (M=0 O=1), then there's no reason at all to suppose that the use of DHCPv6 has anything to do with the prefix management imposed by the routers. They're effectively unrelated protocols at that point, and the RAs are serving as a configuration broadcast mechanism. The one clear purpose of these bits is in distinguishing between the "managed" and "other" cases so that the DHCPv6 client knows whether to start with Solicit or Information-Request. However, on a routerless network, the client must still do something sane even though these bits are absent, and a smart enough client can thus be expected to right itself regardless of the way the server is configured. Though they're part of the standard, and I'm forced to support them, I don't think the ``M'' and ``O'' bits have much to recommend themselves over simply running DHCPv6 on all interfaces by default and perhaps fixing the DHCPv6 specification to make switching between the two modes of operation simpler and more consistent. -- James Carlson, KISS Network <james.d.carlson@xxxxxxx> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf