[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dhcwg] DHCPv6 router option
> -----Original Message-----
> From: Bernie Volz (volz) [mailto:volz at cisco.com]
> Sent: Thursday, March 12, 2009 7:08 AM
> To: Ralph Droms (rdroms); Ted Lemon
> Cc: dhcwg at ietf.org
> Subject: Re: [dhcwg] DHCPv6 router option
>
> 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.
> 2. Use DHCP. Whether RAs are sent or not, the hosts should ignore RAs
> and only make use of the information provided via DHCP.
> 3. Use both? Perhaps 'prefer' the information provided via DHCP,
perhaps
> not?
One thing I haven't seen mentioned yet (or maybe I missed
it) is SEND. For example, it may be useful for a router
to use SEND for RAs in order to represent that it is
indeed authorized to act as a router even if the RAs
contain no PIOs nor router lifetime. It might also be
necessary for RAs to contain other information such as
RIOs (RFC4191) that may not be practically available
from DHCP.
Unless there is a DHCP equivalent for conveying such
"other" information (is there?), I guess that in some
use cases that would argue for option 3 (use both)?
Fred
fred.l.templin at boeing.com
> 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.
>
> - Bernie
>
> -----Original Message-----
> From: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] On Behalf
> Of Ralph Droms (rdroms)
> Sent: Thursday, March 12, 2009 7:14 AM
> To: Ted Lemon
> Cc: dhcwg at ietf.org WG
> Subject: Re: [dhcwg] DHCPv6 router option
>
> Ted - I agree with you: we have two opposing points of view, both of
> which have been fully (exhaustively?) articulated in previous
> discussions of this issue.
>
> The way in which we can have a constructive discussion now is to focus
> on the technical issues in the following way...
>
> Hypothesize that both forms of host configuration are available: a
> list of default routers and on-link prefixes can be delivered through
> either RAs or DHCP. Now, consider your favorite way to configure
> those hosts, and consider the devices that have already been
> deployed. Review the spec to see if you can configure hosts the way
> you want to, considering any effects of other methods of configuration
> and existing deployment scenarios. Let us know if you can run your
> network the way you want to run your network, according to the spec.
> Or, let us know what's missing, or how the spec interferes with how
> you wan to run your network.
>
> For example, the spec shouldn't (I would argue pretty clearly MUST
> NOT) make any changes to the way currently deployed networks are run.
> So, networks using RAs to supply default routers and prefixes MUST NOT
> be affected by any new DHCP options and semantics.
>
> Conversely, to meet the requirements in the spec, the spec should
> allow for operation with an RA configuration that carries no router or
> prefix information and for operation with no RAs at all.
>
> The latest rev of the doc does not meet these requirements because it
> doesn't describe how the client decides which configuration mechanism
> to use. I proposed some rules:
>
> * if it receives no default routers with lifetime > 0, add the default
> router option to the ORO
> * if it receives no prefixes, add the prefixes option to the ORO
>
> These rules are still inadequate; for example, suppose the network
> admin requires that the host use DHCP, and a device on the link sends
> a rogue RA with default router and prefix information. This problem
> is impossible to solve completely through the use of just ND and
> DHCP. We can optimize network behavior; here are a couple of ideas:
>
> * "RA guard" to filter and limit the scope of misconfigured RAs
> * a DHCP option, to be sent with the initial DHCP message exchange,
> signaling the host to ignore all future RAs
>
> We need to continue the discussion; let's focus on how to allow both
> methods of configuration to coexist.
>
> - Ralph
>
> On Mar 11, 2009, at 2:37 PM 3/11/09, Ted Lemon wrote:
>
> > On Mar 11, 2009, at 9:53 AM, sthaug at nethelp.no wrote:
> >> I strongly disagree with your disagreement.
> >
> > This is a major hot-button issue. People have extremely strong
> > opinions about it. It happens that although you and Iljitsch
> > disagree on what to do, you both have valid points. At the same
> > time, you appear to be talking past each other.
> >
> > What appears to be worrying Iljitsch, which you do not appear to be
> > concerned about, is that if a DHCPv6 client is receptive to this
> > option, it will trust it even when it is wrong, not just on your
> > network but on his. So adoption of this option affects Iljitsch
> > just as much as it affects you - he can't "opt out."
> >
> > Similarly, your requirement, which Iljitsch does not agree with, is
> > that on some networks, managing what gets sent in RAs is a lot more
> > work than managing what gets sent by the DHCP server. DHCP
> > provides you with a central control point, whereas RAs are
> > necessarily configured in the router.
> >
> > As I say, I don't know if you can reach any kind of rapprochement,
> > but I think this is the heart of your disagreement, and I think that
> > this conflict is well understood by the working group. It would be
> > nice if there were some way for Iljitsch to opt out that still
> > allowed you to get what you want, but I'm not sure that there is,
> > which is what makes this a contentious discussion.
> >
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg at ietf.org
> > https://www.ietf.org/mailman/listinfo/dhcwg
>
> _______________________________________________
> dhcwg mailing list
> dhcwg at ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> dhcwg at ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg