Re: [dhcwg] DHCPv6 router option

["Bernie Volz (volz)" <volz at cisco.com>]

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?

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