On 1/27/15 9:39 AM, Warren Kumari wrote: > 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.
it's also plausible that the process of obtaining the information is a bit of a race between the two protocols, so you should be ok with the client starting with whichever finishes first. likewise the poosibly unfortunate case where both protocols are present but which you only recived a hint from one. > W > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
