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...)
I'll comment on your mail, but let me first present how I suggest it be done.
Thanks.
I suggest for server to send reconfigure to clients via relays.
From server to relay:
If multicast routing available in the site:
"site" is not a useful concept for autoconfiguration, when the "site" is really small, which is, perhaps, the primary target case of "stateless", which is why I asked multicast over site boundaries.
Note also that "site" local unicast addresses are to be deprecated.
Moreover, multicast is unreliable unless the server have a list of relays, unless unicast ACK is returned from each relay.
And, then, use of multicast reduces the number of traffic by half (ignoring frequent multicast control traffic some are broadcast over a domain), which is not essential.
So,
If multicast routing not available in the site:
unicast to each relay, server has a list of relays
is a rational approach for either case.
Of course, the server have a stable storage.
However, some says "has a list of relays" is a "stateful" approach and is no good.
Lack of well definedness of "stateless" is making design and discussion very hard.
Then from relay to client you can always use multicast on link.
It is unreliable that relays also should have lists of clients and stable storages or the server directly take care of the clients, in either of which case, unicast is good enough.
Reconfigure messages should be protected due to possible DoS attacks. I didn't consider that at first. I think that can be done using public key crypto. Server has a single key pair. Clients get public key together with the config info, and the reconfigure message is signed with the private key.
Sorry, public key crypto is computationary expensive that it rather amplifies than prevents DoS effect.
With your case, reconfigure messages with bogus signature will force clients perform expensive public key crypto computation.
W.r.t. inter-link multicast, what multicast protocols is intended to be used by people in DHC WG?
I'm not sure that should be specified. At least as long as it isn't SSM, the DHCP infrastructure is completely independent of which multicast protocols are used, just like other multicast applications.
I asked not "specified" but "intended".
When we want to analyse specific application, we must take into account all the layers to calculate number of packets, periods of delay, redundancy, security etc.
If it is CBT, PIM-SM or SSM, what happens if CORE, RP or SS crashes or is renumbered?
Interesting question. It's relatively easy with standard PIM-SM. You only need to reconfigure the RP address on the routers, and if you use say BSR, you only need to change on the c-BSRs and c-RPs.
It is more straight forward to change addresses of a DHCP server on relayes to be used for unicast relaying. However, a DHCP server is a single point of failure.
And only within the site.
"site" is not a good idea.
There are also ways to secure multicast against RP crashes etc.
This type of approach improve reliability for certain types of failure but does not improve or rather disimprove reliability for other types.
Discussion on multicast reliability and renumbering could be a good topic for mboned wg. It doesn't belong here.
I'm afraid it is not an attractive idea to involve yet another WG in the thread.
For SSM, relays would need to know unicast addresses of DHCP servers, and if you do reconfigure with multicast, you also need servers to know unicast addresses of relays. Then you might as well use unicast.
Yup. But, is it "stateless"?
Is a well known unicast address is assigned to a primary and a back-up CORE/RP/SS, which means ANYCAST.
Anycast might be used
An interesting fact is that there are someone who don't want to
use "anycast" for DNS servers, because it intermingles DNS and
routing system. However DNS servers by DHCP with multicast is already eaqually bad. Then, are we having DHCP with multicast
with anycast CORE/RP/SS?
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.
I think multicast works pretty well, but this should rather be discussed in mboned.
Sure. However, mboned is the worst place to discuss "multicast does not work at all".
Is it a well known multicast address? If so, is there any
Yes
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?
Of course things can be wrongly configured, but most things can break then.
Yes.
My intention here is to demonstrate that, with multicast, routing and DHCP are intermingled.
If you want to relay DHCP requests out of the site, the best is to use unicast between relay and server I think, using site multicast is only an option.
And, multicast is not a useful option, which means we need something for redundancy.
Masataka Ohta
#---------------------------------------------------------------------- # To unsubscribe, send a message to <[EMAIL PROTECTED]>.
