On Tue, Jan 27, 2015 at 11:31 AM, Ted Lemon <[email protected]> wrote: > On Jan 27, 2015, at 11:20 AM, Warren Kumari <[email protected]> wrote: >> I personally like DHCPv4 and DHCPv6, but there seems to be some >> religion around this stuff :-) >> Supporting multiple option for v6 means need to provide guidance on >> what to do when you get *different* answers in DHCPv6 and IPv6 RA. I >> had text in -02 covering this, I can easily put it back. >> >> The whole DHCPv6 vs RA topic is, um, interesting... there appear to be >> some quite strong opinions around this :-) >> I'll spin another version with both DHCPv6 and RA, and guidance on >> what to do if you get both. This will no-doubt annoy some folk, but I >> can leave the consensus call to Joel :-) > > The problem with RA as opposed to DHCPv6 is that we've seen that uptake of RA > options is slow compared to uptake of DHCPv6 options. But we can't _just_ > do DHCPv6, because as you say there is some religion about DHCPv6, and so > certain companies are slow to implement DHCPv6 client features, if at all.
Yup. I've been in the middle of some of these discussions :-) I've put back the DHCPv6, and made it clear that there are 2 DHCP options (v4 and v6) > I think the right answer in the case where one sends it and the other doesn't > is to assume that whatever _was_ sent is definitive, since we can't assume > that the source of the RA and the source of the DHCP service will necessarily > be updated at the same time. Actually, when I ended up doing was saying that devices should prefer the URI in DHCPv4, then DHCPv6, then RA. This gets around the problem of what to do if the CP *does* send multiple URIs (e.g to support clients that only do DHCPv6 or RA) and they are different. W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
