Subject: [dhcwg] Fwd: Dhcp client behavior in regard to Domain searchlist

From: ravi kumar <[email-masked]>
Date: Sun, 9 Jan 2011 18:57:45 +0530

Incase if there are two domain lists received from Dhcpv4 and Dhcpv6 servers
respectively, what should be the final list of domain suffixes to be used
for resolution.What should the precedence in choosing the list (V4 first and
V6 second etc ), incase if combined list is used for resolution.

regards
Ravi
---------- Forwarded message ----------
From: ravi kumar <[email-masked]>
Date: Fri, Jan 7, 2011 at 4:07 PM
Subject: Dhcp client behavior in regard to Domain searchlist
To: [email-masked], [email-masked]

Incase if Domain searchlist is received via Dhcpv4 and Dhcpv6 servers,
through options 119 and 24, I would like to know the behavior of Linux
client. Are both search lists passed to DNS for DNS resolution ? Is there
any precedence in choosing the order of lists : V4 first and V6 second etc ?

regards
Ravi

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 10 Jan 2011 16:05:44 -0600

You might want to look at
http://tools.ietf.org/id/draft-ietf-dhc-dual-stack-merge-01.txt.

I think this work died?

-          Bernie

From: [email-masked] [mailto:[email-masked]] On Behalf
Of ravi kumar
Sent: Sunday, January 09, 2011 8:28 AM
To: DHC WG
Subject: [dhcwg] Fwd: Dhcp client behavior in regard to Domain
searchlist

Incase if there are two domain lists received from Dhcpv4 and Dhcpv6
servers respectively, what should be the final list of domain suffixes
to be used for resolution.What should the precedence in choosing the
list (V4 first and V6 second etc ), incase if combined list is used for
resolution.

regards

Ravi

---------- Forwarded message ----------
From: ravi kumar <[email-masked]>
Date: Fri, Jan 7, 2011 at 4:07 PM
Subject: Dhcp client behavior in regard to Domain searchlist
To: [email-masked], [email-masked]

Incase if Domain searchlist is received via Dhcpv4 and Dhcpv6 servers,
through options 119 and 24, I would like to know the behavior of Linux
client. Are both search lists passed to DNS for DNS resolution ? Is
there any precedence in choosing the order of lists : V4 first and V6
second etc ?

regards

Ravi

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 Jan 2011 18:05:57 -0500

> I think this work died?

Arguably this is work for the mif working group.

---

From: ravi kumar <[email-masked]>
Date: Tue, 11 Jan 2011 07:05:55 +0530

Thanks for your responses.
What is the approach followed by Dhcp client implemenations that support
both option 119 (Dhcpv4) and option 24 (Dhcpv6), as the behavior is not
documented in any RFC.

regards
Ravi

---

From: Tim Chown <[email-masked]>
Date: Tue, 11 Jan 2011 12:04:01 +0000

> Arguably this is work for the mif working group.

The original problem space is discussed in RFC4477.     A few issues were discussed in that draft, and the conclusion of the wg was to operate separate DHCPv4 and DHCPv6 services until a site becomes fully IPv6-only.   The implication of that conclusion was that a method to merge responses from separate servers was required, which was what led to the now expired draft-ietf-dhc-dual-stack-merge-01 draft being written by Stig and me.  If the servers are under the same administrative control, the responses should be consistent.   The more interesting case is where they are not, which is where Ted's suggestion to look at the mif work is appropriate.    Having said that even back in 2006 when RFC4477 was finalised we said in there 'look at the emerging IETF multiple interface work', but because it's a difficult problem there still really isn't an IETF-published solution.   And of course we also noted in 2006 that production use of DHCPv6 was still in its infancy, which means we didn't have a lot of operational experience to draw on.  That's probably still true to say today, sadly.

If there's interest in reviving the work with the hindsight of 4 extra years of experience we can consider that, otherwise check out the mif WG progress.

Tim

---

From: David Hankins <[email-masked]>
Date: Fri, 14 Jan 2011 14:47:07 -0800

> both option 119 (Dhcpv4) and option 24 (Dhcpv6), as the behavior is not

The client implementations whose inner workings I'm familiar with clobber
each other, one or the other survives.  This isn't a terrible state of
affairs; optimally the administrator should properly keep these two
configuration values identical, at least according to the current
epistemology in domain search path configuration.  As an optimization to
this clobbering, I would mostly only suggest that the DHCPv6 derived value
always take precedence.

It seems like a slightly more clever client might attempt to combine the
lists, either by stupid appension of one after the other or some more
complicated unique-merging of the two.  But I don't think this is helpful to
the network operator who produces the search paths; a DHCPv4 configured
search path could have an element in it that has AAAA's, and thus affect the
IPv6 network.

I have sometimes considered augmenting the client's stub resolver to accept
different search path configurations for AAAA vs A lookups, and to then
configure both values separately.  The client would be expected to perform a
stepladder search between the two.  Starting on the v6 path first, it then
tries the v4 path until it finds a name that matches the next name on the v6
path (and stops before trying this name).  It then returns to the next name
on the v6 path and continues.

v6 path: experiment.example.com, eng.example.com, example.com,
ooo.example.com
v4 path: eng.example.com, ooo.example.com, example.com

In this case the stub resolver would try, in order, until the first success;

AAAA experiment.example.com
AAAA eng.example.com
A eng.example.com
A ooo.example.com
AAAA example.com
A example.com
AAAA ooo.example.com

Primarily, I am attracted to this solution due to its vulgarity, but after
some thought I tend to conclude that this fits with the
DHCP-server-operator's expectations of client behavior with the related
search paths.

-- 
David W. Hankins
SRE
Google, Inc.

---

From: ravi kumar <[email-masked]>
Date: Sun, 16 Jan 2011 00:52:08 +0530

Thanks for your response.

regards
Ravi
On Sat, Jan 15, 2011 at 4:17 AM, David Hankins <[email-masked]> wrote:

>  On Mon, Jan 10, 2011 at 5:35 PM, ravi kumar <[email-masked]>wrote:
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 16 Jan 2011 10:44:02 -0500

Ultimately, of course, the search path is simply a bad idea, and it's best to simply never use it.   Ambiguity is undesirable in networking protocols.