Subject: 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: Karl Auer <[email-masked]>
Date: Mon, 14 Nov 2011 13:10:31 +1100

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

It's about *conflict*, I think.

I.e., when  the information coming from RA and DHCP cannot be "merged" -
for example, differing domain search lists, or default routing
information.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])                   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156

---

From: Karl Auer <[email-masked]>
Date: Mon, 14 Nov 2011 13:20:24 +1100

> d) RA(SEND) vs secure DHCP => prefer DHCP

Can this be summarised as "prefer DHCP except over RA+SEND"?

My apologies if this has already been dealt with, but it seems to me
that the behaviour SHOULD be configurable, with the above being the
default position if it is not configured or not configurable.

Regards, K.

---

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:27:02 +0800

Karl,

> for example, differing domain search lists, or default routing

can you give examples of what information cannot be merged?
certainly a default router list can be merged...

cheers,
Ole

---

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: Karl Auer <[email-masked]>
Date: Mon, 14 Nov 2011 13:47:39 +1100

> certainly a default router list can be merged...

If one source says that the domain search list is "a.com b.com c.com"
and another source says it is "c.com a.com b.com", how can you merge the
search lists?

Or if one source says that the default route is via IP address 1, and
the other source says that the default route is via IP address 2, which
IP address are you supposed to use as your default route? Sure, you can
set up two default routes - but when a packet turns up for which you
have no more specific route, which IP address will you send it to?
Something has to choose, using some criterion or other.

Some things cannot be merged - that's what "conflict" means.

Regards, K.

---

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: Mark Andrews <[email-masked]>
Date: Mon, 14 Nov 2011 14:27:44 +1100

> and another source says it is "c.com a.com b.com", how can you merge the

Anyone depending apon search lists that they did not set already
has a broken configuration.  Anyone depending apon search lists in
RA's or DHCP messages being honoured by machines already has a
broken configuration.

Search lists are things that should be set by users for themselves.

ISP's SHOULD NOT be setting search lists in DHCP responses to
customers.  Hotspots's SHOULD NOT be setting search lists in DHCP
responses to customers.

Enterprises MAY advertise a search lists when configuring their own
machines.  Homes MAY advertise a search lists when configuring their
own machines.

Enterprises and homes SHOULD NOT set search lists when responding
to DHCP queries on guest networks.

Similarly for RA's.

> Something has to choose, using some criterion or other.

If they are both true "default routers" then it doesn't matter which
you send to.  If they are not then there is nothing a machine can
do automatically.

> --=20
> --=-dBD+3PSBkGldJAphgaQ5
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: This is a digitally signed message part
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> 
> iEYEABECAAYFAk7AgUsACgkQMAcU7Vc29od/4QCbBqCgnAOZiE0+zx3l0VFFGP+2
> D0YAnjVCFgBd5WbgE1alnPfi/01lnfQm
> =zTr6
> -----END PGP SIGNATURE-----
> 
> --=-dBD+3PSBkGldJAphgaQ5--
> 
> 
> --===============7419444934332968338==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> --===============7419444934332968338==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Karl Auer <[email-masked]>
Date: Mon, 14 Nov 2011 15:04:51 +1100

On Mon, 2011-11-14 at 14:27 +1100, Mark Andrews wrote:
> has a broken configuration.

I didn't say people should do these things, just that there are things
that *can be* delivered via RA and that *can be* delivered via DHCP, and
that *can conflict*.

If things do conflict, then something has to decide, on some criterion
or other, which to honour (or to honour neither of course).

My post was in answer to a question from someone about about how things
could conflict. That's all.

> machines.  Homes MAY advertise a search lists when configuring their

Well - yes. And if their DHCP server says one thing and their RAs are
saying another, then there should be a sane default for deciding which
to use. That's all this is about.

Regards, K.

---

From: Doug Barton <[email-masked]>
Date: Sun, 13 Nov 2011 20:10:01 -0800

> that *can be* delivered via RA and that *can be* delivered via DHCP, and

Given that this is a configuration error by definition, why can't we
just say that the behavior under these circumstances is undefined?

Doug

-- 

		"We could put the whole Internet into a book."
		"Too practical."

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Mark Andrews <[email-masked]>
Date: Mon, 14 Nov 2011 15:54:41 +1100

> to use. That's all this is about.

Just let implementations pick one and stick with it until it changes.
Difference *will* occur as a matter of operational practice whenever
the list is changed so this isn't a error condition unless it
continues for a long time.  If you update the DHCP server the RA
will be out of date.  If you update the RA first the DHCP server
will be out of date.

> =20

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 14 Nov 2011 00:04:58 -0600

+1 to Karl's emails.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Karl Auer
Sent: Monday, November 14, 2011 12:05 PM
To: IETF IPv6
Subject: Re: [dhcwg] Conflict between RA and DHCP in MIF case

On Mon, 2011-11-14 at 14:27 +1100, Mark Andrews wrote:
> Anyone depending apon search lists that they did not set already has a 
> broken configuration.

I didn't say people should do these things, just that there are things that *can be* delivered via RA and that *can be* delivered via DHCP, and that *can conflict*.

If things do conflict, then something has to decide, on some criterion or other, which to honour (or to honour neither of course).

My post was in answer to a question from someone about about how things could conflict. That's all.

> machines.  Homes MAY advertise a search lists when configuring their 

Well - yes. And if their DHCP server says one thing and their RAs are saying another, then there should be a sane default for deciding which to use. That's all this is about.

Regards, K.

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 14 Nov 2011 00:13:07 -0600

If a correct source is not chosen the return path may not be symmetric
and cause issues to the subscriber.  For example native IPv6 and 6rd are
running concurrently in a home served by broadband access.

I can't see how can routing information from two sources be merged if
there is a conflict.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hemant Singh (shemant)
Sent: Monday, November 14, 2011 2:05 PM
To: Karl Auer; IETF IPv6
Subject: RE: [dhcwg] Conflict between RA and DHCP in MIF case

+1 to Karl's emails.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Karl Auer
Sent: Monday, November 14, 2011 12:05 PM
To: IETF IPv6
Subject: Re: [dhcwg] Conflict between RA and DHCP in MIF case

Regards, K.

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old
fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

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: Ole Troan <[email-masked]>
Date: Thu, 17 Nov 2011 19:28:15 +0800

Karl,

> and another source says it is "c.com a.com b.com", how can you merge the

refer to Mark's mail on search lists.

> Something has to choose, using some criterion or other.

huh? that's exactly how router discovery in IPv6 works.
put all default routers on your default routers list. read 4861 and 4191 for more details.

> Some things cannot be merged - that's what "conflict" means.

I am yet to see what information that would be.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Thu, 17 Nov 2011 19:30:45 +0800

Karl,

> Some things cannot be merged - that's what "conflict" means.

I presume we are talking about merging information received on a single interface?
for the multiple interface case I would consider each interface's configuration information independent.

Ole

---

From: Karl Auer <[email-masked]>
Date: Thu, 17 Nov 2011 23:01:09 +1100

> refer to Mark's mail on search lists.

Why? It has no bearing on your question. You asked for things which
could not be merged. I gave you an example. It wasn't a recommendation.

> put all default routers on your default routers list. read 4861 and 4191 for more details.

Perhaps you should. Most of the discussion of default routers in those
RFCs is actually about discriminating between not-so-default-after-all
routers. However, it was indeed a poor example under the circumstances.

Regards, K.

---

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

> 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 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.

---

From: Tao Sun <[email-masked]>
Date: Thu, 1 Dec 2011 02:30:25 +0800

Sorry for jump to this discussion thread late.
The route policy shall be well considered by the operator/network. If we
discuss confliction, it is more like to be the network configuration that
may appear for MIF host rather than the mechanism of DHCPv6 or RA. Even we
only use RIO, the confliction may still apprear on different interfaces.

You may refer to the problem analysis discussed and agreed in 3GPP:
http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_85_XiAN/Docs/S2-112902.zip
Regards,

Tao
On Tue, Nov 22, 2011 at 11:31 PM, Ted Lemon <[email-masked]> 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.
>
>