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

Qi:

There are no issues caused by not adding this capability.

The benefit, at the cost of more complexity, would be fewer packets being processed by the ‘available’ servers.

I was just raising it as a possibility for the WG to consider. I have no issue if we decide that the benefit is not worth the cost (and thus leave this completely out of the document).

-          Bernie

From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Qi Sun
Sent: Monday, December 02, 2013 1:13 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,

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<mailto: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<mailto: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<mailto:gnocuil@gmail.com>> wrote:
Hi Bernie,

2013/11/28 Bernie Volz (volz) <volz@cisco.com<mailto: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<mailto:dhcwg@ietf.org>
https://www.ietf.org/mailman/listinfo/dhcwg

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