From narten@us.ibm.com Thu Jan 6 06:38:13 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEC573A6E1E for ; Thu, 6 Jan 2011 06:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.127 X-Spam-Level: X-Spam-Status: No, score=-104.127 tagged_above=-999 required=5 tests=[AWL=-1.528, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94nzUtuRulBu for ; Thu, 6 Jan 2011 06:38:12 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by core3.amsl.com (Postfix) with ESMTP id C64063A6D3C for ; Thu, 6 Jan 2011 06:38:12 -0800 (PST) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p06EGNKV009631 for ; Thu, 6 Jan 2011 09:16:25 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 7AC0F4DE8043 for ; Thu, 6 Jan 2011 09:36:53 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p06EdiTI163800 for ; Thu, 6 Jan 2011 09:39:44 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p06EdhiQ032696 for ; Thu, 6 Jan 2011 09:39:44 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-205-129.mts.ibm.com [9.65.205.129]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p06EdhwK032669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Jan 2011 09:39:43 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p06Edgwg022576 for ; Thu, 6 Jan 2011 09:39:42 -0500 Message-Id: <201101061439.p06Edgwg022576@cichlid.raleigh.ibm.com> To: "dhcwg@ietf.org WG" In-reply-to: <36A80113-2DF3-4D81-8490-D0FD91DFD2F9@nominum.com> References: <36A80113-2DF3-4D81-8490-D0FD91DFD2F9@nominum.com> Comments: In-reply-to Ted Lemon message dated "Tue, 21 Dec 2010 15:32:34 -0500." Date: Thu, 06 Jan 2011 09:39:42 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-duid-uuid-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 14:38:13 -0000 Hi all. Now that the holiday break is over, some reviews of this document would be appreciated. The WG won't advance it if there is only silence... It's a short document. Only about 3 pages of substance. Thanks! Thomas Ted Lemon writes: > We've been asked to do a last call on this draft; the authors > believe that it's ready, and at least one reviewer believes so too. > Please take this opportunity to review the draft if you have not > already done so. If you find problems, please discuss them here on > the mailing list. If you favor advancing the draft, please say so. > If you do not want the draft to advance, please say so. If we hear > nothing but dead silence, the draft will not advance. > I will be offline from 12/30/10 to 1/10/10, so I will make some > determination as to the consensus on this draft when I get back > online on the 10th. > Thanks! > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Stephen.Jacob@nominum.com Thu Jan 6 08:53:42 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18B13A6C4F for ; Thu, 6 Jan 2011 08:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icPwCtJoe1F9 for ; Thu, 6 Jan 2011 08:53:40 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id C2B7E3A6C24 for ; Thu, 6 Jan 2011 08:53:40 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTSX0ExggVUcvaGDTj8PwLRDD9coT5Vsq@postini.com; Thu, 06 Jan 2011 08:55:48 PST Received: by shell-too.nominum.com (Postfix, from userid 11053) id 6CF3F1B82CA; Thu, 6 Jan 2011 08:55:47 -0800 (PST) Date: Thu, 6 Jan 2011 08:55:47 -0800 From: Stephen Jacob To: Ted Lemon Message-ID: <20110106165547.GC29859@shell-too.nominum.com> Mail-Followup-To: Ted Lemon , "dhcwg@ietf.org WG" References: <36A80113-2DF3-4D81-8490-D0FD91DFD2F9@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <36A80113-2DF3-4D81-8490-D0FD91DFD2F9@nominum.com> User-Agent: Mutt/1.4.2.2i X-URI: http://www.nominum.com/ Organization: Nominum, Inc. Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-duid-uuid-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 16:53:42 -0000 The document looks good. My only very, very minor concerns are: - A tiny nit! "DHCP protocol" seems repetetive - I have a question in my mind as to whether the security considerations section is even necessary given that there is no new additional security issue. That same issue applies to any DUID, not just DUID-UUID. Even with the above, I approve. +1 Regards, Stephen On Tue, Dec 21, 2010 at 03:32:34PM -0500, Ted Lemon wrote: > We've been asked to do a last call on this draft; the authors believe that it's ready, and at least one reviewer believes so too. Please take this opportunity to review the draft if you have not already done so. If you find problems, please discuss them here on the mailing list. If you favor advancing the draft, please say so. If you do not want the draft to advance, please say so. If we hear nothing but dead silence, the draft will not advance. > > I will be offline from 12/30/10 to 1/10/10, so I will make some determination as to the consensus on this draft when I get back online on the 10th. > > Thanks! > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Stephen Jacob | Stephen.Jacob@nominum.com | +1 650 381 6051 Nominum, Inc. | http://www.nominum.com/ | +1 650 381 6000 From tom111.taylor@bell.net Thu Jan 6 10:38:46 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EEB63A6F3A for ; Thu, 6 Jan 2011 10:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.765 X-Spam-Level: X-Spam-Status: No, score=-101.765 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmy+T8KXSyHR for ; Thu, 6 Jan 2011 10:38:45 -0800 (PST) Received: from blu0-omc1-s13.blu0.hotmail.com (blu0-omc1-s13.blu0.hotmail.com [65.55.116.24]) by core3.amsl.com (Postfix) with ESMTP id B54BD3A6F3D for ; Thu, 6 Jan 2011 10:38:45 -0800 (PST) Received: from BLU0-SMTP35 ([65.55.116.7]) by blu0-omc1-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Jan 2011 10:40:52 -0800 X-Originating-IP: [70.26.23.173] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([70.26.23.173]) by BLU0-SMTP35.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Jan 2011 10:40:52 -0800 Date: Thu, 6 Jan 2011 13:40:55 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Thomas Narten References: <36A80113-2DF3-4D81-8490-D0FD91DFD2F9@nominum.com> <201101061439.p06Edgwg022576@cichlid.raleigh.ibm.com> In-Reply-To: <201101061439.p06Edgwg022576@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jan 2011 18:40:52.0289 (UTC) FILETIME=[3EC26B10:01CBADD1] Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-duid-uuid-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:38:46 -0000 I support advancing this draft. On 06/01/2011 9:39 AM, Thomas Narten wrote: > Hi all. > > Now that the holiday break is over, some reviews of this document > would be appreciated. The WG won't advance it if there is only > silence... > > It's a short document. Only about 3 pages of substance. > > Thanks! > > Thomas > > Ted Lemon writes: > >> We've been asked to do a last call on this draft; the authors >> believe that it's ready, and at least one reviewer believes so too. >> Please take this opportunity to review the draft if you have not >> already done so. If you find problems, please discuss them here on >> the mailing list. If you favor advancing the draft, please say so. >> If you do not want the draft to advance, please say so. If we hear >> nothing but dead silence, the draft will not advance. > >> I will be offline from 12/30/10 to 1/10/10, so I will make some >> determination as to the consensus on this draft when I get back >> online on the 10th. > >> Thanks! > >> _______________________________________________ >> 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 > > From vincent.zimmer@intel.com Thu Jan 6 10:47:10 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5ED3A6F57 for ; Thu, 6 Jan 2011 10:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDLuYzMOdfTL for ; Thu, 6 Jan 2011 10:47:09 -0800 (PST) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by core3.amsl.com (Postfix) with ESMTP id A24D53A6F60 for ; Thu, 6 Jan 2011 10:47:09 -0800 (PST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 06 Jan 2011 10:49:15 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.60,284,1291622400"; d="scan'208";a="371058124" Received: from orsmsx602.amr.corp.intel.com ([10.22.226.211]) by azsmga001.ch.intel.com with ESMTP; 06 Jan 2011 10:49:15 -0800 Received: from orsmsx507.amr.corp.intel.com ([10.22.226.41]) by orsmsx602.amr.corp.intel.com ([10.22.226.211]) with mapi; Thu, 6 Jan 2011 10:49:15 -0800 From: "Zimmer, Vincent" To: Tom Taylor , Thomas Narten Date: Thu, 6 Jan 2011 10:49:14 -0800 Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-duid-uuid-02.txt Thread-Index: Acut0WhUZPpgbkySQhe55w3m3wFT7AAACsXg Message-ID: <382A478CAD40FA4FB46605CF81FE39F4BFD63128@orsmsx507.amr.corp.intel.com> References: <36A80113-2DF3-4D81-8490-D0FD91DFD2F9@nominum.com> <201101061439.p06Edgwg022576@cichlid.raleigh.ibm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-duid-uuid-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:47:10 -0000 This will help in mapping IPV4 network boot bare-metal scenarios that forme= rly used option 97 of DHCP4 for machine identifier to IPV6. Given the gap that this addresses and completeness of document, I support a= dvancing this draft. -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= om Taylor Sent: Thursday, January 06, 2011 10:41 AM To: Thomas Narten Cc: dhcwg@ietf.org WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-duid-uuid-02.txt I support advancing this draft. On 06/01/2011 9:39 AM, Thomas Narten wrote: > Hi all. > > Now that the holiday break is over, some reviews of this document > would be appreciated. The WG won't advance it if there is only > silence... > > It's a short document. Only about 3 pages of substance. > > Thanks! > > Thomas > > Ted Lemon writes: > >> We've been asked to do a last call on this draft; the authors >> believe that it's ready, and at least one reviewer believes so too. >> Please take this opportunity to review the draft if you have not >> already done so. If you find problems, please discuss them here on >> the mailing list. If you favor advancing the draft, please say so. >> If you do not want the draft to advance, please say so. If we hear >> nothing but dead silence, the draft will not advance. > >> I will be offline from 12/30/10 to 1/10/10, so I will make some >> determination as to the consensus on this draft when I get back >> online on the 10th. > >> Thanks! > >> _______________________________________________ >> 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 > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From THUTH@de.ibm.com Fri Jan 7 02:28:08 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E87153A680F for ; Fri, 7 Jan 2011 02:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsnnn-z8SbJY for ; Fri, 7 Jan 2011 02:28:08 -0800 (PST) Received: from mtagate4.uk.ibm.com (mtagate4.uk.ibm.com [194.196.100.164]) by core3.amsl.com (Postfix) with ESMTP id C03EB3A6803 for ; Fri, 7 Jan 2011 02:28:07 -0800 (PST) Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate4.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p07AUBN5002679 for ; Fri, 7 Jan 2011 10:30:11 GMT Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [9.149.37.248]) by d06nrmr1307.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p07AUDd63346550 for ; Fri, 7 Jan 2011 10:30:13 GMT Received: from d06av07.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p07AUAdD004480 for ; Fri, 7 Jan 2011 03:30:10 -0700 Received: from d12ml072.megacenter.de.ibm.com (d12ml072.megacenter.de.ibm.com [9.149.166.115]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p07AUAqp004468; Fri, 7 Jan 2011 03:30:10 -0700 In-Reply-To: <20110106165547.GC29859@shell-too.nominum.com> References: <36A80113-2DF3-4D81-8490-D0FD91DFD2F9@nominum.com> <20110106165547.GC29859@shell-too.nominum.com> X-KeepSent: 2480F816:09D86402-C1257811:00390D68; type=4; name=$KeepSent To: Stephen Jacob , "dhcwg@ietf.org WG" X-Mailer: Lotus Notes Build V852_M2_03302010 March 30, 2010 Message-ID: From: Thomas Huth Date: Fri, 7 Jan 2011 11:26:42 +0100 X-MIMETrack: Serialize by Router on D12ML072/12/M/IBM(Release 8.0.2FP6|July 15, 2010) at 07/01/2011 11:30:12 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-duid-uuid-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 10:28:09 -0000 Stephen Jacob wrote on 06/01/2011 17:55:47:= > - I have a question in my mind as to whether the security > considerations section is even necessary given that there > is no new additional security issue. That same issue > applies to any DUID, not just DUID-UUID. Since all new RFCs must have a security consideration section nowadays,= I think it is ok to have this remark there. So I would opt for keeping this sentence. Mit freundlichen Gr=FC=DFen / Kind regards, =A0=A0 Thomas Huth = IBM Deutschland Vorsitzender des Aufsichtsrats: = Research & Development GmbH Martin=A0Jetter = Sch=F6naicher Str. 220 Gesch=E4ftsf=FChrung: Dirk Wittko= pp 71032 B=F6blingen Sitz der Gesellschaft: B=F6blinge= n Tel.: +49-7031-16-2183 Registergericht: Amtsgericht = Stuttgart, HRB 243294 = = = From THUTH@de.ibm.com Fri Jan 7 03:08:17 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 942DA3A681D for ; Fri, 7 Jan 2011 03:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDMgKDLL8piK for ; Fri, 7 Jan 2011 03:08:16 -0800 (PST) Received: from mtagate3.uk.ibm.com (mtagate3.uk.ibm.com [194.196.100.163]) by core3.amsl.com (Postfix) with ESMTP id 5D8F93A681A for ; Fri, 7 Jan 2011 03:08:16 -0800 (PST) Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate3.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p07BAKtv002909 for ; Fri, 7 Jan 2011 11:10:20 GMT Received: from d06av08.portsmouth.uk.ibm.com (d06av08.portsmouth.uk.ibm.com [9.149.37.249]) by d06nrmr1507.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p07BAFJM3367000 for ; Fri, 7 Jan 2011 11:10:22 GMT Received: from d06av08.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p07BADlk000461 for ; Fri, 7 Jan 2011 11:10:13 GMT Received: from d12ml072.megacenter.de.ibm.com (d12ml072.megacenter.de.ibm.com [9.149.166.115]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p07BAChj000456 for ; Fri, 7 Jan 2011 11:10:12 GMT In-Reply-To: <201101061439.p06Edgwg022576@cichlid.raleigh.ibm.com> References: <36A80113-2DF3-4D81-8490-D0FD91DFD2F9@nominum.com> <201101061439.p06Edgwg022576@cichlid.raleigh.ibm.com> X-KeepSent: 1681248B:E4996232-C1257811:00398E39; type=4; name=$KeepSent To: Thomas Narten , "dhcwg@ietf.org WG" X-Mailer: Lotus Notes Build V852_M2_03302010 March 30, 2010 Message-ID: From: Thomas Huth Date: Fri, 7 Jan 2011 12:09:43 +0100 X-MIMETrack: Serialize by Router on D12ML072/12/M/IBM(Release 8.0.2FP6|July 15, 2010) at 07/01/2011 12:10:14 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-duid-uuid-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 11:08:17 -0000 Thomas Narten wrote on 06/01/2011 15:39:42: > > Now that the holiday break is over, some reviews of this document > would be appreciated. The WG won't advance it if there is only > silence... I now read through the document, and it sounds good to me, so I support= advancing this draft. I just got some minor comments: 1) You're neither referencing RFC 2119 nor using the keywords from that= RFC. However, I also didn't see a lot of sentences in your document whe= re you need it really urgently, so you might get away without it. Anyway, please consider using it, e.g. in the following sentences: - "DHCP UUIDs should be persistant across system restarts ..." - "Implementations of this specification using DUID-UUID must select a = UUID that is persistent across system restart..." 2) You might want to add a sentence like this in the beginning of your document, to make clear where the definitions come from: Terminology specific to IPv6 and DHCPv6 are used in the same way as is defined in the "Terminology" sections of [RFC3315]. 3) In the "Background" section, you explain the previous DUIDs again: "Three DUIDs types have been defined previously: DUID-LLT - the Link-Layer address of one of the device's network interfaces, concatenated with a timestamp DUID-EN - an Enterprise Number plus additional information specific= to the enterprise DUID-LL - the Link-Layer address of one of the device's network interfaces" In my opinion, this is too much detail here, you can simply refer to RFC3315 instead, e.g. Three DUIDs have been defined previously: DUID-LLT, DUID-EN and DUID-LL= (see RFC3315 for details). 4) In some sentences, you're using a lot of "would"s ... that sounds somewhat uncertain to me, and that seems unappropriate for an RFC to me= . For example: In some environments, a UUID-based DUID would be preferable to the othe= r existing DUID types. Please consider whether you could use a more direct language in those sentences, e.g.: In some environments, a UUID-based DUID is preferable to the other exis= ting DUID types. 5) In chapter 4, you've labeled the figure with "DUID-UUID format. ." -= I think you can remove the second (or even both?) dots here. I also doubt= that you need the "Figure 1" label here, since you never reference this= in the rest of the text. Mit freundlichen Gr=FC=DFen / Kind regards, =A0=A0 Thomas Huth = IBM Deutschland Vorsitzender des Aufsichtsrats: = Research & Development GmbH Martin=A0Jetter = Sch=F6naicher Str. 220 Gesch=E4ftsf=FChrung: Dirk Wittko= pp 71032 B=F6blingen Sitz der Gesellschaft: B=F6blinge= n Tel.: +49-7031-16-2183 Registergericht: Amtsgericht = Stuttgart, HRB 243294 = = = From narten@us.ibm.com Fri Jan 7 05:57:09 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B154E3A68CC for ; Fri, 7 Jan 2011 05:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.071 X-Spam-Level: X-Spam-Status: No, score=-104.071 tagged_above=-999 required=5 tests=[AWL=2.528, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aw7UOfHF+bvG for ; Fri, 7 Jan 2011 05:57:08 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by core3.amsl.com (Postfix) with ESMTP id 97BE43A68C6 for ; Fri, 7 Jan 2011 05:57:08 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e35.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p07DjpTV032396 for ; Fri, 7 Jan 2011 06:45:51 -0700 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p07Dx3pg238902 for ; Fri, 7 Jan 2011 06:59:03 -0700 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p07E3RpC009460 for ; Fri, 7 Jan 2011 07:03:27 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-76-155-133.mts.ibm.com [9.76.155.133]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p07E3Qpj009420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jan 2011 07:03:27 -0700 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p07DwwXv011529; Fri, 7 Jan 2011 08:58:58 -0500 Message-Id: <201101071358.p07DwwXv011529@cichlid.raleigh.ibm.com> To: Thomas Huth In-reply-to: References: <36A80113-2DF3-4D81-8490-D0FD91DFD2F9@nominum.com> <201101061439.p06Edgwg022576@cichlid.raleigh.ibm.com> Comments: In-reply-to Thomas Huth message dated "Fri, 07 Jan 2011 12:09:43 +0100." Date: Fri, 07 Jan 2011 08:58:58 -0500 From: Thomas Narten Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-duid-uuid-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 13:57:09 -0000 Hi Thomas. Thomas Huth writes: > 1) You're neither referencing RFC 2119 nor using the keywords from that > RFC. However, I also didn't see a lot of sentences in your document where > you need it really urgently, so you might get away without it. Anyway, > please consider using it, e.g. in the following sentences: > - "DHCP UUIDs should be persistant across system restarts ..." > - "Implementations of this specification using DUID-UUID must select a UUID > that is persistent across system restart..." Personally, I prefer not using 2119 language unless there is a compelling need. I.e., to make very clear that not doing something is a violation of the spec. I don't see a strong need in this document. But if others think this is necessary, I'll make the change. > 2) You might want to add a sentence like this in the beginning of your > document, to make clear where the definitions come from: > Terminology specific to IPv6 and DHCPv6 are used in the same way as is > defined in the "Terminology" sections of [RFC3315]. Will do. > 3) In the "Background" section, you explain the previous DUIDs again: > "Three DUIDs types have been defined previously: > DUID-LLT - the Link-Layer address of one of the device's network > interfaces, concatenated with a timestamp > DUID-EN - an Enterprise Number plus additional information specific > to the enterprise > DUID-LL - the Link-Layer address of one of the device's network > interfaces" > In my opinion, this is too much detail here, you can simply refer to > RFC3315 instead, e.g. > Three DUIDs have been defined previously: DUID-LLT, DUID-EN and DUID-LL > (see RFC3315 for details). I could, but then the reader would need to go look at 3315 to understand what info they contain. And since I talk about the how the existing definitions are inadequate, I think it's better to include the detail. > 4) In some sentences, you're using a lot of "would"s ... that sounds > somewhat uncertain to me, and that seems unappropriate for an RFC to me. > For example: > In some environments, a UUID-based DUID would be preferable to the other > existing DUID types. > Please consider whether you could use a more direct language in those > sentences, e.g.: > In some environments, a UUID-based DUID is preferable to the other existing > DUID types. I will do this. > 5) In chapter 4, you've labeled the figure with "DUID-UUID format. ." - I > think you can remove the second (or even both?) dots here. I also doubt > that you need the "Figure 1" label here, since you never reference this in > the rest of the text. Removed the extra ".". The "figure 1" is generated automatically by xml2rfc and may (I'm not sure) be required as part of the general RFC format. Thanks for the review! Thomas > Mit freundlichen Grüßen / Kind regards, >    Thomas Huth > > IBM Deutschland Vorsitzender des Aufsichtsrats: > Research & Development GmbH Martin Jetter > Schönaicher Str. 220 Geschäftsführung: Dirk Wittkopp > 71032 Böblingen Sitz der Gesellschaft: Böblingen > Tel.: +49-7031-16-2183 Registergericht: Amtsgericht > Stuttgart, HRB 243294 > From Stephen.Jacob@nominum.com Fri Jan 7 10:45:42 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D28333A693D for ; Fri, 7 Jan 2011 10:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAG91EqwqVSg for ; Fri, 7 Jan 2011 10:45:42 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id E16B23A6935 for ; Fri, 7 Jan 2011 10:45:41 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTSdf0h+PRpIikUiEoy1x66OsUov8vjZ2@postini.com; Fri, 07 Jan 2011 10:47:49 PST Received: by shell-too.nominum.com (Postfix, from userid 11053) id 6CC0E1B8300; Fri, 7 Jan 2011 10:47:46 -0800 (PST) Date: Fri, 7 Jan 2011 10:47:46 -0800 From: Stephen Jacob To: Thomas Huth Message-ID: <20110107184746.GA32243@shell-too.nominum.com> Mail-Followup-To: Thomas Huth , "dhcwg@ietf.org WG" References: <36A80113-2DF3-4D81-8490-D0FD91DFD2F9@nominum.com> <20110106165547.GC29859@shell-too.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-URI: http://www.nominum.com/ Organization: Nominum, Inc. Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-duid-uuid-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 18:45:42 -0000 On Fri, Jan 07, 2011 at 11:26:42AM +0100, Thomas Huth wrote: > Stephen Jacob wrote on 06/01/2011 17:55:47: > > > - I have a question in my mind as to whether the security > > considerations section is even necessary given that there > > is no new additional security issue. That same issue > > applies to any DUID, not just DUID-UUID. > > Since all new RFCs must have a security consideration section nowadays, > I think it is ok to have this remark there. So I would opt for keeping > this sentence. Oh, well, that is certainly a good reason. :) Would it be appropriate to add a sentence on to the end saying "This security concern is not new with DUID-UUID but is a concern with all DUID types." or something? Regards, Stephen -- Stephen Jacob | Stephen.Jacob@nominum.com | +1 650 381 6051 Nominum, Inc. | http://www.nominum.com/ | +1 650 381 6000 From ravikumar.lrk@gmail.com Sun Jan 9 05:25:36 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4AF3A6961 for ; Sun, 9 Jan 2011 05:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xt7Z3u21jSSO for ; Sun, 9 Jan 2011 05:25:35 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 7AF513A6952 for ; Sun, 9 Jan 2011 05:25:35 -0800 (PST) Received: by vws7 with SMTP id 7so7627301vws.31 for ; Sun, 09 Jan 2011 05:27:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=R4m8mO8Sn89hW9GY8Z6KJz+iyGwTtp+bl8D2blDm45U=; b=Phmp17hffZpbhWXHZncZK8e8gi/RbdK+xPZ108IoZtpWb92a0ELYjbCRmOdi1OfMyy vgAktmM60RfaQi97DZRhXZiaPuVlaYcRJBIbdkZ/GXOBSNQBHa06uZRFJCvteIlJaes9 xWoLYlYZomc6ZKegemWw1nBEpPpUtj4Su7hxQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=C5K88lrYZnnE+83chWmxTpFz0t5Kf317lwI4Sux8SvOHBFCrElafCp7o+5nNO5/6xH 9aVHU1YSpa3a/kfa0yYEljF8eRaNJz8wY0EBWPkk5lspyAZf+IW2n2f4xQWFkgsFm013 2xxY2OGc7MhqY1RyHXtYfQIyF3DfEYb5/oY/U= MIME-Version: 1.0 Received: by 10.220.176.76 with SMTP id bd12mr7272531vcb.23.1294579665957; Sun, 09 Jan 2011 05:27:45 -0800 (PST) Received: by 10.220.165.1 with HTTP; Sun, 9 Jan 2011 05:27:45 -0800 (PST) In-Reply-To: References: Date: Sun, 9 Jan 2011 18:57:45 +0530 Message-ID: From: ravi kumar To: DHC WG Content-Type: multipart/alternative; boundary=90e6ba4fc1f21f72b1049969d182 Subject: [dhcwg] Fwd: Dhcp client behavior in regard to Domain searchlist X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 13:25:36 -0000 --90e6ba4fc1f21f72b1049969d182 Content-Type: text/plain; charset=ISO-8859-1 Incase if there are two domain lists received from Dhcpv4 and Dhcpv6 servers respectively, what should be the final list of domain suffixes to be used for resolution.What should the precedence in choosing the list (V4 first and V6 second etc ), incase if combined list is used for resolution. regards Ravi ---------- Forwarded message ---------- From: ravi kumar Date: Fri, Jan 7, 2011 at 4:07 PM Subject: Dhcp client behavior in regard to Domain searchlist To: dhcp-users@isc.org, dhcp-users@lists.isc.org Incase if Domain searchlist is received via Dhcpv4 and Dhcpv6 servers, through options 119 and 24, I would like to know the behavior of Linux client. Are both search lists passed to DNS for DNS resolution ? Is there any precedence in choosing the order of lists : V4 first and V6 second etc ? regards Ravi --90e6ba4fc1f21f72b1049969d182 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Incase if there are two domain lists received from Dhcpv4 and Dhcpv6 s= ervers respectively, what should be the final list of domain suffixes to be= used for resolution.What should the precedence in choosing the list (V4 fi= rst and V6 second etc ), incase if combined list is used for resolution.
=A0
regards
Ravi
---------- Forwarded message ----------
From:= ravi kumar <ravikumar.lrk@gmail.com><= br> Date: Fri, Jan 7, 2011 at 4:07 PM
Subject: Dhcp client behavior in regar= d to Domain searchlist
To: dhcp-us= ers@isc.org, dhcp-users@lis= ts.isc.org


Incase if Domain searchlist is received via Dhcpv4 and Dhcpv6 servers,= through options 119 and 24,=A0I would like to know the behavior=A0of=A0Lin= ux client. Are both search lists passed to DNS for DNS resolution ? Is ther= e any precedence in choosing the order of lists : V4 first and V6 second et= c ?
=A0
regards
Ravi

--90e6ba4fc1f21f72b1049969d182-- From volz@cisco.com Mon Jan 10 14:03:34 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A5F63A687B for ; Mon, 10 Jan 2011 14:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.789 X-Spam-Level: X-Spam-Status: No, score=-9.789 tagged_above=-999 required=5 tests=[AWL=0.809, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bv2NGFhZw4Gn for ; Mon, 10 Jan 2011 14:03:33 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 2A1013A687F for ; Mon, 10 Jan 2011 14:03:33 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0GAB8RK02rR7Hu/2dsb2JhbACCOpoEAYgMc6JtmFyFTASEZ4UvhBqCcA Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 10 Jan 2011 22:05:48 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0AM5l61008937; Mon, 10 Jan 2011 22:05:47 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Jan 2011 16:05:47 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBB112.88CC8F87" Date: Mon, 10 Jan 2011 16:05:44 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Fwd: Dhcp client behavior in regard to Domain searchlist Thread-Index: AcuwAQRBiqRgjIjQSW6RFSvE6cQNmgBEUrdw References: From: "Bernie Volz (volz)" To: "ravi kumar" , "DHC WG" X-OriginalArrivalTime: 10 Jan 2011 22:05:47.0544 (UTC) FILETIME=[88F47180:01CBB112] Subject: Re: [dhcwg] Fwd: Dhcp client behavior in regard to Domain searchlist X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 22:03:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB112.88CC8F87 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You might want to look at http://tools.ietf.org/id/draft-ietf-dhc-dual-stack-merge-01.txt. =20 I think this work died? =20 - Bernie =20 From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of ravi kumar Sent: Sunday, January 09, 2011 8:28 AM To: DHC WG Subject: [dhcwg] Fwd: Dhcp client behavior in regard to Domain searchlist =20 Incase if there are two domain lists received from Dhcpv4 and Dhcpv6 servers respectively, what should be the final list of domain suffixes to be used for resolution.What should the precedence in choosing the list (V4 first and V6 second etc ), incase if combined list is used for resolution. =20 regards Ravi ---------- Forwarded message ---------- From: ravi kumar Date: Fri, Jan 7, 2011 at 4:07 PM Subject: Dhcp client behavior in regard to Domain searchlist To: dhcp-users@isc.org, dhcp-users@lists.isc.org Incase if Domain searchlist is received via Dhcpv4 and Dhcpv6 servers, through options 119 and 24, I would like to know the behavior of Linux client. Are both search lists passed to DNS for DNS resolution ? Is there any precedence in choosing the order of lists : V4 first and V6 second etc ? =20 regards Ravi =20 ------_=_NextPart_001_01CBB112.88CC8F87 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You might want to look at = http://tools.ietf.org/id/draft-ietf-dhc-dual-stack-merge-01.txt.

 

I think this work died?

 

-          = Bernie

 

From:= = dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of = ravi kumar
Sent: Sunday, January 09, 2011 8:28 = AM
To: DHC WG
Subject: [dhcwg] Fwd: Dhcp client = behavior in regard to Domain searchlist

 

Incase = if there are two domain lists received from Dhcpv4 and Dhcpv6 servers = respectively, what should be the final list of domain suffixes to be = used for resolution.What should the precedence in choosing the list (V4 = first and V6 second etc ), incase if combined list is used for = resolution.

 

regards

Ravi

---------- Forwarded message = ----------
From: ravi kumar <ravikumar.lrk@gmail.com>Date: Fri, Jan 7, 2011 at 4:07 PM
Subject: Dhcp client behavior in = regard to Domain searchlist
To: dhcp-users@isc.org, dhcp-users@lists.isc.org
=

Incase if Domain searchlist = is received via Dhcpv4 and Dhcpv6 servers, through options 119 and = 24, I would like to know the behavior of Linux client. = Are both search lists passed to DNS for DNS resolution ? Is there any = precedence in choosing the order of lists : V4 first and V6 second etc = ?

 

regards

Ravi

 

------_=_NextPart_001_01CBB112.88CC8F87-- From mellon@fugue.com Mon Jan 10 15:01:21 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A72D43A6767 for ; Mon, 10 Jan 2011 15:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5dNmrcodJj6 for ; Mon, 10 Jan 2011 15:01:21 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by core3.amsl.com (Postfix) with ESMTP id 14CCE3A6403 for ; Mon, 10 Jan 2011 15:01:21 -0800 (PST) Received: from [10.0.1.7] (unknown [64.215.212.233]) by toccata.fugue.com (Postfix) with ESMTPSA id 82E5A34E422E; Mon, 10 Jan 2011 18:03:59 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ted Lemon In-Reply-To: <20110107184746.GA32243@shell-too.nominum.com> Date: Mon, 10 Jan 2011 18:03:33 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <36A80113-2DF3-4D81-8490-D0FD91DFD2F9@nominum.com> <20110106165547.GC29859@shell-too.nominum.com> <20110107184746.GA32243@shell-too.nominum.com> To: Stephen Jacob X-Mailer: Apple Mail (2.1082) Cc: "dhcwg@ietf.org WG" , Thomas Huth Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-duid-uuid-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 23:01:21 -0000 On Jan 7, 2011, at 1:47 PM, Stephen Jacob wrote: > Would it be appropriate to add a sentence on to the end saying "This > security concern is not new with DUID-UUID but is a concern with > all DUID types." or something? Yes. From Ted.Lemon@nominum.com Mon Jan 10 15:03:45 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 705B23A657C for ; Mon, 10 Jan 2011 15:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.955 X-Spam-Level: X-Spam-Status: No, score=-104.955 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qFwKimkxYiX for ; Mon, 10 Jan 2011 15:03:44 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 91D583A6403 for ; Mon, 10 Jan 2011 15:03:44 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTSuQ14UaxLHhPwqLxAT+bNxCOjb0EtyX@postini.com; Mon, 10 Jan 2011 15:05:59 PST 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 36C4F1B82AA for ; Mon, 10 Jan 2011 15:05:59 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 27FEA190054; Mon, 10 Jan 2011 15:05:59 -0800 (PST) Received: from [10.0.1.7] (64.215.212.233) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 10 Jan 2011 15:05:58 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary="Apple-Mail-3-713461477" From: Ted Lemon In-Reply-To: Date: Mon, 10 Jan 2011 18:05:57 -0500 Message-ID: <38CA53B9-A584-49B0-B764-2E83CAF9289F@nominum.com> References: To: Bernie Volz X-Mailer: Apple Mail (2.1082) Cc: DHC WG Subject: Re: [dhcwg] Fwd: Dhcp client behavior in regard to Domain searchlist X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 23:03:45 -0000 --Apple-Mail-3-713461477 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" On Jan 10, 2011, at 5:05 PM, Bernie Volz (volz) wrote: > I think this work died? Arguably this is work for the mif working group. --Apple-Mail-3-713461477 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
I think this work = died?

Arguably this is = work for the mif working group.

= --Apple-Mail-3-713461477-- From ravikumar.lrk@gmail.com Mon Jan 10 17:33:43 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14E253A68D1 for ; Mon, 10 Jan 2011 17:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeCn-XoVynSa for ; Mon, 10 Jan 2011 17:33:42 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id DCA5C3A6896 for ; Mon, 10 Jan 2011 17:33:41 -0800 (PST) Received: by qyk34 with SMTP id 34so2166205qyk.10 for ; Mon, 10 Jan 2011 17:35:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R+uFw4aq5RgiT16G79VtBcICdSGTkYsJmqurkRXu0Ao=; b=u16End0ySbcjrzeL0yF8zw//X3COievGQ3Ux0cIx46reBUp/EvEKfN/6gZUOqRaIDZ qBfC9XI1ESNN41YTyYFtladKOx05i/oaZOxU0ckFpMSNxmulq0FIF5WmDUdZSW55MObg 7fipONyhBg9manCdzAnWmoL9vauc+L/NGJ1YA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Gk17TXLx3ZLFfjUEBz4YVLJEcLt1L3g2gZ5rSdF7eEOwe3A+v9AP6B9+KTPS3FIagW /lb/onl0N9XL2MUOY4tKRAKgP8V0pfZoKmvtEg/eWWDR5q11c9r/SKqbOh9mAiJlQhIZ oiftONhDBpJbSomYML/pKMqyDp8/CQEIWQUPA= MIME-Version: 1.0 Received: by 10.224.11.79 with SMTP id s15mr8256083qas.100.1294709755893; Mon, 10 Jan 2011 17:35:55 -0800 (PST) Received: by 10.220.165.1 with HTTP; Mon, 10 Jan 2011 17:35:55 -0800 (PST) In-Reply-To: <38CA53B9-A584-49B0-B764-2E83CAF9289F@nominum.com> References: <38CA53B9-A584-49B0-B764-2E83CAF9289F@nominum.com> Date: Tue, 11 Jan 2011 07:05:55 +0530 Message-ID: From: ravi kumar To: Ted Lemon Content-Type: multipart/alternative; boundary=0015175cba181657080499881b49 Cc: DHC WG , Bernie Volz Subject: Re: [dhcwg] Fwd: Dhcp client behavior in regard to Domain searchlist X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 01:33:43 -0000 --0015175cba181657080499881b49 Content-Type: text/plain; charset=ISO-8859-1 Thanks for your responses. What is the approach followed by Dhcp client implemenations that support both option 119 (Dhcpv4) and option 24 (Dhcpv6), as the behavior is not documented in any RFC. regards Ravi On Tue, Jan 11, 2011 at 4:35 AM, Ted Lemon wrote: > On Jan 10, 2011, at 5:05 PM, Bernie Volz (volz) wrote: > > I think this work died? > > > Arguably this is work for the mif working group. > > --0015175cba181657080499881b49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for your responses.
What is the approach followed by Dhcp client implemenations that suppo= rt both option 119 (Dhcpv4) and option 24 (Dhcpv6), as the behavior is not = documented in any RFC.
=A0
regards
Ravi
On Tue, Jan 11, 2011 at 4:35 AM, Ted Lemon <Ted.Lemon@nominum= .com> wrote:
On Jan 10, 2011, at 5:05 PM, Bernie Volz (volz) wrote:
I think this work died?

Arguably this is work for the mif working group.


--0015175cba181657080499881b49-- From tjc@ecs.soton.ac.uk Tue Jan 11 04:01:54 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0BC328C0F0 for ; Tue, 11 Jan 2011 04:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsPrbqcHXpKd for ; Tue, 11 Jan 2011 04:01:53 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by core3.amsl.com (Postfix) with ESMTP id 84CC328C157 for ; Tue, 11 Jan 2011 04:01:52 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p0BC450T029070 for ; Tue, 11 Jan 2011 12:04:05 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p0BC450T029070 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1294747445; bh=kV2N0IGnB5tYGOybeYrD8EeJYbs=; h=From:Mime-Version:Subject:Date:In-Reply-To:To:References; b=zCKOVDR9QLCtduKERNsrNzGLBe1FsXpQTwPVgE7/jV1sXBkf+oIVy3IkKoR1udJ6p RvSy1HUeX43AT9/03bMNfG+83WOPGsXC143NClHdscgniKvtNEOMpxt/vwB+y1Zgzj TLAutnT7ocA9ecyW98XcdToA0DsYqnlVj5+iSUnM= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n0AC452308224755yD ret-id none; Tue, 11 Jan 2011 12:04:05 +0000 Received: from dhcp-152-78-94-255.ecs.soton.ac.uk (dhcp-152-78-94-255.ecs.soton.ac.uk [152.78.94.255]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p0BC42uQ009279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 11 Jan 2011 12:04:02 GMT From: Tim Chown Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-1-760145664 Date: Tue, 11 Jan 2011 12:04:01 +0000 In-Reply-To: <38CA53B9-A584-49B0-B764-2E83CAF9289F@nominum.com> To: DHC WG References: <38CA53B9-A584-49B0-B764-2E83CAF9289F@nominum.com> Message-ID: X-Mailer: Apple Mail (2.1082) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n0AC45230822475500; tid=n0AC452308224755yD; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p0BC450T029070 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [dhcwg] Fwd: Dhcp client behavior in regard to Domain searchlist X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 12:01:54 -0000 --Apple-Mail-1-760145664 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 10 Jan 2011, at 23:05, Ted Lemon wrote: > On Jan 10, 2011, at 5:05 PM, Bernie Volz (volz) wrote: >> I think this work died? >=20 > Arguably this is work for the mif working group. The original problem space is discussed in RFC4477. A few issues = were discussed in that draft, and the conclusion of the wg was to = operate separate DHCPv4 and DHCPv6 services until a site becomes fully = IPv6-only. The implication of that conclusion was that a method to = merge responses from separate servers was required, which was what led = to the now expired draft-ietf-dhc-dual-stack-merge-01 draft being = written by Stig and me. If the servers are under the same = administrative control, the responses should be consistent. The more = interesting case is where they are not, which is where Ted's suggestion = to look at the mif work is appropriate. Having said that even back in = 2006 when RFC4477 was finalised we said in there 'look at the emerging = IETF multiple interface work', but because it's a difficult problem = there still really isn't an IETF-published solution. And of course we = also noted in 2006 that production use of DHCPv6 was still in its = infancy, which means we didn't have a lot of operational experience to = draw on. That's probably still true to say today, sadly. If there's interest in reviving the work with the hindsight of 4 extra = years of experience we can consider that, otherwise check out the mif WG = progress. Tim= --Apple-Mail-1-760145664 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jan 10, 2011, at = 5:05 PM, Bernie Volz (volz) wrote:
I think this work = died?

Arguably this is = work for the mif working = group.

The original problem space = is discussed in RFC4477.     A few issues were discussed in = that draft, and the conclusion of the wg was to operate separate DHCPv4 = and DHCPv6 services until a site becomes fully IPv6-only.   The = implication of that conclusion was that a method to merge responses from = separate servers was required, which was what led to the = now expired draft-ietf-dhc-dual-stack-merge-01 draft being = written by Stig and me.  If the servers are under the same = administrative control, the responses should be consistent.   The = more interesting case is where they are not, which is where Ted's = suggestion to look at the mif work is appropriate.    Having = said that even back in 2006 when RFC4477 was finalised we said in there = 'look at the emerging IETF multiple interface work', but because it's a = difficult problem there still really isn't an IETF-published solution. =   And of course we also noted in 2006 that production use of DHCPv6 = was still in its infancy, which means we didn't have a lot of = operational experience to draw on.  That's probably still true to = say today, sadly.

If there's interest in = reviving the work with the hindsight of 4 extra years of experience we = can consider that, otherwise check out the mif WG = progress.

Tim
= --Apple-Mail-1-760145664-- From Internet-Drafts@ietf.org Tue Jan 11 14:30:03 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 140FB3A6AAB; Tue, 11 Jan 2011 14:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueEm31jdso0Y; Tue, 11 Jan 2011 14:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50D883A67C1; Tue, 11 Jan 2011 14:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110111223002.32522.69790.idtracker@localhost> Date: Tue, 11 Jan 2011 14:30:02 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action:draft-ietf-dhc-pd-exclude-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 22:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Prefix Exclude Option for DHCPv6-based Prefix Delegation Author(s) : J. Korhonen, et al. Filename : draft-ietf-dhc-pd-exclude-01.txt Pages : 9 Date : 2011-01-11 This specification defines an optional mechanism to allow exclusion of one specific prefix from a delegated prefix set when using DHCPv6- based prefix delegation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-pd-exclude-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dhc-pd-exclude-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-11141636.I-D@ietf.org> --NextPart-- From MSmith@internode.com.au Wed Jan 12 18:06:57 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1A83A6806 for ; Wed, 12 Jan 2011 18:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cq0P5xRMnju0 for ; Wed, 12 Jan 2011 18:06:56 -0800 (PST) Received: from imail.internode.com.au (exchht01-ext.internode.com.au [203.26.95.185]) by core3.amsl.com (Postfix) with ESMTP id 540B43A67B1 for ; Wed, 12 Jan 2011 18:06:55 -0800 (PST) Received: from [192.168.99.15] (192.168.99.15) by exchht01.staff.internode.com.au (172.17.2.4) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 13 Jan 2011 12:39:14 +1030 Message-ID: <4D2E5ECA.8010300@internode.com.au> Date: Thu, 13 Jan 2011 12:39:14 +1030 From: Mark Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: [dhcwg] LAN side Information Refresh Option time values derived from WAN side DHCPv6-PD timers? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 02:06:57 -0000 Hi, I'm doing some work with a residential CPE vendor on their IPv6 implementation. I've asked them to implement Information Refresh time option support on the stateless DHCPv6 server that is available on the LAN interfaces. I've realised that the time value that this option provides needs to be derived from the DHCPv6-PD timers used on the WAN interface, so that an ISP change of supplied parameters can be propagated to the LAN attached devices in a timely manner. I've reviewed parts of the DHCPv6-PD and Information Refresh Option RFCs, and the 09 revision of the CPE draft, and haven't found anything conclusive. Has there been any related discussion or are there any other references as to how to derive the Information Refresh time from DHCPv6-PD timers? My current thoughts would be to set the Information Refresh time value to either the remaining DHCPv6-PD REBIND time when the stateless DHCPv6 request is made or the initial DHCPv6-PD REBIND time. Would that be reasonable? Thanks, Mark. From mellon@fugue.com Thu Jan 13 10:19:30 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2A293A683D for ; Thu, 13 Jan 2011 10:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CD+BjKptKDLh for ; Thu, 13 Jan 2011 10:19:30 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by core3.amsl.com (Postfix) with ESMTP id 314663A67B8 for ; Thu, 13 Jan 2011 10:19:30 -0800 (PST) Received: from [10.0.1.7] (unknown [64.215.212.233]) by toccata.fugue.com (Postfix) with ESMTPSA id 8D4D334E4454; Thu, 13 Jan 2011 13:22:17 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ted Lemon In-Reply-To: <4D2E5ECA.8010300@internode.com.au> Date: Thu, 13 Jan 2011 13:21:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D2E5ECA.8010300@internode.com.au> To: Mark Smith X-Mailer: Apple Mail (2.1082) Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] LAN side Information Refresh Option time values derived from WAN side DHCPv6-PD timers? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 18:19:31 -0000 I don't see any particular point in syncing up the refresh times. On a = small LAN, just set the timer to some low value, like five minutes, or = something like that. It's not going to cause enough traffic to be an = issue. I suppose the ISP might have a renewal time shorter than that, = but it seems like that would be a poor choice from a reliability = standpoint. If you try to sync to PD refresh timers, you run the risk of not = propagating state when there's a network transient--the cable modem = going offline and coming back on, for instance, and getting different = information in its PD request. From MSmith@internode.com.au Thu Jan 13 16:50:47 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6834D3A683B for ; Thu, 13 Jan 2011 16:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rh7Gt4leCWIt for ; Thu, 13 Jan 2011 16:50:46 -0800 (PST) Received: from imail.internode.com.au (exchht01-ext.internode.com.au [203.26.95.185]) by core3.amsl.com (Postfix) with ESMTP id DC47D3A679F for ; Thu, 13 Jan 2011 16:50:45 -0800 (PST) Received: from [192.168.99.15] (192.168.99.15) by exchht01.staff.internode.com.au (172.17.2.4) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 14 Jan 2011 11:23:08 +1030 Message-ID: <4D2F9E74.8030604@internode.com.au> Date: Fri, 14 Jan 2011 11:23:08 +1030 From: Mark Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ted Lemon References: <4D2E5ECA.8010300@internode.com.au> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] LAN side Information Refresh Option time values derived from WAN side DHCPv6-PD timers? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 00:50:47 -0000 Hi Ted, Thanks very much for getting back to me. On 14/01/2011 4:51 AM, Ted Lemon wrote: > I don't see any particular point in syncing up the refresh times. On a small LAN, just set the timer to some low value, like five minutes, or something like that. It's not going to cause enough traffic to be an issue. I suppose the ISP might have a renewal time shorter than that, but it seems like that would be a poor choice from a reliability standpoint. > The reason I was thinking about the refresh timers being synchronised or derived from the DHCPv6-PD timers is so that an ISP has a known and generally bounded period of transition between old and new services whose parameters are conveyed with these options. For example, if the information request refresh time was a similar time period to the delegated prefix preferred time, which I think would translate into an equivalent DHCPv6-PD REBIND time, then when an ISP transitions it's customers from, for example, old DNS servers to new ones, the maximum time period both the old and new DNS servers would have to be available during the transition would be approximately 2 times the delegated prefix preferred time. Having an known and predictable upper bound for how long legacy services will be used would much better than today's situation with IPv4, where legacy services have to be available for potentially years, and there is still have a likelyhood that a customer's services will be disrupted when those legacy services are eventually decommissioned. > If you try to sync to PD refresh timers, you run the risk of not propagating state when there's a network transient--the cable modem going offline and coming back on, for instance, and getting different information in its PD request. > I think that might be a limitation of stateless DHCPv6 itself unfortunately. Without some sort of flash update or expire message that the CPE can send to the LAN devices upon change of parameters acquired via DHCPv6-PD, as the absolute minimum time for the information refresh looks to be 10 minutes, there would be fairly significant periods where end-nodes are trying to use invalid parameters. Thanks, Mark. From mellon@fugue.com Thu Jan 13 19:07:29 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35C0C3A6C42 for ; Thu, 13 Jan 2011 19:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.266 X-Spam-Level: X-Spam-Status: No, score=-4.266 tagged_above=-999 required=5 tests=[AWL=-1.667, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbiIaVGrV-cG for ; Thu, 13 Jan 2011 19:07:28 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by core3.amsl.com (Postfix) with ESMTP id 63C9A3A6C34 for ; Thu, 13 Jan 2011 19:07:28 -0800 (PST) Received: from [IPv6:2001:55c:ada2:d6d9:226:bbff:fe0c:e5bf] (unknown [IPv6:2001:55c:ada2:d6d9:226:bbff:fe0c:e5bf]) by toccata.fugue.com (Postfix) with ESMTPSA id 4B31C34E4460; Thu, 13 Jan 2011 22:10:14 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ted Lemon In-Reply-To: <4D2F9E74.8030604@internode.com.au> Date: Thu, 13 Jan 2011 22:09:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <53E8A4B6-23A4-4E4B-A3FE-E4FC965B901B@fugue.com> References: <4D2E5ECA.8010300@internode.com.au> <4D2F9E74.8030604@internode.com.au> To: Mark Smith X-Mailer: Apple Mail (2.1082) Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] LAN side Information Refresh Option time values derived from WAN side DHCPv6-PD timers? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 03:07:29 -0000 On Jan 13, 2011, at 7:53 PM, Mark Smith wrote: > For example, if the information request refresh time was a similar = time period to the delegated prefix preferred time, which I think would = translate into an equivalent DHCPv6-PD REBIND time, then when an ISP = transitions it's customers from, for example, old DNS servers to new = ones, the maximum time period both the old and new DNS servers would = have to be available during the transition would be approximately 2 = times the delegated prefix preferred time. This is a solution to a problem that doesn't exist. ISPs don't need to = switch customers from name server A to name server B on a time schedule = that tight. Or, if they do, we need to be talking in detail about the = scenario where you think this is necessary; talking about IRT times is = putting the cart before the horse. > Having an known and predictable upper bound for how long legacy = services will be used would much better than today's situation with = IPv4, where legacy services have to be available for potentially years, = and there is still have a likelyhood that a customer's services will be = disrupted when those legacy services are eventually decommissioned. This is why the ISPs should have been using DHCP with leases. With = leases, you *know* the information will be invalidated when the lease = expires; if it's not, the client is out of spec. If you need a = protocol that doesn't cause customer failures when the customer is = running software that's out of spec, that's a really large solution = space, and I don't think we can help you. > I think that might be a limitation of stateless DHCPv6 itself = unfortunately. Without some sort of flash update or expire message that = the CPE can send to the LAN devices upon change of parameters acquired = via DHCPv6-PD, as the absolute minimum time for the information refresh = looks to be 10 minutes, there would be fairly significant periods where = end-nodes are trying to use invalid parameters. Prefix delegation isn't meant to force rapid renumbering or any sort of = rapid reconfiguration on clients. If you use it that way, yes, you = will definitely experience problems. That's not a problem with the = protocol=1F. Or, I should say, if you think it's a problem with the = protocol, you're going to need to change a lot more than the DHCP = protocol to get something reliable that can be renumbered that quickly. The idea with renumbering in IPv6 is to deprecate the old prefix, but = continue to allow its use for some period after it's deprecated. = Meanwhile you give the PD client a new prefix. The PD client = immediately starts advertising the new prefix, and deprecates the old = prefix. At this point I would actually expect a DHCP client to = reconfigure, because it's got a new prefix. But even if it doesn't, as long as it reconfigures before the deprecated = prefix expires, life should be okay. If this is happening more rapidly = than every five minutes, something very weird is going on. I guess my point is that what you're asking for, and the problems you're = anticipating, seem out of line with the solution you're proposing, and = with the deployment scenario I understood you to be describing. So it = would be good if you could talk some more about that, so that we can get = a better understanding of why you think you have a problem. From dhankins@google.com Fri Jan 14 14:44:45 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 153EC3A6BEB for ; Fri, 14 Jan 2011 14:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.346 X-Spam-Level: X-Spam-Status: No, score=-104.346 tagged_above=-999 required=5 tests=[AWL=-1.370, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIMF3rkNzDfL for ; Fri, 14 Jan 2011 14:44:44 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id D437A3A6BCC for ; Fri, 14 Jan 2011 14:44:43 -0800 (PST) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p0EMl9U7025795 for ; Fri, 14 Jan 2011 14:47:09 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295045230; bh=JLV7bChIjapfKpejbgKOy6DTfEM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type; b=X9uqOa7/bBqsrB4anwj8PeZBaMHsiMuTJdkmIa9kKQCHfIBPlf2yHuy5Pi3IvppXc Tq/RAubhgGpOPFw1TzIQg== Received: from gyf2 (gyf2.prod.google.com [10.243.50.66]) by hpaq1.eem.corp.google.com with ESMTP id p0EMk7Yk027393 for ; Fri, 14 Jan 2011 14:47:08 -0800 Received: by gyf2 with SMTP id 2so1393958gyf.29 for ; Fri, 14 Jan 2011 14:47:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=pr54Bh+UUByD8fx+3u5J8dxbQ6EaBzy8PF6LMuLm1DE=; b=RBvZE2z2mTcIp0kr/v353acyYiqpUGYEO8rtBewa6vcmlGgY1ZVYnEMHrNpIlaGNvT 0EHPwvpvBKtiqaO79HgQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=p6TGFwkci6MfNcr9Y/6lGqnPZodvnoNhxpQ9A/DWc4hPvd9EySB6W30K30We3v+2Z3 ciBdco0CKhpfnVCGbmOQ== MIME-Version: 1.0 Received: by 10.100.210.3 with SMTP id i3mr932592ang.122.1295045227725; Fri, 14 Jan 2011 14:47:07 -0800 (PST) Received: by 10.100.196.20 with HTTP; Fri, 14 Jan 2011 14:47:07 -0800 (PST) In-Reply-To: References: <38CA53B9-A584-49B0-B764-2E83CAF9289F@nominum.com> Date: Fri, 14 Jan 2011 14:47:07 -0800 Message-ID: From: David Hankins To: DHC WG Content-Type: multipart/alternative; boundary=001636af024dc442960499d636c5 X-System-Of-Record: true Subject: Re: [dhcwg] Fwd: Dhcp client behavior in regard to Domain searchlist X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 22:44:45 -0000 --001636af024dc442960499d636c5 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 10, 2011 at 5:35 PM, ravi kumar wrote: > Thanks for your responses. > What is the approach followed by Dhcp client implemenations that support > both option 119 (Dhcpv4) and option 24 (Dhcpv6), as the behavior is not > documented in any RFC. > The client implementations whose inner workings I'm familiar with clobber each other, one or the other survives. This isn't a terrible state of affairs; optimally the administrator should properly keep these two configuration values identical, at least according to the current epistemology in domain search path configuration. As an optimization to this clobbering, I would mostly only suggest that the DHCPv6 derived value always take precedence. It seems like a slightly more clever client might attempt to combine the lists, either by stupid appension of one after the other or some more complicated unique-merging of the two. But I don't think this is helpful to the network operator who produces the search paths; a DHCPv4 configured search path could have an element in it that has AAAA's, and thus affect the IPv6 network. I have sometimes considered augmenting the client's stub resolver to accept different search path configurations for AAAA vs A lookups, and to then configure both values separately. The client would be expected to perform a stepladder search between the two. Starting on the v6 path first, it then tries the v4 path until it finds a name that matches the next name on the v6 path (and stops before trying this name). It then returns to the next name on the v6 path and continues. v6 path: experiment.example.com, eng.example.com, example.com, ooo.example.com v4 path: eng.example.com, ooo.example.com, example.com In this case the stub resolver would try, in order, until the first success; AAAA experiment.example.com AAAA eng.example.com A eng.example.com A ooo.example.com AAAA example.com A example.com AAAA ooo.example.com Primarily, I am attracted to this solution due to its vulgarity, but after some thought I tend to conclude that this fits with the DHCP-server-operator's expectations of client behavior with the related search paths. -- David W. Hankins SRE Google, Inc. --001636af024dc442960499d636c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 10, 2011 at 5:35 PM, ravi kumar <ravikumar.lrk@= gmail.com> wrote:
Thanks for your responses.
What is the approach followed by Dhcp client implemenations that suppo= rt both option 119 (Dhcpv4) and option 24 (Dhcpv6), as the behavior is not = documented in any RFC.

The client imp= lementations whose inner workings I'm familiar with clobber each other,= one or the other survives. =A0This isn't a terrible state of affairs; = optimally the administrator should properly keep these two configuration va= lues identical, at least according to the current epistemology in domain se= arch path configuration. =A0As an optimization to this clobbering, I would = mostly only suggest that the DHCPv6 derived value always take precedence.

It seems like a slightly more clever client might attem= pt to combine the lists, either by stupid appension of one after the other = or some more complicated unique-merging of the two. =A0But I don't thin= k this is helpful to the network operator who produces the search paths; a = DHCPv4 configured search path could have an element in it that has AAAA'= ;s, and thus affect the IPv6 network.

I have sometimes considered augmenting the client's= stub resolver to accept different search path configurations for AAAA vs A= lookups, and to then configure both values separately. =A0The=A0client wou= ld be expected to perform a stepladder search between the two. =A0Starting = on the v6 path first, it then tries the v4 path until it finds a name that = matches the next name on the v6 path (and stops before trying this name). = =A0It then returns to the next name on the v6 path and continues.


In this case the stub resol= ver would try, in order, until the first success;

=
Primarily, I am attracted to this solution due to its vulgar= ity, but after some thought I tend to conclude that this fits with the DHCP= -server-operator's expectations of client behavior with the related sea= rch paths.

--=A0
David W. Hankins
SRE
Google, Inc.
--001636af024dc442960499d636c5-- From ravikumar.lrk@gmail.com Sat Jan 15 11:19:42 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4DBF3A6E1B for ; Sat, 15 Jan 2011 11:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vVOgT6No4Y2 for ; Sat, 15 Jan 2011 11:19:41 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 48F9F3A67F0 for ; Sat, 15 Jan 2011 11:19:41 -0800 (PST) Received: by qwi2 with SMTP id 2so3860519qwi.31 for ; Sat, 15 Jan 2011 11:22:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=g5gWjU0ODhIc53rrDwQ3mJNKksU/qSTrRkpIqY69eVw=; b=Cmr0jeZf+87AjjHmJ6DCbsOmJlXW9AtTc3tFDWQ+0h9uploOcQUc5d3zWNqHS2NeLt PlRx0BPpubBbTD1m8Y7h1adR1nu100hydp1QZYb38r4X2rIrqfpIQjxGBBAIeRzb55WU xxyaB8kejsaxSKF0eik42k64cCemN4jgbxMmQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TNXZOSZDnuW+Jh/2DrEZFq4HhsDYMQIiEPTf5w2XDv7tDW4cUmQEnnWZdcHoiClnr4 /zbfW8jnq6v3BqBFCwCW7xjKByeuQPvPZS67He+ZLEwYRs5TKWIK0cGtzqtohfECRQQd thRtLga0SeMUBcHQMtFoHh5jYs4qXABi4GVgA= MIME-Version: 1.0 Received: by 10.229.186.141 with SMTP id cs13mr1990090qcb.283.1295119328251; Sat, 15 Jan 2011 11:22:08 -0800 (PST) Received: by 10.220.165.1 with HTTP; Sat, 15 Jan 2011 11:22:08 -0800 (PST) In-Reply-To: References: <38CA53B9-A584-49B0-B764-2E83CAF9289F@nominum.com> Date: Sun, 16 Jan 2011 00:52:08 +0530 Message-ID: From: ravi kumar To: David Hankins Content-Type: multipart/alternative; boundary=0016362848bc8092b30499e77768 Cc: DHC WG Subject: Re: [dhcwg] Fwd: Dhcp client behavior in regard to Domain searchlist X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 19:19:42 -0000 --0016362848bc8092b30499e77768 Content-Type: text/plain; charset=ISO-8859-1 Thanks for your response. regards Ravi On Sat, Jan 15, 2011 at 4:17 AM, David Hankins wrote: > On Mon, Jan 10, 2011 at 5:35 PM, ravi kumar wrote: > >> Thanks for your responses. >> What is the approach followed by Dhcp client implemenations that support >> both option 119 (Dhcpv4) and option 24 (Dhcpv6), as the behavior is not >> documented in any RFC. >> > > The client implementations whose inner workings I'm familiar with clobber > each other, one or the other survives. This isn't a terrible state of > affairs; optimally the administrator should properly keep these two > configuration values identical, at least according to the current > epistemology in domain search path configuration. As an optimization to > this clobbering, I would mostly only suggest that the DHCPv6 derived value > always take precedence. > > It seems like a slightly more clever client might attempt to combine the > lists, either by stupid appension of one after the other or some more > complicated unique-merging of the two. But I don't think this is helpful to > the network operator who produces the search paths; a DHCPv4 configured > search path could have an element in it that has AAAA's, and thus affect the > IPv6 network. > > I have sometimes considered augmenting the client's stub resolver to accept > different search path configurations for AAAA vs A lookups, and to then > configure both values separately. The client would be expected to perform a > stepladder search between the two. Starting on the v6 path first, it then > tries the v4 path until it finds a name that matches the next name on the v6 > path (and stops before trying this name). It then returns to the next name > on the v6 path and continues. > > v6 path: experiment.example.com, eng.example.com, example.com, > ooo.example.com > v4 path: eng.example.com, ooo.example.com, example.com > > In this case the stub resolver would try, in order, until the first > success; > > AAAA experiment.example.com > AAAA eng.example.com > A eng.example.com > A ooo.example.com > AAAA example.com > A example.com > AAAA ooo.example.com > > Primarily, I am attracted to this solution due to its vulgarity, but after > some thought I tend to conclude that this fits with the > DHCP-server-operator's expectations of client behavior with the related > search paths. > > -- > David W. Hankins > SRE > Google, Inc. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > --0016362848bc8092b30499e77768 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for your response.
=A0
regards
Ravi
On Sat, Jan 15, 2011 at 4:17 AM, David Hankins <= span dir=3D"ltr"><dhankins@google= .com> wrote:
On Mon, Jan 10, 2011 at 5:35 PM, ravi kumar <ravik= umar.lrk@gmail.com> wrote:
Thanks for your responses.
What is the approach followed by Dhcp client implemenations that suppo= rt both option 119 (Dhcpv4) and option 24 (Dhcpv6), as the behavior is not = documented in any RFC.

The client implementations whose inner workings I'm familiar with = clobber each other, one or the other survives. =A0This isn't a terrible= state of affairs; optimally the administrator should properly keep these t= wo configuration values identical, at least according to the current episte= mology in domain search path configuration. =A0As an optimization to this c= lobbering, I would mostly only suggest that the DHCPv6 derived value always= take precedence.

It seems like a slightly more clever client might attempt to combine t= he lists, either by stupid appension of one after the other or some more co= mplicated unique-merging of the two. =A0But I don't think this is helpf= ul to the network operator who produces the search paths; a DHCPv4 configur= ed search path could have an element in it that has AAAA's, and thus af= fect the IPv6 network.

I have sometimes considered augmenting the client's stub resolver = to accept different search path configurations for AAAA vs A lookups, and t= o then configure both values separately. =A0The=A0client would be expected = to perform a stepladder search between the two. =A0Starting on the v6 path = first, it then tries the v4 path until it finds a name that matches the nex= t name on the v6 path (and stops before trying this name). =A0It then retur= ns to the next name on the v6 path and continues.


In this case the stub resolver would try, in order, until the first su= ccess;

A example.com

Primarily, I am attracted to this solution due to its vulgarity, but a= fter some thought I tend to conclude that this fits with the DHCP-server-op= erator's expectations of client behavior with the related search paths.=

--=A0
David W. Hankins
SRE
Google, Inc.

_______________________________________________<= br>dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg


--0016362848bc8092b30499e77768-- From mellon@fugue.com Sun Jan 16 07:41:34 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B3743A6BFC for ; Sun, 16 Jan 2011 07:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HE5QpbM6-LeH for ; Sun, 16 Jan 2011 07:41:33 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by core3.amsl.com (Postfix) with ESMTP id 858193A6BEA for ; Sun, 16 Jan 2011 07:41:33 -0800 (PST) Received: from [10.0.1.7] (pool-96-236-119-28.spfdma.east.verizon.net [96.236.119.28]) by toccata.fugue.com (Postfix) with ESMTPSA id 0CFB934E4462; Sun, 16 Jan 2011 10:44:28 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ted Lemon In-Reply-To: Date: Sun, 16 Jan 2011 10:44:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <38CA53B9-A584-49B0-B764-2E83CAF9289F@nominum.com> To: ravi kumar X-Mailer: Apple Mail (2.1082) Cc: DHC WG Subject: Re: [dhcwg] Fwd: Dhcp client behavior in regard to Domain searchlist X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 15:41:34 -0000 Ultimately, of course, the search path is simply a bad idea, and it's = best to simply never use it. Ambiguity is undesirable in networking = protocols. From MSmith@internode.com.au Sun Jan 16 20:04:33 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318A928C0CE for ; Sun, 16 Jan 2011 20:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZA6K-y9ETMr for ; Sun, 16 Jan 2011 20:04:32 -0800 (PST) Received: from imail.internode.com.au (exchht01-ext.internode.com.au [203.26.95.185]) by core3.amsl.com (Postfix) with ESMTP id 8721B3A6DA2 for ; Sun, 16 Jan 2011 20:04:31 -0800 (PST) Received: from [192.168.99.15] (192.168.99.15) by exchht01.staff.internode.com.au (172.17.2.4) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 17 Jan 2011 14:37:03 +1030 Message-ID: <4D33C066.40904@internode.com.au> Date: Mon, 17 Jan 2011 14:37:02 +1030 From: Mark Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ted Lemon References: <4D2E5ECA.8010300@internode.com.au> <4D2F9E74.8030604@internode.com.au> <53E8A4B6-23A4-4E4B-A3FE-E4FC965B901B@fugue.com> In-Reply-To: <53E8A4B6-23A4-4E4B-A3FE-E4FC965B901B@fugue.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] LAN side Information Refresh Option time values derived from WAN side DHCPv6-PD timers? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 04:04:33 -0000 Hi Ted, On 14/01/2011 1:39 PM, Ted Lemon wrote: > On Jan 13, 2011, at 7:53 PM, Mark Smith wrote: >> For example, if the information request refresh time was a similar time period to the delegated prefix preferred time, which I think would translate into an equivalent DHCPv6-PD REBIND time, then when an ISP transitions it's customers from, for example, old DNS servers to new ones, the maximum time period both the old and new DNS servers would have to be available during the transition would be approximately 2 times the delegated prefix preferred time. > > This is a solution to a problem that doesn't exist. ISPs don't need to switch customers from name server A to name server B on a time schedule that tight. Or, if they do, we need to be talking in detail about the scenario where you think this is necessary; talking about IRT times is putting the cart before the horse. > It's not clear yet nor does there seem to be a common practice as to what preferred and valid lifetimes ISPs are likely to use, so I suppose the RFC4861 defaults of 7 and 30 days would be reasonable ones to start with as an example. Assuming there are no hardware acquisition lead times, my experience has been that it is possible to build and have ready for production two replacement DNS resolvers in a week, for use in an ISP with 50K+ subscribers. I think a reasonable goal would then be to have all those subscribers using those new DNS resolvers four weeks from when they are first made available to subscribers. If a customer's CPE is doing a rebind of it's delegated prefix at around the 7 day period, then I'd assume that would also be when the new DNS servers addresses would be provided to the CPE at that time. I think that would mean that the last customer CPE to receive the new DNS servers addresses would be the ones that rebound their delegated prefix moments before the DNS servers addresses where changed in the DHCPv6(-PD) server. So within about 7 days from when the DNS servers go into production, it is very probable that all the customers' CPE would now have knowledge of the new ones. Ideally if the end-nodes are asking for and receiving the DNS options from the stateless DHCPv6 server on the LAN interface of the CPE, then they should be updated within a time period that is predictable by the ISP, based on a parameter that the ISP defines. Thinking about it a bit more, if the information refresh option time was set to around 7 days (i.e. preferred lifetime for delegated prefix set by the ISP) on the LAN, then I think end-nodes should have acquired the new DNS servers addresses within a maximum of 14 days from when the DNS servers were first made available to subscribers via updated settings in the ISP's DHCPv6 server. That would fall well within the 4 week goal of transitioning from old DNS servers to new ones. So maybe as a more general rule, the information refresh time value conveyed by a stateless DHCPv6 server on the LAN interface of a CPE would be set to the rebind time value of the DHCPv6(-PD) client on the WAN interface. >> Having an known and predictable upper bound for how long legacy services will be used would much better than today's situation with IPv4, where legacy services have to be available for potentially years, and there is still have a likelyhood that a customer's services will be disrupted when those legacy services are eventually decommissioned. > > This is why the ISPs should have been using DHCP with leases. With leases, you *know* the information will be invalidated when the lease expires; if it's not, the client is out of spec. If you need a protocol that doesn't cause customer failures when the customer is running software that's out of spec, that's a really large solution space, and I don't think we can help you. > DHCPv6-PD (i.e. with leases), is being used by the ISP (i.e. us). The issue is how updates to DHCPv6 options provided by via DHCPv6(-PD) on the WAN side of the CPE are propagated in a timely manner to end-nodes on the LAN side of the CPE, via the stateless DHCPv6 server on the LAN side of the CPE. >> I think that might be a limitation of stateless DHCPv6 itself unfortunately. Without some sort of flash update or expire message that the CPE can send to the LAN devices upon change of parameters acquired via DHCPv6-PD, as the absolute minimum time for the information refresh looks to be 10 minutes, there would be fairly significant periods where end-nodes are trying to use invalid parameters. > > Prefix delegation isn't meant to force rapid renumbering or any sort of rapid reconfiguration on clients. If you use it that way, yes, you will definitely experience problems. That's not a problem with the protocol. Or, I should say, if you think it's a problem with the protocol, you're going to need to change a lot more than the DHCP protocol to get something reliable that can be renumbered that quickly. > > The idea with renumbering in IPv6 is to deprecate the old prefix, but continue to allow its use for some period after it's deprecated. Meanwhile you give the PD client a new prefix. The PD client immediately starts advertising the new prefix, and deprecates the old prefix. At this point I would actually expect a DHCP client to reconfigure, because it's got a new prefix. > > But even if it doesn't, as long as it reconfigures before the deprecated prefix expires, life should be okay. If this is happening more rapidly than every five minutes, something very weird is going on. > > I guess my point is that what you're asking for, and the problems you're anticipating, seem out of line with the solution you're proposing, and with the deployment scenario I understood you to be describing. So it would be good if you could talk some more about that, so that we can get a better understanding of why you think you have a problem. > Thanks, Mark. From dhankins@google.com Fri Jan 21 13:59:16 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41EF23A6845 for ; Fri, 21 Jan 2011 13:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.776 X-Spam-Level: X-Spam-Status: No, score=-105.776 tagged_above=-999 required=5 tests=[AWL=-2.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VTw0ARjOJ8z for ; Fri, 21 Jan 2011 13:59:14 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 95D143A682A for ; Fri, 21 Jan 2011 13:59:14 -0800 (PST) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id p0LM1xo3008772 for ; Fri, 21 Jan 2011 14:02:00 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295647320; bh=2TEKyknzGt7Dlt0q9p/rGinzCIE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=oWiCgbM9i3/f4sD6oavSd7EO5qtnzrwqs/xqqctLgcBAPgH4l4AIugxslhvo08+k0 PV1Cg71ciixpJS9xwVPmg== Received: from gyd12 (gyd12.prod.google.com [10.243.49.204]) by kpbe20.cbf.corp.google.com with ESMTP id p0LM1SRg029525 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 21 Jan 2011 14:01:58 -0800 Received: by gyd12 with SMTP id 12so747031gyd.3 for ; Fri, 21 Jan 2011 14:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2LL+Siau3/6Pboq2DEljcl4ouOXZ/LNuMtazTsMUDDQ=; b=GcOcmiSZNS60NrXm+zM2Fi1rcfhEB5P5kmWQR0xu6lOomzPSVzaHrHScimdRdUarcS h0Udd1Vm7BRS12Gu9ShA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Xx0r5n67Li9zf7LdIahZoKQBkk7ebFAkTyA1YRL2iBKw8zvldxVYASDfZHvycz1Mnn VUUlkaHQAB5NVHqdQxvA== MIME-Version: 1.0 Received: by 10.100.195.5 with SMTP id s5mr854841anf.224.1295647317752; Fri, 21 Jan 2011 14:01:57 -0800 (PST) Received: by 10.100.27.31 with HTTP; Fri, 21 Jan 2011 14:01:57 -0800 (PST) In-Reply-To: <20110121214655.730D43A6AA9@core3.amsl.com> References: <20110121214655.730D43A6AA9@core3.amsl.com> Date: Fri, 21 Jan 2011 14:01:57 -0800 Message-ID: From: David Hankins To: "softwires@ietf.org list" Content-Type: multipart/alternative; boundary=0016e643566220fd7e049a6266c7 X-System-Of-Record: true Cc: DHC WG Subject: [dhcwg] Fwd: New Version Notification for draft-ietf-softwire-ds-lite-tunnel-option-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 21:59:16 -0000 --0016e643566220fd7e049a6266c7 Content-Type: text/plain; charset=ISO-8859-1 Incorporating (opposing) comments from the softwire and DHC wg's; 1) Servers MUST send one option relaxed to SHOULD, on the basis that current DHCPv6 server implementations don't have a control for how many instances of "new options" (defined after the software is released) may be configured or sent. 2) Introduction of a new term, a "B4 system", which is the amalgamation of the B4 element we are configuring and any other software co-resident (specifically the DHCPv6 client or other configuration management layers). Several normative specifications are changed to refer to the B4 system instead of "the client" which could otherwise be seen to require a change in software implementation of DHCPv6 clients specifically - we don't want that. Either the DHCPv6 client, the B4 element, or some software joining the two in the middle need to validate that only one domain name is being used, and we don't care which one. ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Fri, Jan 21, 2011 at 1:46 PM Subject: New Version Notification for draft-ietf-softwire-ds-lite-tunnel-option-08 To: dhankins@google.com Cc: tomasz.mrugalski@eti.pg.gda.pl A new version of I-D, draft-ietf-softwire-ds-lite-tunnel-option-08.txt has been successfully submitted by David Hankins and posted to the IETF repository. Filename: draft-ietf-softwire-ds-lite-tunnel-option Revision: 08 Title: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite Creation_date: 2011-01-21 WG ID: softwire Number_of_pages: 8 Abstract: This document specifies a DHCPv6 option which is meant to be used by a Dual-Stack Lite Basic Bridging Broadband (B4) element to discover the IPv6 address of its corresponding Address Family Transition Router (AFTR). The IETF Secretariat. -- David W. Hankins SRE Google, Inc. --0016e643566220fd7e049a6266c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Incorporating (opposing) comments from the softwire and DHC wg's;
<= br>
1) Servers MUST send one option relaxed to SHOULD, on the bas= is that current DHCPv6 server implementations don't have a control for = how many instances of "new options" (defined after the software i= s released) may be configured or sent.

2) Introduction of a new term, a "B4 system",= which is the amalgamation of the B4 element we are configuring and any oth= er software co-resident (specifically the DHCPv6 client or other configurat= ion management layers). =A0Several normative specifications are changed to = refer to the B4 system instead of "the client" which could otherw= ise be seen to require a change in software implementation of DHCPv6 client= s specifically - we don't want that. =A0Either the DHCPv6 client, the B= 4 element, or some software joining the two in the middle need to validate = that only one domain name is being used, and we don't care which one.
---------- Forwarded message ----------
F= rom: IETF I-D Submission Tool <ids= ubmission@ietf.org>
Date: Fri, Jan 21, 2011 at 1:46 PM
Subject: New Version Notification for= draft-ietf-softwire-ds-lite-tunnel-option-08
To: dhankins@google.com
Cc: = tomasz.= mrugalski@eti.pg.gda.pl



A new version of I-D, draft-ietf-softwire-ds-lite-tunnel-option-08.txt has = been successfully submitted by David Hankins and posted to the IETF reposit= ory.

Filename: =A0 =A0 =A0 =A0draft-ietf-softwire-ds-lite-tunnel-option
Revision: =A0 =A0 =A0 =A008
Title: =A0 =A0 =A0 =A0 =A0 Dynamic Host Configuration Protocol for IPv6 (DH= CPv6) Option for Dual- Stack Lite
Creation_date: =A0 2011-01-21
WG ID: =A0 =A0 =A0 =A0 =A0 softwire
Number_of_pages: 8

Abstract:
This document specifies a DHCPv6 option which is meant to be used by
a Dual-Stack Lite Basic Bridging Broadband (B4) element to discover
the IPv6 address of its corresponding Address Family Transition
Router (AFTR).



The IETF Secretariat.





--
David W. Hankins
SRE<= /div>
Google, Inc.

--0016e643566220fd7e049a6266c7-- From iesg-secretary@ietf.org Mon Jan 24 09:47:34 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E0443A6918; Mon, 24 Jan 2011 09:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1A13HmuE5bdx; Mon, 24 Jan 2011 09:47:33 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3F323A692B; Mon, 24 Jan 2011 09:47:32 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110124174732.30645.86738.idtracker@localhost> Date: Mon, 24 Jan 2011 09:47:32 -0800 Cc: dhc mailing list , dhc chair , Internet Architecture Board , RFC Editor Subject: [dhcwg] Protocol Action: 'Lightweight DHCPv6 Relay Agent' to Proposed Standard (draft-ietf-dhc-dhcpv6-ldra-03.txt) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 17:47:34 -0000 The IESG has approved the following document: - 'Lightweight DHCPv6 Relay Agent' (draft-ietf-dhc-dhcpv6-ldra-03.txt) as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-ldra/ Technical Summary This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces. The LDRA can be implemented in existing access nodes (such as DSLAMs and Ethernet switches) that do not support IPv6 control or routing functions. Working Group Summary This document appeared in the working group at the end of 2008. There has been substantial interest in this document. Document Quality The document has undergone careful review, and the working group is satisfied with its quality. Personnel The document shepherd is Ted Lemon . Ralph Droms is the Responsible AD. RFC Editor Note In section 4, change "must" to "MUST": OLD: DHCP server implementations conforming to this specification must, NEW: DHCP server implementations conforming to this specification MUST, * Section 5.1 OLD: The Relay-Forward message contains relay agent parameters that identify the client-facing interface on which any reply messages should be forwarded. These parameters are link-address, peer-address and Interface-ID. The link-address parameter MUST be set to the unspecified address. The Interface-ID Relay Agent Option MUST be included in the Relay-Forward message. The LDRA MAY insert additional relay agent options. NEW: The Relay-Forward message contains relay agent parameters that identify the client-facing interface on which any reply messages should be forwarded. These parameters are link-address, peer-address and Interface-ID. The link-address parameter MUST be set to the unspecified address. The peer-address parameter MUST be set as specified in Section 6.1. The Interface-ID Relay Agent Option MUST be included in the Relay-Forward message. The LDRA MAY insert additional relay agent options. * Section 6.1 OLD: When a DHCPv6 message (defined in [RFC3315]) is received on any client-facing interface, the LDRA MUST intercept and process the message. The LDRA MUST also prevent the original message from being forwarded on the network facing interface. NEW: The LDRA MUST intercept and process all IP traffic received on any client-facing interface that has: o destination IP address set to All_DHCP_Relay_Agents_and_Servers (FF02::1:2); o protocol type UDP; and o destination port 547 The LDRA MUST also prevent the original message from being forwarded on the network facing interface. * Section 7 OLD: The LDRA intercepts any DHCPv6 message received on client-facing interfaces with a destination IP address of All_DHCP_Relay_Agents_and_Servers (FF02::1:2). The LDRA MUST NOT forward the original client message to a network-facing interface, it MUST process the message and add the appropriate Relay-Forward options as described in previous sections. NEW: The LDRA intercepts any DHCPv6 message received on client-facing interfaces with the traffic pattern specified in Section 6.1. The LDRA MUST NOT forward the original client message to a network-facing interface, it MUST process the message and add the appropriate Relay-Forward options as described in previous sections. * Security Considerations OLD: Although the LDRA only listens to client-originated IPv6 traffic sent to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547, the LDRA SHOULD implement some form of rate-limiting on received messages to prevent excessive process utilisation. As DHCP is session-oriented, messages in excess of the rate-limit may be silently discarded. NEW: The security issues pertaining to DHCPv6 relay agents as specified in Section 23 of [RFC3315] are also applicable to LDRAs. Although the LDRA only listens to client-originated IPv6 traffic sent to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547, the LDRA SHOULD implement some form of rate-limiting on received messages to prevent excessive process utilisation. As DHCP is session-oriented, messages in excess of the rate-limit may be silently discarded. From dhankins@google.com Mon Jan 24 10:51:03 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B6923A6AF6 for ; Mon, 24 Jan 2011 10:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.532 X-Spam-Level: X-Spam-Status: No, score=-104.532 tagged_above=-999 required=5 tests=[AWL=-1.556, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-sDTTEEKMeU for ; Mon, 24 Jan 2011 10:51:02 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 8AD743A698F for ; Mon, 24 Jan 2011 10:51:01 -0800 (PST) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p0OIKECj012670 for ; Mon, 24 Jan 2011 10:20:14 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295893214; bh=eb+Xm0NelF3+dWnAzftyR47uwkg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=hma55zZf9mPgyOZWHgVf3CO7WOPY3/NmAg/38fdMuFG69bslvQhZ35fYT9IijT2st cEIbHux7hcVHKJGRwtL/A== Received: from yxt33 (yxt33.prod.google.com [10.190.5.225]) by hpaq1.eem.corp.google.com with ESMTP id p0OIJcdN024082 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 24 Jan 2011 10:20:13 -0800 Received: by yxt33 with SMTP id 33so1621330yxt.31 for ; Mon, 24 Jan 2011 10:20:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Faj8M5sJDpFlH/MB6vGc5QP9nYELBzQhP7X7WDWwtRA=; b=K5/FY9iL+XhO9OYEK4TA5daRC80opHWibGeX3Py8DTWzn6/BOCNy3dKYAhiUhcjTNW uPfSERBQrFV0fG2Gi18w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lrujUarqXVcWgQ3/HVIc/aCdTgVV8N9cVS253zWgWK4JZ+00I237U/YN6J3WjBKxH2 JPbvl0CmYW9aAQRgf+AQ== MIME-Version: 1.0 Received: by 10.100.96.5 with SMTP id t5mr3168094anb.258.1295893212870; Mon, 24 Jan 2011 10:20:12 -0800 (PST) Received: by 10.100.27.31 with HTTP; Mon, 24 Jan 2011 10:20:12 -0800 (PST) In-Reply-To: <20110124174732.30645.86738.idtracker@localhost> References: <20110124174732.30645.86738.idtracker@localhost> Date: Mon, 24 Jan 2011 10:20:12 -0800 Message-ID: From: David Hankins To: The IESG Content-Type: multipart/alternative; boundary=001485f6d5909ebb7f049a9ba6bb X-System-Of-Record: true Cc: dhc mailing list , dhc chair , Internet Architecture Board , IETF-Announce , RFC Editor Subject: Re: [dhcwg] Protocol Action: 'Lightweight DHCPv6 Relay Agent' to Proposed Standard (draft-ietf-dhc-dhcpv6-ldra-03.txt) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 18:51:03 -0000 --001485f6d5909ebb7f049a9ba6bb Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 24, 2011 at 9:47 AM, The IESG wrote: > OLD: Although the LDRA only listens to client-originated IPv6 traffic sent > to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547, > the LDRA SHOULD implement some form of rate-limiting on received > messages to prevent excessive process utilisation. As DHCP is > session-oriented, messages in excess of the rate-limit may be > silently discarded. > > NEW: > The security issues pertaining to DHCPv6 relay agents as specified in > Section 23 of [RFC3315] are also applicable to LDRAs. Although the > LDRA only listens to client-originated IPv6 traffic sent > to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547, > the LDRA SHOULD implement some form of rate-limiting on received > messages to prevent excessive process utilisation. As DHCP is > session-oriented, messages in excess of the rate-limit may be > silently discarded. > This is false, actually, the LDRA also listens to any "network-originated" (in the draft's terminology) packets sent to link-local addresses and the DHCPv6 client port, and it does process these messages: it must de-encapsulate a relay-reply into a reply (or another nested relay-reply). Does this language intend instead to imply that rate limiting should only be applied to multicast traffic? -- David W. Hankins SRE Google, Inc. --001485f6d5909ebb7f049a9ba6bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jan 24, 2011 at 9:47 AM, The IESG <iesg-secretary@ietf.org> wrot= e:
OLD:
=A0 Although the LDRA only listens to client-originated IPv6 traffic sent<= br> =A0 to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547, =A0 the LDRA SHOULD implement some form of rate-limiting on received
=A0 messages to prevent excessive process utilisation. =A0As DHCP is
=A0 session-oriented, messages in excess of the rate-limit may be
=A0 silently discarded.

NEW:
=A0 The security issues pertaining to DHCPv6 relay agents as specified in<= br> =A0 Section 23 of [RFC3315] are also applicable to LDRAs. Although the
=A0 LDRA only listens to client-originated IPv6 traffic sent
=A0 to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547, =A0 the LDRA SHOULD implement some form of rate-limiting on received
=A0 messages to prevent excessive process utilisation. =A0As DHCP is
=A0 session-oriented, messages in excess of the rate-limit may be
=A0 silently discarded.

This is false,= actually, the LDRA also listens to any "network-originated" (in = the draft's terminology) packets sent to link-local addresses and the D= HCPv6 client port, and it does process these messages: it must de-encapsula= te a relay-reply into a reply (or another nested relay-reply).

Does this language intend instead to imply that rate li= miting should only be applied to multicast traffic?

--
David W. Hankins
SRE
Google, Inc.
--001485f6d5909ebb7f049a9ba6bb-- From dhankins@google.com Wed Jan 26 11:38:51 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB93C3A688C for ; Wed, 26 Jan 2011 11:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.65 X-Spam-Level: X-Spam-Status: No, score=-105.65 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XANOuT7k1MRP for ; Wed, 26 Jan 2011 11:38:51 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id CB89A3A6886 for ; Wed, 26 Jan 2011 11:38:50 -0800 (PST) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p0QJfpgD006738 for ; Wed, 26 Jan 2011 11:41:52 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296070912; bh=uQlesc3RHFZGxcjaBMQ16yMVYls=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=qJ5qFAud8nP8DebP+QyATiWc/oUe+85Xl96AkUO3O+FSUWG/+ePXZV4hJs/FZV66L WBHabrwzyj9mKDohrjrCA== Received: from yxd5 (yxd5.prod.google.com [10.190.1.197]) by wpaz33.hot.corp.google.com with ESMTP id p0QJecTO015230 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 26 Jan 2011 11:41:51 -0800 Received: by yxd5 with SMTP id 5so295671yxd.20 for ; Wed, 26 Jan 2011 11:41:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TvJAx/RMlUt7pBAf39HGDKtCvfE9u864s04dSQ7tg88=; b=vutDYOShKkV2XsHvlxGdIxOVmk0hgjiDOq1aSzSsgQ8owsWMnrm3nHT8QT1ZPu6vI+ ZPvnJ1bJDBxC8XW9XeGg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BAMpm+7z8laVZ0a/GljNHoNPJ4phly3rRdeNRF1g5cmdGg0zp6HDAOJdtsSpjhA0qc ZUEy5tMaeLMV3RrzDDLw== MIME-Version: 1.0 Received: by 10.100.178.5 with SMTP id a5mr5176855anf.184.1296070910555; Wed, 26 Jan 2011 11:41:50 -0800 (PST) Received: by 10.100.92.19 with HTTP; Wed, 26 Jan 2011 11:41:50 -0800 (PST) In-Reply-To: References: <20110124174732.30645.86738.idtracker@localhost> Date: Wed, 26 Jan 2011 11:41:50 -0800 Message-ID: From: David Hankins To: iesg@ietf.org Content-Type: multipart/alternative; boundary=0016e64136e43a377a049ac506bd X-System-Of-Record: true Cc: dhc mailing list , dhc chair , Internet Architecture Board , RFC Editor Subject: [dhcwg] Fwd: Protocol Action: 'Lightweight DHCPv6 Relay Agent' to Proposed Standard (draft-ietf-dhc-dhcpv6-ldra-03.txt) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 19:38:52 -0000 --0016e64136e43a377a049ac506bd Content-Type: text/plain; charset=ISO-8859-1 +to iesg@, -to iesg-secretary@ per Cindy. ---------- Forwarded message ---------- From: David Hankins Date: Mon, Jan 24, 2011 at 10:20 AM Subject: Re: [dhcwg] Protocol Action: 'Lightweight DHCPv6 Relay Agent' to Proposed Standard (draft-ietf-dhc-dhcpv6-ldra-03.txt) To: The IESG Cc: IETF-Announce , dhc mailing list , dhc chair , Internet Architecture Board < iab@iab.org>, RFC Editor On Mon, Jan 24, 2011 at 9:47 AM, The IESG wrote: > OLD: Although the LDRA only listens to client-originated IPv6 traffic sent > to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547, > the LDRA SHOULD implement some form of rate-limiting on received > messages to prevent excessive process utilisation. As DHCP is > session-oriented, messages in excess of the rate-limit may be > silently discarded. > > NEW: > The security issues pertaining to DHCPv6 relay agents as specified in > Section 23 of [RFC3315] are also applicable to LDRAs. Although the > LDRA only listens to client-originated IPv6 traffic sent > to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547, > the LDRA SHOULD implement some form of rate-limiting on received > messages to prevent excessive process utilisation. As DHCP is > session-oriented, messages in excess of the rate-limit may be > silently discarded. > This is false, actually, the LDRA also listens to any "network-originated" (in the draft's terminology) packets sent to link-local addresses and the DHCPv6 client port, and it does process these messages: it must de-encapsulate a relay-reply into a reply (or another nested relay-reply). Does this language intend instead to imply that rate limiting should only be applied to multicast traffic? -- David W. Hankins SRE Google, Inc. -- David W. Hankins SRE Google, Inc. --0016e64136e43a377a049ac506bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +to iesg@, -to iesg-secretary@ per Cindy.

---------- Forwarded message ----------
From: David Hankins <dhankins@google.com>
Date: Mon, Jan 24, 2011 at 10:20 AM
Subject: Re: [dhcwg] Protocol Action= : 'Lightweight DHCPv6 Relay Agent' to Proposed Standard (draft-ietf= -dhc-dhcpv6-ldra-03.txt)
To: The IESG <iesg-secretary@ietf.org>
Cc: IETF-Announce <ietf-announ= ce@ietf.org>, dhc mailing list <dhcwg@ietf.org>, dhc chair <dhc-chairs@tools.ietf.org>, Internet Architecture Board <= ;iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>


On Mon, Jan 24, 2011 at 9:47 AM, The IESG <iesg-secretary@ietf.org> wrote:
OLD:
=A0 Although the LDRA only listens to client-originated IPv6 traffic sent<= br> =A0 to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547, =A0 the LDRA SHOULD implement some form of rate-limiting on received
=A0 messages to prevent excessive process utilisation. =A0As DHCP is
=A0 session-oriented, messages in excess of the rate-limit may be
=A0 silently discarded.

NEW:
=A0 The security issues pertaining to DHCPv6 relay agents as specified in<= br> =A0 Section 23 of [RFC3315] are also applicable to LDRAs. Although the
=A0 LDRA only listens to client-originated IPv6 traffic sent
=A0 to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547, =A0 the LDRA SHOULD implement some form of rate-limiting on received
=A0 messages to prevent excessive process utilisation. =A0As DHCP is
=A0 session-oriented, messages in excess of the rate-limit may be
=A0 silently discarded.

This is = false, actually, the LDRA also listens to any "network-originated"= ; (in the draft's terminology) packets sent to link-local addresses and= the DHCPv6 client port, and it does process these messages: it must de-enc= apsulate a relay-reply into a reply (or another nested relay-reply).

Does this language intend instead to imply that rate li= miting should only be applied to multicast traffic?

--
David W. Hankins
SRE
Google, Inc.

--
David W. Hankins
SRE
Googl= e, Inc.
--0016e64136e43a377a049ac506bd-- From suresh.krishnan@ericsson.com Mon Jan 31 15:01:58 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAD513A6B20; Mon, 31 Jan 2011 15:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ty2nYy8HR5GR; Mon, 31 Jan 2011 15:01:58 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id C5F823A6B16; Mon, 31 Jan 2011 15:01:57 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p0VNl1RG030161; Mon, 31 Jan 2011 17:47:03 -0600 Received: from [142.133.10.107] (147.117.20.213) by eusaamw0712.eamcs.ericsson.se (147.117.20.182) with Microsoft SMTP Server id 8.2.234.1; Mon, 31 Jan 2011 18:04:57 -0500 Message-ID: <4D473FDE.9080304@ericsson.com> Date: Mon, 31 Jan 2011 18:03:58 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: David Hankins References: <20110124174732.30645.86738.idtracker@localhost> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: dhc chair , Internet Architecture Board , The IESG , dhc mailing list , IETF-Announce , RFC Editor Subject: Re: [dhcwg] Protocol Action: 'Lightweight DHCPv6 Relay Agent' to Proposed Standard (draft-ietf-dhc-dhcpv6-ldra-03.txt) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 23:01:59 -0000 Hi David, Thanks for the comments. David Hankins wrote: > On Mon, Jan 24, 2011 at 9:47 AM, The IESG > wrote: > > OLD: > > Although the LDRA only listens to client-originated IPv6 traffic sent > to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547, > the LDRA SHOULD implement some form of rate-limiting on received > messages to prevent excessive process utilisation. As DHCP is > session-oriented, messages in excess of the rate-limit may be > silently discarded. > > NEW: > The security issues pertaining to DHCPv6 relay agents as specified in > Section 23 of [RFC3315] are also applicable to LDRAs. Although the > LDRA only listens to client-originated IPv6 traffic sent > to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547, > the LDRA SHOULD implement some form of rate-limiting on received > messages to prevent excessive process utilisation. As DHCP is > session-oriented, messages in excess of the rate-limit may be > silently discarded. > > > This is false, actually, the LDRA also listens to any > "network-originated" (in the draft's terminology) packets sent to > link-local addresses and the DHCPv6 client port, and it does process > these messages: it must de-encapsulate a relay-reply into a reply (or > another nested relay-reply). What you say is correct (the LDRA also listens to network-originated traffic), but the text in the Security Considerations section was intended to apply only to the client-initiated IPv6 traffic and does not talk about the network-originated traffic. In the deployment scenarios we were targeting, the network-facing interfaces were considered to be trusted and hence there was no need to perform rate-limiting on network-originated traffic. Do you see a need to rate-limit network-originated traffic as well? Thanks Suresh From dhankins@google.com Mon Jan 31 16:44:54 2011 Return-Path: X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 948133A6C95 for ; Mon, 31 Jan 2011 16:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.743 X-Spam-Level: X-Spam-Status: No, score=-105.743 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 226AlXu+tzeH for ; Mon, 31 Jan 2011 16:44:53 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id ADB953A6C97 for ; Mon, 31 Jan 2011 16:44:53 -0800 (PST) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p110m8e9026448 for ; Mon, 31 Jan 2011 16:48:08 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296521289; bh=kcmlho2ys6HqOJEE3TS/dh6FKYU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=O3GXPoIeEjwjJvIMsBj5zMP8q6TE9g5NV3hKLMje/yOGtK1vD3Oj36/MWJYHrEBm7 2hTZo7fsbsgDz/NbPIOiQ== Received: from gxk28 (gxk28.prod.google.com [10.202.11.28]) by hpaq5.eem.corp.google.com with ESMTP id p110lglQ003913 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 31 Jan 2011 16:48:07 -0800 Received: by gxk28 with SMTP id 28so3024617gxk.18 for ; Mon, 31 Jan 2011 16:48:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RN1Q8m7RM9zQo3Mvgf3UnuDs0Bdhs4kDsKnAi7knFyU=; b=JwyVQ2gevAmxPIhmd9mj94KzCNlj39IN8hMAF/Jot630pADuJpzMflwTuh2/0BCMIw bMl6Q3eWCsE5qilxE//g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=m5kQ2j9WgE3Mt0AVgLO+OP82f+yRXJYNdDqb0iddv2iqbcM9oDp1dT672A1DpoDuVO m4dVNbRGmd+smYMEWA6w== MIME-Version: 1.0 Received: by 10.100.178.5 with SMTP id a5mr4346088anf.184.1296521286785; Mon, 31 Jan 2011 16:48:06 -0800 (PST) Received: by 10.100.92.19 with HTTP; Mon, 31 Jan 2011 16:48:06 -0800 (PST) In-Reply-To: <4D473FDE.9080304@ericsson.com> References: <20110124174732.30645.86738.idtracker@localhost> <4D473FDE.9080304@ericsson.com> Date: Mon, 31 Jan 2011 16:48:06 -0800 Message-ID: From: David Hankins To: Suresh Krishnan Content-Type: multipart/alternative; boundary=0016e64136e4be2202049b2de25a X-System-Of-Record: true Cc: dhc chair , Internet Architecture Board , The IESG , dhc mailing list , IETF-Announce , RFC Editor Subject: Re: [dhcwg] Protocol Action: 'Lightweight DHCPv6 Relay Agent' to Proposed Standard (draft-ietf-dhc-dhcpv6-ldra-03.txt) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 00:44:54 -0000 --0016e64136e4be2202049b2de25a Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 31, 2011 at 3:03 PM, Suresh Krishnan < suresh.krishnan@ericsson.com> wrote: > Thanks for the comments. > Sorry I only noticed this in the IESG diff. > What you say is correct (the LDRA also listens to network-originated > traffic), but the text in the Security Considerations section was intended > to apply only to the client-initiated IPv6 traffic and does not talk about > the network-originated traffic. In the deployment scenarios we were > targeting, the network-facing interfaces were considered to be trusted and > hence there was no need to perform rate-limiting on network-originated > traffic. Do you see a need to rate-limit network-originated traffic as well? > That is what I expected - but I think someone could easily misinterpret the existing text. If you have the time or energy to try and make the statement a bit more direct...I would open with the recommendation to rate-limit client-originated traffic and close with admitting the only client-originated traffic the LDRA receives is the one address/port pair mentioned. -- David W. Hankins SRE Google, Inc. --0016e64136e4be2202049b2de25a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 31, 2011 at 3:03 PM, Suresh Krishnan= <suresh.krishnan@ericsson.com> wrote:
Thanks for the comments.

Sorry I only n= oticed this in the IESG diff.
=A0
What you say is correct (the LDRA also listens to network-originated traffi= c), but the text in the Security Considerations section was intended to app= ly only to the client-initiated IPv6 traffic and does not talk about the ne= twork-originated traffic. In the deployment scenarios we were targeting, th= e network-facing interfaces were considered to be trusted and hence there w= as no need to perform rate-limiting on network-originated traffic. Do you s= ee a need to rate-limit network-originated traffic as well?

That is what I expected - but I think some= one could easily misinterpret the existing text. =A0If you have the time or= energy to try and make the statement a bit more direct...I would open with= the recommendation to rate-limit client-originated traffic and close with = admitting the only client-originated traffic the LDRA receives is the one a= ddress/port pair mentioned.

--=A0
David W. Hankins
SRE
Google, Inc.

--0016e64136e4be2202049b2de25a--