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

Qi Sun <sunqi.csnet.thu@gmail.com> Mon, 02 December 2013 06:13 UTC

Return-Path: <sunqi.csnet.thu@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B811AE269 for <dhcwg@ietfa.amsl.com>; Sun, 1 Dec 2013 22:13:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0SQ5W5_dLah for <dhcwg@ietfa.amsl.com>; Sun, 1 Dec 2013 22:13:01 -0800 (PST)
Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id ED2C41AE15C for <dhcwg@ietf.org>; Sun, 1 Dec 2013 22:13:00 -0800 (PST)
Received: by mail-pd0-f170.google.com with SMTP id g10so17511803pdj.1 for <dhcwg@ietf.org>; Sun, 01 Dec 2013 22:12:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=jMpSqdHMDBZg0rKy12ijdmDJO9BvOEUWrLh1Ix9ZdfQ=; b=u0pc/DyH3fa+ZgBSAayn3Gqkvp/62j2NPBrDZylfRXVPuZgHmybQgqSUoGGvN5D/GD l90wMw5iBzI12nJPgPudwFHuQezYtI1QC+D7IELIrtqVd2ZKVIHY28tuldlhqE9XgfEO R3mvMfcWe4XYylDrd3uTfTmC+VS6wg1CWQYrT1X40W06WU5zT7aHPMsh79qNE8yYkzxS SnUczjqvZ7+PponhXtA8LePUVkn7HNThDRQW1COjt/qSKe2PZC7XN3w7VBmt1Pmd8r8X MNZVkaP3VL+cSO1ckKa6gkZqhZSAaY389LeWfH1XiiCMCCBWl3jL1rnGynVNNxv5WTJU hkMg==
X-Received: by 10.66.191.162 with SMTP id gz2mr1621511pac.151.1385964778890; Sun, 01 Dec 2013 22:12:58 -0800 (PST)
Received: from [192.168.199.122] ([166.111.68.231]) by mx.google.com with ESMTPSA id ye1sm135913904pab.19.2013.12.01.22.12.56 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Dec 2013 22:12:58 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-3--364319935
From: Qi Sun <sunqi.csnet.thu@gmail.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1ADC41A3@xmb-rcd-x04.cisco.com>
Date: Mon, 2 Dec 2013 14:12:52 +0800
Message-Id: <F476551F-B235-4334-8A54-13E72984D1CF@gmail.com>
References: <CEBB74DD.9C090%ian.farrer@telekom.de> <124F1F54-5997-46D9-A6F1-54F94E3D6423@gmail.com> <5295FCDD.9000300@viagenie.ca> <51308BAA-5F33-44B9-AB72-6AE42BA5E11D@gmail.com> <5296356D.90405@viagenie.ca> <489D13FBFA9B3E41812EA89F188F018E1ADC24C4@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1ADC25C8@xmb-rcd-x04.cisco.com> <CAF+sHxHSrZ5zEXrn0RpZqCUcfJ3xiisgFYKLCo5adBcMP3rGzA@mail.gmail.com> <6D0BACEB-D945-413B-98D9-3333092F45F6@cisco.com> <CAF+sHxGCk0hG2U+qMc+b=uk90c+c-4_WTJp-mxLLe-Vx_tuwCQ@mail.gmail.com> <489D13FBFA9B3E41812EA89F188F018E1ADC41A3@xmb-rcd-x04.cisco.com>
To: Bernie Volz (volz) <volz@cisco.com>
X-Mailer: Apple Mail (2.1085)
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2013 06:13:04 -0000

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