Subject: [dhcwg] Conflict between RA and DHCP in MIF case

From: Hui Deng <[email-masked]>
Date: Mon, 14 Nov 2011 09:46:47 +0800

Hello 6MAN and DHCP,

Especially thanks *Wes Beebee*, Hemant Singh, Brian Carpenter, Alex and
Ted's discussion.

MIF is going to discuss the confliction between RA and DHCP on tuesday
afternoon MIF session (15:20-17:00)
the author Tomasz has propose below resolution:

The problem is about potential conflict between RA and DHCP. Our
proposed answer is as follows:

RA provides configuration to all hosts in a network. DHCP can provide
configuration on a per host basis. Therefore it may be useful to use
DHCP to "override" configuration for some hosts in a network (e.g.
engineering department has extra routes defined for a lab network). As
such, DHCP should be preferred.

However, there is also a matter of security. Both RA and DHCPv6 can be
secured. If SEND is deployed, RA is more trustworthy than DHCP, so it
should be preferred. Finally, there is such thing as secure DHCP, so if
both RA and DHCP are secure, prefer SEND. I must admit that I never
heard about any realistic deployments of secure DHCP, but it will change
over time.

This approach can be summed as: favor secure, favor DHCP. Or to be more
explicit, there's a complete list of all cases:
a) RA vs DHCP => prefer DHCP
b) RA(SEND) vs DHCP => prefer RA
c) RA vs secure DHCP => prefer DHCP
d) RA(SEND) vs secure DHCP => prefer DHCP

Does it sound reasonable?

This approach is very similar to what was described in DNS configuration
over RA and DHCP (except the part about both RA and DHCP being secure
that is not covered in RFC6106).

To summarize the discussion so far, Ted Lemon on MIF list agreed that
DHCP should be preferred. Herman Singh on 6MAN list suggested to go look
at what DNS over RA proposes and use the same approach. RFC6106, section
5.3.1covers cases a) and b). c) and d) are logical extension that takes
DHCPv6 security into consideration. My understanding is that proposed
solution will be satisfactory to everyone.

---

From: Ole Troan <[email-masked]>
Date: Mon, 14 Nov 2011 09:59:40 +0800

Hui,

why not just merge all the information received?
e.g. if you get DNS server over DHCP and RA, use all.
if you get addresses via SLAAC and DHCP, you use all...

cheers,
Ole

On Nov 14, 2011, at 9:46 , Hui Deng wrote:

> Hello 6MAN and DHCP,
>  
> Especially thanks Wes Beebee, Hemant Singh, Brian Carpenter, Alex and Ted's discussion.
>  
> MIF is going to discuss the confliction between RA and DHCP on tuesday afternoon MIF session (15:20-17:00) 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Nov 2011 15:20:31 +1300

> afternoon MIF session (15:20-17:00)

This clashes with SOFTWIRE. Can you do it in the 17:10 session?

Regards
   Brian

On 2011-11-14 14:46, Hui Deng wrote:
> ------------------------------------------------------------------------
> 
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Nov 2011 02:22:51 +0000

On Nov 14, 2011, at 9:46 AM, "Hui Deng" <[email-masked]> wrote:
> Finally, there is such thing as secure DHCP, so if

This doesn't agree with the list of steps you gave subsequently.  I agree to that list, but not to what is said here.  That is, if both DHCP and ND are secure, prefer DHCP.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Nov 2011 02:24:37 +0000

> if you get addresses via SLAAC and DHCP, you use all...

Because "just merge" is essentially equivalent to "just walk across the river without your feet getting wet.".  If you can write a spec that does this correctly, you are probably the Messiah.

---

From: Ole Troan <[email-masked]>
Date: Mon, 14 Nov 2011 10:30:00 +0800

Ted,

> Because "just merge" is essentially equivalent to "just walk across the river without your feet getting wet.".  If you can write a spec that does this correctly, you are probably the Messiah.

isn't this what a host does anyway? if it has more than one router on the link?

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Nov 2011 02:32:41 +0000

> isn't this what a host does anyway? if it has more than one router on the link?

Yes, and they reliably do it wrong.  This is why we have a MIF working group!  :)

---

From: Ole Troan <[email-masked]>
Date: Mon, 14 Nov 2011 10:35:41 +0800

> Yes, and they reliably do it wrong.  This is why we have a MIF working group!  :)

wouldn't they continue to do it wrong if we were to specify a default "policy"?
I'm in the camp of "use all the information you've got". the prefer one of the other by default, is heading down 3484 country, and that hasn't been a pleasant experience.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Nov 2011 02:59:26 +0000

> I'm in the camp of "use all the information you've got". the prefer one of the other by default, is heading down 3484 country, and that hasn't been a pleasant experience.

Great, then we can disband MIF and save everyone a lot of time!  All of the various failure modes, DOS attacks and spoofing attacks that are possible in a MIF environment aren't all that important...  :)

---

From: Mohacsi Janos <[email-masked]>
Date: Mon, 14 Nov 2011 08:55:41 +0100 (CET)

> solution will be satisfactory to everyone.

I think in reality it will not be very easy to implement all these things. 
Some Operating System might implement RA(SEND), some the Secure DHCP, some 
none of above. . The operator should operate the network consistently: - 
same information all the relevant channel..... This preferential treatment 
can give  some protections against malicious activity or misconfiguration.

Best Regards,
 		Janos Mohacsi

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Nov 2011 09:28:56 +0000

On Nov 14, 2011, at 3:55 PM, "Mohacsi Janos" <[email-masked]> wrote:
> I think in reality it will not be very easy to implement all these things. Some Operating System might implement RA(SEND), some the Secure DHCP, some none of above. . The operator should operate the network consistently: - same information all the relevant channel..... This preferential treatment can give  some protections against malicious activity or misconfiguration.

This is true, but the problem is that the RA may be trustworthy and DHCP not, or vice versa. So it's not safe to assume that the information you get from each one is trustworthy, even though of course on a good network it should be.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 14 Nov 2011 11:08:17 +0100

Le 14/11/2011 03:24, Ted Lemon a écrit :
> On Nov 14, 2011, at 9:59 AM, "Ole Troan"<[email-masked]>
> wrote:
>> why not just merge all the information received? e.g. if you get
>> DNS server over DHCP and RA, use all. if you get addresses via
>> SLAAC and DHCP, you use all...
>
> Because "just merge" is essentially equivalent to "just walk across
> the river without your feet getting wet.".

One ingredient helping the merge is to represent data in the same
manner.  It would hardly merge two default route entries with a
lifetime on 32bit and another on 16bit.

Alex

> If you can write a spec that does this correctly, you are probably
> the Messiah. _______________________________________________ dhcwg
> mailing list [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Nov 2011 10:26:11 +0000

> lifetime on 32bit and another on 16bit.

Again?   Oy. 

The problem of merging has to do with orthogonal (and possibly untrustworthy) administrative domains, not trivial differences in data representation.  If /only/ the problem were that simple!

---

From: Maximilien Mouton <[email-masked]>
Date: Mon, 14 Nov 2011 12:58:26 +0100

Hello Ted, dhc and mif,

>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Ted Lemon
>Sent: lundi 14 novembre 2011 11:26
>To: Alexandru Petrescu
>Cc: [email-masked]; mif
>Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case
>

We all agree that this problem is not that simple.
I think if both RA and DHCP are trustworthy, information received can
be merge and consistent lifetimes size help to do this.
In case of conflict a choice as to be made by the client.
I agree with the rules stated by Hui.

But, for some cases, one way of managing RA and DHCP information is
already close to exist because rcf 4191 and draft route option (it is
not quite clear but it seems) propose route preference option.

Thus, with current specifications, if RA provides a default route with
a high preference and DHCP another default route with medium
preference the client should take RA's default route and vice versa.

The question is: Has this information decided by admins to prevail
over the rules stated here? If yes when?

Personally I think that clients should have the last word.

Maximilien

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 14 Nov 2011 22:41:31 +0900

Hui Deng wrote:

> DHCP should be preferred.

Then, why not just obsolete RA?

						Masataka Ohta

---

From: <[email-masked]>
Date: Mon, 14 Nov 2011 16:41:19 +0100

Hi,

IMU, conflict issue raises up when the node is simultaneously attached to two different administrative domains. In that case, we can't assume consistency in lifetime size or default route preference or whatever... In that case, it is reasonable to state that the node should apply the default policy as suggested by Hui.  

Pierrick
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> Maximilien Mouton
> Envoyé : lundi 14 novembre 2011 12:58
> À : Ted Lemon
> Cc : [email-masked]; mif
> Objet : Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case
> 
> Hello Ted, dhc and mif,
> 
> >
> >The problem of merging has to do with orthogonal (and possibly
> untrustworthy) administrative domains, not trivial differences in data
> representation.  If /only/ the problem were that simple!
> >
> 
>

---

From: Ole Troan <[email-masked]>
Date: Tue, 15 Nov 2011 21:42:13 +0800

> The problem of merging has to do with orthogonal (and possibly untrustworthy) administrative domains, not trivial differences in data representation.  If /only/ the problem were that simple!

how is a network (that I don't trust) going to tell me that I should trust it's information?
making DHCP preferred over RA seems irrelevant here.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Nov 2011 21:17:29 +0000

> making DHCP preferred over RA seems irrelevant here.

Well, things have moved on from this discussion, and now we are thinking that preferring DHCP actually breaks some things that people care about, so we're moving back in the direction of preferring RA.   In answer to your question, of course there's no way, in the abstract, to know what you can and can't trust.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Nov 2011 23:04:17 +1300

The main message I got was that there needs to be great care to ensure
that the semantics of information received via RA should be the
same (modulo superset/subset) as information received via DHCPv6.
That way, merging them becomes feasible.

   Brian

On 2011-11-16 22:34, Dmitry Anipko wrote:
>>> so we're moving back in the direction of preferring RA
> 
> My understanding is that part of the feedback from the room was also to move from "pick one" to "merge with tie breakers" approach, that would be no different from other cases where e.g. multiple RAs with settings of the same kind have been received and those settings are merged (specific prefixes, DNS settings etc).
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
> Sent: Tuesday, November 15, 2011 1:17 PM
> To: Ole Troan
> Cc: [email-masked]; Alexandru Petrescu; mif
> Subject: Re: [dhcwg] Conflict between RA and DHCP in MIF case
>

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 16 Nov 2011 09:34:27 +0000

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 16 Nov 2011 19:25:23 +0800

On 11-11-14 21:41, Masataka Ohta wrote:
> Hui Deng wrote:
> 
>> To summarize the discussion so far, Ted Lemon on MIF list agreed
>> that DHCP should be preferred.
> 
That's definitely a step too far. There are networks that do not
deploy DHCPv6 at all. The need to work. Thus RA is and remain to be needed.

There is significant demand for networks that does not use RA at all.
In such networks DHCPv6 should be able to provision complete set of
routing information. See recent Roberta's post to MIF about rationale
(http://www.ietf.org/mail-archive/web/mif/current/msg01412.html).
Another important list of arguments is provided here:
http://www.ietf.org/proceedings/74/slides/intarea-4.pdf
(Note that it is regarding a different proposal that was abandoned. Key
messages still stand, though).

I see a parallel to the way how addresses can be obtained today
(stateless and over DHCP). Those two methods coexist. Noone sane can
claim that one or the other method will go away. Of course, there are
some cases where one or the other method strongly dominates, but such
cases cannot be generalized ("I don't use feature X, so everyone else
should not use it either" is just wrong).

During recent presentation in MIF, several important aspects were
pointed out. I'll post to MIF, homenet and DHC shortly.

Regarding
Tomek

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 16 Nov 2011 21:03:37 +0900

Tomek Mrugalski wrote:

> That's definitely a step too far.

What is the point to have RA, only to be bothered by DAD
timeout?

> There are networks that do not deploy DHCPv6 at all.

> Thus RA is and remain to be needed.

Note that there are much more networks that do not
deploy IPv6 at all.

> There is significant demand for networks that does not use RA at all.

I know.

> routing information.

That's a wrong architecture.

Routing information should be provided by routing protocols.

It is architecturally wrong to try to make end systems
independent to IGPs.

> claim that one or the other method will go away.

It is a responsibility of IETF to remove unnecessary complexity
caused by useless RA.

Note that so called SLAAC is actually full of states, though
the states are maintained in unnecessarily distributed way by
all the related end systems (each node maintains its own state
of address assignment), which is why, stupidly enough, DAD is
required.

						Masataka Ohta

---

From: Thomas Narten <[email-masked]>
Date: Mon, 21 Nov 2011 15:36:00 -0500

> the river without your feet getting wet.".  If you can write a spec
> that does this correctly, you are probably the Messiah.

Isn't this what DHC already does? I.e., you run DHCP on two
interfaces, and get conflicting information.

The existing DHCP specs are silent on this, and the DHC WG has never
been willing to specify how to handle this case.

The case of getting conflicting DNS configuration information via DHC
seems a realistic scenario to me.

How do you propose this get handled?

Are you proposing we solve it for the DHC/RA case, but not for the
DHC/DHC case?

Thomas

---

From: Ted Lemon <[email-masked]>
Date: Mon, 21 Nov 2011 21:45:41 +0000

> interfaces, and get conflicting information.

I don't know what the antecedent to "this" was intended to be.

> been willing to specify how to handle this case.

Right, because it's been our position that this is not a DHCP problem.

> seems a realistic scenario to me.

It is completely realistic.

> How do you propose this get handled?

I think the right way to handle this is the way that the MIF working group has proposed: treat each provisioning domain separately.   Do not try to merge information you have no basis for assuming is valid across provisioning domains (which is all configuration information).   You wouldn't typically send an IP packet with a source address for interface 2 out of interface 2.   Why would you query a DNS server out of interface 2 when you learned about it through interface 1?

> Are you proposing we solve it for the DHC/RA case, but not for the

I think that having two ways of configuring things is a bad idea, and hence I claim that standardizing the RA DNS server option was a mistake, one which unfortunately can't be undone at this point.   I think that if we are going to say that RAs and DHCP servers can both provide some piece of configuration information, then we kind of have to treat them as separate provisioning domains.   But we can't really do that, because some information is provided only in RAs at the moment.

My main wish is just to not make the mess any worse; secondarily, I'd like to do what we can to make it less bad.

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 21 Nov 2011 16:57:18 -0500

my take: the MIF problem statement draft about to be published as RFC) discusses the various scenarios. probably more exists. But the issue of receiving config info from multiple sources is not specific to dhcpv6. it is related to any protocol sending config info. so it is a problem of pppv4, pppv6, dhcpv4, dhcpv6, RA, maybe even others.  Therefore, we need to find the right solution for all the cases together, instead of just looking at one specific provisioning protocol IP address family.  In this context, it appears to me that the right place to discuss that is within MIF wg.

my 2 cents.

Marc.

---

From: Ole Troan <[email-masked]>
Date: Tue, 22 Nov 2011 14:18:31 +0100

> I think the right way to handle this is the way that the MIF working group has proposed: treat each provisioning domain separately.   Do not try to merge information you have no basis for assuming…

for clarification, that was not my proposal. my suggestion was to merge all information within one "provisioning domain".
unsure if we will end up with provisioning domain = link, as detection of multiple provisioning domains on a single link may not be trivial in all corner cases.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Nov 2011 15:31:43 +0000

On Nov 22, 2011, at 8:18 AM, Ole Troan wrote:
for clarification, that was not my proposal. my suggestion was to merge all information within one "provisioning domain".
unsure if we will end up with provisioning domain = link, as detection of multiple provisioning domains on a single link may not be trivial in all corner cases.

I agree with you that right now detecting provisioning domains is not trivial; indeed, in some cases it's impossible.   However, if you think provisioning domain == link, then that's a problem that needs fixing.   Indeed, that's *the* problem that needs fixing.   I think we have to fix it; if we punt, we're going to pay for it later.