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

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: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Prashanth Patil (praspati)
Sent: Tuesday, July 02, 2013 10:13 AM
To: Ted Lemon
Cc: dhcwg@ietf.org; 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" <Ted.Lemon@nominum.com> wrote:

>(ad hat off)
>
>On Jul 1, 2013, at 9:32 AM, Prashanth Patil (praspati) 
><praspati@cisco.com> 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.
>
>I'm sorry, but you did not answer my question.   The question was this:
>
>>> 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.
>
>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

>

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg