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

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Fri, 7 Jun 2013 12:44:53 +0000

Hi all,
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.

Regards,
Prashanth

On 07/06/13 6:05 PM, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D, draft-wing-dhc-dns-reconfigure-01.txt
>has been successfully submitted by Dan Wing and posted to the
>IETF repository.
>
>Filename:	 draft-wing-dhc-dns-reconfigure
>Revision:	 01
>Title:		 DHCPv6 Dynamic DNS Reconfiguration
>Creation date:	 2013-06-07
>Group:		 Individual Submission
>Number of pages: 8
>URL:             
>http://www.ietf.org/internet-drafts/draft-wing-dhc-dns-reconfigure-01.txt
>Status:          
>http://datatracker.ietf.org/doc/draft-wing-dhc-dns-reconfigure
>Htmlized:        
>http://tools.ietf.org/html/draft-wing-dhc-dns-reconfigure-01
>Diff:            
>http://www.ietf.org/rfcdiff?url2=draft-wing-dhc-dns-reconfigure-01
>
>Abstract:
>   Some networks are expected to support IPv4-only, dual-stack, and
>   IPV6-only hosts at the same time.  This makes prioritizing the DNS
>   servers for hosts tricky due to a heterogeneous mix of protocol
>   stacks causing optimal behavior to occur only when the host stack re-
>   initializes.  The networks infrastructure is usually well equipped to
>   be aware of single/dual-stack nature of hosts.  This specification
>   extends DHCPv6 so that a DHCPv6 Relay Agent can dynamically influence
>   the priority of DNS servers provided to the host, so that the host
>   can use an optimal DNS server for resolution.
>
>                  
>        
>
>
>The IETF Secretariat
>

---

From: <[email-masked]>
Date: Fri, 7 Jun 2013 14:56:57 +0200

Hi all,

FWIW, more discussion on the problem space can be found here: http://www.ietf.org/mail-archive/web/v6ops/current/msg16276.html or http://tools.ietf.org/html/draft-kaliwoda-sunset4-dual-ipv6-coexist-01#section-2.

draft-wing-* solves this issue for dhcp-enabled networks.

Cheers,
Med

>-----Message d'origine-----
>De : Prashanth Patil (praspati) [mailto:[email-masked]]
>Envoyé : vendredi 7 juin 2013 14:45
>À : [email-masked]
>Cc : Dan Wing (dwing); Tirumaleswar Reddy (tireddy); BOUCADAIR Mohamed
>OLNC/OLN
>Objet : FW: New Version Notification for draft-wing-dhc-dns-reconfigure-
>01.txt
>
>Hi all,

---

From: Simon Perreault <[email-masked]>
Date: Mon, 10 Jun 2013 14:54:42 +0200

Hmmm... My first reaction was "this is crazy"...

The useful nugget in this draft is the host mode detection that is done 
by the relay and its communication to the server. It applies to much 
more than just DNS server list prioritization.

Why not generalize this a little bit? That is, have the relay send 
generic messages such as "host A changed from mode X to mode Y" to the 
server. The server would then decide whatever actions need to be done, 
such as reconfiguring DNS server lists.

Simon

Le 2013-06-07 14:56, [email-masked] a écrit :
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: <[email-masked]>
Date: Mon, 10 Jun 2013 15:03:32 +0200

Hi Simon,

Do you still think it is a crazy solution?

The draft focuses on the DNS since this is the concrete issue to be encountered. But, yes I do agree with you sending a generic message characterizing the connectivity gained by the connected device would be even better than giving the impression the message is dns-specific. The triggered-reconfigure procedure will be similar to what is already described in the draft. 

Cheers,
Med 

>De : [email-masked] [mailto:[email-masked]] De la part de
>Simon Perreault
>Envoyé : lundi 10 juin 2013 14:55
>À : [email-masked]
>Objet : Re: [dhcwg] New Version Notification for draft-wing-dhc-dns-
>reconfigure-01.txt
>
>> FWIW, more discussion on the problem space can be found here:
>http://www.ietf.org/mail-archive/web/v6ops/current/msg16276.html or
>http://tools.ietf.org/html/draft-kaliwoda-sunset4-dual-ipv6-coexist-
>01#section-2.
>>

---

From: Simon Perreault <[email-masked]>
Date: Mon, 10 Jun 2013 15:27:05 +0200

> Do you still think it is a crazy solution?

I'm at the "it could work" stage. Still far from the "it's a good idea"
stage. ;)

> The draft focuses on the DNS since this is the concrete issue to be
> encountered. But, yes I do agree with you sending a generic message
> characterizing the connectivity gained by the connected device would
> be even better than giving the impression the message is
> dns-specific. The triggered-reconfigure procedure will be similar to
> what is already described in the draft.

Awesome.

Simon

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 28 Jun 2013 17:40:01 +0000

Isn't this also only half the problem? And doesn't it cause more work for the relay?

What I mean is shouldn't there also be an option for the relay to communicate this for "normal" client traffic? I.e., all Relay-Forws. There might be more values (such as unknown) to be considered -- though I guess not including the option could imply that.

Doesn't this also imply that the relay would have to monitor what the server provided the client to know if it was wrong (and hence trigger a reconfigure). I guess the relay could just do this when things (regarding the client's provisioning) changed.

But what then happens if the client sends requests to the server at a later time? There's no signaling to the server from the relay as to what to send then? If the server sends the wrong information, how would the relay know without monitoring what the server actually delivers to the client (as there may not be a change in the client's connective).

While you could require the server to remember this from a Reconfigure-Request, that seems rather onerous and has issues if this state is lost or becomes stale (i.e., server misses updates from relay).

Also, this mechanism currently requires the clients to support Reconfigure. Otherwise, the relay's request doesn't cause any change at the client.

And, this again is where having this be a normal part of the Relay-Forw would be useful -- at least the server then has the ability to update the client at the next communication.

Note also that server policy to use perhaps shorter Information-Refresh or T1 times when this information isn't available or the relay reports it is 'unknown' could be used to 'correct' the information in the client more quickly once it is determined?

It would also be nice if this was expanded to handle more than DNS -- though exactly what else would use that information isn't completely clear.

Anyway, looks like this work will be discussed in the Sunset4/DHC WG joint session at Berlin (as well as at the DHC wg session).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Prashanth Patil (praspati)
Sent: Friday, June 07, 2013 8:45 AM
To: [email-masked]
Cc: Tirumaleswar Reddy (tireddy)
Subject: [dhcwg] FW: New Version Notification for draft-wing-dhc-dns-reconfigure-01.txt

Hi all,

Regards,
Prashanth

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Jun 2013 17:48:10 +0000

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

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?