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

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

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.

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

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

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg