Ralph Droms (rdroms) writes:
-----Original Message-----
From: Soliman, Hesham [mailto:hsoliman(_at_)qualcomm(_dot_)com]
[...]
> 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(_dot_)d(_dot_)carlson(_at_)sun(_dot_)com>
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf