[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dhcwg] DHCPv6 router option
Bernie,
"Bernie Volz (volz)" <volz at cisco.com> writes:
> While we can't do anything about existing hosts that don't make use of
> these new options, it seems to me that ideally people may want three
> modes (for hosts that support these new options):
> 1. Use RAs. Hence if a client includes the options in the ORO, the
> server SHOULD NOT include these options in the response. This is what we
> have today.
Right. This works today Just Fine.
> 2. Use DHCP. Whether RAs are sent or not, the hosts should ignore RAs
> and only make use of the information provided via DHCP.
I disagree with this approach. The problem is that the
*implementation* is the one that has to decide whether to ignore RAs
or not. But that decision is really best made by the network
adminsistrator, since they know what is running on their network and
what their requirements are. The worst situation here would be if
clients did varying things, and the network admin couldn't run their
network as they'd like.
IMO, the only viable approach is that a client accept information from
both DHC and RAs and merge the info together. Clients are not smart
enough to know how to make any other choice when there are conflicts.
> 3. Use both? Perhaps 'prefer' the information provided via DHCP, perhaps
> not?
I would be nervous about configuration learned via one or the other as
being more "prefered". But I agree we need to think about this a bit
and have recommendations on what a client should implement.
> This draft states:
> Conflicting or overlapping information received through Router
> Advertisements and through DHCP is considered a misconfiguration and
> is out-of-scope of this document. For example, if a host receives a
> list of default routers through DHCP and a Router Advertisement with
> a non-zero lifetime, the result is undefined.
> Which makes 2 (when RAs exist with overlapping information) and 3 out of
> scope? This is probably what is causing much of the problem as I think
> some want to use this to avoid rogue RAs (putting aside whether DHCP is
> any more secure than RAs).
> I also think that expecting to live in a clean world (whether EITHER RAs
> OR DHCP are ONLY used) is unrealistic.
> Therefore, I think the draft needs to address this as it has little
> benefit to just declare this as "out-of-scope". Perhaps it can be
> addressed in a separate document, but I don't think we should advance
> this work until that document is also available.
I agree that the draft needs to address this.
Thomas