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

"Bernie Volz (volz)" <> Thu, 28 November 2013 16:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C35571AE0BC for <>; Thu, 28 Nov 2013 08:20:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.501
X-Spam-Status: No, score=-9.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, 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 j7iUxlbY-Rjr for <>; Thu, 28 Nov 2013 08:20:50 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 19B351AE058 for <>; Thu, 28 Nov 2013 08:20:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=14215; q=dns/txt; s=iport; t=1385655649; x=1386865249; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5gWj0R0rkdI+KAxI2qdWzDDdWmFaqxTx9skUUCFiUys=; b=di0+NWwTk92ExfWmHaviMoPpJkNjoDVjtQ8ccHNt61122gqdbN3kufB8 HiBa9wgu8BXaNYqNfGw8yuvbopc/BCNQQZGFmr/ympP4aYa+RALeQsUlI S8xIKNvIFGMZmhVk6G6pS2vULJr5xP8uwQrpalhEREEEDSqwEzVnpXxSh g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.93,791,1378857600"; d="scan'208,217";a="2954484"
Received: from ([]) by with ESMTP; 28 Nov 2013 16:20:29 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id rASGKTmD025160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Nov 2013 16:20:29 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Thu, 28 Nov 2013 10:20:29 -0600
From: "Bernie Volz (volz)" <>
To: Cong Liu <>
Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013
Thread-Index: Ac7pYNYYaEg536DmSXaLna21+HapNwCJ4I2AAATinFcAAnKFAAAAXnfQACXBnoAAAXNIagAPuz+AAAtX1gA=
Date: Thu, 28 Nov 2013 16:20:28 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1ADC41A3xmbrcdx04ciscoc_"
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: Thu, 28 Nov 2013 16:20:54 -0000

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