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

[Masataka Ohta <[e-mail]>]

Stig;

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



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