Subject: [mif] FW: Review requested: draft-ietf-mif-dhcpv6-route-option

From: Hui Deng <[email-masked]>
Date: Sat, 29 Oct 2011 02:07:20 +0800

Just want to remind that there is on-going review in 6MAN for this draft.
 
thanks
 
-Hui

> Date: Fri, 28 Oct 2011 12:58:06 -0500
> From: [email-masked]
> To: [email-masked]; [email-masked]; [email-masked]
> CC: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Review requested: draft-ietf-mif-dhcpv6-route-option
> 
> This is precisely the question that I and Bernie Volz asked a year or
> two back. Similarly when it was discussed to add a DNS option to the
> IPv6 ND RA when the DNS option was already supported by DHCPv6. The
> question was if the receiving node gets the same information from two
> different sources, which information wins? What if one information was
> fat-fingered at the SP provisioning system while the other was not? We
> should look at the RFC that added the DNS option to the RA and see if
> that RFC has a section regarding this question and we could copy that
> guidance.
> 
> Hemant
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Wes Beebee (wbeebee)
> Sent: Friday, October 28, 2011 1:52 PM
> To: Brian Haberman; IPv6 WG Mailing List
> Cc: [email-masked]; Bob Hinden; [email-masked]
> Subject: Re: Review requested: draft-ietf-mif-dhcpv6-route-option
> 
> What happens when both RA and DHCPv6 are configured?
> 
> - Wes
> 
> On 10/28/11 9:11 AM, "Brian Haberman" <[email-masked]> wrote:
> 
> > All,
> > The MIF WG is currently defining a DHCPv6 option for defining
> > routes (including default routes) on client nodes. Please review the
> > draft and provide any feedback you have.
> > 
> > http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03
> > 
> > Regards,
> > Brian
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [email-masked]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 30 Oct 2011 18:02:54 +0100

> Just want to remind that there is on-going review in 6MAN for this

Thanks for the pointer.

I have posted separately to 6man on this topic.

The question one raised on 6man is about coexistence with RA about
default route.  One is aware that a similar situation (alternate
mechanism DHCP-vs-RA for default route) appeared recently when DNS-in-RA
was proposed (DHCP existed doing DNS).  RFC6106 proposes to  do
DNS-in-RA but has a section explaining coexistence with DHCP about DNS
address - and gives the latter precedence over.

Additionally, the same issue may be raised about co-existence with
routing protocols.  Currently, the route-option draft says that
DHCP-route-option should not be used when dynamic routing protocols are
used (section 3.6 Limitations).  This is one particular way of building
co-existence.

In some cases this recommendation may be inappropriate - there may exist
cases where routing protocol software _and_ DHCP software should be used
on the same machine (e.g. use DHCP to get DNS address, and use OSPF to
do routing).  At that point it may be hard to prevent some particular
option of DHCP (route-option) being physically available on the machine.
  Accidentally misconfiguration may happen.

Another way would be to recommend that all data be in some list, and if
conflict arises precedence be given to some data over other.

This is of course debatable.

(In the past I have myself preferred to recommend to use mechanisms in
an alternative manner, rather than keeping prioritized lists.)

Alex

>
> thanks
>
> -Hui
>
>> Date: Fri, 28 Oct 2011 12:58:06 -0500 From: [email-masked] To:
>> [email-masked]; [email-masked]; [email-masked] CC:
>> [email-masked]; [email-masked];
> [email-masked]
>> This is precisely the question that I and Bernie Volz asked a year
>> or two back. Similarly when it was discussed to add a DNS option to
>> the IPv6 ND RA when the DNS option was already supported by DHCPv6.
>> The question was if the receiving node gets the same information
>> from two different sources, which information wins? What if one
>> information was fat-fingered at the SP provisioning system while
>> the other was not? We should look at the RFC that added the DNS
>> option to the RA and see if that RFC has a section regarding this
>> question and we could copy that guidance.
>>
>> Hemant
>>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Wes Beebee (wbeebee)
>> Sent: Friday, October 28, 2011 1:52 PM To: Brian Haberman; IPv6 WG
>> Mailing List Cc: [email-masked]; Bob Hinden;
>> [email-masked] Subject: Re: Review requested:
>> draft-ietf-mif-dhcpv6-route-option
>>
>>> All, The MIF WG is currently defining a DHCPv6 option for
>>> defining routes (including default routes) on client nodes.
>>> Please review the draft and provide any feedback you have.
>>>
>>> Regards, Brian ----------------
>>> ---------------------------------------------------- IETF IPv6
>>> working group mailing list [email-masked] Administrative Requests:
>>> https://www.ietf.org/mailman/listinfo/ipv6
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6
> _______________________________________________ mif mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mif

---

From: Ted Lemon <[email-masked]>
Date: Sun, 30 Oct 2011 17:24:35 +0000

On Oct 30, 2011, at 1:02 PM, Alexandru Petrescu wrote:

This is a very good point, which should be addressed in the route option draft.   I think the right thing is to give RA precedence over DHCP for routing information, but am curious to know if others disagree.

Fortunately, this is not a very serious problem: the router and the DHCP server are both under control of the administrator, so they can simply configure them correctly, and the right thing will happen.   It is always possible, if the network administrator sets things up wrong, for the network to not work, and there is nothing the IETF can do to eliminate this risk.   Since the default case is for the network administrator not to configure DHCP, I think it's pretty safe to assume that we won't get a bad route configuration without some kind of positive action on the part of the administrator.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 31 Oct 2011 09:35:01 +1300

Ted,

> This is a very good point, which should be addressed in the route option draft.   I think the right thing is to give RA precedence over DHCP for routing information, but am curious to know if other…

It makes my head hurt a bit to give RA config priority in one context and
DHCPv6 config priority in another context. I think this point requires
a wider discussion; you could find opinions about this in (at least)
6man, v6ops, homenet, and 6renum.

> Fortunately, this is not a very serious problem: the router and the DHCP server are both under control of the administrator, so they can simply configure them correctly, and the right thing will ha…

Not necessarily, if you think about out-of-the box default behaviour
when someone hooks a few boxes together in an unmanaged network. That's why
I have a feeling that "in case of conflict, DHVPv6 always wins" may turn out
to be the right answer.

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Sun, 30 Oct 2011 21:38:15 +0000

> 6man, v6ops, homenet, and 6renum.

I really don't see how we can manage that.   That's five different mailing lists, not even counting the DHC mailing list.   The way I deal with this is to be on all those mailing lists.

As for your head hurting, you have my sympathy.   In reality, I think that if DHCP and RA disagree, that is a configuration error, and so it doesn't particularly matter which one is given priority.   They should agree.

> I have a feeling that "in case of conflict, DHVPv6 always wins" may turn out

In this case, I would expect there to be no DHCP server.   Or if the homenet group decides that DHCP needs to work in this case, based on prefix delegation, then I would argue that DHCP should not automatically configure itself to provide a default route, since the default route ought to appear in the RA anyway.   But again, in this situation, even if homenet decides that DHCP should send a default route, the default route it sends should agree with the one sent in the RA.

If you are thinking of a bridged situation, homenet seems to have concluded that that's not the right thing to do anyway.  In a bridged environment, if more than one device tries to be the source of truth, it's pretty much a given that it's simply not going to work.

---

From: Tomasz Mrugalski <[email-masked]>
Date: Mon, 31 Oct 2011 12:06:02 +0100

On 30.10.2011 22:38, Ted Lemon wrote:
>> It makes my head hurt a bit to give RA config priority in one
>> context and DHCPv6 config priority in another context. I think this
>> point requires a wider discussion; you could find opinions about
>> this in (at least) 6man, v6ops, homenet, and 6renum.
> 
> I really don't see how we can manage that.   That's five different
> mailing lists, not even counting the DHC mailing list.   The way I
> deal with this is to be on all those mailing lists.
> 
> As for your head hurting, you have my sympathy.   In reality, I think
> that if DHCP and RA disagree, that is a configuration error, and so
> it doesn't particularly matter which one is given priority.   They
> should agree.
How about a different perspective on RA and DHCP disagreement? RA
provides generic mechanism for all hosts in a network. DHCP allows to
provision routing information on per host basis. Therefore you can
deliver additional configuration to selected subset of hosts. That's why
I would prefer DHCP over RA as a way to override "default" configuration.

There's another aspect and I'm not sure if mentioning this will open can
of worms. What about security aspect of it? While is possible to
establish security relationship between DHCP server and clients, I'm not
aware of any such mechanism for RA. (There's SEND, but that is a
different matter. My understanding is that we are talking about "plain"
RA). I would propose to favor DHCP over RA, because it may be less prone
to attacks. I admit that this may be very strong or very weak (almost
nobody uses security in DHCPv6 nowadays) argument, depending on which
perspective you take on it.

Brian,
Thanks for pointers to other groups. Unfortunately, due to other
obligations I'm unable to handle additional traffic. I will,
occasionally, keep checking out occasionally what is happening in those
groups. I'm afraid that if I asked on each group separately, I may get
different answer every time. Reaching a consensus on this one may be tricky.

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 Oct 2011 13:30:06 +0000

> I would prefer DHCP over RA as a way to override "default" configuration.

Yup, that's a really good point.  I think this is sufficient justification for preferring the value obtained through DHCP. 

I will buy the security argument when I see the first successful use of DHCP security by a naive end user...  :)

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 31 Oct 2011 18:16:17 +0100

Le 30/10/2011 18:24, Ted Lemon a écrit :
> This is a very good point, which should be addressed in the route option
> draft. I think the right thing is to give RA precedence over DHCP for
> routing information, but am curious to know if others disagree.

I do not disagree: in the default route case, if RA offers such data 
then give it preference over the default route obtained from DHCP.

(the preference mechanism can be specified by using the lifetime mechanism).

Alex

> Fortunately, this is not a very serious problem: the router and the DHCP
> server are both under control of the administrator, so they can simply
> configure them correctly, and the right thing will happen. It is always
> possible, if the network administrator sets things up wrong, for the
> network to not work, and there is nothing the IETF can do to eliminate
> this risk. Since the default case is for the network administrator not
> to configure DHCP, I think it's pretty safe to assume that we won't get
> a bad route configuration without some kind of positive action on the
> part of the administrator.
>

---

From: Tomasz Mrugalski <[email-masked]>
Date: Mon, 31 Oct 2011 18:38:02 +0100

> then give it preference over the default route obtained from DHCP.
Sorry, but I can't parse that sentence. You seem to agree with Ted (DHCP
preferred over RA), but the later part of the sentence states otherwise
(RA preferred over RA).

> (the preference mechanism can be specified by using the lifetime
Can you elaborate on that? What has lifetime to do with preference? Do
you want to somehow prefer longer (or shorter) lifetimes? That is rather
dangerous and I would like to avoid that. I believe that clear statement
("DHCP overrides RA" or "RA overrides DHCP") will help a lot here.

Tomek

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 31 Oct 2011 19:07:49 +0100

Le 31/10/2011 18:38, Tomasz Mrugalski a écrit :
>>>> The question one raised on 6man is about coexistence with RA
>>>> about default route. One is aware that a similar situation
>>>> (alternate mechanism DHCP-vs-RA for default route) appeared
>>>> recently when DNS-in-RA was proposed (DHCP existed doing DNS).
>>>> RFC6106 proposes to do DNS-in-RA but has a section explaining
>>>> coexistence with DHCP about DNS address - and gives the latter
>>>> precedence over.
>>>
>>> This is a very good point, which should be addressed in the
>>> route option draft. I think the right thing is to give RA
>>> precedence over DHCP for routing information, but am curious to
>>> know if others disagree.
>>
>> I do not disagree: in the default route case, if RA offers such
>> data then give it preference over the default route obtained from
>> DHCP.
>
> Sorry, but I can't parse that sentence. You seem to agree with Ted
> (DHCP preferred over RA), but the later part of the sentence states
> otherwise (RA preferred over RA).

Ted suggested RA to be prefered over DHCP and I agree with it.

(in another email you propose DHCP preferred over RA, and Ted seems to
agree with you as well).

> Can you elaborate on that? What has lifetime to do with preference?
> Do you want to somehow prefer longer (or shorter) lifetimes?

YEs, that.  RA has this Router Lifetime field.  When two routers send RA
each with a default default router, the Host could 'prefer' one over the
other based on the longest lifetime.  RFC4861 says 'The Router Lifetime
applies only to the router's usefulness as a default router'.

A similar mechanism could happen to compare a default route obtained
from DHCP, and from RA: prefer the one whith longer lifetime.

> That is rather dangerous and I would like to avoid that. I believe
> that clear statement ("DHCP overrides RA" or "RA overrides DHCP")
> will help a lot here.

Hm, but that's not how DNS-RA RFC does.  DNS-RA RFC6106 does preferences
instead of a yes-no alternative.  RFC4191 "Default Router Preferences"
also works with preferences instead of exclusion.

What do you think?

Alex

>
> Tomek _______________________________________________ mif mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/mif
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 01 Nov 2011 09:41:33 +1300

> Yup, that's a really good point.  I think this is sufficient justification for preferring the value obtained through DHCP. 

Yes, that's a good way to look at it.

I don't see how to avoid some discussion outside MIF, however. Probably v6ops
is best for this particular aspect.

> I will buy the security argument when I see the first successful use of DHCP security by a naive end user...  :)

Fair enough, but at least the security benefits should be written down.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 Oct 2011 22:26:36 +0000

On Oct 31, 2011, at 2:07 PM, Alexandru Petrescu wrote:
(in another email you propose DHCP preferred over RA, and Ted seems to
agree with you as well).

Tomek changed my mind.  :)

BTW, lifetimes are a red herring, since both mechanisms provide for and expect lifetimes to be updated, so you'd be predicting the future based on data that gives no indication of the future.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 Oct 2011 22:28:08 +0000

On Oct 31, 2011, at 4:41 PM, Brian E Carpenter wrote:
Fair enough, but at least the security benefits should be written down.

At present I don't think DHCP is better than SEND.