Re: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments

[Stig Venaas <[e-mail]>]

On Tue, Aug 10, 2004 at 09:45:36AM -0700, Ted Lemon wrote:
> Stig, maybe you can explain for me how it is less complicated to supply 
> multicast prefixes than it is to do stateful allocation - I don't get 
> it.   With multicast prefixes, the client either has to take its 

OK, I'll try.

> chances with the possibility of a collision, which seems quite likely 
> (random number generators are usually deterministic, not random, and 
> getting one that uses any real source of entropy is difficult, not 
> easy), or it has to do some kind of duplicate address detection, which 
> also seems difficult, not easy.

I don't have a clue what the likelihood is. But just to make it clear,
we're talking of a 32-bit number. So question is how likely is it for
two hosts/applications on the same link to pick the same 32-bit value.
I agree that some form of DAD could be needed, and I agree it's not
easy. I've been wondering slightly if the DAD in Neighbor Discovery
could be reused, but anyway, it's a big complication, I agree.

> In contrast, while stateful address allocation requires slightly more 
> work on the server side (in the sense that the server has to remember 
> which address it allocated), it's much easier on the client side - the 
> client gets a specific address, doesn't need a good RNG, and doesn't 
> need to do multicast DAD.   The additional complexity of remembering 
> which IP address we gave to the client is well-understood technology, 
> requiring no innovations and risking no accidental DoS attacks from 
> broken clients.

The stateful approach introduces some other complexity on the client
that I'm concerned about.

The main issue, is that it's the application that needs the
addresses. You need some additional infrastructure/middleware on the
host. Either the application needs to act as DHCP client (there are
big issues with that) or the application needs some standardized way
of communicating with the DHCP client. Basically the application will
need to signal to the DHCP client that it needs an address, and that
must be returned back to the client. Also, while the application is
running, the DHCP client must renew the address on behalf of the
application. I've been trying to think through how to actually
implement this, and it's not easy.

I must say though, that coming up with a general solution to how
applications can interact with DHCP might be interesting.

If we instead used the stateless prefix announcement solution we may
need to solve the DAD issue, but there are some advantages.

o For link-local multicast, it would be possible to generate link
  unique multicast addresses with no need for DHCP servers or routers.

o For unicast-prefix-based addressing (RFC 3306) you can generate a
  /96 multicast prefix from the links unicast /64 prefix and then
  using RNG plus possibly DAD you can come up with prefixes to use on
  the link. This can be done without DHCP.

o For Embedded-RP the application will need to learn the prefix from
  somewhere. But the system could learn the prefix once (from DHCP,
  from config file or whatever) and all the applications use the same.
  You can perhaps compare it to how applications use resolv.conf on
  unix and how it might be configured from DHCP or other systems.

> History suggests that DHCP server implementations are more likely to be 
> correct than DHCP client implementations, perhaps because there is less 
> risk of monoculture in the interoperability testing done by a DHCP 
> server vendor than by a DHCP client vendor (a client vendor will 
> typically test against a single server, whereas a server vendor will 
> typically have many different clients to test against).

Right

> So if it makes sense to do something like this, I would vote for doing 
> it in a stateful manner, not a stateless manner.

I think something like this is needed. Currently I'm in favour of
stateless, but I'm trying to explore both possibilities. I'm not
sure myself which one is superior.

Stig

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