Re: [dhcwg] draft-jiang-dhc-stateless-reconfiguration-01

Sheng Jiang <jiangsheng@huawei.com> Mon, 17 February 2014 05:43 UTC

Return-Path: <jiangsheng@huawei.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 7D86C1A035A for <dhcwg@ietfa.amsl.com>; Sun, 16 Feb 2014 21:43:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.749
X-Spam-Level:
X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 7oHkKG8H56WD for <dhcwg@ietfa.amsl.com>; Sun, 16 Feb 2014 21:43:01 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 37CC01A033C for <dhcwg@ietf.org>; Sun, 16 Feb 2014 21:43:00 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBE87455; Mon, 17 Feb 2014 05:42:57 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 05:42:35 +0000
Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 05:42:40 +0000
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.51]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 17 Feb 2014 13:42:36 +0800
From: Sheng Jiang <jiangsheng@huawei.com>
To: Yusuke DOI <yusuke.doi@toshiba.co.jp>, "<dhcwg@ietf.org>" <dhcwg@ietf.org>
Thread-Topic: [dhcwg] draft-jiang-dhc-stateless-reconfiguration-01
Thread-Index: AQHPK4ZD1LIqFKk32E6YYvetgI1Xj5q4tc1Q
Date: Mon, 17 Feb 2014 05:42:35 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923ADE4D33@nkgeml512-mbx.china.huawei.com>
References: <530170E0.3040004@toshiba.co.jp>
In-Reply-To: <530170E0.3040004@toshiba.co.jp>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.145]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/KZEUhVvOY_btYmUn1R8zCxqILIg
Subject: Re: [dhcwg] draft-jiang-dhc-stateless-reconfiguration-01
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, 17 Feb 2014 05:43:03 -0000

Hi, Yusuke,

Thanks for your reply and support. Some explanation below.

>>    {Question to WG No.2} There could be two kind of stateless DHCPv6
>>    reconfiguration modes as the following, which one is proper?  Or we
>>    should support both?
>
>Is there any difficulty to support both modes? I think these two modes should
>have different use cases. 'Push mode' will fit to our use case because the
>configuration is network-wide and push-mode (with multicast target -- it can
>be broadcasted on a link) is much much more efficient than trigger mode in
>LLN. But some administrator may want to have per-client configuration and
>that is the nature of DHCP, as described.

The difficulty is no technical aspect. However, there are two considerations for push mode:

a) the push mode is different from traditional DHC behavior in that clients is the initiator. So, this would need the agreement of DHC WG However, even the existing reconfiguration in stateful DHCPv6 is initiated by server side. So, this may not be too controversial. It is still a question requiring confirmation for now.

b) "push mode' may have more security issues that trigger mode. How to prevent a fake DHCPv6 server push malicious configuration is a difficulty, although DHCPv6 snooping may help. "Trigger mode" is safer for that client would contact original server for update configuration.

Regards,

Sheng

>Regards,
>
>// Yusuke DOI <yusuke.doi@toshiba.co.jp>
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www.ietf.org/mailman/listinfo/dhcwg