Subject: Re: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Mon, 1 Jul 2013 13:32:20 +0000

Hi Ted,

On 28/06/13 11:18 PM, "Ted Lemon" <[email-masked]> wrote:

>On Jun 7, 2013, at 8:44 AM, Prashanth Patil (praspati)
><[email-masked]> wrote:
>> This draft proposes a mechanism to extend DHCPv6 such that a DHCPv6
>>Relay
>> Agent can dynamically influence priority of DNS servers provided to a
>> host, so that a host can use an optimal DNS server for resolution.
>
>Why don't you just configure the DHCP server to return DNS servers in a
>different order for different links?   Links are identified by relay
>agent, so this gets you the precise behavior you want, but with a
>centralized configuration file rather than with per-relay configuration.

Yes, this was one of the suggestions made earlier. Notification from relay
then becomes generic and not specific to DNS. The server decides whatever
actions need to be done, such as reconfiguring DNS server lists.

-Prashanth

>
>If you really want the relay to be the source of knowledge about DNS, why
>not return DNS servers via a relay-supplied options option?
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 1 Jul 2013 18:58:02 +0000

(ad hat off)

>> centralized configuration file rather than with per-relay configuration.

That is, I am not suggesting this as an alternative.   I am asking you why you don't consider this to be a better alternative.

The reason I ask is that what you are proposing is extremely harmful.   You are requiring new special protocol extension with new special-case code to be added to the DHCP server to handle this use case, and you are requiring that relay agents throughout the network be individually configured to specify behavior on the DHCP server, which is a maintenance nightmare.

So if you want to do something this harmful, you should have a good explanation for why it's better than the alternative.

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Tue, 2 Jul 2013 14:12:38 +0000

Hi Ted,

On 02/07/13 12:28 AM, "Ted Lemon" <[email-masked]> wrote:

>That is, I am not suggesting this as an alternative.   I am asking you
>why you don't consider this to be a better alternative.
>
>The reason I ask is that what you are proposing is extremely harmful.
>You are requiring new special protocol extension with new special-case
>code to be added to the DHCP server to handle this use case, and you are
>requiring that relay agents throughout the network be individually
>configured to specify behavior on the DHCP server, which is a maintenance
>nightmare.
>
>So if you want to do something this harmful, you should have a good
>explanation for why it's better than the alternative.

A static DNS order for different links introduces sub-optimal behavior
during transitions unless the servers are re-prioritized or until the host
stack re-initializes.
The draft proposes that a relay indicate dynamic transitions of the host
to the server which the server cannot learn otherwise or at best until the
next request eg: Dual-Stack-only to IPv6-only transition. With some
generalization to the proposal, a DHCP server could provide desired config
updates in a more responsive manner when the relay notifies host mode
changes without specifying behavior eg "Host changed from mode X to mode
Y".

-Prashanth

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 2 Jul 2013 16:22:41 +0000

I think they key concepts are:

1. An option from the relay during client requests (Relay-Forw) to the server as to whether the client is single/dual stacked (as the assumption is the relay monitors this).
2. A means for the relay to reconfigure the client (already covered by Reconfigure-Request) when changes in the dual stack-ness for a client is detected, perhaps passing this option to help the server determine what to tell the client about reconfiguring. I'm not sure that option adds significant value and requires complicated processing by the server - but if some implementation wanted to use it, I don't see the harm (it would be a MAY).

The above is also much more generalized. Whether the value here is worth it isn't for me to decide (as it may require substantial work in the relay agents).

How the server deals with that relay option data to select appropriate options (or option value ordering) is out of scope? Servers have vastly different configuration mechanisms. For example, with our server this could be easy to do as you can use client classing to control which bundle of options to use (we wouldn't have to change the code, though customers would have to write appropriate classing expressions to use the relay's option).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Prashanth Patil (praspati)
Sent: Tuesday, July 02, 2013 10:13 AM
To: Ted Lemon
Cc: [email-masked]; Tirumaleswar Reddy (tireddy)
Subject: Re: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt

Hi Ted,

On 02/07/13 12:28 AM, "Ted Lemon" <[email-masked]> wrote:

>> Yes, this was one of the suggestions made earlier. Notification from 
>>relay  then becomes generic and not specific to DNS. The server 
>>decides whatever  actions need to be done, such as reconfiguring DNS 
>>server lists.
>
>code to be added to the DHCP server to handle this use case, and you 
>are requiring that relay agents throughout the network be individually 
>configured to specify behavior on the DHCP server, which is a 
>maintenance nightmare.
>

A static DNS order for different links introduces sub-optimal behavior during transitions unless the servers are re-prioritized or until the host stack re-initializes.
The draft proposes that a relay indicate dynamic transitions of the host to the server which the server cannot learn otherwise or at best until the next request eg: Dual-Stack-only to IPv6-only transition. With some generalization to the proposal, a DHCP server could provide desired config updates in a more responsive manner when the relay notifies host mode changes without specifying behavior eg "Host changed from mode X to mode Y".

-Prashanth

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Jul 2013 16:39:07 +0000

> 2. A means for the relay to reconfigure the client (already covered by Reconfigure-Request) when changes in the dual stack-ness for a client is detected, perhaps passing this option to help the ser…

Thanks, Bernie—that's helpful.   I guess I can see the motivation for doing this, but it seems like some heavy gymnastics the entire purpose of which is to get around bugs in the client stack.   It's also something that a dual-stack DHCP server could detect on its own, if the relays implement the client link-layer-address relay option.   And it's also pretty experimental.

What's the use case?   Do we have a real-world application for this, or is it just something that is theorized to be useful in the future?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 2 Jul 2013 16:51:47 +0000

I'm not clear on the need for this myself. Is this a real problem or just an optimization?

I just figured if there was value, that this seemed like a much more streamlined approach. The draft didn't seem to address what happens when the client sends in requests (and making the DHCP server remember this from a reconfigure-request seemed a bit odd -- why not have the relay include this in each Relay-Forw if this is 'needed').

There's also the question of whether the client itself c/should tell the server this (i.e., it has a v4 address) -- if it is important. That would eliminate the relay from having to do the monitoring.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Tuesday, July 02, 2013 12:39 PM
To: Bernie Volz (volz)
Cc: Prashanth Patil (praspati); [email-masked]; Tirumaleswar Reddy (tireddy)
Subject: Re: [dhcwg] New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt

> 2. A means for the relay to reconfigure the client (already covered by Reconfigure-Request) when changes in the dual stack-ness for a client is detected, perhaps passing this option to help the ser…

Thanks, Bernie-that's helpful.   I guess I can see the motivation for doing this, but it seems like some heavy gymnastics the entire purpose of which is to get around bugs in the client stack.   It's also something that a dual-stack DHCP server could detect on its own, if the relays implement the client link-layer-address relay option.   And it's also pretty experimental.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Jul 2013 16:56:39 +0000

> I just figured if there was value, that this seemed like a much more streamlined approach. The draft didn't seem to address what happens when the client sends in requests (and making the DHCP serve…

Yes.   Also, why not just have an option that says "client is dual-stack, or not" and let the DHCP server decide what to do about it, rather than getting all specific about what it does with it?

> There's also the question of whether the client itself c/should tell the server this (i.e., it has a v4 address) -- if it is important. That would eliminate the relay from having to do the monitori…

Requires client changes, so it's understandable that we'd want to do it in relays.   Of course, there's a third unanswered question, which is "what about DHCPv4?"