Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03

Hi Bernie,

Thanks for considering this. It could optimize the DHCPv4 unicast case, but may bring in some complexity. 

IMHO, this is the current model:

When DHCPv4 unicast, the 4o6 client sends unicast packets to the available servers (listed in the 4o6 Server Address option), of course, with the Unicast Flag set. The server that was selected by the client will reply while the other servers would silently drop the packets. Then the client will get response from the dedicated server. 

I'm not sure if this model would cause potential issues (it works, IMHO). Could you please point out if I missed anything?  

Thanks,
Qi

On 2013-11-29, at 上午12:20, Bernie Volz (volz) wrote:

> The Server-Unicast option (if this is adopted) would be in the BOOTREPLYV6 which is processed by the 4o6 DHCP Client and does not impact the normal DHCPv6 transactions. (The 4o6 DHCP Client would request this in the ORO in the BOOTREQUESTV6.)
>  
> I’m not sure if this is worth it. But just figured I’d suggest it.
>  
> -          Bernie
>  
> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Cong Liu
> Sent: Thursday, November 28, 2013 10:44 AM
> To: Bernie Volz (volz)
> Cc: dhcwg@ietf.org
> Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013
>  
> Hi Bernie,
>  
> Sorry, I thought you were talking about reuse 4o6 Server Address option.
>  
> If regular DHCPv6 process is not affected by reusing Server Unicast option, I think it's a good solution.
>  
> Cong
>  
> 2013/11/28 Bernie Volz (volz) <volz@cisco.com>
> Cong, I don't understand this. Server-unicast option can only specify one address.
>  
> The 4o6 client has two lists - the "broadcast" list and the "unicast" list. When v4 packet is to be "broadcast", the "broadcast" list is used. When unicast and the unicast list is not empty, it is used; otherwise broadcast list is used. Broadcast list comes from new 4o6 option or the v6 multicast address. Unicast list is empty unless the server's v4 lease that was selected sent a server-unicast option.
>  
> Yes, if v4 client sends broadcast, packet could go to multiple servers but that's what happens with native v4.
>  
> Anyway, just a thought to reduce traffic for v4 unicast case.
>  
> - Bernie (from iPad)
> 
> On Nov 28, 2013, at 2:32 AM, "Cong Liu" <gnocuil@gmail.com> wrote:
> 
> Hi Bernie,
>  
> 2013/11/28 Bernie Volz (volz) <volz@cisco.com>
> Here's a question we can also ponder ...
> 
> Should we perhaps allow the server to send back the Server-Unicast option to tell the 4o6 Client where it can send unicast (DHCPv4) packets to? This would allow DHCPv4 unicast packets to be sent directly to the server (of course inside a BOOTREQUESTV6 message).
>  
> Assume IPv6 lease time is 100s, and IPv4 lease time is 200s. Then the 4o6 Client receives a Server-Unicast option (which may contains 10 unicast addresses) every 100s, and a Server-Unicast option (which contains 1 unicast address) every 200s. I think it adds more complexity for client to deal with the same option from different servers (DHCPv6 / DHCP4o6).
>  
> Best Regards,
> Cong
> _______________________________________________
> 
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>  
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg