[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dhcwg] DHCPv6 router option
Hi Thomas:
>> 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
The reason this approach may be desirable is that it avoids the rogue RA
issue.
There are flaws with this because if the client doesn't know in advance,
it will depend on what the client does and finds when it starts. If the
rogue RA arrives just as the client is starting up, the client may
accept that information and use it (potentially never doing DHCP). On
switched networks, this might be solved by having the switches filter
out (all) RAs.
My reason for including this was to address the following in section 3
(Requirments and Design Considerations):
o Misconfigured Router Advertisements immediately cause connectivity
disruptions and can come from any router as a side effect of other
changes in configuration or even simple attachment to a link.
DHCP service is typically provided by a centralized service
composed of fewer managed components, so DHCP server
misconfiguration is less likely than delivery of misconfigured
Router Advertisements.
If you allow RAs to be used, you haven't solve this problem? And how
would the draft address this requirement/design consideration?
Later in section 6, it does state:
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.
So, why have the above mentioned bullet in 3 if this is clearly out of
scope? Or, perhaps you need to clarify how that issue is addressed by
the draft?
Perhaps it can also extend to the following bullet in section 3:
o Use of Router Advertisements provides identical configuration of
default routers and prefixes for all hosts on a link, while some
deployments require that different classes or groups of hosts be
configured with different default routers and prefixes.
You could have cases where some clients use the RA data and others
explicitly do NOT use it (as they've been configured via DHCP).
I was assuming that if this was desirable, there would be an option (or
data in an option) to communicate to the client "don't use RAs; only use
DHCP data." One could take this a step further and have several
settings:
- Default Router settings:
- Use RAs for default routers.
- Use DHCP only for default routers.
- Prefer DHCP default routers.
- Prefer RA default routers.
- Prefix Information settings:
- Use RAs for prefixes.
- Use DHCP only for prefixes.
- Prefer DHCP prefixes.
- Prefer RA prefixes.
Note that today we have "prefer RA default routers" + "prefer RA
prefixes" (and DHCP can't supply either). One could add additional
settings to include SeND vs non-SeND Ras?
I think without something like this, the benefit of using DHCP for RA
related data is mostly lost (except perhaps providing additional prefix
advertisements).
- Bernie
-----Original Message-----
From: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] On Behalf
Of Thomas Narten
Sent: Friday, March 20, 2009 2:12 PM
To: Bernie Volz (volz)
Cc: dhcwg at ietf.org; Ted Lemon; Ralph Droms (rdroms)
Subject: 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
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg