Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

"Bernie Volz (volz)" <> Mon, 02 December 2013 16:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B89C41AD6D2 for <>; Mon, 2 Dec 2013 08:54:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cvckbQgMU5OW for <>; Mon, 2 Dec 2013 08:54:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2A4FC1AD6D1 for <>; Mon, 2 Dec 2013 08:54:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=31702; q=dns/txt; s=iport; t=1386003274; x=1387212874; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mdP7ANQ47/hU6FjAApPHojm7pwky8SG19SotM15uRX0=; b=C+XDa9qpD/R+827XIN/Q120OheFzUE23gxKRqpBBsWcOycYbfzljfnva oLx6rI5i3ycMMQU3AE1mqG2Fr1J3/1A6/qW1B/RPIDy254KyC45E76ioh wgZ3KSiu6dIC96+WQtM6Vy/qytH5T6+Jd8UmRIAdjF7C1G39WEbzOB73k 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.93,811,1378857600"; d="scan'208,217"; a="288816830"
Received: from ([]) by with ESMTP; 02 Dec 2013 16:54:33 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id rB2GsXSR027475 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 16:54:33 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 10:54:32 -0600
From: "Bernie Volz (volz)" <>
To: Qi Sun <>
Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013
Thread-Index: AQHO7yWSS0MmG+jVj0KJEABUOdok9ppBH2XQ
Date: Mon, 2 Dec 2013 16:54:32 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1ADC94F2xmbrcdx04ciscoc_"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Dec 2013 16:54:38 -0000


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 [] On Behalf Of Qi Sun
Sent: Monday, December 02, 2013 1:13 AM
To: Bernie Volz (volz)
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?


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 [] On Behalf Of Cong Liu
Sent: Thursday, November 28, 2013 10:44 AM
To: Bernie Volz (volz)
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.


2013/11/28 Bernie Volz (volz) <<>>
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" <<>> wrote:
Hi Bernie,

2013/11/28 Bernie Volz (volz) <<>>
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,

dhcwg mailing list<>

dhcwg mailing list<>