IETF Logo Mail Archive

Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt

Ted Lemon <Ted.Lemon@nominum.com> Sat, 29 September 2012 02:59 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4463B21F8643 for <dhcwg@ietfa.amsl.com>; Fri, 28 Sep 2012 19:59:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.626
X-Spam-Level:
X-Spam-Status: No, score=-105.626 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkIaYiKUrByE for <dhcwg@ietfa.amsl.com>; Fri, 28 Sep 2012 19:59:22 -0700 (PDT)
Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8B60821F863F for <dhcwg@ietf.org>; Fri, 28 Sep 2012 19:59:22 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUGZkChQaz2zaNGFy9IZeilS6QXAUXqvV@postini.com; Fri, 28 Sep 2012 19:59:22 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id BC03C108007 for <dhcwg@ietf.org>; Fri, 28 Sep 2012 19:59:21 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id AE65E19005C; Fri, 28 Sep 2012 19:59:21 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 28 Sep 2012 19:59:16 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Xuxiaohu <xuxiaohu@huawei.com>
Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt
Thread-Index: AQHNnPUuXMpQailO5E2MrdROm+zFG5eferUAgAC9JwCAAN51AIAAAe+A
Date: Sat, 29 Sep 2012 02:59:16 +0000
Message-ID: <96AEEED6-F7E2-4C0D-84B8-B4ED0CF5E054@nominum.com>
References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <5064C1D6.6070201@gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0755D36B@szxeml525-mbx.china.huawei.com> <489D13FBFA9B3E41812EA89F188F018E0F50792C@xmb-rcd-x04.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0755D57E@szxeml525-mbx.china.huawei.com>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0755D57E@szxeml525-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="gb2312"
Content-ID: <C2042346C31ECD4FAABE959C50A5EE65@nominum.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
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: Sat, 29 Sep 2012 02:59:23 -0000

On Sep 28, 2012, at 10:52 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> In addition, since this draft is just intended to use stateless DHCPv6, would you please list any concrete cases where the server needs to use the correct relay information?

The reason that even information request messages are required to be broadcast is that a device that does stateful and then stateless should get the same answers, and this can't happen if the relays aren't in the path and aren't able to add their options.

Also, it seems to me that your tunnel draft is applicable to prefix delegation; I realize this isn't an intended use that you have in mind, but it's certainly a perfectly valid one, and someone will no doubt want it at some later date.   So we shouldn't design a solution that we're not comfortable with in that case.

> As such, no matter a DHCP server or a DHCP relay agent is present on that BR, the implementations of DHCP on both the BR (either as a server or a relay agent) and the CE (as a client) should be changed and therefore are not in accordance with the existing RFC3315 specifications anymore.

This is why we are talking about updating RFC3315.

v2.23.0 | Report a Bug | By Email