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

["Prashanth Patil (praspati)" <[e-mail]>]

Hi Bernie,

On 28/06/13 11:10 PM, "Bernie Volz (volz)" <[e-mail]> wrote:

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

Yes, this can be extended to relay forwards as well. In some cases, the
relay could already be aware of network characteristics which can be
indicated during a relay forward. The focus of the draft was to propose a
means to do this dynamically whenever the relay learns network
characteristics - especially in the DNS case where the relay determines
transitions such as IPv6-only to dual-stack, dual-stack to IPv6-only and
dual-stack to IPv4-only.

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

Right, currently the draft states that the relay only does this when
things change and doesn't have to monitor server responses. As you suggest
it would be useful to have this as part of subsequent Relay-Forw and not
have the server remember these.


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

Sure. The idea is to make this more generic and handle more than just DNS,
we'll update the draft.

-Prashanth


>
>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: [e-mail] [mailto:[e-mail]] On Behalf Of
>Prashanth Patil (praspati)
>Sent: Friday, June 07, 2013 8:45 AM
>To: [e-mail]
>Cc: Tirumaleswar Reddy (tireddy)
>Subject: [dhcwg] FW: New Version Notification for
>draft-wing-dhc-dns-reconfigure-01.txt
>
>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, "[e-mail]" <[e-mail]>
>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
>>
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dhcwg