[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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