IETF Logo Mail Archive

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

"Bernie Volz (volz)" <volz@cisco.com> Sat, 29 September 2012 03:38 UTC

Return-Path: <volz@cisco.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 1A0BE21F8613 for <dhcwg@ietfa.amsl.com>; Fri, 28 Sep 2012 20:38:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.474
X-Spam-Level:
X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 tPsJXir4pb61 for <dhcwg@ietfa.amsl.com>; Fri, 28 Sep 2012 20:37:59 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA6C21F8496 for <dhcwg@ietf.org>; Fri, 28 Sep 2012 20:37:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2305; q=dns/txt; s=iport; t=1348889867; x=1350099467; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Rp+TrvnndHQbC4G5OVXiRQiK0Lf3y3PNT24TvCW+5F0=; b=Qs1YeweJpx30UX9Rtc8nZJdtVgFd05vvzwcoU4NLiyQCuWkYDxC71Ww9 IIVyL2Q1ttBGElD7zLCdwUKKVSJrEABIKOcNmk74AZNwaWKYI0502TRey AaymFP8+8rKX9OwMfErqaIBnAMURcGvnvRzy9BIEqwjakitj5Li7cSBbz g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAOZrZlCtJXHA/2dsb2JhbABFvjCBCIIgAQEBAwESASc/BQcEAgEIEQQBAQEKFAkHMhQJCAIEAQ0FCBMHh10GmG+gGYsfFIVXYAOkK4FpgmeBWj0
X-IronPort-AV: E=Sophos;i="4.80,505,1344211200"; d="scan'208";a="126595926"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 29 Sep 2012 03:37:46 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8T3bkUl007358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 29 Sep 2012 03:37:46 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Fri, 28 Sep 2012 22:37:46 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Ted Lemon <Ted.Lemon@nominum.com>, Xuxiaohu <xuxiaohu@huawei.com>
Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt
Thread-Index: AQHNnPUoSDMOAnuzpUmlatl1eCUEGJee/TdwgAC6FeCAANr4AIAAZHYA//+0lMA=
Date: Sat, 29 Sep 2012 03:37:45 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F507C50@xmb-rcd-x04.cisco.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> <96AEEED6-F7E2-4C0D-84B8-B4ED0CF5E054@nominum.com>
In-Reply-To: <96AEEED6-F7E2-4C0D-84B8-B4ED0CF5E054@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.86.247.159]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19216.004
x-tm-as-result: No--35.764700-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
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 03:38:00 -0000

> This is why we are talking about updating RFC3315.

Yup ... my point exactly.

As stated in RFC3315 section 13, a separate document may detail how to apply DHCPv6 to other link types. I think it is rather natural to have to relax some of the unicast restrictions if multicast isn't used (how else would this work). I think this is perfectly in line with what was intended by such a document.

I would also like to make sure we design something that can support all of DHCPv6 and not something limited to Information-Request/Reply. Also, perhaps I missed it but I see nothing in your document that states it is limited to Information-Request/Reply? But again, even if it did say that, I would still want us to specify something that could accommodate the full DHCPv6 range of messages.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com] 
Sent: Friday, September 28, 2012 10:59 PM
To: Xuxiaohu
Cc: Bernie Volz (volz); Tomek Mrugalski; dhcwg@ietf.org
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt

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