Re: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug?

[Stig Venaas <[e-mail]>]

On Fri, Nov 14, 2003 at 07:24:06AM +0900, Masataka Ohta wrote:
> >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.

I suggest for server to send reconfigure to clients via relays.

>From server to relay:

    If multicast routing available in the site:

	site scoped multicast from server to relays

    If multicast routing not available in the site:

	unicast to each relay, server has a list of relays

Then from relay to client you can always use multicast on link.

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.

Now to your comments.

> 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.

> 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. And only within the site. There are
also ways to secure multicast against RP crashes etc.
Discussion on multicast reliability and renumbering could be
a good topic for mboned wg. It doesn't belong here.

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.

> 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

> Is DVMRP assumed, instead?

Nothing is assumed I think.

> 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.

> 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. 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.

Stig

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg