I think that it is silently assumed that DHCPv6-lite is configured of DNS server addresses without relaying requests to others.
That is, reconfiguration upon renumbering is necessary.
Or, DHCPv6-lite may be (pre)configured with well known addresses, as I suggested at the last meeting.
But, let's assume relaying is performed, which is a likely scenario on "stateful" cases, anyway.
One option for passing the new DNS options from the DHCPv6 Light server
to the client is a multicast Reconfigure message. That would work if the DHCPv6 Light server is on link, but if relays are used and there
is no multicast routing on site, this seems to be a gap (and a case for the RA method - though of course with RA method you still need to reconfigure the router for the new RA...)
W.r.t. inter-link multicast, what multicast protocols is intended to be used by people in DHC WG?
If it is CBT, PIM-SM or SSM, what happens if CORE, RP or SS crashes or is renumbered?
Is a well known unicast address is assigned to a primary and a back-up CORE/RP/SS, which means ANYCAST.
Is DVMRP assumed, instead?
Or, will we wait until yet another multicast protocol is standardized, hoping that it will solve all the problems?
Assuming that some multicast protocol solves all the problems, another question is on multicast address.
Is it a well known multicast address? If so, is there any configuration necessary at a site (or something like that) border router? If so, what happens if a customer want to relay DHCP request to ISP's DHCP server? What happens the border router is wrongly configured?
Masataka Ohta
PS
It seems to me that relying on multicast does not solve but merely refer the problem, which is better solved at the point (protocol) where it is observed.
#---------------------------------------------------------------------- # To unsubscribe, send a message to <[EMAIL PROTECTED]>.
