From wwwrun@rfc-editor.org Sat Sep 1 05:13:41 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D62021F8565 for ; Sat, 1 Sep 2012 05:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.296 X-Spam-Level: X-Spam-Status: No, score=-102.296 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOONubp8ZGvw for ; Sat, 1 Sep 2012 05:13:40 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 36B5C21F853B for ; Sat, 1 Sep 2012 05:13:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9372CB1E002; Sat, 1 Sep 2012 05:11:10 -0700 (PDT) To: jouni.nospam@gmail.com, teemu.savolainen@nokia.com, suresh.krishnan@ericsson.com, ot@cisco.com, rdroms.ietf@gmail.com, brian@innovationslab.net, ted.lemon@nominum.com, john_brzozowski@cable.comcast.com From: RFC Errata System Message-Id: <20120901121110.9372CB1E002@rfc-editor.org> Date: Sat, 1 Sep 2012 05:11:10 -0700 (PDT) X-Mailman-Approved-At: Sat, 01 Sep 2012 09:00:58 -0700 Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] [Editorial Errata Reported] RFC6603 (3332) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 12:13:41 -0000 The following errata report has been submitted for RFC6603, "Prefix Exclude Option for DHCPv6-based Prefix Delegation". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6603&eid=3332 -------------------------------------- Type: Editorial Reported by: Gaurav Halwasia Section: 4.2 Original Text ------------- Any prefix excluded from the delegated prefix MUST be contained in OPTION_PD_EXCLUDE options within the corresponding OPTION_IAPREFIX. Corrected Text -------------- Any prefix excluded from the delegated prefix MUST be contained in OPTION_PD_EXCLUDE option within the corresponding OPTION_IAPREFIX. Notes ----- As per this specification OPTION_PD_EXCLUDE option is used to exclude exactly one prefix from a delegated prefix. So as per this specification only one instance of OPTION_PD_EXCLUDE option can be present within OPTION_IAPREFIX. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6603 (draft-ietf-dhc-pd-exclude-04) -------------------------------------- Title : Prefix Exclude Option for DHCPv6-based Prefix Delegation Publication Date : May 2012 Author(s) : J. Korhonen, Ed., T. Savolainen, S. Krishnan, O. Troan Category : PROPOSED STANDARD Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG From jouni.nospam@gmail.com Sun Sep 2 05:03:58 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA6421F8A2A for ; Sun, 2 Sep 2012 05:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pp+ucMn6tqjx for ; Sun, 2 Sep 2012 05:03:58 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB2F521F8A29 for ; Sun, 2 Sep 2012 05:03:57 -0700 (PDT) Received: by eaai11 with SMTP id i11so1285027eaa.31 for ; Sun, 02 Sep 2012 05:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=XLdelyi1g+DyMm4XdNjXPegnTnyMetszZkDYNgb16E4=; b=TMv6qJjtZB9/QCOWYgdU4lu+ppxFuHU3VCI2W3D3mHvuUPM4G4vbiYcQ+GLI9Gx2Sc sz4BD/k6PG31vk3MFRIV8DTojbqhFfL5mHRka3O6IZysO54mV7XE9fFgZZg5zeAqtpVb fZGDgkIHCN43X+rWRKaRtUGhCGAA1uAPnFagr4K28vp7PcyYoLhtFUacdco7X25QyRYL UEA1jJDhZsdLXXTroeJGoJqicjnygumxWSN73O5woMFViBsP7Bp2OKYt+zQq7tUB94+S ToJXVxKzc9vVqG89ZBY5CXmMtRI52CkslUcfAPMlagDUcdm8iVsFPPUVDlMOQ9HxTnst tMiA== Received: by 10.14.172.193 with SMTP id t41mr17426359eel.25.1346587436791; Sun, 02 Sep 2012 05:03:56 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:a4ea:23dc:c8a6:a267? ([2001:1bc8:101:f101:a4ea:23dc:c8a6:a267]) by mx.google.com with ESMTPS id k41sm27763084eep.13.2012.09.02.05.03.48 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Sep 2012 05:03:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: <20120901121110.9372CB1E002@rfc-editor.org> Date: Sun, 2 Sep 2012 15:03:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <95AA3CFE-8839-4283-9B57-E9B05A31F5E4@gmail.com> References: <20120901121110.9372CB1E002@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Sun, 02 Sep 2012 06:45:15 -0700 Cc: ot@cisco.com, brian@innovationslab.net, rdroms.ietf@gmail.com, dhcwg@ietf.org, ted.lemon@nominum.com Subject: Re: [dhcwg] [Editorial Errata Reported] RFC6603 (3332) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 12:03:58 -0000 The errata is correct and should be accepted. In section 4.1 it is specifically stated that "There can be at most one OPTION_PD_EXCLUDE option in one OPTION_IAPREFIX option." - Jouni On Sep 1, 2012, at 3:11 PM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC6603, > "Prefix Exclude Option for DHCPv6-based Prefix Delegation". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6603&eid=3D3332 >=20 > -------------------------------------- > Type: Editorial > Reported by: Gaurav Halwasia >=20 > Section: 4.2 >=20 > Original Text > ------------- > Any prefix excluded from the delegated prefix MUST be contained in > OPTION_PD_EXCLUDE options within the corresponding OPTION_IAPREFIX. >=20 > Corrected Text > -------------- > Any prefix excluded from the delegated prefix MUST be contained in > OPTION_PD_EXCLUDE option within the corresponding OPTION_IAPREFIX. >=20 > Notes > ----- > As per this specification OPTION_PD_EXCLUDE option is used to exclude = exactly one prefix from a delegated prefix. So as per this specification = only one instance of OPTION_PD_EXCLUDE option can be present within = OPTION_IAPREFIX. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6603 (draft-ietf-dhc-pd-exclude-04) > -------------------------------------- > Title : Prefix Exclude Option for DHCPv6-based Prefix = Delegation > Publication Date : May 2012 > Author(s) : J. Korhonen, Ed., T. Savolainen, S. Krishnan, O. = Troan > Category : PROPOSED STANDARD > Source : Dynamic Host Configuration > Area : Internet > Stream : IETF > Verifying Party : IESG From brian@innovationslab.net Sun Sep 2 05:28:35 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134A121F88C3 for ; Sun, 2 Sep 2012 05:28:35 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sb25OkjaBFTM for ; Sun, 2 Sep 2012 05:28:34 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6C021F88BA for ; Sun, 2 Sep 2012 05:28:34 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 1336288094; Sun, 2 Sep 2012 05:28:34 -0700 (PDT) Received: from Littlejohn.local (c-69-140-213-249.hsd1.md.comcast.net [69.140.213.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id C6C63130019; Sun, 2 Sep 2012 05:28:32 -0700 (PDT) Message-ID: <504350EE.7000301@innovationslab.net> Date: Sun, 02 Sep 2012 08:28:30 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Jouni References: <20120901121110.9372CB1E002@rfc-editor.org> <95AA3CFE-8839-4283-9B57-E9B05A31F5E4@gmail.com> In-Reply-To: <95AA3CFE-8839-4283-9B57-E9B05A31F5E4@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 02 Sep 2012 06:45:15 -0700 Cc: ot@cisco.com, rdroms.ietf@gmail.com, dhcwg@ietf.org, RFC Errata System , ted.lemon@nominum.com Subject: Re: [dhcwg] [Editorial Errata Reported] RFC6603 (3332) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 12:28:35 -0000 Hi Jouni, I agree that this is an error. The question is whether it can demonstrably cause an implementation error. If it can, then it should be accepted. If it is easily recognized as a typo, it should classified as "hold for document update". Regards, Brian On 9/2/12 8:03 AM, Jouni wrote: > > The errata is correct and should be accepted. In section 4.1 it is > specifically stated that "There can be at most one OPTION_PD_EXCLUDE > option in one OPTION_IAPREFIX option." > > - Jouni > > > On Sep 1, 2012, at 3:11 PM, RFC Errata System wrote: > >> >> The following errata report has been submitted for RFC6603, >> "Prefix Exclude Option for DHCPv6-based Prefix Delegation". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=6603&eid=3332 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Gaurav Halwasia >> >> Section: 4.2 >> >> Original Text >> ------------- >> Any prefix excluded from the delegated prefix MUST be contained in >> OPTION_PD_EXCLUDE options within the corresponding OPTION_IAPREFIX. >> >> Corrected Text >> -------------- >> Any prefix excluded from the delegated prefix MUST be contained in >> OPTION_PD_EXCLUDE option within the corresponding OPTION_IAPREFIX. >> >> Notes >> ----- >> As per this specification OPTION_PD_EXCLUDE option is used to exclude exactly one prefix from a delegated prefix. So as per this specification only one instance of OPTION_PD_EXCLUDE option can be present within OPTION_IAPREFIX. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6603 (draft-ietf-dhc-pd-exclude-04) >> -------------------------------------- >> Title : Prefix Exclude Option for DHCPv6-based Prefix Delegation >> Publication Date : May 2012 >> Author(s) : J. Korhonen, Ed., T. Savolainen, S. Krishnan, O. Troan >> Category : PROPOSED STANDARD >> Source : Dynamic Host Configuration >> Area : Internet >> Stream : IETF >> Verifying Party : IESG From jouni.nospam@gmail.com Sun Sep 2 07:57:54 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D38B21F8452 for ; Sun, 2 Sep 2012 07:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RS-L0ucBuzP for ; Sun, 2 Sep 2012 07:57:53 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8288F21F8450 for ; Sun, 2 Sep 2012 07:57:53 -0700 (PDT) Received: by eekb45 with SMTP id b45so1676319eek.31 for ; Sun, 02 Sep 2012 07:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=7boZqbXhipQx0yMKOAaT9J5ogAbf1NUyQTuLKhpxL3M=; b=X9dMw4gCpjSQNNP+LU6YPqCbeauAWE6ARMl09fis9yhvZWalOPhg8ZrWBfTH78At1+ Y5lf4l/O9ZCIyLFfc65yVeMEWXR+oBavYnfQSG3mFA8kMCudKa38ojFDpNzxc9NJkZw6 ZJTdjQJPEavZqpB0e07LIskfnIcGzOtuGdDSI3L8Qy5THHcuyUOqg/74blJv43itK+aY sdNapyWS9d6mVmf7Mzvdzu5LbrD66Kidd04ms7CMl17McyeucZaQ3LRcEVNfYmxOez/D rlifER0tlq8l1sWtyN1WWlgi1pSGVXqWO4hMGeRCbwhJJa7C4HxBr6K8yWAcbyatuMMZ VQ4Q== Received: by 10.14.198.65 with SMTP id u41mr17949709een.22.1346597872609; Sun, 02 Sep 2012 07:57:52 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:a4ea:23dc:c8a6:a267? ([2001:1bc8:101:f101:a4ea:23dc:c8a6:a267]) by mx.google.com with ESMTPS id 45sm28681061eed.17.2012.09.02.07.57.43 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Sep 2012 07:57:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Jouni In-Reply-To: <504350EE.7000301@innovationslab.net> Date: Sun, 2 Sep 2012 17:57:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4530B20D-56B2-4293-AFA5-A531A768CE90@gmail.com> References: <20120901121110.9372CB1E002@rfc-editor.org> <95AA3CFE-8839-4283-9B57-E9B05A31F5E4@gmail.com> <504350EE.7000301@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Sun, 02 Sep 2012 16:21:40 -0700 Cc: ot@cisco.com, rdroms.ietf@gmail.com, dhcwg@ietf.org, RFC Errata System , ted.lemon@nominum.com Subject: Re: [dhcwg] [Editorial Errata Reported] RFC6603 (3332) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 14:57:54 -0000 Brian, I say it is easily recognized as a typo. The text in the option introduction in Section 4.1 is very clear. So, ok with "hold for document update". - Jouni On Sep 2, 2012, at 3:28 PM, Brian Haberman wrote: > Hi Jouni, > I agree that this is an error. The question is whether it can = demonstrably cause an implementation error. If it can, then it should = be accepted. If it is easily recognized as a typo, it should classified = as "hold for document update". >=20 > Regards, > Brian >=20 > On 9/2/12 8:03 AM, Jouni wrote: >>=20 >> The errata is correct and should be accepted. In section 4.1 it is >> specifically stated that "There can be at most one OPTION_PD_EXCLUDE >> option in one OPTION_IAPREFIX option." >>=20 >> - Jouni >>=20 >>=20 >> On Sep 1, 2012, at 3:11 PM, RFC Errata System wrote: >>=20 >>>=20 >>> The following errata report has been submitted for RFC6603, >>> "Prefix Exclude Option for DHCPv6-based Prefix Delegation". >>>=20 >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3D6603&eid=3D3332 >>>=20 >>> -------------------------------------- >>> Type: Editorial >>> Reported by: Gaurav Halwasia >>>=20 >>> Section: 4.2 >>>=20 >>> Original Text >>> ------------- >>> Any prefix excluded from the delegated prefix MUST be contained in >>> OPTION_PD_EXCLUDE options within the corresponding = OPTION_IAPREFIX. >>>=20 >>> Corrected Text >>> -------------- >>> Any prefix excluded from the delegated prefix MUST be contained in >>> OPTION_PD_EXCLUDE option within the corresponding OPTION_IAPREFIX. >>>=20 >>> Notes >>> ----- >>> As per this specification OPTION_PD_EXCLUDE option is used to = exclude exactly one prefix from a delegated prefix. So as per this = specification only one instance of OPTION_PD_EXCLUDE option can be = present within OPTION_IAPREFIX. >>>=20 >>> Instructions: >>> ------------- >>> This errata is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>>=20 >>> -------------------------------------- >>> RFC6603 (draft-ietf-dhc-pd-exclude-04) >>> -------------------------------------- >>> Title : Prefix Exclude Option for DHCPv6-based Prefix = Delegation >>> Publication Date : May 2012 >>> Author(s) : J. Korhonen, Ed., T. Savolainen, S. Krishnan, = O. Troan >>> Category : PROPOSED STANDARD >>> Source : Dynamic Host Configuration >>> Area : Internet >>> Stream : IETF >>> Verifying Party : IESG >=20 From zhou.sujing@zte.com.cn Mon Sep 3 01:03:15 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3A821F84B6 for ; Mon, 3 Sep 2012 01:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.298 X-Spam-Level: X-Spam-Status: No, score=-101.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Jun6WarGdm9 for ; Mon, 3 Sep 2012 01:03:15 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id A10BF21F84B3 for ; Mon, 3 Sep 2012 01:03:14 -0700 (PDT) Received: from [192.168.168.119] by mx5.zte.com.cn with surfront esmtp id 23255262235339; Mon, 3 Sep 2012 15:56:23 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 4E723713AA1 for ; Mon, 3 Sep 2012 15:59:05 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q83832Wp011622 for ; Mon, 3 Sep 2012 16:03:02 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) To: dhcwg@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Mon, 3 Sep 2012 16:03:02 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-09-03 16:03:03, Serialize complete at 2012-09-03 16:03:03 Content-Type: multipart/alternative; boundary="=_alternative 002C496648257A6E_=" X-MAIL: mse02.zte.com.cn q83832Wp011622 Subject: [dhcwg] Ask for comments on draft-zhou-dhc-ibc-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 08:03:15 -0000 This is a multipart message in MIME format. --=_alternative 002C496648257A6E_= Content-Type: text/plain; charset="US-ASCII" Hi, all Who will pls take some time giving a review on http://tools.ietf.org/id/draft-zhou-dhc-ibc-00.txt? Thank you. Regards~~~ -Sujing Zhou --=_alternative 002C496648257A6E_= Content-Type: text/html; charset="US-ASCII"
Hi, all
   
 Who will pls take some time giving a review on  http://tools.ietf.org/id/draft-zhou-dhc-ibc-00.txt?
 Thank you.


Regards~~~

-Sujing Zhou --=_alternative 002C496648257A6E_=-- From ichiroumakino@gmail.com Mon Sep 3 01:03:43 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7102F21F84B6 for ; Mon, 3 Sep 2012 01:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.105 X-Spam-Level: X-Spam-Status: No, score=-3.105 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gdeycyPNRuj for ; Mon, 3 Sep 2012 01:03:43 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 83B2C21F84A6 for ; Mon, 3 Sep 2012 01:03:42 -0700 (PDT) Received: by eekb45 with SMTP id b45so1844154eek.31 for ; Mon, 03 Sep 2012 01:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=WDXRyYeZQbTSCaTsyiHGRYIXL5hzI9T3lo3udoPLcCg=; b=Z/N9N5qBEja3XiH38ioHZ+lZQ8w2fvU5mMViK5BMHzOt+hLwijzmB55fMXSmEkB3lA b+eA6SS9p5SaJha4uAdh/p3cKg55V2myMU46dGlHxFZYQYPKbBN/BIqSijmJMG2MiGWM JhUt1JzdnMc5Rhfhrg+FCOOFW2onH9wwQSkgYWhBGqpOe+ZeDF6zxHhZImayQjt/QOWS jMP06ClMg5E7Z1Ux6MM0GrvQgTFpZ4l0P3Zae7NZgOgzLUREShBxw/TmUjnBG7ujWOSn vRK68jek4ZHbCe7AQF5TO8fiL1NltF60XzWjCXzcaeKHpISA+BvKhpzJoc1wxOnkAK0z NSgw== Received: by 10.14.211.3 with SMTP id v3mr20226737eeo.43.1346659421620; Mon, 03 Sep 2012 01:03:41 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-75.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id e7sm34202069eep.2.2012.09.03.01.03.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Sep 2012 01:03:40 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_DCCF2F24-D223-413F-9F98-B1EFD6B43643"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> Date: Mon, 3 Sep 2012 10:03:38 +0200 Message-Id: <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1278) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 08:03:43 -0000 --Apple-Mail=_DCCF2F24-D223-413F-9F98-B1EFD6B43643 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > The authors have proposed that the working group adopt the prefix pool = option draft as a working group item. We have engaged in some = correspondence with participants in the Routing Area, and while some = helpful advice was given, no objections were raised to going forward = with the work, and it's a DHCP protocol extension, so it makes sense for = it to happen in the DHC working group. >=20 > The document proposes an extension to the DHCP protocol that allows = the DHCP server to communicate prefixes to the provider edge router when = doing prefix delegation, such that this router can advertise a route to = an aggregate prefix, rather than to many individual prefixes, and so = that this router does not have to perform ad-hoc prefix aggregation, = which may produce less optimal results. >=20 > If you think this work should be adopted by the working group, please = reply to this message saying so. If you think this work should not be = adopted by the working group, please reply to this message saying so. = We will evaluate consensus on September 7. I'm generally uncomfortable with piggybacking on the client initiated = protocol, to manage a DHCPv6 relay sitting in the middle of the = conversation. I do not think it is a good idea to require DHCPv6 relays to rewrite = DHCPv6 client messages. does this work with DHCPv6 authentication? do we want to make DHCP a general management protocol of the = DR/first-hop router? I am against adopting this document as a working group document. cheers, Ole= --Apple-Mail=_DCCF2F24-D223-413F-9F98-B1EFD6B43643 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwOTAzMDgwMzM4WjAjBgkqhkiG9w0BCQQxFgQUobxLlsHU8o9R59fw EaWqM0A7320wggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAfUlUANDaTLrTfehCuI5v NZ7+heVbPi6K0APjRTTX976A9WZwrCW3aiWMVUHXDfYivaV5NqbM1K0nym9uW3ku16M8YHd0ijBd BY+HMmFRdPXbv71Fpb6kiHVDdmpHUmA8+aoPNHhVTsSyvBjBE2MGygglyjhcRCoBgteM5MgqG73K hzK411LSqD7dAVpBf1bzImD/+YpqHFGA8x10xqcJVyfHnt+5fZA1dQR8xpvohlXp/TouMY5soe+L 3eeMU4OW7J5fGWF/QKDwiXD4VnFo8u6tDGKPM74IfquBe3A2a2I+ijMzKvjANCUFA0ur4NVG5Pra F74ZocwX/URwcVD79AAAAAAAAA== --Apple-Mail=_DCCF2F24-D223-413F-9F98-B1EFD6B43643-- From tomasz.mrugalski@gmail.com Mon Sep 3 07:48:52 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E6A21F8666 for ; Mon, 3 Sep 2012 07:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6zq8OLBCO+Z for ; Mon, 3 Sep 2012 07:48:52 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA09921F865E for ; Mon, 3 Sep 2012 07:48:51 -0700 (PDT) Received: by eekb45 with SMTP id b45so2054293eek.31 for ; Mon, 03 Sep 2012 07:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=19Zs6KHtZsH3Y0zYRKoS2eb7xd0YK0tThgfoh3gtJOo=; b=FSws5A954On3vNfKbc1StK81ARsEUpkQbgAI+LXsVNCN8twGMDlR0VVdhUyf51N5R9 JP+rF/NXraE5Am/1jlaywvfEupkV3JBJWOgaCwJM+vlOV3kpa7BGYdwzI4Nz/BqkqzAQ CUtHcole15ubHA/eXK+1yzud1/2AOr0GPNRx1KCFiS2OFaZ2KSbxRU0BgrqZbqGranMB ZZT7eaNa6Xj00DqkBX1fOjrFYZjuSCzX5GVtFYaC2/RMSN9A2Y0OvAlD/2KnBEF69I34 +rw532L4Rv3V/BAAmc75b5GgSfwcdtICpGyvPyBZDarEcl93ps17jAPBqsKQz8ghyhHf VCLw== Received: by 10.14.199.67 with SMTP id w43mr21909339een.33.1346683730966; Mon, 03 Sep 2012 07:48:50 -0700 (PDT) Received: from ?IPv6:2001:470:6061:1:c6f:7fc7:4c78:2f7e? ([2001:470:6061:1:c6f:7fc7:4c78:2f7e]) by mx.google.com with ESMTPS id k49sm37171999een.4.2012.09.03.07.48.49 (version=SSLv3 cipher=OTHER); Mon, 03 Sep 2012 07:48:50 -0700 (PDT) Message-ID: <5044C350.4010403@gmail.com> Date: Mon, 03 Sep 2012 16:48:48 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> In-Reply-To: <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> X-TagToolbar-Keys: D20120903164848462 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 14:48:52 -0000 On 03.09.2012 10:03, Ole Trĝan wrote: >> [...] >> If you think this work should be adopted by the working >> group, please reply to this message saying so. If you think this >> work should not be adopted by the working group, please reply to >> this message saying so. We will evaluate consensus on September >> 7. > > I'm generally uncomfortable with piggybacking on the client > initiated protocol, to manage a DHCPv6 relay sitting in the middle of > the conversation. Piggybacking is not very elegant, but the alternatives are worse. If you chose not to piggyback, you would have to use some form (something like) leasequery + active pushback from the server to notify relays that something has changed. Such a protocol would add new message types, new connections, perhaps even new state in the server. What is such hypothetical prefix-pool-queries came from outside your network (or any unathorized source)? So new attack vectors would have to be considered and possible protected against. With prefix pool option in RELAY_REPL that contains PD REPLY, your server already decided that is ok to respond. No extra connections, no extra message types, no new state. So in my opinion piggybacking is not the most elegant solution, but the alternatives are much worse. One thing that should probably improved is handing of the case when server policy changes. Right now the draft says to trigger reconfigure and force a client to start reconfigure process. The client won't get any new or changed configuration. Also, there may be a network does not have any client that supports reconfigure (which is optional). So in my opinion that part of the draft requires some extra work. Does it mean that we should throw away the whole concept? In my opinion - definitely not. > I do not think it is a good idea to require DHCPv6 relays to rewrite > DHCPv6 client messages. Nobody suggested such a thing. Relays would consume some options put in RELAY-REPL. The decapsulation process would work as it is now - take contents of RELAY-MSG option and send it downlink (be it the next relay or the client - it doesn't matter). > does this work with DHCPv6 authentication? It doesn't affect it at all. Servers that auhenticate their responses are signing REPLY message that is in turn encapsulated in RELAY-REPL. THe prefix-pool option is insterted in RELAY-REPL and the REPLY inside is never modified. prefix-pool never reaches the client. If that is was your impression after reading the draft, perhaps it should be clarified in the text? Tomek From shrinivas_ashok.joshi@alcatel-lucent.com Mon Sep 3 22:16:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46EE721F84AF for ; Mon, 3 Sep 2012 22:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rjDBQxZ6st7 for ; Mon, 3 Sep 2012 22:16:00 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 93C5A21F84A0 for ; Mon, 3 Sep 2012 22:15:59 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q845FnCP011250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Sep 2012 00:15:55 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q845FlEw006889 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Sep 2012 10:45:48 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Tue, 4 Sep 2012 10:45:47 +0530 From: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" To: Tomek Mrugalski , "dhcwg@ietf.org" Date: Tue, 4 Sep 2012 10:45:46 +0530 Thread-Topic: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Thread-Index: Ac2J4z70zEoodo6vTh2FMAmyGSgreQAd50Rg Message-ID: References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> In-Reply-To: <5044C350.4010403@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 05:16:01 -0000 Tomek, Since the goal of the solution is to transfer a prefix table from dhcp serv= er to the relay why not use DHCP inform with options,or a separate message = to get this information(draft-joshi-dhc-dhcpv6-aggr-route-opt) ?=20 This would not have the overhead per transaction and also the handling at t= he relay would be much elegant and simpler. Current draft requires relay to implement bulk lease query and additional p= rocessing per relayed PD request. As such the prefix routes are not supposed to change frequently and would i= n any case require additional routing policy and routing protocol configura= tion which would be done external to DHCP. So is this additional complexity & piggy backing at relay per dhcp PD excha= nge really required or should alternatives be considered / -- Shree >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of >Tomek Mrugalski >Sent: Monday, September 03, 2012 8:19 PM >To: dhcwg@ietf.org >Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-o= pt-08 > >On 03.09.2012 10:03, Ole Tr=F8an wrote: >>> [...] >>> If you think this work should be adopted by the working >>> group, please reply to this message saying so. If you think this >>> work should not be adopted by the working group, please reply to >>> this message saying so. We will evaluate consensus on September >>> 7. >> >> I'm generally uncomfortable with piggybacking on the client >> initiated protocol, to manage a DHCPv6 relay sitting in the middle of >> the conversation. >Piggybacking is not very elegant, but the alternatives are worse. If you >chose not to piggyback, you would have to use some form (something like) >leasequery + active pushback from the server to notify relays that >something has changed. Such a protocol would add new message types, new >connections, perhaps even new state in the server. What is such >hypothetical prefix-pool-queries came from outside your network (or any >unathorized source)? So new attack vectors would have to be considered >and possible protected against. > >With prefix pool option in RELAY_REPL that contains PD REPLY, your >server already decided that is ok to respond. No extra connections, no >extra message types, no new state. So in my opinion piggybacking is not >the most elegant solution, but the alternatives are much worse. > >One thing that should probably improved is handing of the case when >server policy changes. Right now the draft says to trigger reconfigure >and force a client to start reconfigure process. The client won't get >any new or changed configuration. Also, there may be a network does not >have any client that supports reconfigure (which is optional). So in my >opinion that part of the draft requires some extra work. Does it mean >that we should throw away the whole concept? In my opinion - definitely no= t. > >> I do not think it is a good idea to require DHCPv6 relays to rewrite >> DHCPv6 client messages. >Nobody suggested such a thing. Relays would consume some options put in >RELAY-REPL. The decapsulation process would work as it is now - take >contents of RELAY-MSG option and send it downlink (be it the next relay >or the client - it doesn't matter). > >> does this work with DHCPv6 authentication? >It doesn't affect it at all. Servers that auhenticate their responses >are signing REPLY message that is in turn encapsulated in RELAY-REPL. >THe prefix-pool option is insterted in RELAY-REPL and the REPLY inside >is never modified. prefix-pool never reaches the client. If that is was >your impression after reading the draft, perhaps it should be clarified >in the text? > >Tomek >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From xuxiaohu@huawei.com Mon Sep 3 23:45:56 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD80921F8512 for ; Mon, 3 Sep 2012 23:45:56 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlzMBlpuJMPo for ; Mon, 3 Sep 2012 23:45:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B4B5A21F84FD for ; Mon, 3 Sep 2012 23:45:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKI18064; Tue, 04 Sep 2012 06:45:52 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 4 Sep 2012 07:45:08 +0100 Received: from SZXEML426-HUB.china.huawei.com (10.72.61.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 4 Sep 2012 14:45:51 +0800 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.168]) by szxeml426-hub.china.huawei.com ([10.72.61.34]) with mapi id 14.01.0323.003; Tue, 4 Sep 2012 14:44:51 +0800 From: Xuxiaohu To: "dhcwg@ietf.org" Thread-Topic: Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Thread-Index: AQHNgg2f2GWemYRp/0G7NT9hbKcz65d5ysHwgAACCaA= Date: Tue, 4 Sep 2012 06:44:52 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07555FC6@szxeml525-mbx.china.huawei.com> References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.24] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 06:45:56 -0000 Support. > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of > Ted Lemon > Sent: Friday, August 24, 2012 11:32 PM > To: dhcwg@ietf.org WG > Subject: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-= 08 >=20 > The authors have proposed that the working group adopt the prefix pool op= tion > draft as a working group item. We have engaged in some correspondence > with participants in the Routing Area, and while some helpful advice was = given, > no objections were raised to going forward with the work, and it's a DHCP > protocol extension, so it makes sense for it to happen in the DHC working > group. >=20 > The document proposes an extension to the DHCP protocol that allows the > DHCP server to communicate prefixes to the provider edge router when doin= g > prefix delegation, such that this router can advertise a route to an aggr= egate > prefix, rather than to many individual prefixes, and so that this router = does not > have to perform ad-hoc prefix aggregation, which may produce less optimal > results. >=20 > If you think this work should be adopted by the working group, please rep= ly to > this message saying so. If you think this work should not be adopted by= the > working group, please reply to this message saying so. We will evaluate > consensus on September 7. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From ichiroumakino@gmail.com Tue Sep 4 02:29:13 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37F221F8552 for ; Tue, 4 Sep 2012 02:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EZ+3hK+emZo for ; Tue, 4 Sep 2012 02:29:12 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id E88D521F84F3 for ; Tue, 4 Sep 2012 02:29:11 -0700 (PDT) Received: by eaai11 with SMTP id i11so1864047eaa.31 for ; Tue, 04 Sep 2012 02:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=uD4qO6+9QxrQs9iUzPWi6xN0F5fnlolOnibX2CXvumI=; b=rDdqPXyVcOlpgbjAFdqA4dM12qWibXydLymNeUa4za2CdCIjJpHef2FEiSL741m45P QSaQHnP7pc8BUmxekzTsPFWEIg7fi3zuvv0D4GOEwE2iHfBegWbTXVYhLRB+cVQdxWCC 0a08A3MN82rPjUqA0KU/9fZggqekTu4ajJSPc+YKsNwtIXdRcXcfjQG5WWexa+itkVwW ROu8AqkPPHsF9yEN/2ytySIoUG+D50+Xyib0ZMR788/uhDokzt4QLQerdIUTcrnJwhSB +3E5vG6M9SUsyCCdYDJxGkSvUnVHqfkLhJ4VpNx/7HWthBO8DlJ7XeqpBmignjpxDhG5 yZXg== Received: by 10.14.215.197 with SMTP id e45mr25147367eep.36.1346750951175; Tue, 04 Sep 2012 02:29:11 -0700 (PDT) Received: from dhcp-10-55-90-46.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id u47sm43745386eeo.9.2012.09.04.02.29.06 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 02:29:10 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_CA2924C5-B6D1-445D-A527-6E7294903582"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <5044C350.4010403@gmail.com> Date: Tue, 4 Sep 2012 11:29:03 +0200 Message-Id: References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> To: Tomek Mrugalski X-Mailer: Apple Mail (2.1278) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 09:29:13 -0000 --Apple-Mail=_CA2924C5-B6D1-445D-A527-6E7294903582 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Tomek, >>> [...]=20 >>> If you think this work should be adopted by the working >>> group, please reply to this message saying so. If you think this >>> work should not be adopted by the working group, please reply to >>> this message saying so. We will evaluate consensus on September >>> 7. >>=20 >> I'm generally uncomfortable with piggybacking on the client >> initiated protocol, to manage a DHCPv6 relay sitting in the middle of >> the conversation. > Piggybacking is not very elegant, but the alternatives are worse. If = you > chose not to piggyback, you would have to use some form (something = like) > leasequery + active pushback from the server to notify relays that > something has changed. Such a protocol would add new message types, = new > connections, perhaps even new state in the server. What is such > hypothetical prefix-pool-queries came from outside your network (or = any > unathorized source)? So new attack vectors would have to be considered > and possible protected against. >=20 > With prefix pool option in RELAY_REPL that contains PD REPLY, your > server already decided that is ok to respond. No extra connections, no > extra message types, no new state. So in my opinion piggybacking is = not > the most elegant solution, but the alternatives are much worse. this doesn't mean a separate binding for the relay set of options? the alternatives as I see it are: - use whatever other management / configuration protocol used to manage = the relay - use a separate DHC session for the relay. noting that DHC isn't the = protocol normally used to manage PE routers. there are lots of other hammers in the toolbox, so we don't need to use = the DHC hammer for every problem we have... > One thing that should probably improved is handing of the case when > server policy changes. Right now the draft says to trigger reconfigure > and force a client to start reconfigure process. The client won't get > any new or changed configuration. Also, there may be a network does = not > have any client that supports reconfigure (which is optional). So in = my > opinion that part of the draft requires some extra work. Does it mean > that we should throw away the whole concept? In my opinion - = definitely not. right, I think that is broken. >> I do not think it is a good idea to require DHCPv6 relays to rewrite=20= >> DHCPv6 client messages. > Nobody suggested such a thing. Relays would consume some options put = in > RELAY-REPL. The decapsulation process would work as it is now - take > contents of RELAY-MSG option and send it downlink (be it the next = relay > or the client - it doesn't matter). >> does this work with DHCPv6 authentication? > It doesn't affect it at all. Servers that auhenticate their responses > are signing REPLY message that is in turn encapsulated in RELAY-REPL. > THe prefix-pool option is insterted in RELAY-REPL and the REPLY inside > is never modified. prefix-pool never reaches the client. If that is = was > your impression after reading the draft, perhaps it should be = clarified > in the text? ah, I see. I must have missed that in the text. I see there is a MAY in = 3315. cheers, Ole= --Apple-Mail=_CA2924C5-B6D1-445D-A527-6E7294903582 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwOTA0MDkyOTAzWjAjBgkqhkiG9w0BCQQxFgQUHnf7VJlFA5JTOMjg lFMqeltn+S4wggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAKHlPs7bRjbfYxg88PlEH Ifnot2HEg+ELEd7LHLFuJkzdx5zJM9AoeM1FUWslZ2Zm6sy8ecsQBPX3FHa31IOgCbQ6ND5rnw+7 Z2fkhLq6cLQ5FSzGMk4vbyj9AedencuDtd497VWRi9qTKEtbLRdhffbz0zpH+UrqW0/lT3O5s5lc QQGA/mLc+Hw7Yk6uMY0Boi/drlkHwMPYqAx2b1LddGkkte1+Qwk1+iXjtlmKt4foUEYbBtX0djZy 0y9txMTA6LOTCmS0ND+yQ0VDvN7mRStWZyv3h0bgD3uLqD18uHWIbP7aj4kN14P7vV93cW13ZcmN AwJqZRhnBbhdXowRmQAAAAAAAA== --Apple-Mail=_CA2924C5-B6D1-445D-A527-6E7294903582-- From Carl.Wuyts@technicolor.com Tue Sep 4 04:10:20 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3E321F8504 for ; Tue, 4 Sep 2012 04:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.521 X-Spam-Level: X-Spam-Status: No, score=-4.521 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ByZrQ7IjPmz for ; Tue, 4 Sep 2012 04:10:17 -0700 (PDT) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id C16BA21F84FA for ; Tue, 4 Sep 2012 04:10:16 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKUEXhmFleglzPzj4idq+/vZd1PO401NmY@postini.com; Tue, 04 Sep 2012 04:10:16 PDT Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.264.0; Tue, 4 Sep 2012 13:08:04 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.14]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Tue, 4 Sep 2012 13:08:07 +0200 From: Wuyts Carl To: dhc WG Date: Tue, 4 Sep 2012 13:08:05 +0200 Thread-Topic: SOL MAX RT Thread-Index: Ac2KjY71PtWS24h1QXS6kMDArPK2Sw== Message-ID: <867F4B6A1672E541A94676D556793ACD16E4DC56E6@MOPESMBX01.eu.thmulti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD16E4DC56E6MOPESMBX01eut_" MIME-Version: 1.0 Subject: [dhcwg] SOL MAX RT X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 11:10:20 -0000 --_000_867F4B6A1672E541A94676D556793ACD16E4DC56E6MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Anyone an idea when an option number will be assigned for this oro (as it s= till says TBD in below draft) ? (I-D.droms-dhc-dhcpv6-solmaxrt-update) Thx and regs Carl --_000_867F4B6A1672E541A94676D556793ACD16E4DC56E6MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,<= /p>

 

Anyone an= idea when an option number will be assigned for this oro (as it still says= TBD in below draft) ?

(I-D.droms-dhc-dhcpv6-solmaxrt-up= date)

 

Thx and regs

Carl

 

= --_000_867F4B6A1672E541A94676D556793ACD16E4DC56E6MOPESMBX01eut_-- From Ted.Lemon@nominum.com Tue Sep 4 06:56:29 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D490221F850C for ; Tue, 4 Sep 2012 06:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdM0YdH4jmaq for ; Tue, 4 Sep 2012 06:56:28 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id CAC8621F854A for ; Tue, 4 Sep 2012 06:56:27 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUEYIi9uvuGZN7IhG6bVivGHea0X1hB2s@postini.com; Tue, 04 Sep 2012 06:56:27 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A0A8A1B80B8 for ; Tue, 4 Sep 2012 06:56:26 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 95EDB19005C; Tue, 4 Sep 2012 06:56:26 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Tue, 4 Sep 2012 06:56:26 -0700 From: Ted Lemon To: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" Thread-Topic: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Thread-Index: AQHNilxkzqWc/Q9DJ0mcHtn1PhlGPpd6qseA Date: Tue, 4 Sep 2012 13:56:26 +0000 Message-ID: <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_6C1B27BB3FBD404699230FE6080D8AECnominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 13:56:30 -0000 --_000_6C1B27BB3FBD404699230FE6080D8AECnominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Sep 4, 2012, at 1:15 AM, "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" > wrote: This would not have the overhead per transaction and also the handling at t= he relay would be much elegant and simpler. Current draft requires relay to implement bulk lease query and additional p= rocessing per relayed PD request. The overhead per transaction here is a bit of a red herring=97we're talking= about thirteen bytes, if I count correctly. Furthermore, the working group already went down the path of separating out= the transactions a couple of years ago, and determined that there were syn= chronization problems; that work was eventually dropped for lack of interes= t. The problem remains unsolved; this is actually a pretty good solution, beca= use it involves fate sharing, with a netconf solution wouldn't have, and us= es an established communications path, which netconf/yang doesn't offer. This is definitely better than the solution vendors are currently offering,= which is to simply sniff the prefixes from DHCP messages to the client. = With my working group chair hat off, I'm in favor of doing this work precis= ely because it solves the problem neatly, and no better solution has ever b= een presented of which I'm aware. --_000_6C1B27BB3FBD404699230FE6080D8AECnominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0B59CE81416D6841A90CBD7DEC2A9D12@nominum.com> Content-Transfer-Encoding: quoted-printable
On Sep 4, 2012, at 1:15 AM, "JOSHI, SHRINIVAS ASHOK (SHRINIVAS AS= HOK)" <= shrinivas_ashok.joshi@alcatel-lucent.com> wrote:
This would not have the overhead per transaction and also the handling at the r= elay would be much elegant and simpler.
Current draft requires relay to implement bulk lease query and additional processi= ng per relayed PD request.

The overhead per transaction here is a bit of a red herring=97we're ta= lking about thirteen bytes, if I count correctly. 

Furthermore, the working group already went down the path of separatin= g out the transactions a couple of years ago, and determined that there wer= e synchronization problems; that work was eventually dropped for lack of in= terest.

The problem remains unsolved; this is actually a pretty good solution,= because it involves fate sharing, with a netconf solution wouldn't have, a= nd uses an established communications path, which netconf/yang doesn't offe= r.   

This is definitely better than the solution vendors are currently offe= ring, which is to simply sniff the prefixes from DHCP messages to the clien= t.   With my working group chair hat off, I'm in favor of doing this w= ork precisely because it solves the problem neatly, and no better solution has ever been presented of which I'm aware.=

--_000_6C1B27BB3FBD404699230FE6080D8AECnominumcom_-- From ichiroumakino@gmail.com Tue Sep 4 09:32:26 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC3521F8518 for ; Tue, 4 Sep 2012 09:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Fjcde2ul7Jw for ; Tue, 4 Sep 2012 09:32:26 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0046911E80A3 for ; Tue, 4 Sep 2012 09:32:25 -0700 (PDT) Received: by eaai11 with SMTP id i11so2032527eaa.31 for ; Tue, 04 Sep 2012 09:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=8S4otU+aa3ztExYh0uR//SBt9V9ryY8kWVJ6ujAB6dI=; b=X7UanrcVni7ycTpBNadw+qQvKT2QEPFBudbuPjJxG1YdAUy6nSHbUdrxNukiNZkoH4 9jmWYlAzisM1g9v8+1Q7cwIQVzzhqLjtjNoludN9qCiS2Z/9M4OvHlmcmkm+UajhpAjt zI/F5uoCM5/BsdsbCK4e+Jp283yHg1EJKOZD/37b6Qkni1u/U7NM9eSSAfEwDQ/VkPBW LZ/9Tm0xtYZ1CLGWPsjiS/7yNs5oYzQaaQ+nMtD1FcJLY4gCNKTcjGyy8NMrkUdvcvYZ Fl0mSEo6OJTjqnczuDZ7PliWx/JHn1wmWP7svH3+YvhfgNOp5ClU4Vat3gAK4gUy0ovG VYJg== Received: by 10.14.173.9 with SMTP id u9mr26869889eel.8.1346776345012; Tue, 04 Sep 2012 09:32:25 -0700 (PDT) Received: from dhcp-10-55-86-245.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id i8sm46735565eeo.16.2012.09.04.09.32.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 09:32:23 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_1D6A9EE7-29B9-4E29-8096-BF455A330C85"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> Date: Tue, 4 Sep 2012 18:32:21 +0200 Message-Id: <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1278) Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 16:32:27 -0000 --Apple-Mail=_1D6A9EE7-29B9-4E29-8096-BF455A330C85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ted, >> This would not have the overhead per transaction and also the = handling at the relay would be much elegant and simpler. >> Current draft requires relay to implement bulk lease query and = additional processing per relayed PD request. >=20 > The overhead per transaction here is a bit of a red herring=97we're = talking about thirteen bytes, if I count correctly.=20 >=20 > Furthermore, the working group already went down the path of = separating out the transactions a couple of years ago, and determined = that there were synchronization problems; that work was eventually = dropped for lack of interest. >=20 > The problem remains unsolved; this is actually a pretty good solution, = because it involves fate sharing, with a netconf solution wouldn't have, = and uses an established communications path, which netconf/yang doesn't = offer. fate sharing of what? the client functions independently of whatever = aggregate route there is for a whole block of subscribers. this just = adds another cog in the machinery that may fail. > This is definitely better than the solution vendors are currently = offering, which is to simply sniff the prefixes from DHCP messages to = the client. With my working group chair hat off, I'm in favor of doing = this work precisely because it solves the problem neatly, and no better = solution has ever been presented of which I'm aware. this does not solve the DHCPv6 PD problem of route injection. a route = needs to be installed per client, and snooping is still needed for that. = this proposal _only_ solves the problem of installing an aggregate route = for multiple PD RRs into a PE/relay. this is most typically done with = static configuration today. cheers, Ole= --Apple-Mail=_1D6A9EE7-29B9-4E29-8096-BF455A330C85 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwOTA0MTYzMjIxWjAjBgkqhkiG9w0BCQQxFgQUevg+hIuEkRwNBot2 j8sQG/INKIUwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEARaPia5Xq45lEBXq/QFUo iR8SvRVqdw+OzM+C3XQSPkhiZYS12Vv6i8wsmGwrTBggXf1ZXJ/UkNvFMBQ3JU13m/XGQ6ZOgBFn AqlYAvuyYTS8FQOw7lG2BZlBAjSrdzlK/2PYQvJlRnQdtsDmaU7KERGKDZt56CL2sN2p16ekiYz5 9EbZ1XX5gVKuW72kl+AHWRGYwIo+DeTqsC737MUtp9GaUund7ME4DJJxzpH76EsW5HTVVTPqCMIc FCjlDo2rhVIQ1ACnjMO6A8yvGNahUea8r2ymJ1Mxm9SCU5sKVJYMreA7Y6SwQ/hAJfRRQ9Jva1oL 7zyfdS4JWu1NEy0CRwAAAAAAAA== --Apple-Mail=_1D6A9EE7-29B9-4E29-8096-BF455A330C85-- From Ted.Lemon@nominum.com Tue Sep 4 10:43:54 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C603811E80A3 for ; Tue, 4 Sep 2012 10:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApkVfRadLBKZ for ; Tue, 4 Sep 2012 10:43:48 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id B173511E809A for ; Tue, 4 Sep 2012 10:43:48 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUEY91M4djmULuguIW+ZGeoyJQCKMfGa0@postini.com; Tue, 04 Sep 2012 10:43:48 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id BAE671B829F for ; Tue, 4 Sep 2012 10:43:47 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A53DB19005C; Tue, 4 Sep 2012 10:43:47 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Tue, 4 Sep 2012 10:43:47 -0700 From: Ted Lemon To: =?Windows-1252?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Thread-Index: AQHNilxkzqWc/Q9DJ0mcHtn1PhlGPpd6qseAgAArj4CAABP1gA== Date: Tue, 4 Sep 2012 17:43:47 +0000 Message-ID: References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> In-Reply-To: <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5A79DAE5317A6449AF7B8EACFD0B3B22@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 17:43:55 -0000 On Sep 4, 2012, at 12:32 PM, Ole Tr=F8an wrote: > fate sharing of what? the client functions independently of whatever aggr= egate route there is for a whole block of subscribers. this just adds anoth= er cog in the machinery that may fail. Fate sharing in the sense that the DHCP server is best able to know from wh= at aggregate prefix prefixes for clients on a particular router will be all= ocated, and the DHCP packet is the way these prefixes get allocated to the = client. So we can be sure that if the network is working at all, it will = be working completely. > this does not solve the DHCPv6 PD problem of route injection. a route nee= ds to be installed per client, and snooping is still needed for that. this = proposal _only_ solves the problem of installing an aggregate route for mul= tiple PD RRs into a PE/relay. this is most typically done with static confi= guration today. It solves half the problem: configuring the route that the router advertise= s. You are correct that it doesn't solve the other half=97figuring out wh= ere to send packets downstream. But actually, snooping the DHCP packet is= a perfectly good solution for this problem; what is lacking is a standard = that says how it's done.=20 What snooping is _not_ good for is figuring out what route to advertise ups= tream. To say that the upstream route is currently done with static confi= guration is synonymous with saying that the problem is currently unsolved. From ichiroumakino@gmail.com Tue Sep 4 11:03:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F7421E805E for ; Tue, 4 Sep 2012 11:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1F2xfFHHWArE for ; Tue, 4 Sep 2012 11:03:00 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B76821E8054 for ; Tue, 4 Sep 2012 11:03:00 -0700 (PDT) Received: by eekb45 with SMTP id b45so2629412eek.31 for ; Tue, 04 Sep 2012 11:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=dGo2q6Tzsm75Jhud7ZVdMtsAN69XTpKBGs+wrht76eo=; b=hFMsUS2dU7dmgYpcTp0w0JIDIsXNzNaTMg6PrlWai7S2v/ZBzQaOConePgwnvOwcQZ pAgnQRD/8WcFL+sfjc1RgXjK16Bv9rE+AnmIo9kGcTBaEFSyaArffrb62n5V9uzRNdwN 1AcArgujEwcjv24S4hhvpx7wEsM9yx1KVG0q2NaRpqJeLVo7cs7CJ0ZwJ4ohHlbOXOaE Y6N4fq9dJ9s8Mimt+1G5ka9yh01a0U5Y9hR+Dkp/Ehby3vMf8hVgkudBkaVD7deTmhS6 J26HtSR5dX2jIeqhF0Un09tTwkKobqEH9ul04Jso2TXHdVngFt9Rn0+Jigovnf2F8ei9 fanQ== Received: by 10.14.212.72 with SMTP id x48mr27094266eeo.40.1346781779630; Tue, 04 Sep 2012 11:02:59 -0700 (PDT) Received: from dhcp-10-55-86-245.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id i41sm47326183eem.7.2012.09.04.11.02.57 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 11:02:58 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_AE4FE18F-D4D5-4DA5-9E9C-5F3BE12B5438"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Tue, 4 Sep 2012 20:02:55 +0200 Message-Id: <0CFEF31D-4A01-42A7-89B7-69BDBB41E9C8@employees.org> References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> To: Ted Lemon X-Mailer: Apple Mail (2.1278) Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 18:03:01 -0000 --Apple-Mail=_AE4FE18F-D4D5-4DA5-9E9C-5F3BE12B5438 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >> fate sharing of what? the client functions independently of whatever = aggregate route there is for a whole block of subscribers. this just = adds another cog in the machinery that may fail. >=20 > Fate sharing in the sense that the DHCP server is best able to know = from what aggregate prefix prefixes for clients on a particular router = will be allocated, and the DHCP packet is the way these prefixes get = allocated to the client. So we can be sure that if the network is = working at all, it will be working completely. I look at it differently. you are adding more complexity on functions = that are not in the data path. in my book that isn't fate sharing. >> this does not solve the DHCPv6 PD problem of route injection. a route = needs to be installed per client, and snooping is still needed for that. = this proposal _only_ solves the problem of installing an aggregate route = for multiple PD RRs into a PE/relay. this is most typically done with = static configuration today. >=20 > It solves half the problem: configuring the route that the router = advertises. You are correct that it doesn't solve the other = half=97figuring out where to send packets downstream. But actually, = snooping the DHCP packet is a perfectly good solution for this problem; = what is lacking is a standard that says how it's done.=20 we did try with the use of the RAAN option. > What snooping is _not_ good for is figuring out what route to = advertise upstream. To say that the upstream route is currently done = with static configuration is synonymous with saying that the problem is = currently unsolved. this is like saying that configuring OSPF on a router is a unsolved = problem, just because it isn't done with DHCP. ;-) cheers, Ole= --Apple-Mail=_AE4FE18F-D4D5-4DA5-9E9C-5F3BE12B5438 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwOTA0MTgwMjU1WjAjBgkqhkiG9w0BCQQxFgQUApZQwAWH+hBeGBWA 89o7JcmTsO8wggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAshUbfimYa0JjFj68FChZ ZbFbp+6C8LEoAbQZH4BOJZBx0BcR/zDENhn9oL8C6bSvWyS3RAFgp3PdgIdJvsGnVFijNpp2esWt PLPUd+NjTCdUXF5WR5V3K1TS0P3W2VASnDaV1G2Iel/lBZwXwPVurUs2tKBjJyzeVUZvihLm5L6Y Ji5sFwHZBAkRBaOrbiCYE9UN9R4fRsh/H/B8jAx2FTaUUvYI1iQ3d/7JT1onQQO2lEUmJb6KPXcT uLtaWsEoxczkjQmxtvPQ316didnZPL/meNggVvw7L8iL65tvs2gCFWvIOXsyv/7V8xaIb/Sieg02 U15PJeqWHXuX6Dh+OQAAAAAAAA== --Apple-Mail=_AE4FE18F-D4D5-4DA5-9E9C-5F3BE12B5438-- From Ted.Lemon@nominum.com Tue Sep 4 12:33:00 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE2211E80A3 for ; Tue, 4 Sep 2012 12:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xr6iENj9F6Ag for ; Tue, 4 Sep 2012 12:32:59 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1BF11E809A for ; Tue, 4 Sep 2012 12:32:59 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUEZXarj0xKBceqY8CzoLa5xVCMPwLD3z@postini.com; Tue, 04 Sep 2012 12:32:59 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0ECED1B8325 for ; Tue, 4 Sep 2012 12:32:58 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 03E4A19005C; Tue, 4 Sep 2012 12:32:58 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Tue, 4 Sep 2012 12:32:59 -0700 From: Ted Lemon To: =?Windows-1252?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Thread-Index: AQHNiseG0gBB4UDEXUCV9TC7KIiRUpd7B/YA Date: Tue, 4 Sep 2012 19:32:57 +0000 Message-ID: <6069AF94-1587-496D-BE15-5A9B6892E9F6@nominum.com> References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> <0CFEF31D-4A01-42A7-89B7-69BDBB41E9C8@employees.org> In-Reply-To: <0CFEF31D-4A01-42A7-89B7-69BDBB41E9C8@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <221F6A452373A74DB2A39DEF6A2D5E1E@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 19:33:00 -0000 On Sep 4, 2012, at 2:02 PM, Ole Tr=F8an wrote: > I look at it differently. you are adding more complexity on functions tha= t are not in the data path. in my book that isn't fate sharing. How is this not on the data path? > we did try with the use of the RAAN option. Right, but this wasn't useful because it added no functionality=97the only = purpose it served was to avoid having the relay agent look in the client pa= rt of the DHCP packet. I never understood why you guys wanted this. If = you think the work is important, I am certainly not opposed to reviving it,= though=97it was a perfectly good draft. > this is like saying that configuring OSPF on a router is a unsolved probl= em, just because it isn't done with DHCP. ;-) No, if OSPF is how these routers are being configured, that's not what I th= ink of as static configuration. Is that in fact the case? It's my under= standing that there is no clean dynamic configuration mechanism that ties b= ack to the address allocation system (that is, to DHCP).=20 It seems to me that what we are talking about here is exactly analogous to = what's done today in IPv4 with DHCP snooping and DHCP leasequery, both of w= hich seem to be good solutions that are widely deployed and work well for n= etwork providers. If there's a better way, I'm all ears, but when I asked= in the routing area, I got some pretty vague answers that sounded a lot li= ke "it's configured statically." From rdroms.ietf@gmail.com Tue Sep 4 13:12:31 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FAA21E8084 for ; Tue, 4 Sep 2012 13:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8-LBvr18LmJ for ; Tue, 4 Sep 2012 13:12:30 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC60521E8082 for ; Tue, 4 Sep 2012 13:12:30 -0700 (PDT) Received: by yenm5 with SMTP id m5so1462819yen.31 for ; Tue, 04 Sep 2012 13:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=kFwDdp+vjAZQyk1Hlz0BUq8McR+vAlGScKweo7VtXqY=; b=UjoKKo3sRRYKRQvsjsK1vijl3WsqC6i8VdI67wNctEanyZ2txO3lJYl5Rz5MuX/XoT 8uO33/H6LWOttTviYSTsfJlhcRVybr+HmWrK7aUCuPIbdEOSamgE6ggfLKRHu9r5nm9U MJO4f3b7nK1GOGPkV8y2gmd5e9WOklyTS9XamBbh8AcB9DkSupu0xRb8jvQ/wYeLQ7z8 ayvtCLqe5bBW96qc0Q/h+i7i76Qx/MrzSwoDbGOBd0F8HqtuIV2t94rdz8poVkd201Ze p5pr2DggXJelVA5OdwFhBzL4zjzxK4fyQYIKu7aa6qH8tdNJYgCi31FOjvgeRPC8j3hj dBbg== Received: by 10.236.115.102 with SMTP id d66mr19461056yhh.67.1346789550191; Tue, 04 Sep 2012 13:12:30 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id v5sm15977336anj.16.2012.09.04.13.12.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 13:12:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Ralph Droms In-Reply-To: <6069AF94-1587-496D-BE15-5A9B6892E9F6@nominum.com> Date: Tue, 4 Sep 2012 16:12:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> <0CFEF31D-4A01-42A7-89B7-69BDBB41E9C8@employees.org> <6069AF94-1587-496D-BE15-5A9B6892E9F6@nominum.com> To: Lemon Ted , =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1278) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 20:12:31 -0000 On Sep 4, 2012, at 3:32 PM 9/4/12, Ted Lemon wrote: > On Sep 4, 2012, at 2:02 PM, Ole Tr=F8an > wrote: >> I look at it differently. you are adding more complexity on functions = that are not in the data path. in my book that isn't fate sharing. >=20 > How is this not on the data path? >=20 >> we did try with the use of the RAAN option. >=20 > Right, but this wasn't useful because it added no functionality=97the = only purpose it served was to avoid having the relay agent look in the = client part of the DHCP packet. I never understood why you guys wanted = this. If you think the work is important, I am certainly not opposed = to reviving it, though=97it was a perfectly good draft. >=20 >> this is like saying that configuring OSPF on a router is a unsolved = problem, just because it isn't done with DHCP. ;-) >=20 > No, if OSPF is how these routers are being configured, that's not what = I think of as static configuration. Is that in fact the case? It's = my understanding that there is no clean dynamic configuration mechanism = that ties back to the address allocation system (that is, to DHCP).=20 >=20 > It seems to me that what we are talking about here is exactly = analogous to what's done today in IPv4 with DHCP snooping and DHCP = leasequery, both of which seem to be good solutions that are widely = deployed and work well for network providers. If there's a better way, = I'm all ears, but when I asked in the routing area, I got some pretty = vague answers that sounded a lot like "it's configured statically." One issue that comes to mind for me is that the DHCPv6 server may not, = in fact, have complete information about the routing and prefix = aggregation information. The DHCPv6 server would be inferring = aggregation information from the pools of prefixes it has to delegate. = Looked at another way, there is likely an oracle of network = configuration somewhere from which the delegated prefix pools and prefix = aggregation for routing is derived. The DHCPv6 server might be able to = make an educated guess but it doesn't have necessarily authoritative = information. Another issue with piggybacking is that the routing information may = change independent of any specific DHCPv6 message exchanges (someone = else raised this issue), so that there would be noway to send updates if = there was no DHCPv6 traffic to send through the router. Why would this aggregation information not be provided through whatever = configuration mechanism is used to manage the router? - Ralph >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Tue Sep 4 13:23:42 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8683421E8043 for ; Tue, 4 Sep 2012 13:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.448 X-Spam-Level: X-Spam-Status: No, score=-106.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lz+USejM-yGD for ; Tue, 4 Sep 2012 13:23:41 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE2A21E803F for ; Tue, 4 Sep 2012 13:23:41 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUEZjTIlPzQKxUN4z2pRzUml/RVmTT3Hk@postini.com; Tue, 04 Sep 2012 13:23:41 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AF6011B8314 for ; Tue, 4 Sep 2012 13:23:19 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A0DC319005C; Tue, 4 Sep 2012 13:23:19 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Tue, 4 Sep 2012 13:23:21 -0700 From: Ted Lemon To: Ralph Droms Thread-Topic: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Thread-Index: AQHNiseG0gBB4UDEXUCV9TC7KIiRUpd7B/YAgAALBQCAAAMLAA== Date: Tue, 4 Sep 2012 20:23:18 +0000 Message-ID: <673BFDC7-AEC2-4944-BECA-828F9DC06206@nominum.com> References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> <0CFEF31D-4A01-42A7-89B7-69BDBB41E9C8@employees.org> <6069AF94-1587-496D-BE15-5A9B6892E9F6@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_673BFDC7AEC24944BECA828F9DC06206nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 20:23:42 -0000 --_000_673BFDC7AEC24944BECA828F9DC06206nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Sep 4, 2012, at 4:12 PM, Ralph Droms > wrote: One issue that comes to mind for me is that the DHCPv6 server may not, in f= act, have complete information about the routing and prefix aggregation inf= ormation. The DHCPv6 server would be inferring aggregation information fro= m the pools of prefixes it has to delegate. Looked at another way, there i= s likely an oracle of network configuration somewhere from which the delega= ted prefix pools and prefix aggregation for routing is derived. The DHCPv6= server might be able to make an educated guess but it doesn't have necessa= rily authoritative information. I don't think you'd want to configure this option if you didn't think the D= HCP server had accurate information about the network configuration. Another issue with piggybacking is that the routing information may change = independent of any specific DHCPv6 message exchanges (someone else raised t= his issue), so that there would be noway to send updates if there was no DH= CPv6 traffic to send through the router. Can you describe an actual use case where this would happen? It seems to = me that in a situation like the one you describe, you'd have chaos and wrec= kage, because all the CPE devices would still be configured with prefixes t= hat were no longer valid. Why would this aggregation information not be provided through whatever con= figuration mechanism is used to manage the router? Because it might change dynamically whereas the rest of the router configur= ation is static? --_000_673BFDC7AEC24944BECA828F9DC06206nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8EC253D93098DA42B8856FBFB1B5F32D@nominum.com> Content-Transfer-Encoding: quoted-printable
On Sep 4, 2012, at 4:12 PM, Ralph Droms <rdroms.ietf@gmail.com>
 wrote:
One issue that comes to mind for me is that the DHCPv6 server may not, in fact= , have complete information about the routing and prefix aggregation inform= ation.  The DHCPv6 server would be inferring aggregation information f= rom the pools of prefixes it has to delegate.  Looked at another way, there is likely an oracle of network configur= ation somewhere from which the delegated prefix pools and prefix aggregatio= n for routing is derived.  The DHCPv6 server might be able to make an = educated guess but it doesn't have necessarily authoritative information.

I don't think you'd want to configure this option if you didn't think the D= HCP server had accurate information about the network configuration.

Another issue with piggybacking is that the routing information may change indepen= dent of any specific DHCPv6 message exchanges (someone else raised this iss= ue), so that there would be noway to send updates if there was no DHCPv6 tr= affic to send through the router.

Can you describe an actual use case where this would happen?   It seem= s to me that in a situation like the one you describe, you'd have chaos and= wreckage, because all the CPE devices would still be configured with prefi= xes that were no longer valid.

Why would this aggregation information not be provided through whatever config= uration mechanism is used to manage the router?

Because it might change dynamically whereas the rest of the router con= figuration is static?

--_000_673BFDC7AEC24944BECA828F9DC06206nominumcom_-- From leaf.y.yeh@huawei.com Tue Sep 4 20:16:59 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926D411E808D for ; Tue, 4 Sep 2012 20:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfwuHWxyvTbS for ; Tue, 4 Sep 2012 20:16:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2B39E21F8643 for ; Tue, 4 Sep 2012 20:16:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKJ01269; Wed, 05 Sep 2012 03:16:55 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Sep 2012 04:16:09 +0100 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Sep 2012 04:16:54 +0100 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.119]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Wed, 5 Sep 2012 11:16:51 +0800 From: Leaf yeh To: Ralph Droms , Lemon Ted , =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Thread-Index: AQHNitmm4tBGx+Xg5U+Msj0pdVOFp5d7ANNg Date: Wed, 5 Sep 2012 03:16:51 +0000 Message-ID: References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> <0CFEF31D-4A01-42A7-89B7-69BDBB41E9C8@employees.org> <6069AF94-1587-496D-BE15-5A9B6892E9F6@nominum.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 03:16:59 -0000 Ralph - One issue that comes to mind for me is that the DHCPv6 server may n= ot, in fact, have complete information about the routing and prefix aggrega= tion information. The DHCPv6 server would be inferring aggregation informa= tion from the pools of prefixes it has to delegate. Looked at another way,= there is likely an oracle of network configuration somewhere from which th= e delegated prefix pools and prefix aggregation for routing is derived. Th= e DHCPv6 server might be able to make an educated guess but it doesn't have= necessarily authoritative information. General Idea Clarification on the draft (OPTION_PREFIX_POOL): If we are on= ly thinking about the delegated prefix to customer and its pre-configured p= refix pool on the DHCPv6 server (or DR), the server does know all the lease= of the delegated prefix, then can definitely derive the status ('Active' o= r 'Released') of the prefix pool. There is no 'educated guess' here. Becaus= e the server acts as the manager (or administrator) of all the pools, he au= thorize (or delegate) the prefix to the customer, and know all the informat= ion (or aspects) of the delegated prefixes. Ralph - Another issue with piggybacking is that the routing information may= change independent of any specific DHCPv6 message exchanges (someone else = raised this issue), so that there would be no way to send updates if there = was no DHCPv6 traffic to send through the router. General Idea Clarification on the draft (OPTION_PREFIX_POOL): The draft cr= eates somewhat of new reasonable function on the server to support the poli= cy change (for route aggregation based on the information of the prefix poo= ls), the basic proposal in the draft is to utilize the process of 'Prefix D= elegation Reconfiguration' to trigger the immediately update. See Section 6= of the draft. Ralph - Why would this aggregation information not be provided through what= ever configuration mechanism is used to manage the router? General Idea Clarification on the draft (OPTION_PREFIX_POOL): DHCPv6-PD wo= rks closely with the prefix pools, (which always mean the necessary aggrega= tion route in Ole's static configuration,) it could be the simplest way to = do the dynamic parameter provisioning to PE router. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of R= alph Droms Sent: Wednesday, September 05, 2012 4:12 AM To: Lemon Ted; Ole Tr=F8an Cc: dhcwg@ietf.org WG Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-op= t-08 On Sep 4, 2012, at 3:32 PM 9/4/12, Ted Lemon wrote: > On Sep 4, 2012, at 2:02 PM, Ole Tr=F8an > wrote: >> I look at it differently. you are adding more complexity on functions th= at are not in the data path. in my book that isn't fate sharing. >=20 > How is this not on the data path? >=20 >> we did try with the use of the RAAN option. >=20 > Right, but this wasn't useful because it added no functionality-the only = purpose it served was to avoid having the relay agent look in the client pa= rt of the DHCP packet. I never understood why you guys wanted this. If = you think the work is important, I am certainly not opposed to reviving it,= though-it was a perfectly good draft. >=20 >> this is like saying that configuring OSPF on a router is a unsolved prob= lem, just because it isn't done with DHCP. ;-) >=20 > No, if OSPF is how these routers are being configured, that's not what I = think of as static configuration. Is that in fact the case? It's my und= erstanding that there is no clean dynamic configuration mechanism that ties= back to the address allocation system (that is, to DHCP).=20 >=20 > It seems to me that what we are talking about here is exactly analogous t= o what's done today in IPv4 with DHCP snooping and DHCP leasequery, both of= which seem to be good solutions that are widely deployed and work well for= network providers. If there's a better way, I'm all ears, but when I ask= ed in the routing area, I got some pretty vague answers that sounded a lot = like "it's configured statically." One issue that comes to mind for me is that the DHCPv6 server may not, in f= act, have complete information about the routing and prefix aggregation inf= ormation. The DHCPv6 server would be inferring aggregation information fro= m the pools of prefixes it has to delegate. Looked at another way, there i= s likely an oracle of network configuration somewhere from which the delega= ted prefix pools and prefix aggregation for routing is derived. The DHCPv6= server might be able to make an educated guess but it doesn't have necessa= rily authoritative information. Another issue with piggybacking is that the routing information may change = independent of any specific DHCPv6 message exchanges (someone else raised t= his issue), so that there would be noway to send updates if there was no DH= CPv6 traffic to send through the router. Why would this aggregation information not be provided through whatever con= figuration mechanism is used to manage the router? - Ralph >=20 > _______________________________________________ > 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 zhou.sujing@zte.com.cn Tue Sep 4 20:36:12 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7A211E80D3; Tue, 4 Sep 2012 20:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.526 X-Spam-Level: X-Spam-Status: No, score=-98.526 tagged_above=-999 required=5 tests=[AWL=3.772, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrEey8Dt2f1c; Tue, 4 Sep 2012 20:36:11 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE6911E80BA; Tue, 4 Sep 2012 20:36:10 -0700 (PDT) Received: from [192.168.168.119] by mx5.zte.com.cn with surfront esmtp id 10723543655668; Wed, 5 Sep 2012 11:18:39 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 40EA972CDF5; Wed, 5 Sep 2012 11:32:03 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q853a0GO071709; Wed, 5 Sep 2012 11:36:00 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: =?ISO-8859-1?Q?Ole_Tr=F8an?= MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Wed, 5 Sep 2012 11:35:53 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-09-05 11:35:57, Serialize complete at 2012-09-05 11:35:57 Content-Type: multipart/alternative; boundary="=_alternative 0013D6B548257A70_=" X-MAIL: mse02.zte.com.cn q853a0GO071709 Cc: dhcwg@ietf.org, dhcwg-bounces@ietf.org Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 03:36:12 -0000 This is a multipart message in MIME format. --=_alternative 0013D6B548257A70_= Content-Type: text/plain; charset="US-ASCII" But the prefix pool transfer between DHCP server and DHCP Relay also needs to be authenticated. > > >> does this work with DHCPv6 authentication? > > It doesn't affect it at all. Servers that auhenticate their responses > > are signing REPLY message that is in turn encapsulated in RELAY-REPL. > > THe prefix-pool option is insterted in RELAY-REPL and the REPLY inside > > is never modified. prefix-pool never reaches the client. If that is was > > your impression after reading the draft, perhaps it should be clarified > > in the text? > > ah, I see. I must have missed that in the text. I see there is a MAY in 3315. > > cheers, > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --=_alternative 0013D6B548257A70_= Content-Type: text/html; charset="US-ASCII"
But the prefix pool transfer between DHCP server and DHCP Relay also  needs to be authenticated.

>
> >> does this work with DHCPv6 authentication?
> > It doesn't affect it at all. Servers that auhenticate their responses
> > are signing REPLY message that is in turn encapsulated in RELAY-REPL.
> > THe prefix-pool option is insterted in RELAY-REPL and the REPLY inside
> > is never modified. prefix-pool never reaches the client. If that is was
> > your impression after reading the draft, perhaps it should be clarified
> > in the text?
>
> ah, I see. I must have missed that in the text. I see there is a MAY in 3315.
>
> cheers,
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
 --=_alternative 0013D6B548257A70_=-- From leaf.y.yeh@huawei.com Tue Sep 4 21:15:19 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBCD11E80DE for ; Tue, 4 Sep 2012 21:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVzD1p02UIxP for ; Tue, 4 Sep 2012 21:15:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DBC8C21F85A8 for ; Tue, 4 Sep 2012 21:15:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJI95735; Wed, 05 Sep 2012 04:15:15 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Sep 2012 05:14:26 +0100 Received: from SZXEML435-HUB.china.huawei.com (10.72.61.63) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Sep 2012 05:15:05 +0100 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.119]) by szxeml435-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 5 Sep 2012 12:14:59 +0800 From: Leaf yeh To: =?iso-8859-1?Q?Ole_Tr=F8an?= , Ted Lemon Thread-Topic: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Thread-Index: AQHNiseVdGeCAF4wLUKyAUMjVYzV7Zd7FGcA Date: Wed, 5 Sep 2012 04:14:59 +0000 Message-ID: References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> <0CFEF31D-4A01-42A7-89B7-69BDBB41E9C8@employees.org> In-Reply-To: <0CFEF31D-4A01-42A7-89B7-69BDBB41E9C8@employees.org> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org" , Ralph Droms Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 04:15:19 -0000 Ole - we did try with the use of the RAAN option. General Idea Clarification on the draft (OPTION_PREFIX_POOL): The draft ad= opts roughly the same design idea as that of OPTION_RAAN, no new DHCPv6 mes= sage here. Ole - this is like saying that configuring OSPF on a router is a unsolved p= roblem, just because it isn't done with DHCP. ;-) The explanation from Ted about the routing aspect is thorough. We all know = discussion on OSPF is not in the scope of this draft. General Idea Clarification on the draft (OPTION_PREFIX_POOL): The draft pr= oposed the PE router to add (or withdraw) one more route (called as the agg= regation route) per OPTION_PREFIX_POOL. The routing protocol (such as OSFP,= ISIS) enabled on the network-facing interface of the PE router helps to ad= vertise this additional route to the ISP core network. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of O= le Tr?an Sent: Wednesday, September 05, 2012 2:03 AM To: Ted Lemon Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-op= t-08 >> fate sharing of what? the client functions independently of whatever agg= regate route there is for a whole block of subscribers. this just adds anot= her cog in the machinery that may fail. >=20 > Fate sharing in the sense that the DHCP server is best able to know from = what aggregate prefix prefixes for clients on a particular router will be a= llocated, and the DHCP packet is the way these prefixes get allocated to th= e client. So we can be sure that if the network is working at all, it wil= l be working completely. I look at it differently. you are adding more complexity on functions that = are not in the data path. in my book that isn't fate sharing. >> this does not solve the DHCPv6 PD problem of route injection. a route ne= eds to be installed per client, and snooping is still needed for that. this= proposal _only_ solves the problem of installing an aggregate route for mu= ltiple PD RRs into a PE/relay. this is most typically done with static conf= iguration today. >=20 > It solves half the problem: configuring the route that the router adverti= ses. You are correct that it doesn't solve the other half-figuring out wh= ere to send packets downstream. But actually, snooping the DHCP packet is= a perfectly good solution for this problem; what is lacking is a standard = that says how it's done.=20 we did try with the use of the RAAN option. > What snooping is _not_ good for is figuring out what route to advertise u= pstream. To say that the upstream route is currently done with static con= figuration is synonymous with saying that the problem is currently unsolved= . this is like saying that configuring OSPF on a router is a unsolved problem= , just because it isn't done with DHCP. ;-) cheers, Ole From mohamed.boucadair@orange.com Tue Sep 4 22:42:37 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A714321F850C for ; Tue, 4 Sep 2012 22:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FwJPXmS9mnt for ; Tue, 4 Sep 2012 22:42:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 915FE21F853A for ; Tue, 4 Sep 2012 22:42:36 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id CEDFA264823; Wed, 5 Sep 2012 07:42:31 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id B47934C0F8; Wed, 5 Sep 2012 07:42:31 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 5 Sep 2012 07:42:31 +0200 From: To: Ted Lemon , "dhcwg@ietf.org WG" Date: Wed, 5 Sep 2012 07:42:29 +0200 Thread-Topic: Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Thread-Index: AQHNgg2f2GWemYRp/0G7NT9hbKcz65d7TL4Q Message-ID: <94C682931C08B048B7A8645303FDC9F36E57B07F24@PUEXCB1B.nanterre.francetelecom.fr> References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> In-Reply-To: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.5.23317 Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 05:42:37 -0000 Dear Chairs, all, I support the adoption of this draft as it allows to: * Avoid misbehaving routers which inject a large number of individual prefi= xes instead of aggregating them. The behaviour of the edge router supportin= g this mechanism is deterministic and it does not depend on a specific impl= ementation. Network operators may decide to inject an aggregate even if all= individual prefixes are not assigned to connected nodes.=20 * Control the prefixes to be injected in routing without requiring a dedica= ted configuration interface no a new DHCP message.=20 * Retrieve the set of routes injected by the router embedding the relay age= nt. Cheers, Med PS: I'm also co-author of the draft. =20 >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De=20 >la part de Ted Lemon >Envoy=E9 : vendredi 24 ao=FBt 2012 17:32 >=C0 : dhcwg@ietf.org WG >Objet : [dhcwg] Call for Adoption:=20 >draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 > >The authors have proposed that the working group adopt the=20 >prefix pool option draft as a working group item. We have=20 >engaged in some correspondence with participants in the=20 >Routing Area, and while some helpful advice was given, no=20 >objections were raised to going forward with the work, and=20 >it's a DHCP protocol extension, so it makes sense for it to=20 >happen in the DHC working group. > >The document proposes an extension to the DHCP protocol that=20 >allows the DHCP server to communicate prefixes to the provider=20 >edge router when doing prefix delegation, such that this=20 >router can advertise a route to an aggregate prefix, rather=20 >than to many individual prefixes, and so that this router does=20 >not have to perform ad-hoc prefix aggregation, which may=20 >produce less optimal results. > >If you think this work should be adopted by the working group,=20 >please reply to this message saying so. If you think this=20 >work should not be adopted by the working group, please reply=20 >to this message saying so. We will evaluate consensus on September 7. > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg >= From Carl.Wuyts@technicolor.com Tue Sep 4 23:50:24 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AAD21F8501 for ; Tue, 4 Sep 2012 23:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.929 X-Spam-Level: X-Spam-Status: No, score=-5.929 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+dovP24gTmB for ; Tue, 4 Sep 2012 23:50:21 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aob106.obsmtp.com [74.125.149.76]) by ietfa.amsl.com (Postfix) with ESMTP id B71D721F8514 for ; Tue, 4 Sep 2012 23:50:19 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKUEb2KfLtQU6LZ2ACoQeKrtJHVNny9oAX@postini.com; Tue, 04 Sep 2012 23:50:21 PDT Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.264.0; Wed, 5 Sep 2012 08:50:06 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.14]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Wed, 5 Sep 2012 08:50:15 +0200 From: Wuyts Carl To: "Bernie Volz (volz)" , =?iso-8859-1?Q?Ole_Tr=F8an?= , Ted Lemon Date: Wed, 5 Sep 2012 08:50:13 +0200 Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 -- multiple adminstrative domains Thread-Index: Ac1+2qSXxInmBkiATQCmRLl22d35BgMVxw0g Message-ID: <867F4B6A1672E541A94676D556793ACD16E4E37464@MOPESMBX01.eu.thmulti.com> References: <489D13FBFA9B3E41812EA89F188F018E0F4EE2F8@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F4EE2F8@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD16E4E37464MOPESMBX01eut_" MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 -- multiple adminstrative domains X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 06:50:24 -0000 --_000_867F4B6A1672E541A94676D556793ACD16E4E37464MOPESMBX01eut_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think, as CPE vendor, there's no other possibility then to vote AGAINST t= his proposal. I read: "" Clients may select one or several administrative domains; If multiple, each= is a separate state machine "" In some other discussion some time ago, there was already some proposal on = having multiple/separate state machine for dhcpv6 client. In this proposal= , I see the same thing popping up, but in another context. For CPE devices, this is really a no-go. Apart from splitting up state mac= hine (and as such, multiplying memory consumption with factor X), it'll als= o inject extra complexity. The CPE, the low-end, nearly free-of-charge, de= vice again seems to be victim of these kind of proposal!! I don't know if some other CPE vendor people are subscribed to this WG, but= I'd like to read how they feel about this... Regs Carl From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: maandag 20 augustus 2012 15:50 To: Ole Tr=F8an; Ted Lemon Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 -- mult= iple adminstrative domains In the slides I presented at IETF-83 (Paris) and IETF-84 (Vancouver) about = this work, the last slide had: Multiple Administrative Domains =B7 Still planning to write new Internet-Draft on multiple administ= rative domains =B7 Basic proposal will be for Advertise to include "Administrative= Domain" option which contains an "administrative domain string" =B7 Clients treat Advertises with the same administrative domain st= ring as 'equal' =B7 Clients may select one or several administrative domains; If mu= ltiple, each is a separate state machine The basic idea here is that if a client sends a Solicit with IA_NA and IA_P= D, one server (or set of servers) may respond with IA_NA information and ad= ministrative domain string A and another server (or set of servers) may res= pond with IA_PD and administrative domain string B. This would trigger the = client to initiate two separate state machines. Of course, there is also the possibility that other server(s) may respond w= ith both the IA_NA and IA_PD and administrative domain string C. In which c= ase the client now has to determine whether to use one state machine (and a= dministrative domain C) or two state machines and administrative domain A (= IA_NA) & B (IA_PD). While fairly simple in concept (and for servers [include administrative dom= ain option] and relays [no impact]), it does greatly complicate clients. One idea would be for clients to implement something similar to what they d= o for WiFi and SSIDs - a user would be required to select which administrat= ive domains are valid. One interesting twist here is that just like with Wi= FI, we could also secure this -- add an encryption option which would provi= de a way to secure the DHCP server(s) with which you are willing to communi= cate. I haven't started work on this draft as it wasn't clear how much interest t= here is and if there are real world requirements for something like this. I= f there is sufficient interest, I would be happy to start work on it. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-b= ounces@ietf.org] On Behalf Of Ole Tr=F8an Sent: Monday, August 20, 2012 8:45 AM To: Ted Lemon Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Ted, >> could we go forward with this draft that clarifies how multiple stateful= options work in a single session, and with the general assumption that a c= lient will choose one DHCP server and that server is authoritative? > > My concern is that if you do so, it will essentially result in clients st= andardizing on whatever behavior you specify, and so whether we write anoth= er standard or not, it will not be available in practice. to turn the question around. is there anyone who thinks that we should _not_ make multiple stateful opti= ons work in a single DHCP session? cheers, Ole --_000_867F4B6A1672E541A94676D556793ACD16E4E37464MOPESMBX01eut_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I think, = as CPE vendor, there’s no other possibility then to vote AGAINST this= proposal.

 

I read:

“”
Clients may select one or several = administrative domains; If multiple, each is a separate state machine

= 220;”

 

In some other discussion some tim= e ago, there was already some proposal on having multiple/separate state ma= chine for dhcpv6 client.=A0 In this proposal, I see the same thing popping = up, but in another context.

For CPE devices, this is really a no-go.=A0 Apart from splitting up state= machine (and as such, multiplying memory consumption with factor X), it= 217;ll also inject extra complexity.=A0 The CPE, the low-end, nearly free-o= f-charge, device again seems to be victim of these kind of proposal!!<= /o:p>

 

I don’t know if some other CPE vendor people= are subscribed to this WG, but I’d like to read how they feel about = this…

 

Regs

Carl

=  

 

 

 

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Be= half Of Bernie Volz (volz)
Sent: maandag 20 augustus 2012 15:= 50
To: Ole Tr=F8an; Ted Lemon
Cc: dhc WG
Subject:= Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 -- multiple= adminstrative domains

 

In the slides I presented at IETF= -83 (Paris) and IETF-84 (Vancouver) about this work, the last slide had:

 

Multiple Administrative Domains

=

=B7         S= till planning to write new Internet-Draft on multiple administrative domain= s

=B7         <= /span>Basic proposal will be for Advertise to include “Admi= nistrative Domain” option which contains an “administrative dom= ain string”

=B7       = ;  Clients treat Advertises with the same admi= nistrative domain string as ‘equal’

=B7  = ;       Clients may s= elect one or several administrative domains; If multiple, each is a separat= e state machine

 <= /span>

The basic idea here is that if a client = sends a Solicit with IA_NA and IA_PD, one server (or set of servers) may re= spond with IA_NA information and administrative domain string A and another= server (or set of servers) may respond with IA_PD and administrative domai= n string B. This would trigger the client to initiate two separate state ma= chines.

 

Of course, there is also the possibility th= at other server(s) may respond with both the IA_NA and IA_PD and administra= tive domain string C. In which case the client now has to determine whether= to use one state machine (and administrative domain C) or two state machin= es and administrative domain A (IA_NA) & B (IA_PD).

 

While fairly simple in concept (and for servers [include administrati= ve domain option] and relays [no impact]), it does greatly complicate clien= ts.

 <= /p>

One idea would be for clients to implement some= thing similar to what they do for WiFi and SSIDs - a user would be required= to select which administrative domains are valid. One interesting twist he= re is that just like with WiFI, we could also secure this -- add an encrypt= ion option which would provide a way to secure the DHCP server(s) with whic= h you are willing to communicate.

 

 

I haven't started work on this draft a= s it wasn't clear how much interest there is and if there are real world re= quirements for something like this. If there is sufficient interest, I woul= d be happy to start work on it.

 

- Bernie

 

-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ole Tr=F8anSent: Monday, August 20, 2012 8:45 AM
To: Ted Lemon
Cc: dhc WG
Su= bject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

 

Ted,

 

>> could we go forward wi= th this draft that clarifies how multiple stateful options work in a single= session, and with the general assumption that a client will choose one DHC= P server and that server is authoritative?

=

>

> My c= oncern is that if you do so, it will essentially result in clients standard= izing on whatever behavior you specify, and so whether we write another sta= ndard or not, it will not be available in practice.

 

to turn the question around.

is there anyone who thinks that we should _not_ make multiple stateful opt= ions work in a single DHCP session?

 

cheers,

Ole

=

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'> 

= --_000_867F4B6A1672E541A94676D556793ACD16E4E37464MOPESMBX01eut_-- From ichiroumakino@gmail.com Wed Sep 5 00:48:29 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAB521F8540 for ; Wed, 5 Sep 2012 00:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UGYgdc2QuNy for ; Wed, 5 Sep 2012 00:48:28 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCED21F84AE for ; Wed, 5 Sep 2012 00:48:28 -0700 (PDT) Received: by eaai11 with SMTP id i11so66774eaa.31 for ; Wed, 05 Sep 2012 00:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=wlmQjpGvZMbEGXYP7W66p01vyrvhMX7BseanIwqE46A=; b=rTSELM7XnFSKPK+RW/qM4FN7O/CvT4vZXcupkWB0L45Xw5Ck7j4y+Ihu6DY70DiiDF i1vAvxNztvwx/kDOFkGFaPcrs84oRuTyQWKL9f4IiBAnxCSOizD9oydnDUV1wS4BH3t7 Jkbm7hhisTp+dWPBiuwIRj81GCr3eNud0+jBH/gNWMeayjxC6sKh9tiaiVEzWrdsDDb6 z4OgKSAKAFx2Qjby2Nk0o+FN7+H7QABnz8n8ZyFz/RYPVGgQQk3qxzgjnlvYSExT74zf 0QtRZTx38xJbgP0xM4BXv8Yn6HvrD7jbm0YkffHWIWJXrHkGCzL0HSUDG31gOoidfiJX ESsQ== Received: by 10.14.203.73 with SMTP id e49mr29422197eeo.27.1346831307187; Wed, 05 Sep 2012 00:48:27 -0700 (PDT) Received: from ?IPv6:2001:420:44ff:fd17:ec30:b128:b467:6482? ([2001:420:44ff:fd17:ec30:b128:b467:6482]) by mx.google.com with ESMTPS id 45sm1871009eeb.8.2012.09.05.00.48.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Sep 2012 00:48:25 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_646D753D-C658-4D1D-8509-90E8907EBF78"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <867F4B6A1672E541A94676D556793ACD16E4E37464@MOPESMBX01.eu.thmulti.com> Date: Wed, 5 Sep 2012 09:48:18 +0200 Message-Id: <74EF5E8B-CE4E-40AD-885E-8EB80729D9D5@employees.org> References: <489D13FBFA9B3E41812EA89F188F018E0F4EE2F8@xmb-rcd-x04.cisco.com> <867F4B6A1672E541A94676D556793ACD16E4E37464@MOPESMBX01.eu.thmulti.com> To: Wuyts Carl X-Mailer: Apple Mail (2.1278) Cc: dhc WG , "Bernie Volz \(volz\)" , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 -- multiple adminstrative domains X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:48:29 -0000 --Apple-Mail=_646D753D-C658-4D1D-8509-90E8907EBF78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Carl, this document assumes a single administrative domain and that multiple = administrative domains are _out of scope_. isn't that in agreement with what you are saying too? cheers, Ole > I think, as CPE vendor, there=92s no other possibility then to vote = AGAINST this proposal. > =20 > I read: > =93=94 > Clients may select one or several administrative domains; If multiple, = each is a separate state machine > =93=94 > =20 > In some other discussion some time ago, there was already some = proposal on having multiple/separate state machine for dhcpv6 client. = In this proposal, I see the same thing popping up, but in another = context. > For CPE devices, this is really a no-go. Apart from splitting up = state machine (and as such, multiplying memory consumption with factor = X), it=92ll also inject extra complexity. The CPE, the low-end, nearly = free-of-charge, device again seems to be victim of these kind of = proposal!! > =20 > I don=92t know if some other CPE vendor people are subscribed to this = WG, but I=92d like to read how they feel about this=85 > =20 > Regs > Carl > =20 > =20 > =20 > =20 > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Bernie Volz (volz) > Sent: maandag 20 augustus 2012 15:50 > To: Ole Tr=F8an; Ted Lemon > Cc: dhc WG > Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 -- = multiple adminstrative domains > =20 > In the slides I presented at IETF-83 (Paris) and IETF-84 (Vancouver) = about this work, the last slide had: > =20 > Multiple Administrative Domains > =B7 Still planning to write new Internet-Draft on multiple = administrative domains > =B7 Basic proposal will be for Advertise to include = =93Administrative Domain=94 option which contains an =93administrative = domain string=94 > =B7 Clients treat Advertises with the same administrative = domain string as =91equal=92 > =B7 Clients may select one or several administrative domains; = If multiple, each is a separate state machine > =20 > The basic idea here is that if a client sends a Solicit with IA_NA and = IA_PD, one server (or set of servers) may respond with IA_NA information = and administrative domain string A and another server (or set of = servers) may respond with IA_PD and administrative domain string B. This = would trigger the client to initiate two separate state machines. > =20 > Of course, there is also the possibility that other server(s) may = respond with both the IA_NA and IA_PD and administrative domain string = C. In which case the client now has to determine whether to use one = state machine (and administrative domain C) or two state machines and = administrative domain A (IA_NA) & B (IA_PD). > =20 > While fairly simple in concept (and for servers [include = administrative domain option] and relays [no impact]), it does greatly = complicate clients. > =20 > One idea would be for clients to implement something similar to what = they do for WiFi and SSIDs - a user would be required to select which = administrative domains are valid. One interesting twist here is that = just like with WiFI, we could also secure this -- add an encryption = option which would provide a way to secure the DHCP server(s) with which = you are willing to communicate. > =20 > =20 > I haven't started work on this draft as it wasn't clear how much = interest there is and if there are real world requirements for something = like this. If there is sufficient interest, I would be happy to start = work on it. > =20 > - Bernie > =20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Ole Tr=F8an > Sent: Monday, August 20, 2012 8:45 AM > To: Ted Lemon > Cc: dhc WG > Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 > =20 > Ted, > =20 > >> could we go forward with this draft that clarifies how multiple = stateful options work in a single session, and with the general = assumption that a client will choose one DHCP server and that server is = authoritative? > > > > My concern is that if you do so, it will essentially result in = clients standardizing on whatever behavior you specify, and so whether = we write another standard or not, it will not be available in practice. > =20 > to turn the question around. > is there anyone who thinks that we should _not_ make multiple stateful = options work in a single DHCP session? > =20 > cheers, > Ole > =20 > =20 --Apple-Mail=_646D753D-C658-4D1D-8509-90E8907EBF78 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwOTA1MDc0ODE5WjAjBgkqhkiG9w0BCQQxFgQUJt236e+NqsYeoKeB 3wdR5RovRjcwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAGa+OF96mssIr52lIwSGE 6us/DgKqi+vQHj3abKODYlDX1VNwnXG9NNuym23kf8wB81hXt8iyOl8CseMUw7xC/ZPnWI1R/qJz OcHYXo+6VsKRjYx8vAXCwBdUbgt8OhutCX3wmQV/MxMnjS64+ssLMXyrIoa3gfrQotMqOyiBXdk9 GrlXM1AkkRPvUexNlm65+tgW3LScXOXt8TUw6iO82/i/LG5JWJyOctgTw3YHc1wOhDftGHiZngHG oH3QvxAHSV8G6Ow2KMqB2bYx0cbkchJ6croo9GcIYqpRJ7uHC6X5p2jFa7WdXo3k4foC80UHB+1R XbWowPOhw5nxzCc67AAAAAAAAA== --Apple-Mail=_646D753D-C658-4D1D-8509-90E8907EBF78-- From Carl.Wuyts@technicolor.com Wed Sep 5 00:57:38 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3994221F84B2 for ; Wed, 5 Sep 2012 00:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.077 X-Spam-Level: X-Spam-Status: No, score=-6.077 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zARoPI1c2Q7X for ; Wed, 5 Sep 2012 00:57:37 -0700 (PDT) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with ESMTP id B64BD21F84CE for ; Wed, 5 Sep 2012 00:57:35 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKUEcF7V9RO7ZVFpPPVJDRHY6iPp7fMnZK@postini.com; Wed, 05 Sep 2012 00:57:37 PDT Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.264.0; Wed, 5 Sep 2012 09:56:05 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.14]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Wed, 5 Sep 2012 09:56:14 +0200 From: Wuyts Carl To: =?iso-8859-1?Q?Ole_Tr=F8an?= Date: Wed, 5 Sep 2012 09:56:14 +0200 Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 -- multiple adminstrative domains Thread-Index: Ac2LOts7rHJfoowdSQC5wEWAnKaOPgAALibQ Message-ID: <867F4B6A1672E541A94676D556793ACD16E4E37496@MOPESMBX01.eu.thmulti.com> References: <489D13FBFA9B3E41812EA89F188F018E0F4EE2F8@xmb-rcd-x04.cisco.com> <867F4B6A1672E541A94676D556793ACD16E4E37464@MOPESMBX01.eu.thmulti.com> <74EF5E8B-CE4E-40AD-885E-8EB80729D9D5@employees.org> In-Reply-To: <74EF5E8B-CE4E-40AD-885E-8EB80729D9D5@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG , "Bernie Volz \(volz\)" , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 -- multiple adminstrative domains X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:57:38 -0000 Hi Ole, "assumes", but what if not ? :-) anyway, if multiple admin domains are out_of_scope, this could be fine. Tx and regs Carl -----Original Message----- From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Tr=F8an Sent: woensdag 5 september 2012 9:48 To: Wuyts Carl Cc: Bernie Volz (volz); Ted Lemon; dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 -- mult= iple adminstrative domains Carl, this document assumes a single administrative domain and that multiple admi= nistrative domains are _out of scope_. isn't that in agreement with what you are saying too? cheers, Ole > I think, as CPE vendor, there's no other possibility then to vote AGAINST= this proposal. > =20 > I read: > "" > Clients may select one or several administrative domains; If multiple, ea= ch is a separate state machine > "" > =20 > In some other discussion some time ago, there was already some proposal o= n having multiple/separate state machine for dhcpv6 client. In this propos= al, I see the same thing popping up, but in another context. > For CPE devices, this is really a no-go. Apart from splitting up state m= achine (and as such, multiplying memory consumption with factor X), it'll a= lso inject extra complexity. The CPE, the low-end, nearly free-of-charge, = device again seems to be victim of these kind of proposal!! > =20 > I don't know if some other CPE vendor people are subscribed to this WG, b= ut I'd like to read how they feel about this. > =20 > Regs > Carl > =20 > =20 > =20 > =20 > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of= Bernie Volz (volz) > Sent: maandag 20 augustus 2012 15:50 > To: Ole Tr=F8an; Ted Lemon > Cc: dhc WG > Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 -- mu= ltiple adminstrative domains > =20 > In the slides I presented at IETF-83 (Paris) and IETF-84 (Vancouver) abou= t this work, the last slide had: > =20 > Multiple Administrative Domains > =B7 Still planning to write new Internet-Draft on multiple admini= strative domains > =B7 Basic proposal will be for Advertise to include "Administrati= ve Domain" option which contains an "administrative domain string" > =B7 Clients treat Advertises with the same administrative domain = string as 'equal' > =B7 Clients may select one or several administrative domains; If = multiple, each is a separate state machine > =20 > The basic idea here is that if a client sends a Solicit with IA_NA and IA= _PD, one server (or set of servers) may respond with IA_NA information and = administrative domain string A and another server (or set of servers) may r= espond with IA_PD and administrative domain string B. This would trigger th= e client to initiate two separate state machines. > =20 > Of course, there is also the possibility that other server(s) may respond= with both the IA_NA and IA_PD and administrative domain string C. In which= case the client now has to determine whether to use one state machine (and= administrative domain C) or two state machines and administrative domain A= (IA_NA) & B (IA_PD). > =20 > While fairly simple in concept (and for servers [include administrative d= omain option] and relays [no impact]), it does greatly complicate clients. > =20 > One idea would be for clients to implement something similar to what they= do for WiFi and SSIDs - a user would be required to select which administr= ative domains are valid. One interesting twist here is that just like with = WiFI, we could also secure this -- add an encryption option which would pro= vide a way to secure the DHCP server(s) with which you are willing to commu= nicate. > =20 > =20 > I haven't started work on this draft as it wasn't clear how much interest= there is and if there are real world requirements for something like this.= If there is sufficient interest, I would be happy to start work on it. > =20 > - Bernie > =20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of= Ole Tr=F8an > Sent: Monday, August 20, 2012 8:45 AM > To: Ted Lemon > Cc: dhc WG > Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 > =20 > Ted, > =20 > >> could we go forward with this draft that clarifies how multiple statef= ul options work in a single session, and with the general assumption that a= client will choose one DHCP server and that server is authoritative? > > > > My concern is that if you do so, it will essentially result in clients = standardizing on whatever behavior you specify, and so whether we write ano= ther standard or not, it will not be available in practice. > =20 > to turn the question around. > is there anyone who thinks that we should _not_ make multiple stateful op= tions work in a single DHCP session? > =20 > cheers, > Ole > =20 > =20 From ichiroumakino@gmail.com Wed Sep 5 01:07:02 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D192C21F8699 for ; Wed, 5 Sep 2012 01:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GRg2dPepkIf for ; Wed, 5 Sep 2012 01:07:02 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id B019E21F8698 for ; Wed, 5 Sep 2012 01:06:49 -0700 (PDT) Received: by eekb45 with SMTP id b45so90218eek.31 for ; Wed, 05 Sep 2012 01:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=kb0cNQWD6H1HpbZ+4Z7vq7rE55epb1QL1dAArZ5D1YM=; b=cOChat3qPPxsu2aCxEPwnSJxB/V6PGIosxZ+Q/CDb9/6h60g7ewjqPnNPRDeORY6+6 BM2rtKHWBO+QwiUhuHlrwUFgmRjtWi78xwtydt5lfL6F8JGxXSdH3uAkd+3GANmoTbiO Pe7ZDQ/KF9QiNEVKZEEi2RfntBJnQoBecdr523qFs/p6Jc652PF4BDDHsWM5xFWyBuAF +v4HxFpn97ujlU8NXZXIxCkNzjwNJXaYwAaClxIgtWecOKv/Om5WDAmVj5QJMrlrPr9Z AIcrPPawCex7CNjq1ZysccC987vzT8rtck+ZbgFy7nTcBN4TbjjknUp6EMxMcHLxiIJw wS9w== Received: by 10.14.215.197 with SMTP id e45mr29341862eep.36.1346832408906; Wed, 05 Sep 2012 01:06:48 -0700 (PDT) Received: from ?IPv6:2001:420:44ff:fd17:ec30:b128:b467:6482? ([2001:420:44ff:fd17:ec30:b128:b467:6482]) by mx.google.com with ESMTPS id v3sm1982379eep.10.2012.09.05.01.06.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Sep 2012 01:06:47 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_A7628528-45D6-45A5-93D9-9521995450FF"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <6069AF94-1587-496D-BE15-5A9B6892E9F6@nominum.com> Date: Wed, 5 Sep 2012 10:06:42 +0200 Message-Id: References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> <0CFEF31D-4A01-42A7-89B7-69BDBB41E9C8@employees.org> <6069AF94-1587-496D-BE15-5A9B6892E9F6@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1278) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 08:07:03 -0000 --Apple-Mail=_A7628528-45D6-45A5-93D9-9521995450FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ted, >> I look at it differently. you are adding more complexity on functions = that are not in the data path. in my book that isn't fate sharing. >=20 > How is this not on the data path? the DHCP server is not on the data path. unless one follows the model = described in 3633 where the DHCP server is on the PE router. [...] >> this is like saying that configuring OSPF on a router is a unsolved = problem, just because it isn't done with DHCP. ;-) >=20 > No, if OSPF is how these routers are being configured, that's not what = I think of as static configuration. Is that in fact the case? It's = my understanding that there is no clean dynamic configuration mechanism = that ties back to the address allocation system (that is, to DHCP).=20 I might be missing something here. I don't understand how the aggregate = route for a set of delegated prefixes is dynamic. when and how could all = subscribers within a aggregate move? > It seems to me that what we are talking about here is exactly = analogous to what's done today in IPv4 with DHCP snooping and DHCP = leasequery, both of which seem to be good solutions that are widely = deployed and work well for network providers. If there's a better way, = I'm all ears, but when I asked in the routing area, I got some pretty = vague answers that sounded a lot like "it's configured statically." hmm, I didn't think the IPv4 aggregate route was deduced or configured = from DHCPv4 either. the deployments I'm aware of, the PE is always = configured outside of DHCP with the IPv4 subnets / aggregate routes. = what's the analogy? cheers, Ole= --Apple-Mail=_A7628528-45D6-45A5-93D9-9521995450FF Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwOTA1MDgwNjQyWjAjBgkqhkiG9w0BCQQxFgQUk/3olcqEx9cw+3Hp ewDkE5YRGbkwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAL36cGakr96PZfegW/8f1 9rMaDpn5gAtiSxnRo+UKwDx+qV6ymC5mhnHnHrcLPz8mgrjN/ic3u7b/TQ7OoyvTgMg7FWd5xdIa NcV0PPBY1q92drUgHdA5tStjmqXLKnIbYjvLUwTylNpGNimcptCbkN7ecjYqtQGnbCFaSdh2iJT+ Or407YVpMMG09HXt5KHb71lx7m3xsrNdk1tYRYAufOH6R7HUYuKAHoQ/NvSrpEENW4vwoJ+FjLFa cGAi7dC2WMmeGPZNEDkApHIh1lSJxrDPIkWhITNN106kU3fFIVQxA4PErJRRF2Ky9XQWC3lX6p1B Kx8aBUKciMNH+baDsAAAAAAAAA== --Apple-Mail=_A7628528-45D6-45A5-93D9-9521995450FF-- From mohamed.boucadair@orange.com Wed Sep 5 05:01:32 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8690A21F8653 for ; Wed, 5 Sep 2012 05:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2UEvGUzUo7P for ; Wed, 5 Sep 2012 05:01:32 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D2F6321F84DA for ; Wed, 5 Sep 2012 05:01:31 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 7B24A3B4807; Wed, 5 Sep 2012 14:01:30 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 6004D27C0D0; Wed, 5 Sep 2012 14:01:30 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 5 Sep 2012 14:01:29 +0200 From: To: "dhcwg@ietf.org WG" Date: Wed, 5 Sep 2012 14:01:29 +0200 Thread-Topic: draft-boucadair-dhc-address-name-encoding Thread-Index: Ac2LXi7xV060/dOBQiKVqql4iypz2A== Message-ID: <94C682931C08B048B7A8645303FDC9F36E57B0812A@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E57B0812APUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.5.103320 Subject: [dhcwg] draft-boucadair-dhc-address-name-encoding X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 12:01:32 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E57B0812APUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Together with Roberta we submitted a short I-D which proposes a generic rec= ommendation to be followed for the design of future DHCP options when both = IP address and FQDN are required. More discussion can be found at: http://tools.ietf.org/html/draft-boucadair= -dhc-address-name-encoding-00. Comments and suggestions are welcome. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F36E57B0812APUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D= ear=20 all,
 
T= ogether=20 with Roberta we submitted a short I-D which proposes a generic recommendati= on to=20 be followed for the design of future DHCP options when both IP address and = FQDN=20 are required.
 
M= ore=20 discussion can be found at: http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encod= ing-00.
C= omments and=20 suggestions are welcome.
 
Cheers,
Med
--_000_94C682931C08B048B7A8645303FDC9F36E57B0812APUEXCB1Bnante_-- From Ted.Lemon@nominum.com Wed Sep 5 06:16:40 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997A321F8504 for ; Wed, 5 Sep 2012 06:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.329 X-Spam-Level: X-Spam-Status: No, score=-106.329 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDCV9yscNFjt for ; Wed, 5 Sep 2012 06:16:40 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id D840221F84EA for ; Wed, 5 Sep 2012 06:16:39 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUEdQtqTB1KZJRGzBD2Aqi1+f8RFhR8Od@postini.com; Wed, 05 Sep 2012 06:16:39 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 26CB91B82F4 for ; Wed, 5 Sep 2012 06:16:38 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 14BA019005C; Wed, 5 Sep 2012 06:16:38 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 5 Sep 2012 06:16:38 -0700 From: Ted Lemon To: =?Windows-1252?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Thread-Index: AQHNiseG0gBB4UDEXUCV9TC7KIiRUpd7B/YAgADSmACAAFaXgA== Date: Wed, 5 Sep 2012 13:16:37 +0000 Message-ID: <0EC8B878-F490-4B9B-B49B-DCB92372A4CF@nominum.com> References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> <0CFEF31D-4A01-42A7-89B7-69BDBB41E9C8@employees.org> <6069AF94-1587-496D-BE15-5A9B6892E9F6@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9878D9266C5E9A4090FC409150F431B0@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 13:16:40 -0000 On Sep 5, 2012, at 4:06 AM, Ole Tr=F8an wrote: > the DHCP server is not on the data path. unless one follows the model des= cribed in 3633 where the DHCP server is on the PE router. Oh, I see what you mean. No, the DHCP server isn't on the data path, but = it's using the data path. The fate sharing is with respect to the PE rout= er=97the relay=97and the CPE router. Since both are being configured by t= he same message, there is no possibility of partial configuration. > I might be missing something here. I don't understand how the aggregate r= oute for a set of delegated prefixes is dynamic. when and how could all sub= scribers within a aggregate move? The prefix might expand or contract depending on usage patterns. I don't = know if that's actually a use case that Leaf is considering=97it's just one= that occurred to me when I read the draft. > hmm, I didn't think the IPv4 aggregate route was deduced or configured fr= om DHCPv4 either. the deployments I'm aware of, the PE is always configured= outside of DHCP with the IPv4 subnets / aggregate routes. what's the analo= gy? The analogy is that the PE router's downstream routing configuration is in = fact determined from snooping DHCPv4. This is the entire justification for= leasequery=97to rebuild the router's DHCP snooping cache after a power cyc= le. From leaf.y.yeh@huawei.com Wed Sep 5 20:00:49 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9CF21F84BF for ; Wed, 5 Sep 2012 20:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eO6sjUrtnS0u for ; Wed, 5 Sep 2012 20:00:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBF321F854D for ; Wed, 5 Sep 2012 20:00:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKJ94793; Thu, 06 Sep 2012 03:00:44 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Sep 2012 03:59:51 +0100 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Sep 2012 04:00:39 +0100 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.119]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Thu, 6 Sep 2012 11:00:32 +0800 From: Leaf yeh To: =?iso-8859-1?Q?Ole_Tr=F8an?= , Ted Lemon Thread-Topic: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Thread-Index: AQHNiz3JybEem5ZQYkac9Lq+3sR22Zd8h9xw Date: Thu, 6 Sep 2012 03:00:32 +0000 Message-ID: References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> <0CFEF31D-4A01-42A7-89B7-69BDBB41E9C8@employees.org> <6069AF94-1587-496D-BE15-5A9B6892E9F6@nominum.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 03:00:49 -0000 Ole - I might be missing something here. I don't understand how the aggrega= te route for a set of delegated prefixes is dynamic. when and how could all= subscribers within a aggregate move? It is my duty to make you love it. :-) General Idea Clarification on the draft (OPTION_PREFIX_POOL): The draft de= fined the 'Status' of the PD prefix pool in Section 4, which maintained on = the server (and the relay). It has 2 codes now, 'Active' or 'Released', whi= ch can be derived from the leases of delegated subscriber prefixes, or be s= et by the administration of server. The 'Status' in the OPTION_PREFIX_POOL = received by the relay is used for the addition or removal the aggregation r= oute on the PE router (acting as the relay). Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of O= le Tr?an Sent: Wednesday, September 05, 2012 4:07 PM To: Ted Lemon Cc: dhcwg@ietf.org WG Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-op= t-08 Ted, >> I look at it differently. you are adding more complexity on functions th= at are not in the data path. in my book that isn't fate sharing. >=20 > How is this not on the data path? the DHCP server is not on the data path. unless one follows the model descr= ibed in 3633 where the DHCP server is on the PE router. [...] >> this is like saying that configuring OSPF on a router is a unsolved prob= lem, just because it isn't done with DHCP. ;-) >=20 > No, if OSPF is how these routers are being configured, that's not what I = think of as static configuration. Is that in fact the case? It's my und= erstanding that there is no clean dynamic configuration mechanism that ties= back to the address allocation system (that is, to DHCP).=20 I might be missing something here. I don't understand how the aggregate rou= te for a set of delegated prefixes is dynamic. when and how could all subsc= ribers within a aggregate move? > It seems to me that what we are talking about here is exactly analogous t= o what's done today in IPv4 with DHCP snooping and DHCP leasequery, both of= which seem to be good solutions that are widely deployed and work well for= network providers. If there's a better way, I'm all ears, but when I ask= ed in the routing area, I got some pretty vague answers that sounded a lot = like "it's configured statically." hmm, I didn't think the IPv4 aggregate route was deduced or configured from= DHCPv4 either. the deployments I'm aware of, the PE is always configured o= utside of DHCP with the IPv4 subnets / aggregate routes. what's the analogy= ? cheers, Ole From budmillwood@gmail.com Thu Sep 6 14:36:56 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3746321F8762 for ; Thu, 6 Sep 2012 14:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2nUwybUUXfM for ; Thu, 6 Sep 2012 14:36:55 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id B842E21F8716 for ; Thu, 6 Sep 2012 14:36:55 -0700 (PDT) Received: by ieak13 with SMTP id k13so4328510iea.31 for ; Thu, 06 Sep 2012 14:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ttEmeXYaykiw3naQe5Yu9dskVfKRxox98RnwFXPcDhY=; b=WAeAWBmBIE62+SmF5+KSU3q/2WuVQOPBHZDRyucVj0EHV1/QaJ14pwJE7p6xzA3KvF XwKjCh8QRiID2ij4rZN4voyh5pekdUZo1EJar/RnYTA3rhXEkOco60qlTg09PdNe85X0 XP+pu7nvx1YUMFnu386Swxc4BbQsDto7mx+dOpumm8BVQPD50KWQ5jby/d1RpqZQ7xN7 //XFzTt67EMbW33nXD6CJ2nKCx/RAQhW+SKCuPVNyZKWTBRID7ATKIlOuDDCKq/4oS6e Jaq+ej654wsC0AZTX5uBOLh5XvLFekLiQ83rr3CgEyCzbNR636C2ECbmAv4Fh5t95pz5 JHfw== MIME-Version: 1.0 Received: by 10.50.220.169 with SMTP id px9mr5171566igc.8.1346967415320; Thu, 06 Sep 2012 14:36:55 -0700 (PDT) Sender: budmillwood@gmail.com Received: by 10.64.94.228 with HTTP; Thu, 6 Sep 2012 14:36:55 -0700 (PDT) In-Reply-To: References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Thu, 6 Sep 2012 23:36:55 +0200 X-Google-Sender-Auth: KCjeWm9rbLB1snZBfCWHIm9r9sg Message-ID: From: Bud Millwood To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Cc: "dhcwg@ietf.org" , Andre Kostur , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 21:36:56 -0000 > Does anybody recall why the original load balancing had the 16 byte > restriction? > > > Nope. It might be worth visiting the question of whether the hash > algorithm is the right one. Any particular reason for revisiting the hash algorithm itself, as opposed to just dropping the 16 byte limit in DHCPv6? - Bud From akostur@incognito.com Thu Sep 6 14:44:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FD321F8546 for ; Thu, 6 Sep 2012 14:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJb+AfWiUSTe for ; Thu, 6 Sep 2012 14:44:00 -0700 (PDT) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with SMTP id F1B6C21F8539 for ; Thu, 6 Sep 2012 14:43:59 -0700 (PDT) Received: from mail-ie0-f172.google.com ([209.85.223.172]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKUEkZH0Z6Xe+v2Eh2lfYv9sYXTDcOlEuG@postini.com; Thu, 06 Sep 2012 14:44:00 PDT Received: by ieak13 with SMTP id k13so4338577iea.31 for ; Thu, 06 Sep 2012 14:43:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=+bnO0zKvc4YJL3OcgHCDzsnOGI+O3JfsaLTRqOV6ebI=; b=H6UgnRx7HtBpoEPLliVWn6kcQWALIQDlnf3MHsnVjopBPf0lggePvnzMJWI6JHLhW4 QiIhMA/B7Gi4JUUnde7tP6br1spqL0gov/05FntxpITyofXuQWZIda29DtattzSAnfJd VD+slui01w2JEnQmqMCNosu2yWnvbAjA/v0ps46j55dVCPYxg+YQGqsYRRLuJG5BND+i vu6AoUWMP87X860FA6WfTECVbOywpTNX3qbpaDv2nZQVX7jDpFs0IlPYjgWs59Z9Q/5z frnJedMcQO0kLBZSWjicJ8NHGiRLabQujN3US787zo390m2yLOw4S4rAwEp08KUFFp17 pLNw== MIME-Version: 1.0 Received: by 10.50.213.97 with SMTP id nr1mr25222170igc.40.1346967839157; Thu, 06 Sep 2012 14:43:59 -0700 (PDT) Received: by 10.64.100.137 with HTTP; Thu, 6 Sep 2012 14:43:59 -0700 (PDT) In-Reply-To: References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Thu, 6 Sep 2012 14:43:59 -0700 Message-ID: From: Andre Kostur To: Bud Millwood Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn9Dw8HN3QHwFzy/tJ56BFKUGInmQ7P1SrJKNTS5P0woeSYucar0BhIeGSePlet+cmbRyXD Cc: "dhcwg@ietf.org" , Ted Lemon , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 21:44:01 -0000 On Thu, Sep 6, 2012 at 2:36 PM, Bud Millwood wrote: > > > Does anybody recall why the original load balancing had the 16 byte > > restriction? > > > > > > Nope. It might be worth visiting the question of whether the hash > > algorithm is the right one. > > Any particular reason for revisiting the hash algorithm itself, as > opposed to just dropping the 16 byte limit in DHCPv6? > > - Bud Personally I don't think we need to revisit the algorithm. I have not heard of anybody complain about it, and existing DHCP servers and relays (assuming they're doing load balancing now) will already have the implementation done. I think the 16 byte limitation should just be lifted. In the common cases of ethernet-based networks, DUID-LLT is 14 bytes (below the 16), DUID-LL is only 10, and DUID-UUID is 18 bytes (only 2 beyond the 16). The only one that is more of a question mark is DUID-EN as the vendor-specific identifier could be of arbitrary length. The one case that we've heard of so far puts the length at 13 bytes + the length of a serial number. I'll wait for this discussion before I publish an updated draft to reflect this topic. -- Andre Kostur From Ted.Lemon@nominum.com Thu Sep 6 14:44:16 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D896E21F8578 for ; Thu, 6 Sep 2012 14:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.474 X-Spam-Level: X-Spam-Status: No, score=-106.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiC58NJddH0H for ; Thu, 6 Sep 2012 14:44:16 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 468C421F8574 for ; Thu, 6 Sep 2012 14:44:16 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUEkZL9HPYFnfISxeXuD5dY0irexoJDQC@postini.com; Thu, 06 Sep 2012 14:44:16 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 54ED21B8346 for ; Thu, 6 Sep 2012 14:44:15 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 4CA1819005C; Thu, 6 Sep 2012 14:44:15 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 6 Sep 2012 14:44:15 -0700 From: Ted Lemon To: Bud Millwood Thread-Topic: [dhcwg] Load Balancing for DHCPv6 Thread-Index: AQHNhTu7gFlX/ZntC0OFRh8xVQ/AAZdwtBEAgACi1QCAAB9FgIAAA4kAgAABYICADN9FgIAAAgsA Date: Thu, 6 Sep 2012 21:44:15 +0000 Message-ID: References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Andre Kostur , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 21:44:17 -0000 On Sep 6, 2012, at 5:36 PM, Bud Millwood wrote: > Any particular reason for revisiting the hash algorithm itself, as > opposed to just dropping the 16 byte limit in DHCPv6? I don't actually remember the criteria that were used to choose the old has= h algorithm. Are we still happy with it? Things have changed since the = previous draft was published. From volz@cisco.com Thu Sep 6 14:58:46 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2354B21F8690 for ; Thu, 6 Sep 2012 14:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiOMuOQ+nmib for ; Thu, 6 Sep 2012 14:58:45 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF6321F8687 for ; Thu, 6 Sep 2012 14:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=729; q=dns/txt; s=iport; t=1346968725; x=1348178325; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zBAuj+OClkM7H0iOqxYz8nL94GIIEdtVOn003QL+DKw=; b=FORNU0No0d24XTI4R6Hu8YzTSFB3yyXMHJ/kSMST1C92g7m/vdVHaz8/ idIHSaR9v3g0Vw9fNrcJrNYhUHlaqMvvKT42wT89n18zbeT9XIVn6yUUu VnD/6aPAjFFxkLG4c+gKoiaHVaTV9RlFFKEKFbZ305RqcKi7k9Nz7UuZV Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAKYbSVCtJV2Z/2dsb2JhbABFhUC2D4EHgiABAQEEEgEnPwwEAgEIEQQBAQEKFAkHMhQJCAIEAQ0FCBMHh26bN6AyixEVhVBgA6QPgWeCY4FZ X-IronPort-AV: E=Sophos;i="4.80,381,1344211200"; d="scan'208";a="119116668" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 06 Sep 2012 21:58:45 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q86Lwi9t022920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Sep 2012 21:58:45 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Thu, 6 Sep 2012 16:58:44 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , Bud Millwood Thread-Topic: [dhcwg] Load Balancing for DHCPv6 Thread-Index: AQHNjHe9qDjW3gEpckeBYuf8K4cCpZd+LGeA//+v1vA= Date: Thu, 6 Sep 2012 21:58:44 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F4F79B6@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.204] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19166.007 x-tm-as-result: No--30.577900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Andre Kostur Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 21:58:46 -0000 I think the algorithm is fine. We've never run into any operational issues = with it. -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Thursday, September 06, 2012 5:44 PM To: Bud Millwood Cc: Andre Kostur; dhcwg@ietf.org; Bernie Volz (volz) Subject: Re: [dhcwg] Load Balancing for DHCPv6 On Sep 6, 2012, at 5:36 PM, Bud Millwood wrote: > Any particular reason for revisiting the hash algorithm itself, as > opposed to just dropping the 16 byte limit in DHCPv6? I don't actually remember the criteria that were used to choose the old has= h algorithm. Are we still happy with it? Things have changed since the = previous draft was published. From tomasz.mrugalski@gmail.com Fri Sep 7 02:49:17 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A208F21F876F for ; Fri, 7 Sep 2012 02:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHYmUJ1BkYIA for ; Fri, 7 Sep 2012 02:49:17 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1870E21F8763 for ; Fri, 7 Sep 2012 02:49:15 -0700 (PDT) Received: by eekb45 with SMTP id b45so1145053eek.31 for ; Fri, 07 Sep 2012 02:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=aEKim4rqIRNkv7iPIYj4LaSP6RA8nuhXGLGko+xvz/g=; b=s9QHW2cJSK8N23vyuHUKfu7OEo14kfpFLGwcJ5z+8V03n92QB23IZPg6XyRxmQvwZj mYFCTQ1psXqLs4bIaPzgbn83MuT6D90IROEPCn9LJTwWvG1bw1TBI+Q3OPi8/LkTbHxi mmXW9eofPSw5N/9CZPn8wvifKISJKOphIAZJ3r+VwlCo/ZWVs6Exon17jFqoHAGetKL8 J1fEyvx9lPhXNuId6sQt7Uq1vD2L0i1cvopJEmuCmVV2NddP1okXtPxlLy9M8Rq58HXL 42QFhVv8L7YLIlvml3BHmpqW7AWtZOC391P/w8Av94IYBaM8+nLniOdhA+hcGmwmXs/r RlBQ== Received: by 10.14.223.9 with SMTP id u9mr6986915eep.10.1347011355309; Fri, 07 Sep 2012 02:49:15 -0700 (PDT) Received: from ?IPv6:2001:470:6061:1:e086:e8e7:836c:20ad? ([2001:470:6061:1:e086:e8e7:836c:20ad]) by mx.google.com with ESMTPS id e42sm11198791eem.8.2012.09.07.02.49.13 (version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 02:49:14 -0700 (PDT) Message-ID: <5049C317.7090603@gmail.com> Date: Fri, 07 Sep 2012 11:49:11 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> In-Reply-To: X-TagToolbar-Keys: D20120907114911385 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 09:49:17 -0000 On 06.09.2012 23:43, Andre Kostur wrote: > bytes (only 2 beyond the 16). The only one that is more of a question > mark is DUID-EN as the vendor-specific identifier could be of > arbitrary length. The one case that we've heard of so far puts the Sort of arbitrary, until you hit the limit of 128 octets, imposed by 3315 section 9.1. I'm ok with lifting the 16 bytes limit (or rather extending it to 128 bytes). There are some devices out there that are using DUIDs with duid type 14. I have no idea what those devices are, I just saw traffic captures from a production network. It is odd, but any server that follows 3315, section 9 ("servers MUST treat DUIDs as opaque values") will handle them ok. Anyway, my recommendation is to include the whole DUID as is in the hash and don't to any clever things with duid types. Regarding hashing algorithm, I never heard anyone complaining about it. So don't fix it if it isn't broken. It can handle data chunks up to 128 bytes, right? Tomek From volz@cisco.com Fri Sep 7 04:16:27 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D430521F87D7 for ; Fri, 7 Sep 2012 04:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ok1TgrIo1d4c for ; Fri, 7 Sep 2012 04:16:27 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 50AF921F87B9 for ; Fri, 7 Sep 2012 04:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1515; q=dns/txt; s=iport; t=1347016587; x=1348226187; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Emf+DQSG5PxFO8nUyvF66IdGQO/74WYxJNb13Fqc6no=; b=gv1Ii9wIuvBe9cY3ihA9L89/6CiSrdE2ZwbV2jmAQQ+JPPdFApK+Az+w z42nNrNyhGuLUhdbNc3XTLmJjlxyvUKB1H6X2HDRgWoqw5C2vQWJcFSv+ lXmCm+V4KEEfLCqp1+5/85ztlaspsdGtcpJ3nsjubs+aJKOdtvDWzpI08 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANXWSVCtJXHA/2dsb2JhbABFuzmBB4IgAQEBAwEBAQEPASc0CwULAgEIDgoeECEGCyUCBA4FIodcAwkGC5sglmUNiU8Eii9jFYU/YAOUCIFVixSDIYFngmSBWw X-IronPort-AV: E=Sophos;i="4.80,385,1344211200"; d="scan'208";a="119268644" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 07 Sep 2012 11:16:26 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q87BGQpc001065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Sep 2012 11:16:26 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Fri, 7 Sep 2012 06:16:25 -0500 From: "Bernie Volz (volz)" To: Tomek Mrugalski Thread-Topic: [dhcwg] Load Balancing for DHCPv6 Thread-Index: AQHNjN4IqDjW3gEpckeBYuf8K4cCpZd+urP1 Date: Fri, 7 Sep 2012 11:16:25 +0000 Message-ID: <94FA926F-2432-4AE7-BC20-AE7458AB40D9@cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> , <5049C317.7090603@gmail.com> In-Reply-To: <5049C317.7090603@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19168.005 x-tm-as-result: No--50.472700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 11:16:27 -0000 Yes it can handle any length of data - the 16 limit came from max of chaddr= . There is no harm in using whole duid, skipping type just reduces bytes us= ed and as that field varies little it adds little. Sent from my iPad On Sep 7, 2012, at 5:49 AM, "Tomek Mrugalski" = wrote: > On 06.09.2012 23:43, Andre Kostur wrote: >> bytes (only 2 beyond the 16). The only one that is more of a question >> mark is DUID-EN as the vendor-specific identifier could be of >> arbitrary length. The one case that we've heard of so far puts the > Sort of arbitrary, until you hit the limit of 128 octets, imposed by > 3315 section 9.1. I'm ok with lifting the 16 bytes limit (or rather > extending it to 128 bytes). >=20 > There are some devices out there that are using DUIDs with duid type 14. > I have no idea what those devices are, I just saw traffic captures from > a production network. It is odd, but any server that follows 3315, > section 9 ("servers MUST treat DUIDs as opaque values") will handle them > ok. Anyway, my recommendation is to include the whole DUID as is in the > hash and don't to any clever things with duid types. >=20 > Regarding hashing algorithm, I never heard anyone complaining about it > So don't fix it if it isn't broken. It can handle data chunks up to 128 > bytes, right? >=20 > Tomek >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From alexandru.petrescu@gmail.com Fri Sep 7 05:10:50 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6185021F87D2 for ; Fri, 7 Sep 2012 05:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXZjsXbjO615 for ; Fri, 7 Sep 2012 05:10:49 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 31CA621F87D0 for ; Fri, 7 Sep 2012 05:10:49 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q87CAl7w023665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 7 Sep 2012 14:10:47 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q87CAlTZ005582 for ; Fri, 7 Sep 2012 14:10:47 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q87CAhf7022282 for ; Fri, 7 Sep 2012 14:10:47 +0200 Message-ID: <5049E443.5040305@gmail.com> Date: Fri, 07 Sep 2012 14:10:43 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> In-Reply-To: <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 12:10:50 -0000 Le 04/09/2012 18:32, Ole Trĝan a écrit : > Ted, > >>> This would not have the overhead per transaction and also the >>> handling at the relay would be much elegant and simpler. Current >>> draft requires relay to implement bulk lease query and >>> additional processing per relayed PD request. >> >> The overhead per transaction here is a bit of a red herring—we're >> talking about thirteen bytes, if I count correctly. >> >> Furthermore, the working group already went down the path of >> separating out the transactions a couple of years ago, and >> determined that there were synchronization problems; that work was >> eventually dropped for lack of interest. >> >> The problem remains unsolved; this is actually a pretty good >> solution, because it involves fate sharing, with a netconf >> solution wouldn't have, and uses an established communications >> path, which netconf/yang doesn't offer. > > fate sharing of what? the client functions independently of whatever > aggregate route there is for a whole block of subscribers. this just > adds another cog in the machinery that may fail. > >> This is definitely better than the solution vendors are currently >> offering, which is to simply sniff the prefixes from DHCP messages >> to the client. With my working group chair hat off, I'm in favor >> of doing this work precisely because it solves the problem neatly, >> and no better solution has ever been presented of which I'm aware. > > this does not solve the DHCPv6 PD problem of route injection. a > route needs to be installed per client, and snooping is still needed > for that. this proposal _only_ solves the problem of installing an > aggregate route for multiple PD RRs into a PE/relay. In a sense I agree - this proposal seems to still require snooping. (i.e. existing single prefixes in PD require snooping and pool-opt draft requires it too). > this is most typically done with static configuration today. Well no, static configuration at Relay is not sufficient for PD to work, even if we dont talk pool-opt draft - there is a need of that route at Relay. There is no other solution to that than DHCP Relay to become more intelligent (i.e. "snoop"). Alex > > cheers, Ole > > > > _______________________________________________ dhcwg mailing list > dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg > From alexandru.petrescu@gmail.com Fri Sep 7 05:12:26 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0868B21F84F5 for ; Fri, 7 Sep 2012 05:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7x3OLuA107S for ; Fri, 7 Sep 2012 05:12:25 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3714221F84E6 for ; Fri, 7 Sep 2012 05:12:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q87CCNlb020345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 7 Sep 2012 14:12:23 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q87CCN7D006192 for ; Fri, 7 Sep 2012 14:12:23 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q87CCM6S023111 for ; Fri, 7 Sep 2012 14:12:23 +0200 Message-ID: <5049E4A6.6070005@gmail.com> Date: Fri, 07 Sep 2012 14:12:22 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> <0CFEF31D-4A01-42A7-89B7-69BDBB41E9C8@employees.org> In-Reply-To: <0CFEF31D-4A01-42A7-89B7-69BDBB41E9C8@employees.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 12:12:26 -0000 Le 04/09/2012 20:02, Ole Trĝan a écrit : >>> fate sharing of what? the client functions independently of >>> whatever aggregate route there is for a whole block of >>> subscribers. this just adds another cog in the machinery that may >>> fail. >> >> Fate sharing in the sense that the DHCP server is best able to know >> from what aggregate prefix prefixes for clients on a particular >> router will be allocated, and the DHCP packet is the way these >> prefixes get allocated to the client. So we can be sure that if >> the network is working at all, it will be working completely. > > I look at it differently. you are adding more complexity on functions > that are not in the data path. in my book that isn't fate sharing. > >>> this does not solve the DHCPv6 PD problem of route injection. a >>> route needs to be installed per client, and snooping is still >>> needed for that. this proposal _only_ solves the problem of >>> installing an aggregate route for multiple PD RRs into a >>> PE/relay. this is most typically done with static configuration >>> today. >> >> It solves half the problem: configuring the route that the router >> advertises. You are correct that it doesn't solve the other >> half—figuring out where to send packets downstream. But actually, >> snooping the DHCP packet is a perfectly good solution for this >> problem; what is lacking is a standard that says how it's done. > > we did try with the use of the RAAN option. > >> What snooping is _not_ good for is figuring out what route to >> advertise upstream. To say that the upstream route is currently >> done with static configuration is synonymous with saying that the >> problem is currently unsolved. > > this is like saying that configuring OSPF on a router is a unsolved > problem, just because it isn't done with DHCP. ;-) But for this there is a need to have OSPF talk DHCP or vice-versa. Is there a spec for DHCP-OSPF Gateway? Alex > > cheers, Ole > > > > _______________________________________________ dhcwg mailing list > dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg > From alexandru.petrescu@gmail.com Fri Sep 7 05:23:39 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E633021F880C for ; Fri, 7 Sep 2012 05:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoOjqQq5CmyK for ; Fri, 7 Sep 2012 05:23:39 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id AF0D921F8805 for ; Fri, 7 Sep 2012 05:23:38 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q87CNbej031871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 7 Sep 2012 14:23:37 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q87CNajS010587 for ; Fri, 7 Sep 2012 14:23:37 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q87CNWQK028970 for ; Fri, 7 Sep 2012 14:23:36 +0200 Message-ID: <5049E744.30700@gmail.com> Date: Fri, 07 Sep 2012 14:23:32 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> <0CFEF31D-4A01-42A7-89B7-69BDBB41E9C8@employees.org> <6069AF94-1587-496D-BE15-5A9B6892E9F6@nominum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 12:23:40 -0000 Le 05/09/2012 05:16, Leaf yeh a écrit : > Ralph - One issue that comes to mind for me is that the DHCPv6 server > may not, in fact, have complete information about the routing and > prefix aggregation information. I tend to agree with this statement. > The DHCPv6 server would be inferring aggregation information from > the pools of prefixes it has to delegate. Looked at another way, > there is likely an oracle of network configuration somewhere from > which the delegated prefix pools and prefix aggregation for routing > is derived. The DHCPv6 server might be able to make an educated guess > but it doesn't have necessarily authoritative information. I wonder about the implementation of educated guess... Given a set of prefixes find their common longest prefix (easy) and make sure its other subprefixes are not in use elsewhere (more difficult.) I mean I dont think an educated guess could be done reasonably to form a common prefix and instruct the Relay about it. Even less that Relay to advertise the aggregated prefix instead of numerous specific routes. But I agree there may be a problem in too numerous specific routes advertised by Relay to routers, about the dynamically delegated prefixes. Alex > > > General Idea Clarification on the draft (OPTION_PREFIX_POOL): If we > are only thinking about the delegated prefix to customer and its > pre-configured prefix pool on the DHCPv6 server (or DR), the server > does know all the lease of the delegated prefix, then can definitely > derive the status ('Active' or 'Released') of the prefix pool. There > is no 'educated guess' here. Because the server acts as the manager > (or administrator) of all the pools, he authorize (or delegate) the > prefix to the customer, and know all the information (or aspects) of > the delegated prefixes. > > > Ralph - Another issue with piggybacking is that the routing > information may change independent of any specific DHCPv6 message > exchanges (someone else raised this issue), so that there would be no > way to send updates if there was no DHCPv6 traffic to send through > the router. > > > General Idea Clarification on the draft (OPTION_PREFIX_POOL): The > draft creates somewhat of new reasonable function on the server to > support the policy change (for route aggregation based on the > information of the prefix pools), the basic proposal in the draft is > to utilize the process of 'Prefix Delegation Reconfiguration' to > trigger the immediately update. See Section 6 of the draft. > > > Ralph - Why would this aggregation information not be provided > through whatever configuration mechanism is used to manage the > router? > > > General Idea Clarification on the draft (OPTION_PREFIX_POOL): > DHCPv6-PD works closely with the prefix pools, (which always mean the > necessary aggregation route in Ole's static configuration,) it could > be the simplest way to do the dynamic parameter provisioning to PE > router. > > > > Best Regards, Leaf > > > -----Original Message----- From: dhcwg-bounces@ietf.org > [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ralph Droms Sent: > Wednesday, September 05, 2012 4:12 AM To: Lemon Ted; Ole Trĝan Cc: > dhcwg@ietf.org WG Subject: Re: [dhcwg] Call for Adoption: > draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 > > > On Sep 4, 2012, at 3:32 PM 9/4/12, Ted Lemon wrote: > >> On Sep 4, 2012, at 2:02 PM, Ole Trĝan >> wrote: >>> I look at it differently. you are adding more complexity on >>> functions that are not in the data path. in my book that isn't >>> fate sharing. >> >> How is this not on the data path? >> >>> we did try with the use of the RAAN option. >> >> Right, but this wasn't useful because it added no functionality-the >> only purpose it served was to avoid having the relay agent look in >> the client part of the DHCP packet. I never understood why you >> guys wanted this. If you think the work is important, I am >> certainly not opposed to reviving it, though-it was a perfectly >> good draft. >> >>> this is like saying that configuring OSPF on a router is a >>> unsolved problem, just because it isn't done with DHCP. ;-) >> >> No, if OSPF is how these routers are being configured, that's not >> what I think of as static configuration. Is that in fact the >> case? It's my understanding that there is no clean dynamic >> configuration mechanism that ties back to the address allocation >> system (that is, to DHCP). >> >> It seems to me that what we are talking about here is exactly >> analogous to what's done today in IPv4 with DHCP snooping and DHCP >> leasequery, both of which seem to be good solutions that are >> widely deployed and work well for network providers. If there's >> a better way, I'm all ears, but when I asked in the routing area, >> I got some pretty vague answers that sounded a lot like "it's >> configured statically." > > One issue that comes to mind for me is that the DHCPv6 server may > not, in fact, have complete information about the routing and prefix > aggregation information. The DHCPv6 server would be inferring > aggregation information from the pools of prefixes it has to > delegate. Looked at another way, there is likely an oracle of > network configuration somewhere from which the delegated prefix pools > and prefix aggregation for routing is derived. The DHCPv6 server > might be able to make an educated guess but it doesn't have > necessarily authoritative information. > > Another issue with piggybacking is that the routing information may > change independent of any specific DHCPv6 message exchanges (someone > else raised this issue), so that there would be noway to send > updates if there was no DHCPv6 traffic to send through the router. > > Why would this aggregation information not be provided through > whatever configuration mechanism is used to manage the router? > > - Ralph > >> >> _______________________________________________ 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 alexandru.petrescu@gmail.com Fri Sep 7 05:26:54 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9092C21F880E for ; Fri, 7 Sep 2012 05:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJAO-QF+rgXH for ; Fri, 7 Sep 2012 05:26:54 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id B6A4A21F8800 for ; Fri, 7 Sep 2012 05:26:53 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q87CQqD2000990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 7 Sep 2012 14:26:52 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q87CQqlV011894 for ; Fri, 7 Sep 2012 14:26:52 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q87CQp5H030945 for ; Fri, 7 Sep 2012 14:26:52 +0200 Message-ID: <5049E80B.8000200@gmail.com> Date: Fri, 07 Sep 2012 14:26:51 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> <0CFEF31D-4A01-42A7-89B7-69BDBB41E9C8@employees.org> <6069AF94-1587-496D-BE15-5A9B6892E9F6@nominum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 12:26:54 -0000 Le 05/09/2012 10:06, Ole Trĝan a écrit : > Ted, > >>> I look at it differently. you are adding more complexity on >>> functions that are not in the data path. in my book that isn't >>> fate sharing. >> >> How is this not on the data path? > > the DHCP server is not on the data path. unless one follows the model > described in 3633 where the DHCP server is on the PE router. I agree because our DHCP Server is not on the data path, but has the info about all data paths. > [...] > >>> this is like saying that configuring OSPF on a router is a >>> unsolved problem, just because it isn't done with DHCP. ;-) >> >> No, if OSPF is how these routers are being configured, that's not >> what I think of as static configuration. Is that in fact the >> case? It's my understanding that there is no clean dynamic >> configuration mechanism that ties back to the address allocation >> system (that is, to DHCP). > > I might be missing something here. I don't understand how the > aggregate route for a set of delegated prefixes is dynamic. when and > how could all subscribers within a aggregate move? I dont think the aggregation relationship could be dynamic - it's frozen bitwise operation - 11 is prefix of 1101 whatever the routing is set up. Alex >> It seems to me that what we are talking about here is exactly >> analogous to what's done today in IPv4 with DHCP snooping and DHCP >> leasequery, both of which seem to be good solutions that are widely >> deployed and work well for network providers. If there's a better >> way, I'm all ears, but when I asked in the routing area, I got some >> pretty vague answers that sounded a lot like "it's configured >> statically." > > hmm, I didn't think the IPv4 aggregate route was deduced or > configured from DHCPv4 either. the deployments I'm aware of, the PE > is always configured outside of DHCP with the IPv4 subnets / > aggregate routes. what's the analogy? > > cheers, Ole > > > > _______________________________________________ dhcwg mailing list > dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg > From alexandru.petrescu@gmail.com Fri Sep 7 05:44:56 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A48F21F8715 for ; Fri, 7 Sep 2012 05:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZ5FRCrv7pBd for ; Fri, 7 Sep 2012 05:44:55 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3478F21F8734 for ; Fri, 7 Sep 2012 05:44:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q87Cirbq008562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 7 Sep 2012 14:44:53 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q87CirvI018816 for ; Fri, 7 Sep 2012 14:44:53 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q87Cin3h015555 for ; Fri, 7 Sep 2012 14:44:53 +0200 Message-ID: <5049EC41.3080809@gmail.com> Date: Fri, 07 Sep 2012 14:44:49 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "dhcwg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dhcwg] Comments on some aspects on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 12:44:56 -0000 DHC WG, Comments on some aspects on this draft. > When a routing protocol is enabled on the network-facing interface > of the PE router, all the routes directing to the customer networks > are advertised in the ISP network. This will make the number of > route entries in the routing table on the ISP router be unacceptable > large. Hence, it is desirable to aggregate the routes directing to > the customer networks on the PE router. In general, I can visualize the problem, and I believe more things about it: - it could be better described with an example and a topology which pictures many routes (like in 1, 2 ... n). This is just a comment, not necessarily should be done. (Graphs are already drawn which is good already in the draft.) - but if we do and draw pictures we may realize that the problem is exhibited in cases where the default route may not be given enough importance. For example, if the Relay has a single default route and is statically in charge of a short prefix (many subprefixes) then there is no problem of Relay advertising too many routes - only one. And of course, if it is not possible to have the Relay in charge of a single short prefix then ultimately one ends up with many specific routes advertised to the network and with the need to reduce them. One alternative solution may be to have a mechanism by which the Relay itself first executes Requesting Router (before being a Relay) to obtain that short prefix, at which point we no longer talk 'snooping'. This could be the Prefix Pool Option without snooping. Alex From alexandru.petrescu@gmail.com Fri Sep 7 05:52:00 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19D621F8790 for ; Fri, 7 Sep 2012 05:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMJ0QlbfEAb2 for ; Fri, 7 Sep 2012 05:51:59 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id C049A21F87B0 for ; Fri, 7 Sep 2012 05:51:58 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q87CpvcG007481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 7 Sep 2012 14:51:57 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q87CpvLq021661 for ; Fri, 7 Sep 2012 14:51:57 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q87Cpu4h019429 for ; Fri, 7 Sep 2012 14:51:57 +0200 Message-ID: <5049EDEC.7000607@gmail.com> Date: Fri, 07 Sep 2012 14:51:56 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> In-Reply-To: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 12:52:00 -0000 I think it should be adopted because I like the idea to avoid numerous dynamic specific routes presumably introduced by the use of Prefix Delegation for autoconfiguring mobile routers on a large scale. But I also think that some of the problem of too many specific routes in the dynamic routing protocol generated by Relay could be avoided with help from (1) a better address planning by a human and (2) less computer intelligence at Relay. To me it also depends on the willingness of authors to push forward and of group members to help find consensus. Let's see further, Alex Le 24/08/2012 17:32, Ted Lemon a écrit : > The authors have proposed that the working group adopt the prefix > pool option draft as a working group item. We have engaged in some > correspondence with participants in the Routing Area, and while some > helpful advice was given, no objections were raised to going forward > with the work, and it's a DHCP protocol extension, so it makes sense > for it to happen in the DHC working group. > > The document proposes an extension to the DHCP protocol that allows > the DHCP server to communicate prefixes to the provider edge router > when doing prefix delegation, such that this router can advertise a > route to an aggregate prefix, rather than to many individual > prefixes, and so that this router does not have to perform ad-hoc > prefix aggregation, which may produce less optimal results. > > If you think this work should be adopted by the working group, > please reply to this message saying so. If you think this work > should not be adopted by the working group, please reply to this > message saying so. We will evaluate consensus on September 7. > > _______________________________________________ dhcwg mailing list > dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg > > From Ted.Lemon@nominum.com Fri Sep 7 06:20:31 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7177B21E8051 for ; Fri, 7 Sep 2012 06:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.492 X-Spam-Level: X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8T2XZUhL3MgP for ; Fri, 7 Sep 2012 06:20:30 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id DC33F21E804D for ; Fri, 7 Sep 2012 06:20:29 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUEn0neRR9RLdXRfpJnG56mmON0Nz//aI@postini.com; Fri, 07 Sep 2012 06:20:29 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E08E21B82D0 for ; Fri, 7 Sep 2012 06:20:28 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D77F319005C; Fri, 7 Sep 2012 06:20:28 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 7 Sep 2012 06:20:28 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Thread-Index: AQHNixTt7j4mGsE020mooYLMfMfNj5d/Rl8AgAAP6AA= Date: Fri, 7 Sep 2012 13:20:28 +0000 Message-ID: <9DB266A4-F0B6-43C4-BF8B-8A6C65792CAB@nominum.com> References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> <0CFEF31D-4A01-42A7-89B7-69BDBB41E9C8@employees.org> <6069AF94-1587-496D-BE15-5A9B6892E9F6@nominum.com> <5049E744.30700@gmail.com> In-Reply-To: <5049E744.30700@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 13:20:31 -0000 On Sep 7, 2012, at 8:23 AM, Alexandru Petrescu wrote: > I mean I dont think an educated guess could be done reasonably to form a > common prefix and instruct the Relay about it. Even less that Relay to > advertise the aggregated prefix instead of numerous specific routes. I think the whole point of the prefix pool option is to avoid making educat= ed guesses, by coming up with the aggregate route in the core of the networ= k, as a management function. IOW, I don't think the DHCP server will be f= ollowing some heuristic to figure out what the aggregate prefix is; rather,= it will be configured either to allocate one specifically, or will be conf= igured by a management system with a predefined prefix pool. From internet-drafts@ietf.org Fri Sep 7 07:40:29 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA1021E80AD; Fri, 7 Sep 2012 07:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqPVfe-7f8xs; Fri, 7 Sep 2012 07:40:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2C721E80B2; Fri, 7 Sep 2012 07:40:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120907144028.15942.16897.idtracker@ietfa.amsl.com> Date: Fri, 07 Sep 2012 07:40:28 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-redundancy-consider-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 14:40:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : DHCPv6 Redundancy Deployment Considerations Author(s) : John Jason Brzozowski Jean-Francois Tremblay Jack Chen Tomasz Mrugalski Filename : draft-ietf-dhc-dhcpv6-redundancy-consider-03.txt Pages : 17 Date : 2012-09-07 Abstract: This document provides information for those wishing to use DHCPv6 to support their deployment of IPv6. In particular, it discusses the provision of semi-redundant DHCPv6 services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-redundancy-consider There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-redundancy-consider-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-redundancy-conside= r-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From d3e3e3@gmail.com Fri Sep 7 07:44:57 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7834D21E80BA for ; Fri, 7 Sep 2012 07:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbqnaheRdgkh for ; Fri, 7 Sep 2012 07:44:56 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8327321E80B2 for ; Fri, 7 Sep 2012 07:44:56 -0700 (PDT) Received: by iabz21 with SMTP id z21so3615836iab.31 for ; Fri, 07 Sep 2012 07:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Ym/ISVZbyqOLKK0FQcjyFZO3sUBRJYnazUz+XVp+08c=; b=a/oJyIHoNmfw12e4yAXC7fzssnFR/oPyN0Ghv1E4ig+LRWApC40xfeAjDmI/npwINz b8nSY+5+GijwHxOW4jS44Sdxwb3g6eTnJxcEFQ/q9syvP+F8cU5knWR06b3oeDG44ps4 bOF5PI/nmahLuJokdF0l3EGJtXU2OyNURoD48jvUavEhJDtrx36yVEMy4yVcOwj8wLWE gaWhGEZKeghkw9KCeHNBS8E7UTFLC/GHMm07kByeyrgVupWxLt1zgocnyU7zQ6bec7VC vN5gr1bW7VZdtnuLmYGmGpxmm5ebPWnRBbhIBGUFDX7FSP7wUxVlQ+U0tnibzYnl96JW ZLyw== Received: by 10.43.45.200 with SMTP id ul8mr7283696icb.36.1347029095986; Fri, 07 Sep 2012 07:44:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.143.103 with HTTP; Fri, 7 Sep 2012 07:44:35 -0700 (PDT) In-Reply-To: <94FA926F-2432-4AE7-BC20-AE7458AB40D9@cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> <5049C317.7090603@gmail.com> <94FA926F-2432-4AE7-BC20-AE7458AB40D9@cisco.com> From: Donald Eastlake Date: Fri, 7 Sep 2012 10:44:35 -0400 Message-ID: To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 14:44:57 -0000 If it is working fine, there is certainly no reason to change it, which could lead to interoperability problems. But I'd be willing to bet that FNV is superior... https://datatracker.ietf.org/doc/draft-eastlake-fnv/ Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Fri, Sep 7, 2012 at 7:16 AM, Bernie Volz (volz) wrote: > Yes it can handle any length of data - the 16 limit came from max of chaddr. There is no harm in using whole duid, skipping type just reduces bytes used and as that field varies little it adds little. > > Sent from my iPad > > On Sep 7, 2012, at 5:49 AM, "Tomek Mrugalski" wrote: > >> On 06.09.2012 23:43, Andre Kostur wrote: >>> bytes (only 2 beyond the 16). The only one that is more of a question >>> mark is DUID-EN as the vendor-specific identifier could be of >>> arbitrary length. The one case that we've heard of so far puts the >> Sort of arbitrary, until you hit the limit of 128 octets, imposed by >> 3315 section 9.1. I'm ok with lifting the 16 bytes limit (or rather >> extending it to 128 bytes). >> >> There are some devices out there that are using DUIDs with duid type 14. >> I have no idea what those devices are, I just saw traffic captures from >> a production network. It is odd, but any server that follows 3315, >> section 9 ("servers MUST treat DUIDs as opaque values") will handle them >> ok. Anyway, my recommendation is to include the whole DUID as is in the >> hash and don't to any clever things with duid types. >> >> Regarding hashing algorithm, I never heard anyone complaining about it >> So don't fix it if it isn't broken. It can handle data chunks up to 128 >> bytes, right? >> >> Tomek >> >> _______________________________________________ >> 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 volz@cisco.com Fri Sep 7 08:09:13 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC0B21F85B1 for ; Fri, 7 Sep 2012 08:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8giEcurA3NNm for ; Fri, 7 Sep 2012 08:09:13 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 11F9321F85AF for ; Fri, 7 Sep 2012 08:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2230; q=dns/txt; s=iport; t=1347030553; x=1348240153; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=fiB2f7EgkmsfBHKNRhi2IdwFEm80b6C3G4SHcIU7c7o=; b=iv+hHpE9nP6mrg7HNKNaPL/9B+sdB0mJFwCtD1Pm/vDYnGcKCXmycenp WttUjfBuEXBBZOlrdOXrdP9Xil4MbniuV5UkA33seAGUYgt5vuI5JfY2/ CC3E87AGIYU5iSelPLb8o4yZghWVorn3ViH3oQ+HbPlGuKuzMXbV6Bj4O c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAL0MSlCtJV2Y/2dsb2JhbABFuzmBB4IgAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCBMHh24LmyegSQSLEoVUYAOkEoFngmQ X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="119319111" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 07 Sep 2012 15:09:12 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q87F9CWs013426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Sep 2012 15:09:12 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Fri, 7 Sep 2012 10:09:11 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , dhc WG Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpd/Jdsw Date: Fri, 7 Sep 2012 15:09:10 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F4F83D1@xmb-rcd-x04.cisco.com> References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> In-Reply-To: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.254] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19168.005 x-tm-as-result: No--35.890500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:09:13 -0000 Chairs: Where does this Last Call stand? August 24th has passed ... I do know Ted wants to see an I-D regarding the multiple provisioning domai= ns but I am not sure whether that would block draft-ietf-dhc-dhcpv6-statefu= l-issues-00 until available. I just haven't had much time to work on that I= D -- the concept is fairly simple in that servers would have to include the= provisioning domain identifier in their responses and clients would have t= o make decisions based on the provisioning identifier - Advertisements that= have the same provisioning identifier are selected from pretty much as cli= ents do today without this support and if multiple provisioning identifiers= are present, a client can select one Advertisement from each set and fork = separate transactions (when and why a client may want to do this need to be= worked out - such as is it only done if one domain provides addresses and = another prefixes, or should the client do it always). It likely is also app= ropriate to allow a user to control which provisioning domains are to be us= ed (much like Wifi network selections). There may also be some authenticati= on information that could be used (much like the Wifi shared secret). - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Thursday, August 09, 2012 11:15 PM To: dhc WG Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 The authors have requested a working group last call. The document descri= bes some problems that exist in the way DHCP clients handle multiple statef= ul options, and proposes a solution that unifies the client state machine t= o accommodate these issues. This document could use additional review, so please take the time to read = it over and comment on it if you have any comments. If you are in favor o= f advancing the document, please say so. If you oppose advancing it, plea= se say so, and say why. We will evaluate the consensus based on these res= ponses on August 24. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From internet-drafts@ietf.org Fri Sep 7 08:20:21 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAC221F8681; Fri, 7 Sep 2012 08:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmOApfs4YEaD; Fri, 7 Sep 2012 08:20:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB7A21F8671; Fri, 7 Sep 2012 08:20:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120907152021.23654.74974.idtracker@ietfa.amsl.com> Date: Fri, 07 Sep 2012 08:20:21 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-failover-requirements-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:20:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : DHCPv6 Failover Requirements Author(s) : Tomasz Mrugalski Kim Kinnear Filename : draft-ietf-dhc-dhcpv6-failover-requirements-02.txt Pages : 20 Date : 2012-09-07 Abstract: The DHCPv6 protocol, defined in [RFC3315] allows for multiple servers to operate on a single network, however it does not define any way the servers could share information about currently active clients and their leases. Some sites are interested in running multiple servers in such a way as to provide increased availability in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. [RFC3315] allows for but does not define any redundancy or failover mechanisms. This document outlines requirements for DHCPv6 failover, enumerates related problems, and discusses the proposed scope of work to be conducted. This document does not define a DHCPv6 failover protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirements-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-failover-requireme= nts-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Sep 7 08:21:38 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1591321F8581; Fri, 7 Sep 2012 08:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nht3WjIsWvBA; Fri, 7 Sep 2012 08:21:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FA021F8673; Fri, 7 Sep 2012 08:21:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120907152137.16776.42357.idtracker@ietfa.amsl.com> Date: Fri, 07 Sep 2012 08:21:37 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-failover-design-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:21:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : DHCPv6 Failover Design Author(s) : Tomasz Mrugalski Kim Kinnear Filename : draft-ietf-dhc-dhcpv6-failover-design-01.txt Pages : 50 Date : 2012-09-07 Abstract: DHCPv6 defined in [RFC3315] does not offer server redundancy. This document defines a design for DHCPv6 failover, a mechanism for running two servers on the same network with capability for either server to take over clients' leases in case of server failure or network partition. This is a DHCPv6 Failover design document, it is not protocol specification document. It is a second document in a planned series of three documents. DHCPv6 failover requirements are specified in [I-D.ietf-dhc-dhcpv6-failover-requirements]. A protocol specification document is planned to follow this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-design There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-failover-design-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Ted.Lemon@nominum.com Fri Sep 7 08:27:34 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F14A21F8690 for ; Fri, 7 Sep 2012 08:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.505 X-Spam-Level: X-Spam-Status: No, score=-106.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WNtI6bOIqek for ; Fri, 7 Sep 2012 08:27:34 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id BA23121F866B for ; Fri, 7 Sep 2012 08:27:33 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUEoSZXYeYXoHCbageAyI+yg/E7zm8pl4@postini.com; Fri, 07 Sep 2012 08:27:33 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0F7741B8330 for ; Fri, 7 Sep 2012 08:27:33 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 03EB519005C; Fri, 7 Sep 2012 08:27:33 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 7 Sep 2012 08:27:33 -0700 From: Ted Lemon To: Donald Eastlake Thread-Topic: [dhcwg] Load Balancing for DHCPv6 Thread-Index: AQHNhTu7gFlX/ZntC0OFRh8xVQ/AAZdwtBEAgACi1QCAAB9FgIAAA4kAgAABYICADN9FgIAAAfqAgADKnoCAABhfgIAAOiqAgAAMAAA= Date: Fri, 7 Sep 2012 15:27:32 +0000 Message-ID: <71F17433-B2D9-4366-9B32-F0E4D294EDB5@nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> <5049C317.7090603@gmail.com> <94FA926F-2432-4AE7-BC20-AE7458AB40D9@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <0BF2524C56AA624FA14E9FC31B254677@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:27:34 -0000 On Sep 7, 2012, at 10:44 AM, Donald Eastlake wrote: > If it is working fine, there is certainly no reason to change it, > which could lead to interoperability problems. But I'd be willing to > bet that FNV is superior... There's no risk of an interoperability problem, since DHCPv6 and DHCPv4 nev= er interoperate. However, the advantages of the hash mentioned in the dra= ft are pretty handwavy. Is there any more detailed analysis somewhere? From ichiroumakino@gmail.com Fri Sep 7 08:30:48 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C7321F86D0 for ; Fri, 7 Sep 2012 08:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nP96owUr2BZ3 for ; Fri, 7 Sep 2012 08:30:47 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 695F221F86C2 for ; Fri, 7 Sep 2012 08:30:47 -0700 (PDT) Received: by eekb45 with SMTP id b45so1316902eek.31 for ; Fri, 07 Sep 2012 08:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=qfXwIuR+RpD/tmS9tTct/41Z1IjhdXPD2YjZ5SQRyz8=; b=A202+oqnTfeIRosBVEqH4+Kk9xr4J1NrOIpjKazzllxvs6qhK2i7wwpie/xBydhSUQ CltTuRkKOBW2w2GUwdqaS5kfS1pnLEuQ163abgkI4X+z9zw8YP8rEwQwbX4GBZTrtmYI gTpiSz+mINY68OPxQTY1UCe1+RL7tO+F2ouPBbXWAUCRxUY7gElsgFk2cSiZtyH0Nueb Yg6xp8LJRNGfA7J5KR1ALI32Zn8UcyDNUI+pILDB7uT4Xzm7Hih2OFXW5IQSllnMNHQV hyKnVIFG64gLQ0RtHztLOvcfvLkLT8ZxBG31xS24POSDqUB4IP+ncLwGWPZa47B4NT1t NiHA== Received: by 10.14.175.7 with SMTP id y7mr8454159eel.29.1347031846620; Fri, 07 Sep 2012 08:30:46 -0700 (PDT) Received: from ?IPv6:2a02:fe0:cf15:30:5cdb:e28b:d24c:c442? ([2a02:fe0:cf15:30:5cdb:e28b:d24c:c442]) by mx.google.com with ESMTPS id u47sm15587677eeo.9.2012.09.07.08.30.44 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Sep 2012 08:30:45 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_B124D37A-F103-40EE-9745-BCC0B0EDC3C4"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <5049E443.5040305@gmail.com> Date: Fri, 7 Sep 2012 17:30:42 +0200 Message-Id: <48CC6041-9BAA-4D92-A13E-307BB7CBA459@employees.org> References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> <5049E443.5040305@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1278) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:30:48 -0000 --Apple-Mail=_B124D37A-F103-40EE-9745-BCC0B0EDC3C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Alex, [...] >> this does not solve the DHCPv6 PD problem of route injection. a >> route needs to be installed per client, and snooping is still needed >> for that. this proposal _only_ solves the problem of installing an >> aggregate route for multiple PD RRs into a PE/relay. >=20 > In a sense I agree - this proposal seems to still require snooping. > (i.e. existing single prefixes in PD require snooping and pool-opt = draft > requires it too). >=20 >> this is most typically done with static configuration today. >=20 > Well no, static configuration at Relay is not sufficient for PD to = work, > even if we dont talk pool-opt draft - there is a need of that route at > Relay. There is no other solution to that than DHCP Relay to become > more intelligent (i.e. "snoop"). the _aggregate route_ (i.e the route covering the PD prefixes) = installation and redistribution in an IGP is typically done with manual = configuration on the PEs. route injection by PD itself, is typically done by DHCP snooping. cheers, Ole= --Apple-Mail=_B124D37A-F103-40EE-9745-BCC0B0EDC3C4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwOTA3MTUzMDQzWjAjBgkqhkiG9w0BCQQxFgQUOk98Yv6GBN4BkKiZ z73KoZGlxOwwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAO2mJVr8Yu2JIf6NEaOb8 b290b0iaPOtG+I00DpdG8xH/n6a9nwQF1409Ez3OTrLe74nCyHOuEX79sckQAnqb6qdH19B3cfku 7IcAabDXreh99yh5IE2FDDfpr02Cis6TPQ85VWrF9QK51G6+NbtXFMM/tq0RMCrSQNRG3Am16hsc jSGBez26SFoK4Hz96YOBwP3OPV2n5Tf9+VGuitPGtZcNwmhiN6zt1aIBv+6CmLQss9hNTUL4kHuk jQolVUOn+jZqMaUfUbc4MFcFfFXCWY9TvNVv6jYTvqIvbMdTRHE+NgtyL53GiM9KKBMRW1DjppZv LNZ2pHy7NOxlfK0ijwAAAAAAAA== --Apple-Mail=_B124D37A-F103-40EE-9745-BCC0B0EDC3C4-- From Ted.Lemon@nominum.com Fri Sep 7 08:38:15 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C4821F855A for ; Fri, 7 Sep 2012 08:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.516 X-Spam-Level: X-Spam-Status: No, score=-106.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8F9BaL6KDyP for ; Fri, 7 Sep 2012 08:38:14 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 964F621F855F for ; Fri, 7 Sep 2012 08:38:14 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUEoU5kfRBHfZ6tTBFxXXcFS21C/QE7kS@postini.com; Fri, 07 Sep 2012 08:38:14 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D90691B832F for ; Fri, 7 Sep 2012 08:38:13 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id CC8E919005C; Fri, 7 Sep 2012 08:38:13 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 7 Sep 2012 08:38:13 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpd/JdswgAB/xoA= Date: Fri, 7 Sep 2012 15:38:13 +0000 Message-ID: <21C54D57-372F-46B0-892B-398919992546@nominum.com> References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F83D1@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F4F83D1@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <243F27FC502C704585DBB564AF1D9DD6@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:38:15 -0000 On Sep 7, 2012, at 11:09 AM, Bernie Volz (volz) wrote: > Where does this Last Call stand? August 24th has passed ... There were a lot of comments in the WGLC, and lot of support for what is to= be accomplished here, but several people raised concerns as well. There = were a few responses in favor of advancing the current document; Hemant Sin= gh had some suggestions, to which Ole responded. I do not know if the res= ponses satisfied Hemant's concerns. I raised some concerns which were not= really addressed. Wes Beebe raised a concern which Ole responded to, but= again I don't know if Wes was satisfied with Ole's response. So I think this is borderline. There's clearly widespread support for wha= t this draft is trying to do; I would like to hear from Hemant and Wes as t= o whether they are satisfied with Ole's responses. I tend to agree with W= es' sentiment that we need to think this through very carefully; I would li= ke to see a new draft that addresses Hemant's and Wes' concerns, if possibl= e, and then do a second last call to get more review. Does that work for = the authors?= From Ted.Lemon@nominum.com Fri Sep 7 08:39:55 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361FE21F855F for ; Fri, 7 Sep 2012 08:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.374 X-Spam-Level: X-Spam-Status: No, score=-106.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3ULlMSdEJn7 for ; Fri, 7 Sep 2012 08:39:54 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB3121F855A for ; Fri, 7 Sep 2012 08:39:54 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUEoVSiiCElmYrlJ5A5XpvQVJIWEmm0ZR@postini.com; Fri, 07 Sep 2012 08:39:54 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 3E50D1B832F for ; Fri, 7 Sep 2012 08:39:52 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3749A19005C; Fri, 7 Sep 2012 08:39:52 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 7 Sep 2012 08:39:52 -0700 From: Ted Lemon To: =?Windows-1252?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Thread-Index: AQHNjPHVwYEl2V2/qUGyV2fW0++Fb5d/dvAAgAACjoA= Date: Fri, 7 Sep 2012 15:39:51 +0000 Message-ID: <96001808-B7B2-47F2-8E4C-CB292BF41862@nominum.com> References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> <5049E443.5040305@gmail.com> <48CC6041-9BAA-4D92-A13E-307BB7CBA459@employees.org> In-Reply-To: <48CC6041-9BAA-4D92-A13E-307BB7CBA459@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <46E6FF6354C4934DB0C47F2A20EDC9A9@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Alexandru Petrescu Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:39:55 -0000 On Sep 7, 2012, at 11:30 AM, Ole Tr=F8an wrote: > the _aggregate route_ (i.e the route covering the PD prefixes) installati= on and redistribution in an IGP is typically done with manual configuration= on the PEs. Right. This is a proposal to do it differently. From leaf.yeh.sdo@gmail.com Fri Sep 7 09:06:55 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738C621E8040 for ; Fri, 7 Sep 2012 09:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGUXDQgNx9Pd for ; Fri, 7 Sep 2012 09:06:54 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id EFBAE21E8034 for ; Fri, 7 Sep 2012 09:06:53 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so4157036pbb.31 for ; Fri, 07 Sep 2012 09:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=Dh03UjFhw7cUaZg1wFgT9+aHfTSmjhpGEoMcE0ORioc=; b=wTPgiyqzXe+N4qFbn9sjMiTeXcp6JvcwmzdEBgDNFaak6y6jGF0fg0ZtZIvcztZIXf esxpMENeJyFL9IWeX8TlHIJLpgkBofPGULIxCtvJZ83sRXqI48R3+Sc2CUdKoY5t9HTG 4pUiGZe+Bz8MPHnxWDMvD2Qz3SyIZnDmys4xrp6J/2hKIWQ/8/B/IZGqJyL7CKP0BUGx /7RcZIihAAqHa+2H+JXwsibkhVrG+drsDk+APfbMwO5Btdq+bBBx4EYR0z9tAVhBYD2p kWslnxkF85lfYGLjMfdFZ9LDsxLRvhKnGxnCQZQkWJg6AdnZ/sfZuCzd46B9auXOEODP D3Jw== Received: by 10.68.203.196 with SMTP id ks4mr10347252pbc.107.1347034013734; Fri, 07 Sep 2012 09:06:53 -0700 (PDT) Received: from lst9242355d22a ([218.18.199.45]) by mx.google.com with ESMTPS id jz4sm3354646pbc.17.2012.09.07.09.06.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Sep 2012 09:06:52 -0700 (PDT) From: "Leaf Yeh" To: =?iso-8859-1?Q?'Ole_Tr=F8an'?= , "'Alexandru Petrescu'" References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> <5049E443.5040305@gmail.com> <48CC6041-9BAA-4D92-A13E-307BB7CBA459@employees.org> In-Reply-To: <48CC6041-9BAA-4D92-A13E-307BB7CBA459@employees.org> Date: Sat, 8 Sep 2012 00:06:51 +0800 Message-ID: <504a1b9c.64c9440a.61e1.4dfe@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2NDcOj8ferFqxnQde+rWTnvY/GkQAAfV3w Content-Language: zh-cn Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 16:06:55 -0000 Ole - the _aggregate route_ (i.e the route covering the PD prefixes) installation and redistribution in an IGP is typically done with manual configuration on the PEs. route injection by PD itself, is typically done by DHCP snooping. Agreed the above if we don't have draft (OPTION_PREFIX_POOL). :-) DHCPv6-PD inject the dynamic routes per the lease of delegated prefixes, while the draft (OPTION_PREFIX_POOL) help to inject the *dynamic* aggregation route per the *status* of the prefix pool. (See the definition of *status* in Section 4 ) All the configuration for the necessary aggregation routes (on the relay) per the prefix pools (and its status) turns to be automatic after employing the mechanism newly introduced in this draft. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ole Tr?an Sent: Friday, September 07, 2012 11:31 PM To: Alexandru Petrescu Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Alex, [...] >> this does not solve the DHCPv6 PD problem of route injection. a route >> needs to be installed per client, and snooping is still needed for >> that. this proposal _only_ solves the problem of installing an >> aggregate route for multiple PD RRs into a PE/relay. > > In a sense I agree - this proposal seems to still require snooping. > (i.e. existing single prefixes in PD require snooping and pool-opt > draft requires it too). > >> this is most typically done with static configuration today. > > Well no, static configuration at Relay is not sufficient for PD to > work, even if we dont talk pool-opt draft - there is a need of that > route at Relay. There is no other solution to that than DHCP Relay to > become more intelligent (i.e. "snoop"). the _aggregate route_ (i.e the route covering the PD prefixes) installation and redistribution in an IGP is typically done with manual configuration on the PEs. route injection by PD itself, is typically done by DHCP snooping. cheers, Ole From tomasz.mrugalski@gmail.com Fri Sep 7 09:13:12 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44FC21F871A for ; Fri, 7 Sep 2012 09:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fsmed94Z646a for ; Fri, 7 Sep 2012 09:13:12 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id B6B4F21F8713 for ; Fri, 7 Sep 2012 09:13:11 -0700 (PDT) Received: by eekb45 with SMTP id b45so1350109eek.31 for ; Fri, 07 Sep 2012 09:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=bRlXdQFZEqdvlgiHj99V1jxU+ZQUhkbjnrRD8vHcuKM=; b=zqEEGJxhi/YwvEJyrwoOxyfPBw1/hVONIpddva1CY+HzEV9rwr0ZR9Bghw4UqNk9K6 5sE0e/N9BNrAWybXoH45NaVAp9y7l5gb3iY0HGpYozwcsMEUF19Ix4d+XhEHPU6G3wtg q7cy/xcr9gz0a/z9RcyNIKgRz8E/jEp0STXHrzOuO0lOSIR/moK858F37fGtJlWNrU1D hizBgOIhk4HG7J5+H5BJyh9JEGgSbqfAsfV/fQCJoBnRmY4bUcve2CTMj13g1Zz1aapD 8I/aX7ZmoHha/m62hydGqs2eBBMCxkF64HbIK7GJ2UBNreC/xO2+agbT0AayG8gH69TQ UNrA== Received: by 10.14.173.131 with SMTP id v3mr3267073eel.15.1347034390968; Fri, 07 Sep 2012 09:13:10 -0700 (PDT) Received: from ?IPv6:2001:470:6061:1:e086:e8e7:836c:20ad? ([2001:470:6061:1:e086:e8e7:836c:20ad]) by mx.google.com with ESMTPS id i8sm15906456eeo.16.2012.09.07.09.13.09 (version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 09:13:10 -0700 (PDT) Message-ID: <504A1D13.8090003@gmail.com> Date: Fri, 07 Sep 2012 18:13:07 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: dhcwg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCPv6 failover update X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 16:13:12 -0000 Hi, You may have noticed some recent movements in the failover area. It may be a bit confusing, so I wanted to explain what has happened recently. Step 0: DHCPv6 Redundancy Considerations draft-ietf-dhc-dhcpv6-redundancy-consider-03 This draft is in IESG review now. A kind of soft discuss was raised, so authors worked on an updated version that hopefully addresses all concerns. It already completed WGLC, so no extra actions are requested at this time. Of course, you are welcome to (re)read and review it, but if your time is limited, there are better things to do to help with failover (see steps 1 and 2 below). Step 1: DHCPv6 Failover Requirements draft-ietf-dhc-dhcpv6-failover-requirements-02 This is a first in a series of 3 drafts planned. It lays out requirements for DHCPv6 failover. Authors believe that work on this document is more or less done and would like to ask for WGLC. If you have only short time for failover related things, please review this. Step 2: DHCPv6 Failover Design draft-ietf-dhc-dhcpv6-failover-design-01 This is the actual design. There is a significant progress from the -00 version, but this work is not complete yet. Although failover endpoints state machine and lease lifecycle descriptions are more or less complete, there are still missing bits and pieces. See several TODO tags in the txt version or issues marked in XML version. It would be great to hear your comments and suggestions about this draft, or even better, contributed text for missing pieces. There is a step 3 planned - the actual on-wire spec for the design laid out in failover-design draft. This work hasn't started yet. If you are interested in the failover work, you are more then welcome to join the effort. We have a public GIT repo for intermediate versions, with a simple list of issues, historical v4 failover drafts etc. It is available here: https://github.com/tomaszmrugalski/ietf-dhcpv6-fo Cheers, Tomek From volz@cisco.com Fri Sep 7 09:18:30 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C54B21F8466 for ; Fri, 7 Sep 2012 09:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYcYwL4zjJPR for ; Fri, 7 Sep 2012 09:18:29 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0E60E21F845C for ; Fri, 7 Sep 2012 09:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6393; q=dns/txt; s=iport; t=1347034709; x=1348244309; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pcZud1fGHydTm11KG99QvRLrGzXJbXkSdT4U46VS7tQ=; b=P4T41Q7JCKMWa1KELJz/FoKzy2Eb6e7fmiZaG7bn8NqUZeRpCzV4XNhP INYTPtJXVgxH4Fe4GdjelCfpJCeLwQggWcWJMjQpQhwBILW5la89w5Oi0 4y89OIr5KRqJL50MIHyk+8wA+KQIl0Kd+JUol/Yfll5aDNjzRFh8B83k2 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADcdSlCtJXHA/2dsb2JhbABABbs7gQeCIAEBAQMBEgEnLQsHBQcEAgEIEQQBAQEKFAkHMhQJCAIEDgUIEweHaAabLqBIixIohSxgA6QSgWeCZIFj X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="116364986" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 07 Sep 2012 16:18:28 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q87GIREd006724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Sep 2012 16:18:27 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Fri, 7 Sep 2012 11:18:27 -0500 From: "Bernie Volz (volz)" To: Ted Lemon Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpd/JdswgAB/xoD//5GrgA== Date: Fri, 7 Sep 2012 16:18:27 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F4F857F@xmb-rcd-x04.cisco.com> References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F83D1@xmb-rcd-x04.cisco.com> <21C54D57-372F-46B0-892B-398919992546@nominum.com> In-Reply-To: <21C54D57-372F-46B0-892B-398919992546@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.254] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19168.005 x-tm-as-result: No--47.750300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG , "Ole Troan \(otroan\)" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 16:18:30 -0000 I believe Wes' and Hemant's issues were: Wes (message on Thu 8/16/2012): Why MUST the client ignore an Advertise message with no bindings? What if stateful and stateless options are carried in the same message? Does this mean the stateless options will be ignored just because the st= ateful Options failed? --- Ole's answer was that basically this is how RFC 3315 operates today and we = didn't want to change this (we are fixing what happens if IA_NA and IA_PD a= re requested in a Solicit and only one of these is available) -- which is d= ifferent than the no bindings at all case. RFC 3315 basically expects clien= ts to use Information-Request in this case. A while back, Ralph and I considered that this might be a good change - esp= ecially given the case when M says to use stateful but the server is not co= nfigured to give (the requesting client) any stateful bindings. Server coul= d effectively respond with the other configuration options. But an Advertis= e is not the same as a Reply, so if the client was going to do a Request/Re= ply, we'd have to change that processing to and so why doesn't the client j= ust do an Information-Request? (Sure, if Rapid Commit is requested, server = would just Reply and client would be done.) If the WG feels that would be a useful change, we can certainly do this cha= nge. But for this particular work, we didn't feel that change was warranted= . And, it might be best to do under a separate document? Or something for a= 3315bis? Hemant (message on 8/17/2012) and Ole's response (using Ole's email on 8/20= /2012): > +1 to Wes' comment that this document is addressing a very important prob= lem space and the solutions are needed urgently. However, more thought is = required for the solutions. >=20 > In regards to section 4.4, if the server only checks the network configur= ation to reply to a Confirm message, how is it possible for most network co= nfigurations that the server determines an IA_PD is on-link? I suspect th= at is why RFC 3633 prohibited use of the Confirm for the IA_PD. In any cas= e this document should explain why did RFC 3633 have a restriction on using= the Confirm for the IA_PD. Or does network configuration include looking = up the prefix pool configured on the server for allocation? In contrast, t= o make an on-link determination for an IA_NA IA_Address, all the server has= to do is match (longest-prefix match) all IPv6 addresses configured on the= machine that the server is running on. These addresses are clearly networ= k configuration. =20 right, either the server has the binding, or the server has configuration t= hat it can look up in, to verify if the client has moved or not. if it has = no information it MUST not reply. > Section 4.1: =20 >=20 > # In relation to the first paragraph the document is addressing the fact = that one server replies with, say, an IA_NA, while another server replies b= ack with only the IA_PD. Then why in section 4.7 the case of section 4.1 = is deemed out of scope? I also do not understand what does "equal" in sec= tion 4.7 mean. Does it mean each server replies with all IAs that the depl= oyment needs? the assumption in 3315/3633 is that a client is connected to a single admin= istrative dhc domain on an interface. scenarios where a client finds two DHCP servers, that are administered by t= wo different entities, are outside of the scope of 3315/3633 and therefore = also outside the scope of this update. there is as far as I know separate w= ork in progress on this. > # In relation to the text in the last paragraph of section 4.1, if the cl= ient does not restart the Solicit retransmissions timers, what does the cli= ent do? continues with the timers it has. otherwise as the text says, a received advertise with a consequent restart = of solicit timers would result in a solicit storm. >=20 > # Other comment: Shouldn't the header of the document have an Updates ta= g to signify this document updates RFC 3315? good point. both 3315 and 3633. --- I guess the one change that I see is to assure we update the document heade= r. We can respin the document for this change. Section 4.4 is just extending the Confirm to include prefixes - this issue = is already covered in RFC 3315 for Confirm processing: If the serve= r is unable to perform this test (for example, the server does not have information about prefixes on the link to which the client is connected), or there were no addresses in any of the IAs sent by the client, the server MUST NOT send a reply to the client. The section 4.1 / 4.7 issue is the single vs multiple provisioning domains = - we assume a single in this document. If Wes or Hemant would like other changes to clarify any of their concerns,= we would appreciate text to be added/modified. - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Friday, September 07, 2012 11:38 AM To: Bernie Volz (volz) Cc: dhc WG Subject: Re: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 On Sep 7, 2012, at 11:09 AM, Bernie Volz (volz) wrote: > Where does this Last Call stand? August 24th has passed ... There were a lot of comments in the WGLC, and lot of support for what is to= be accomplished here, but several people raised concerns as well. There = were a few responses in favor of advancing the current document; Hemant Sin= gh had some suggestions, to which Ole responded. I do not know if the res= ponses satisfied Hemant's concerns. I raised some concerns which were not= really addressed. Wes Beebe raised a concern which Ole responded to, but= again I don't know if Wes was satisfied with Ole's response. So I think this is borderline. There's clearly widespread support for wha= t this draft is trying to do; I would like to hear from Hemant and Wes as t= o whether they are satisfied with Ole's responses. I tend to agree with W= es' sentiment that we need to think this through very carefully; I would li= ke to see a new draft that addresses Hemant's and Wes' concerns, if possibl= e, and then do a second last call to get more review. Does that work for = the authors? From Ted.Lemon@nominum.com Fri Sep 7 09:22:24 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C53D21F85C0 for ; Fri, 7 Sep 2012 09:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.517 X-Spam-Level: X-Spam-Status: No, score=-106.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g71hSZ-cXy-A for ; Fri, 7 Sep 2012 09:22:23 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9373221F8557 for ; Fri, 7 Sep 2012 09:22:23 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUEofP7P0crdqtuAKsGnYPXQ/+8tH5rtn@postini.com; Fri, 07 Sep 2012 09:22:23 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 70F981B8341 for ; Fri, 7 Sep 2012 09:22:22 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 66AAE19005C; Fri, 7 Sep 2012 09:22:22 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 7 Sep 2012 09:22:22 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpd/JdswgAB/xoD//5GrgIAAeqgA Date: Fri, 7 Sep 2012 16:22:22 +0000 Message-ID: References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F83D1@xmb-rcd-x04.cisco.com> <21C54D57-372F-46B0-892B-398919992546@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F857F@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F4F857F@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG , "Ole Troan \(otroan\)" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 16:22:24 -0000 Was that a yes or a no? From volz@cisco.com Fri Sep 7 09:41:15 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C86221E804E for ; Fri, 7 Sep 2012 09:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1q1TVmwUB7Zg for ; Fri, 7 Sep 2012 09:41:15 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E469B21E8034 for ; Fri, 7 Sep 2012 09:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=859; q=dns/txt; s=iport; t=1347036075; x=1348245675; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WwiiNs63ma3JFFZn3XXi8hVd7pZd6cIudcrboX78EG0=; b=B6MnV/ugZJMICEgjNzaFP0wmbPBANgaJgOygJsmupCRHmifip7gcrw2M 7etw3KPoB471axyvYSEuqFM6Ij3Gbu7Idmh2q7lEd1bEQImoVI8g81kkU XC4/8I+NKhBnnRKZNSrvOiy+09SCCCHSKvpTUBk9pA1AnMiZThDVn1JjQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAHQiSlCtJXG9/2dsb2JhbABFhUC1fIEHgiABAQEEEgEnPwwEAgEIEQQBAQsUCQcyFAkIAgQOBQgah26bNaA/ixKFVGADpBKBZ4Jk X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="119375536" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 07 Sep 2012 16:41:14 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q87GfEGS016677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Sep 2012 16:41:14 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Fri, 7 Sep 2012 11:41:14 -0500 From: "Bernie Volz (volz)" To: Ted Lemon Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpd/JdswgAB/xoD//5GrgIAAeqgA//+K+5A= Date: Fri, 7 Sep 2012 16:41:13 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F4F85BA@xmb-rcd-x04.cisco.com> References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F83D1@xmb-rcd-x04.cisco.com> <21C54D57-372F-46B0-892B-398919992546@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F857F@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.254] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19168.005 x-tm-as-result: No--28.232400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG , "Ole Troan \(otroan\)" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 16:41:15 -0000 Ted: Speaking for myself, I believe the answer is yes ... once I know what the s= cope of changes are (other than indicating that the document updates 3315/3= 633), I am happy to update and respin the document and do a second WG last = call if the changes warrant or if the chairs or WG feels it is needed. I too would like to have seen and see more people comment on this because t= here are some fairly significant changes. It also surprises me that few of = the people that pushed for these changes have commented. - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Friday, September 07, 2012 12:22 PM To: Bernie Volz (volz) Cc: dhc WG; Wes Beebee (wbeebee); Hemant Singh (shemant); Ole Troan (otroan= ) Subject: Re: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Was that a yes or a no? From Ted.Lemon@nominum.com Fri Sep 7 09:43:43 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75C521F8653 for ; Fri, 7 Sep 2012 09:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELWN8ntglO0E for ; Fri, 7 Sep 2012 09:43:43 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id DF03F21F862A for ; Fri, 7 Sep 2012 09:43:42 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUEokPulrgRGkm/ylALBAccIF9Z0F7R4/@postini.com; Fri, 07 Sep 2012 09:43:42 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 14CB71B8330 for ; Fri, 7 Sep 2012 09:43:42 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0B6A419005C; Fri, 7 Sep 2012 09:43:42 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 7 Sep 2012 09:43:42 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpd/JdswgAB/xoD//5GrgIAAeqgA//+K+5CAAHr7AA== Date: Fri, 7 Sep 2012 16:43:41 +0000 Message-ID: References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F83D1@xmb-rcd-x04.cisco.com> <21C54D57-372F-46B0-892B-398919992546@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F857F@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E0F4F85BA@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F4F85BA@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <005A69BFB36B4E4189D1E6D1CD7F6359@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG , "Ole Troan \(otroan\)" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 16:43:44 -0000 On Sep 7, 2012, at 12:41 PM, "Bernie Volz (volz)" wrote: > Speaking for myself, I believe the answer is yes ... once I know what the= scope of changes are (other than indicating that the document updates 3315= /3633), I am happy to update and respin the document and do a second WG las= t call if the changes warrant or if the chairs or WG feels it is needed. >=20 > I too would like to have seen and see more people comment on this because= there are some fairly significant changes. It also surprises me that few o= f the people that pushed for these changes have commented. Yes, I think that's what Wes was getting at as well. I will give the docu= ment a thorough read during the new WGLC. From d3e3e3@gmail.com Fri Sep 7 14:37:42 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EFB21E80CB for ; Fri, 7 Sep 2012 14:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXsuA5JWkWLE for ; Fri, 7 Sep 2012 14:37:40 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B77D321E808F for ; Fri, 7 Sep 2012 14:37:40 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so76781obb.31 for ; Fri, 07 Sep 2012 14:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OuisrMBw+si0z/fxWLm8+i1qggpyFUx2VoXwREMzADE=; b=QiUd8GHI9Cb3A4/V4dE3Ivc6jvrd33xqLnftu2O2hzs9Ha/h3ah0WY0l6ciYWHEeIp r2s4+7OlRI2xU5uMEO71v+wTQlOcIrk3b9et+QHDtk6zHpwiXMUQYPc1TylVS71gVqRe AvQDPPTYOcYavCIiOHjwMqIebNjVlql11hKA5DyGt9E7JJuQ7zcZemGH862Ak4W+chiP 8AbBMjZ0TCG8xQvOBywXeIl3E/uPyyZerT41Tu2mveWIl59xwEg3e4+fZZFQU9JbNqiH RAVPhbuYxplXrfXQmCWaIIeu1csCm5x5u0jFWGMnRQESyIac/Ak2biOFAotXyC4kpmXe xzoA== Received: by 10.60.1.106 with SMTP id 10mr3344107oel.84.1347053860201; Fri, 07 Sep 2012 14:37:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.135.1 with HTTP; Fri, 7 Sep 2012 14:37:19 -0700 (PDT) In-Reply-To: <71F17433-B2D9-4366-9B32-F0E4D294EDB5@nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> <5049C317.7090603@gmail.com> <94FA926F-2432-4AE7-BC20-AE7458AB40D9@cisco.com> <71F17433-B2D9-4366-9B32-F0E4D294EDB5@nominum.com> From: Donald Eastlake Date: Fri, 7 Sep 2012 17:37:19 -0400 Message-ID: To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 21:37:42 -0000 Hi Ted, On Fri, Sep 7, 2012 at 11:27 AM, Ted Lemon wrote: > On Sep 7, 2012, at 10:44 AM, Donald Eastlake wrote: >> If it is working fine, there is certainly no reason to change it, >> which could lead to interoperability problems. But I'd be willing to >> bet that FNV is superior... > > There's no risk of an interoperability problem, since DHCPv6 and DHCPv4 never interoperate. However, the advantages of the hash mentioned in the draft are pretty handwavy. Is there any more detailed analysis somewhere? Here is one study done by Brian Carpenter related to equal cost multi-path hashing based on the IP 5-tuple: https://researchspace.auckland.ac.nz/bitstream/handle/2292/13240/flowhashRep.pdf?sequence=2 Here is a study done by Puneet Agarwal (of Broadcom) related to equal cost multi-path hashing based on Layer 2 headers: http://www.ieee802.org/1/files/public/docs2011/bp-agarwal-hash-proposal-0411-v03.pdf FNV takes a little more effort than Pearson. It also has a smaller footprint in memory. And I believe it will produce statistically better results. What are the relative weights of these or other factors in this case? Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From Ted.Lemon@nominum.com Fri Sep 7 15:29:22 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D6B21F8512 for ; Fri, 7 Sep 2012 15:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.53 X-Spam-Level: X-Spam-Status: No, score=-106.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0irkFfFrHst for ; Fri, 7 Sep 2012 15:29:22 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id DE05521F850C for ; Fri, 7 Sep 2012 15:29:21 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUEp1QWio/gFw5WUqJz59GhjjCyYyHsbk@postini.com; Fri, 07 Sep 2012 15:29:21 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0F6131B8330 for ; Fri, 7 Sep 2012 15:29:21 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id F1B8E19005C; Fri, 7 Sep 2012 15:29:20 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 7 Sep 2012 15:29:21 -0700 From: Ted Lemon To: Donald Eastlake Thread-Topic: [dhcwg] Load Balancing for DHCPv6 Thread-Index: AQHNhTu7gFlX/ZntC0OFRh8xVQ/AAZdwtBEAgACi1QCAAB9FgIAAA4kAgAABYICADN9FgIAAAfqAgADKnoCAABhfgIAAOiqAgAAMAACAAGdRgIAADogA Date: Fri, 7 Sep 2012 22:29:20 +0000 Message-ID: References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> <5049C317.7090603@gmail.com> <94FA926F-2432-4AE7-BC20-AE7458AB40D9@cisco.com> <71F17433-B2D9-4366-9B32-F0E4D294EDB5@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <15C6AA3B783B5A4887E32ADDCCFD11B3@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 22:29:22 -0000 On Sep 7, 2012, at 5:37 PM, Donald Eastlake wrote: > FNV takes a little more effort than Pearson. It also has a smaller > footprint in memory. And I believe it will produce statistically > better results. What are the relative weights of these or other > factors in this case? Unfortunately, as far as I can tell neither of the studies you cite compare= s FNV to Pearson, although the results from Brian Carpenter's study are cer= tainly pretty impressive. I think more work is worse, smaller footprint = probably doesn't matter (this algorithm is being run in DHCP servers, which= typically aren't seriously memory-constrained), and statistically better r= esults only matter if it's a pretty big difference, so it's frustrating tha= t we don't have a comparison to the existing algorithm. To me, the biggest win of using FNV would be if there were an RFC to refer = to, but it looks like this is not quite there yet. So my conclusion is th= at I certainly don't oppose using FNV instead of Pearson, but I don't see a= strong reason to support it either. From alexandru.petrescu@gmail.com Sat Sep 8 09:17:27 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8617721F8549 for ; Sat, 8 Sep 2012 09:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.129 X-Spam-Level: X-Spam-Status: No, score=0.129 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16O-eypJWcLo for ; Sat, 8 Sep 2012 09:17:26 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 55B1A21F84AE for ; Sat, 8 Sep 2012 09:17:24 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 3CD68940048; Sat, 8 Sep 2012 18:17:17 +0200 (CEST) Message-ID: <504B6F87.9000306@gmail.com> Date: Sat, 08 Sep 2012 18:17:11 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: =?windows-1252?Q?Ole_Tr=F8an?= References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> <5049E443.5040305@gmail.com> <48CC6041-9BAA-4D92-A13E-307BB7CBA459@employees.org> In-Reply-To: <48CC6041-9BAA-4D92-A13E-307BB7CBA459@employees.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 120908-0, 08/09/2012), Outbound message X-Antivirus-Status: Clean Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 16:17:27 -0000 Hello Ole, I meant the following below... Le 07/09/2012 17:30, Ole Trĝan a écrit : > Alex, > > [...] > >>> this does not solve the DHCPv6 PD problem of route injection. a >>> route needs to be installed per client, and snooping is still >>> needed for that. this proposal _only_ solves the problem of >>> installing an aggregate route for multiple PD RRs into a >>> PE/relay. >> >> In a sense I agree - this proposal seems to still require >> snooping. (i.e. existing single prefixes in PD require snooping and >> pool-opt draft requires it too). >> >>> this is most typically done with static configuration today. >> >> Well no, static configuration at Relay is not sufficient for PD to >> work, even if we dont talk pool-opt draft - there is a need of >> that route at Relay. There is no other solution to that than DHCP >> Relay to become more intelligent (i.e. "snoop"). > > the _aggregate route_ (i.e the route covering the PD prefixes) > installation and redistribution in an IGP is typically done with > manual configuration on the PEs. > > route injection by PD itself, is typically done by DHCP snooping. I meant to say that DHCP snooping is needed anyway to insert a route in the routing table at Relay, with respect to the allocated prefix during a regular PD operation - that route is about the allocated prefix and the next hop being the address of the Requesting Router. Whether that particular route gets distributed in the core is a question which when there are many such routes it be big. But 'snooping' must already be there for that route in the Relay. (if I understand correctly this 'snooping' behaviour). The logic would be that if snooping is already there then it wouldn't be the fault of this draft about it. But I think this is already clarified by recent days discussions on this topic, no need for me to insist. Alex > > cheers, Ole > From alexandru.petrescu@gmail.com Sat Sep 8 09:18:51 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D183A21F857E for ; Sat, 8 Sep 2012 09:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ7QPsk9yP88 for ; Sat, 8 Sep 2012 09:18:51 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 08D4621F849B for ; Sat, 8 Sep 2012 09:18:49 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 1842294014C; Sat, 8 Sep 2012 18:18:43 +0200 (CEST) Message-ID: <504B6FDE.9060901@gmail.com> Date: Sat, 08 Sep 2012 18:18:38 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Ted Lemon References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> <0CFEF31D-4A01-42A7-89B7-69BDBB41E9C8@employees.org> <6069AF94-1587-496D-BE15-5A9B6892E9F6@nominum.com> <5049E744.30700@gmail.com> <9DB266A4-F0B6-43C4-BF8B-8A6C65792CAB@nominum.com> In-Reply-To: <9DB266A4-F0B6-43C4-BF8B-8A6C65792CAB@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 120908-0, 08/09/2012), Outbound message X-Antivirus-Status: Clean Cc: "" Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 16:18:51 -0000 Le 07/09/2012 15:20, Ted Lemon a écrit : > On Sep 7, 2012, at 8:23 AM, Alexandru Petrescu > wrote: >> I mean I dont think an educated guess could be done reasonably to >> form a common prefix and instruct the Relay about it. Even less >> that Relay to advertise the aggregated prefix instead of numerous >> specific routes. > > I think the whole point of the prefix pool option is to avoid making > educated guesses, by coming up with the aggregate route in the core > of the network, as a management function. IOW, I don't think the > DHCP server will be following some heuristic to figure out what the > aggregate prefix is; rather, it will be configured either to allocate > one specifically, or will be configured by a management system with a > predefined prefix pool. Ok, I understand now. It makes sense what you explain above. On another hand, the idea of a Relay to act first as a Requesting Router has already been discarded somehow? Alex From Ted.Lemon@nominum.com Sat Sep 8 09:43:12 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A7521F851C for ; Sat, 8 Sep 2012 09:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.535 X-Spam-Level: X-Spam-Status: No, score=-106.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8fym39+ltFI for ; Sat, 8 Sep 2012 09:43:11 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id E836221F8467 for ; Sat, 8 Sep 2012 09:43:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUEt1nsPvsv+3Q7iQ2EpjGLP2gmqDXb2f@postini.com; Sat, 08 Sep 2012 09:43:11 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 171541B831D for ; Sat, 8 Sep 2012 09:43:10 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0A9D419005C; Sat, 8 Sep 2012 09:43:10 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Sat, 8 Sep 2012 09:43:09 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Thread-Index: AQHNjd2jjF/7xAgSiEuAh53a0ICeZpeBG6uA Date: Sat, 8 Sep 2012 16:43:09 +0000 Message-ID: <66943696-4C9F-4A83-A419-C049EE756691@nominum.com> References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> <0CFEF31D-4A01-42A7-89B7-69BDBB41E9C8@employees.org> <6069AF94-1587-496D-BE15-5A9B6892E9F6@nominum.com> <5049E744.30700@gmail.com> <9DB266A4-F0B6-43C4-BF8B-8A6C65792CAB@nominum.com> <504B6FDE.9060901@gmail.com> In-Reply-To: <504B6FDE.9060901@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 16:43:12 -0000 On Sep 8, 2012, at 12:18 PM, Alexandru Petrescu wrote: > On another hand, the idea of a Relay to act first as a Requesting Router = has already been discarded somehow? That may well be a valid configuration in some settings, but for an ISP, pa= rticularly with legal record-keeping mandates, doing CPE prefix allocation = in the core of the network makes more sense. Also, by doing it this way, = the PE router can be simpler and cheaper. From d3e3e3@gmail.com Sat Sep 8 16:36:09 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD1E21F84D4 for ; Sat, 8 Sep 2012 16:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmI+pEuwwmc2 for ; Sat, 8 Sep 2012 16:36:08 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 33E6F21F84D3 for ; Sat, 8 Sep 2012 16:36:08 -0700 (PDT) Received: by iabz21 with SMTP id z21so713992iab.31 for ; Sat, 08 Sep 2012 16:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=KlHOvsb5Wywt8B+BCon7FNurTkAan2N2CNpT8rerhhQ=; b=JtuP3EueBLfGgToHaqSSVZbHRmheCEhBy4LBJHgxw8JD6U/VaLycT27coFWSN/lhPY FVwLLLocuaxdAEqs/6EkcFHP3rnV2SGIqp8i692/p2h+7FReRRJIs5s5dTs0PTWVl1cX kNpZXG6jq/E6WuGviL2v/GExcu793KXpOP385uYQiYwv0pGM20nWIGZh7uPWtbBQ7/4s sUgoCesPcK3+KH2cl/OI3ttOawT7CuqRGMdJP2A7PA16ssiFwBhqRkIggs29aCNSrlbB kL/W//PiFE5EODFe/a4AozQ/CwEfwUyqHzEUpf4t1FRdkwaiZJ4zHikNLW4O9gIxSOuS uwTw== Received: by 10.50.17.230 with SMTP id r6mr2548563igd.16.1347147367591; Sat, 08 Sep 2012 16:36:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.143.103 with HTTP; Sat, 8 Sep 2012 16:35:47 -0700 (PDT) In-Reply-To: References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> <5049C317.7090603@gmail.com> <94FA926F-2432-4AE7-BC20-AE7458AB40D9@cisco.com> <71F17433-B2D9-4366-9B32-F0E4D294EDB5@nominum.com> From: Donald Eastlake Date: Sat, 8 Sep 2012 19:35:47 -0400 Message-ID: To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 23:36:09 -0000 How much of a rush is there on this? I've sent a message to Brian Carpenter asking if he could run his test data with Pearson to compare with FNV. The FNV draft has been presented at a SAAG meeting and the comments received resolved. I think it is in quite good shape. I just need to finish up the source code. Maybe this is just the incentive I need :-) Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Fri, Sep 7, 2012 at 6:29 PM, Ted Lemon wrote: > On Sep 7, 2012, at 5:37 PM, Donald Eastlake wrote: >> FNV takes a little more effort than Pearson. It also has a smaller >> footprint in memory. And I believe it will produce statistically >> better results. What are the relative weights of these or other >> factors in this case? > > Unfortunately, as far as I can tell neither of the studies you cite compa= res FNV to Pearson, although the results from Brian Carpenter's study are c= ertainly pretty impressive. I think more work is worse, smaller footprin= t probably doesn't matter (this algorithm is being run in DHCP servers, whi= ch typically aren't seriously memory-constrained), and statistically better= results only matter if it's a pretty big difference, so it's frustrating t= hat we don't have a comparison to the existing algorithm. > > To me, the biggest win of using FNV would be if there were an RFC to refe= r to, but it looks like this is not quite there yet. So my conclusion is = that I certainly don't oppose using FNV instead of Pearson, but I don't see= a strong reason to support it either. > From Ted.Lemon@nominum.com Sat Sep 8 19:50:50 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AE621F850D for ; Sat, 8 Sep 2012 19:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIxbuiJP9nx9 for ; Sat, 8 Sep 2012 19:50:46 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id E8F1821F84DD for ; Sat, 8 Sep 2012 19:50:42 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUEwEAZZ7hMduInUyzO95AdkdQ808usRC@postini.com; Sat, 08 Sep 2012 19:50:44 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A06921B8348 for ; Sat, 8 Sep 2012 19:50:40 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9389A19005C; Sat, 8 Sep 2012 19:50:40 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Sat, 8 Sep 2012 19:50:40 -0700 From: Ted Lemon To: Donald Eastlake Thread-Topic: [dhcwg] Load Balancing for DHCPv6 Thread-Index: AQHNhTu7gFlX/ZntC0OFRh8xVQ/AAZdwtBEAgACi1QCAAB9FgIAAA4kAgAABYICADN9FgIAAAfqAgADKnoCAABhfgIAAOiqAgAAMAACAAGdRgIAADogAgAGk5oCAADZygA== Date: Sun, 9 Sep 2012 02:50:39 +0000 Message-ID: References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> <5049C317.7090603@gmail.com> <94FA926F-2432-4AE7-BC20-AE7458AB40D9@cisco.com> <71F17433-B2D9-4366-9B32-F0E4D294EDB5@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <404D1B3D45AE1B4FA7DF1E02D0B0217F@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 02:50:50 -0000 On Sep 8, 2012, at 7:35 PM, Donald Eastlake wrote: > How much of a rush is there on this? I don't think there's a huge rush, but Andre might disagree... :) From akostur@incognito.com Sun Sep 9 07:43:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1535A21F8522 for ; Sun, 9 Sep 2012 07:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Euv9TOLsGxJv for ; Sun, 9 Sep 2012 07:43:00 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with SMTP id 65B8221F8518 for ; Sun, 9 Sep 2012 07:43:00 -0700 (PDT) Received: from mail-ie0-f172.google.com ([209.85.223.172]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKUEyq8xv2TSyDk2PSQqLWKOi0Gly+o2ss@postini.com; Sun, 09 Sep 2012 07:43:00 PDT Received: by ieak13 with SMTP id k13so1796651iea.31 for ; Sun, 09 Sep 2012 07:42:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=+ZWxOii/4UggvKk3W6kow6v4ej3xxq0g+eaCBUuV/tE=; b=o0/zvnYcg8z6vHKDROZQNJtnmokYg7NrXBqqlH9XwanpWeArDYdQB6g7nRykzpWR9z AkAYLDCkWMCTEvGTOZN8U/UKQJJh+zCrlmI2Ll9pwqFMXvvQW1zIGu9v3zrLxmfyuonJ ijImxburjYXZbQ3mDMZXpNxA00Ot9kebMHapsE5hFA2Rvr99weHCu3fQ9UK7noOen+gZ NTQ4eQa65nu3x9QrkWtnvl8ofr+uw3hrr7YkGV89qH1I822zG5SVYncXiAENZwSwnDQJ bRbSj9srq/7HSa/wOMh74OVlmi3iYCKCrXGpffSI4KzGQqWc6S+T1+jKUafFi1LgrCZj fllw== MIME-Version: 1.0 Received: by 10.50.213.97 with SMTP id nr1mr6919001igc.40.1347201779332; Sun, 09 Sep 2012 07:42:59 -0700 (PDT) Received: by 10.64.100.137 with HTTP; Sun, 9 Sep 2012 07:42:59 -0700 (PDT) In-Reply-To: References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> <5049C317.7090603@gmail.com> <94FA926F-2432-4AE7-BC20-AE7458AB40D9@cisco.com> <71F17433-B2D9-4366-9B32-F0E4D294EDB5@nominum.com> Date: Sun, 9 Sep 2012 07:42:59 -0700 Message-ID: From: Andre Kostur To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnIwel+6gAco0duDvGwUK5Tv4PaqkoWUqjqBX/126xJc4aq3HMYBRP0NE7sI3sNp8qaU3tL Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 14:43:01 -0000 On Sat, Sep 8, 2012 at 7:50 PM, Ted Lemon wrote: > > On Sep 8, 2012, at 7:35 PM, Donald Eastlake wrote: > > How much of a rush is there on this? > > I don't think there's a huge rush, but Andre might disagree... :) > Other than keeping the draft moving along.... Does the WG want to take this on as a working item? I think we can get that part of the draft process resolved (and possibly publish draft-ietf-dhc-loadbv6-00) while we're waiting for the results of Pearson vs. FNV. -- Andre Kostur From ghalwasi@cisco.com Sun Sep 9 18:43:19 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800DC21F84E4 for ; Sun, 9 Sep 2012 18:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.489 X-Spam-Level: X-Spam-Status: No, score=-9.489 tagged_above=-999 required=5 tests=[AWL=1.111, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGXZUEAst4Ku for ; Sun, 9 Sep 2012 18:43:18 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5F56C21F84D7 for ; Sun, 9 Sep 2012 18:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1154; q=dns/txt; s=iport; t=1347241397; x=1348450997; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=3rcEFpWL5EMLJ1+M8NUDR0+0qybfIyTJorhVDaPutC8=; b=JGRIeqfqs05JU7kyUzZP/yNxhiOrE9V/8m3NEMeo0zUnHn9NOnm1AJUc oEM2/JzOlavE7uaz0zC4hqZEFd/kmd7fAMplvW6eZIfAdnFfQRhYQYFOb cLR97U3TrL5NpYVkpcSpnG6mx9NXJWplSHYVA77GPiv/o5cNpRMHfOdlB w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFABNFTVCtJV2d/2dsb2JhbABFhUBHtEx8gQeCIgEEEgEQEVcBIgIGIAIEMBURAQQbARmHbguZVIEojRmSA4EhjxYyYAOkE4FngmY X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="119858980" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 10 Sep 2012 01:43:17 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8A1hGV5028969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Sep 2012 01:43:16 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.246]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Sun, 9 Sep 2012 20:43:16 -0500 From: "Gaurav Halwasia (ghalwasi)" To: "dhcwg@ietf.org" Thread-Topic: DHCPv4 INFORM Refresh Time Option Thread-Index: Ac2O9aIJmSIHA7SwRXiFsB02PKBpNA== Date: Mon, 10 Sep 2012 01:43:15 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB102CE5@xmb-aln-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.70.241] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19172.004 x-tm-as-result: No--28.338200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [dhcwg] DHCPv4 INFORM Refresh Time Option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 01:43:19 -0000 SGkgVGVhbSwNCg0KV2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgSS1EIGZvciBpbmNsdWRpbmcgUmVm cmVzaCBUaW1lIG9wdGlvbiBpbiBJTkZPUk0gbWVzc2FnZSwgc2ltaWxhciB0byB3aGF0IERIQ1B2 NiBoYXMuDQoNClRoZSBkcmFmdCBpcyBhdmFpbGFibGUgYXQ6DQpodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1oYWx3YXNpYS1kaGMtaW5mb3JtLXJlZnJlc2gtdGltZS1v cHQtMDAudHh0DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBEeW5h bWljIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbCBmb3INCiAgIElQdjQgKERIQ1B2NCkgW1JG QzIxMzFdIG9wdGlvbiBmb3Igc3BlY2lmeWluZyBhbiB1cHBlciBib3VuZCBmb3IgaG93DQogICBs b25nIGEgY2xpZW50IHNob3VsZCB3YWl0IGJlZm9yZSByZWZyZXNoaW5nIGluZm9ybWF0aW9uIHJl dHJpZXZlZA0KICAgZnJvbSBESENQdjQgU2VydmVyIGJ5IHVzaW5nIERIQ1AgSU5GT1JNIG1lc3Nh Z2UuICBJdCBpcyB1c2VkIHdpdGgNCiAgIHN0YXRlbGVzcyBESENQdjQgYXMgdGhlcmUgYXJlIG5v IGFkZHJlc3NlcyBvciBvdGhlciBlbnRpdGllcyB3aXRoDQogICBsaWZldGltZXMgdGhhdCBjYW4g dGVsbCB0aGUgY2xpZW50IHdoZW4gdG8gY29udGFjdCB0aGUgREhDUHY0IHNlcnZlcg0KICAgdG8g cmVmcmVzaCBpdHMgY29uZmlndXJhdGlvbi4NCg0KQXBwcmVjaWF0ZSB5b3VyIGNvbW1lbnRzIGFu ZCBzdWdnZXN0aW9ucy4gICBXZSBhcmUgYWxzbyBsb29raW5nIHRvIGhhdmUgdGhlIFdHIHRha2Ug dGhpcyBvbiBhcyBhIHdvcmsgaXRlbS4NCg0KVGhhbmtzLA0KR2F1cmF2DQo= From Ted.Lemon@nominum.com Sun Sep 9 19:09:48 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4EC21F85A8 for ; Sun, 9 Sep 2012 19:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.543 X-Spam-Level: X-Spam-Status: No, score=-106.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLvCozqO1jl6 for ; Sun, 9 Sep 2012 19:09:48 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 0130021F8552 for ; Sun, 9 Sep 2012 19:09:47 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUE1L630IEhMhraRCHRaKXLw4O+iw0hcL@postini.com; Sun, 09 Sep 2012 19:09:48 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 11C9C1B8490 for ; Sun, 9 Sep 2012 19:09:47 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0463519005C; Sun, 9 Sep 2012 19:09:47 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Sun, 9 Sep 2012 19:09:41 -0700 From: Ted Lemon To: "Gaurav Halwasia (ghalwasi)" Thread-Topic: [dhcwg] DHCPv4 INFORM Refresh Time Option Thread-Index: Ac2O9aIJmSIHA7SwRXiFsB02PKBpNAAPmAQA Date: Mon, 10 Sep 2012 02:09:40 +0000 Message-ID: References: <90903C21C73202418A48BFBE80AEE5EB102CE5@xmb-aln-x06.cisco.com> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB102CE5@xmb-aln-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv4 INFORM Refresh Time Option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 02:09:48 -0000 On Sep 9, 2012, at 9:43 PM, "Gaurav Halwasia (ghalwasi)" wrote: > Appreciate your comments and suggestions. We are also looking to have t= he WG take this on as a work item. Do we have any reasonable expectation that any clients will implement this = feature? From ghalwasi@cisco.com Sun Sep 9 19:24:12 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6CA21F8593 for ; Sun, 9 Sep 2012 19:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.489 X-Spam-Level: X-Spam-Status: No, score=-9.489 tagged_above=-999 required=5 tests=[AWL=1.111, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7X+arhWThYd5 for ; Sun, 9 Sep 2012 19:24:12 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 41D9F21F856D for ; Sun, 9 Sep 2012 19:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1265; q=dns/txt; s=iport; t=1347243852; x=1348453452; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pkRT03DCT6pdu08l6bm9O95xQiImGt2R9b2Ihk2UVZI=; b=bNRL8iGEw+yrYhCaweTPcSbZfjYaKQtmpYRN4HOF11u2EFhA0kKptinq szafuEwQa6eaaE8y6DOMQxkSHHQYZZQ7Z8cOssABEZsJIPHHNyRcCbdQh jgxqSXW4LuQHXku93SH9B02gBU3KbgtUa53h1ZT7s7FihtpKOaRQu9I4v I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADVOTVCtJXG8/2dsb2JhbABFu0+BB4IgAQEBAwESASc/DAQCAQgRBAEBAQoUCQcyFAkIAQEEDgUIGodoBpp7nxuLE4VWYAOkE4FngmY X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="119864548" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 10 Sep 2012 02:24:11 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8A2OBxP010222 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Sep 2012 02:24:11 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.246]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0298.004; Sun, 9 Sep 2012 21:24:11 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Ted Lemon Thread-Topic: [dhcwg] DHCPv4 INFORM Refresh Time Option Thread-Index: Ac2O9aIJmSIHA7SwRXiFsB02PKBpNAAPmAQAAA6VYfA= Date: Mon, 10 Sep 2012 02:24:10 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB102D5D@xmb-aln-x06.cisco.com> References: <90903C21C73202418A48BFBE80AEE5EB102CE5@xmb-aln-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.70.241] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19174.001 x-tm-as-result: No--37.171100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv4 INFORM Refresh Time Option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 02:24:13 -0000 >> Appreciate your comments and suggestions. We are also looking to have = the WG take this on as a work item. >Do we have any reasonable expectation that any clients will implement this= feature? [Gaurav] Yes, I think so. Certainly not going to get implemented by most. M= oreover, DHCP INFORM apart from being used by literal end host devices, als= o gets used in a lot of other deployments/scenarios. One of the vendor uses= it for network discovery. In one another use-case, local dhcp servers on H= ubs (in Hub and Spoke) kind of deployments needs to periodically refresh th= e local config parameters from the central server which it can use while re= plying to dhcp requests on it's LAN.=20 Thanks, Gaurav=20 -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Monday, September 10, 2012 7:40 AM To: Gaurav Halwasia (ghalwasi) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv4 INFORM Refresh Time Option On Sep 9, 2012, at 9:43 PM, "Gaurav Halwasia (ghalwasi)" wrote: > Appreciate your comments and suggestions. We are also looking to have t= he WG take this on as a work item. Do we have any reasonable expectation that any clients will implement this = feature? From Ted.Lemon@nominum.com Sun Sep 9 20:05:26 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F1921F8505 for ; Sun, 9 Sep 2012 20:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.546 X-Spam-Level: X-Spam-Status: No, score=-106.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpL+CvQUYwCx for ; Sun, 9 Sep 2012 20:05:26 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 01F1621F84EC for ; Sun, 9 Sep 2012 20:05:25 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUE1Y9VVa6cX87LNrdxBy++HAmIJlasGF@postini.com; Sun, 09 Sep 2012 20:05:26 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 195941B84AC for ; Sun, 9 Sep 2012 20:05:25 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1120819005C for ; Sun, 9 Sep 2012 20:05:25 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Sun, 9 Sep 2012 20:05:18 -0700 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Thread-Index: AQHNgg2f2GWemYRp/0G7NT9hbKcz65eDc3KA Date: Mon, 10 Sep 2012 03:05:17 +0000 Message-ID: <03595D60-FAA0-41A5-B3AE-446F839E92FB@nominum.com> References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> In-Reply-To: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <6E49A49959D3AD42B7F6A6107AABAF12@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 03:05:26 -0000 On Aug 24, 2012, at 11:32 AM, Ted Lemon wrote: > If you think this work should be adopted by the working group, please rep= ly to this message saying so. If you think this work should not be adopte= d by the working group, please reply to this message saying so. We will e= valuate consensus on September 7. There were a few comments, and I think there's at least one person who oppo= sed adopting this work, and perhaps two others who are on the fence about i= t but didn't say specifically. But there are also seven people in favor o= f adopting the work. Since this is a call for adoption, and not a working= group last call, I think that this means that there is a rough consensus t= hat we should do this work. Hopefully the people who had comments will wo= rk with Leaf to improve the draft. Thanks! From internet-drafts@ietf.org Sun Sep 9 20:06:02 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A77B21F8512; Sun, 9 Sep 2012 20:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2LW4zUk4zwu; Sun, 9 Sep 2012 20:06:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FF821F84EC; Sun, 9 Sep 2012 20:06:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120910030601.15271.21391.idtracker@ietfa.amsl.com> Date: Sun, 09 Sep 2012 20:06:01 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-prefix-pool-opt-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 03:06:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : Prefix Pool Option for DHCPv6 Relay Agents on Provider E= dge Routers Author(s) : Leaf Y. Yeh Ted Lemon Mohamed Boucadair Filename : draft-ietf-dhc-dhcpv6-prefix-pool-opt-00.txt Pages : 13 Date : 2012-09-09 Abstract: The DHCPv6 Prefix Pool option provides a mechanism for DHCPv6 Prefix Delegation (DHCPv6-PD), allowing the DHCPv6 server to notify a DHCPv6 relay agent implemented on a Provider Edge (PE) router about active prefix pools allocated by the DHCPv6 server to the PE router. The information of active prefix pools can be used to enforce IPv6 route aggregation on the PE router by adding or removing aggregation routes according to the status of the prefix pools. The advertising of the aggregation routes in the routing protocol enabled on the network- facing interface of PE routers will dramatically decreases the number of the routing table entries in the ISP network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-prefix-pool-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From akostur@incognito.com Sun Sep 9 20:31:14 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED3821F852B for ; Sun, 9 Sep 2012 20:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pk3FGJOj-Hr6 for ; Sun, 9 Sep 2012 20:31:13 -0700 (PDT) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with SMTP id 4A9C421F8526 for ; Sun, 9 Sep 2012 20:31:11 -0700 (PDT) Received: from mail-ie0-f172.google.com ([209.85.223.172]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKUE1e/vgXD84xanONlVS14kbLv9TMNqqx@postini.com; Sun, 09 Sep 2012 20:31:11 PDT Received: by ieak13 with SMTP id k13so2438870iea.31 for ; Sun, 09 Sep 2012 20:31:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=DlISRKUFTmlGRTl9OoiYaDaFCDcMxJAqjeVmWYflBHU=; b=oPazWZi63ImPpBFATbsPlWd+0/J4r+ZfEwhvRw6o1CDtD3JvrmTKWOHqP+87fdas0e t0tWZruYtVjnptOLHcLzw6BwvQTI2idZNVUFmQvqdCN3nw+OPuUA+Lbt2pDHOkiyVbOG 8vFGMvmlIexATZh3x4dC00dAh9Ymm2wRXTxjqC4cOLYOUjMC8kLvFQFgN44FJSflHyyZ cpq7TKblV0COgWp0loZYmcdbqncO02jqp5B/nycxdFCxoDiBETz2n8bnxheoaMllx+kX tL2GIgbIEjVUMze9UmkSIlfD6VZtxMcB5f3PSfpXpBiJ74S3jE/qT8y63qQ7uk7HsP7E 27mA== MIME-Version: 1.0 Received: by 10.50.161.167 with SMTP id xt7mr8783383igb.62.1347247870333; Sun, 09 Sep 2012 20:31:10 -0700 (PDT) Received: by 10.64.100.137 with HTTP; Sun, 9 Sep 2012 20:31:10 -0700 (PDT) In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB102D5D@xmb-aln-x06.cisco.com> References: <90903C21C73202418A48BFBE80AEE5EB102CE5@xmb-aln-x06.cisco.com> <90903C21C73202418A48BFBE80AEE5EB102D5D@xmb-aln-x06.cisco.com> Date: Sun, 9 Sep 2012 20:31:10 -0700 Message-ID: From: Andre Kostur To: "Gaurav Halwasia (ghalwasi)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmxTpsxl6gBmgXlQZUJHBFT6Iy+EB1b2SbKuXnUyw9yBTnCIbZBywGE7l4FNQy8BVft8Sur Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] DHCPv4 INFORM Refresh Time Option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 03:31:14 -0000 On Sun, Sep 9, 2012 at 7:24 PM, Gaurav Halwasia (ghalwasi) wrote: >>> Appreciate your comments and suggestions. We are also looking to have= the WG take this on as a work item. > >>Do we have any reasonable expectation that any clients will implement thi= s feature? > [Gaurav] Yes, I think so. Certainly not going to get implemented by most.= Moreover, DHCP INFORM apart from being used by literal end host devices, a= lso gets used in a lot of other deployments/scenarios. One of the vendor us= es it for network discovery. In one another use-case, local dhcp servers on= Hubs (in Hub and Spoke) kind of deployments needs to periodically refresh = the local config parameters from the central server which it can use while = replying to dhcp requests on it's LAN. As another option, did you consider using Lease Time/T1/T2 instead of having a completely new option for this? --=20 Andre Kostur From ghalwasi@cisco.com Sun Sep 9 20:53:24 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0C521F853B for ; Sun, 9 Sep 2012 20:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.859 X-Spam-Level: X-Spam-Status: No, score=-9.859 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAd7bV07oBTo for ; Sun, 9 Sep 2012 20:53:24 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1F66421F852A for ; Sun, 9 Sep 2012 20:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1556; q=dns/txt; s=iport; t=1347249204; x=1348458804; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KnVpvzfSzI6utRjbC9707Y0yOuP0jS2s6KPDeeKwg0k=; b=g7A1vTOUUQaFE1yjN2UkCu+VLEO+NHU126geh46YtNi3X+4+R/cw4bBs obH6Djt6tB4jbnEePvoXec2Te2+cLkjDE1O1S1YAdCVQTvrjZEeN0gvS6 yNF29/kjdjPSU4WFxSjYb8TUXNG5KShdmOi9gcrUzsqI2n+bAqfhXrxhK Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKxjTVCtJV2Z/2dsb2JhbABFu1CBB4IgAQEBAwESASc/BQcEAgEIDgMEAQEBChQJBzIUCQgBAQQOBQgah2gGmnmfJYsThVZgA6QTgWeCZg X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="119838429" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 10 Sep 2012 03:53:23 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8A3rNau007330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Sep 2012 03:53:23 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.246]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Sun, 9 Sep 2012 22:53:23 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Andre Kostur Thread-Topic: [dhcwg] DHCPv4 INFORM Refresh Time Option Thread-Index: Ac2O9aIJmSIHA7SwRXiFsB02PKBpNAAPmAQAAA6VYfD//4CTAIAATrCA Date: Mon, 10 Sep 2012 03:53:22 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB102FCA@xmb-aln-x06.cisco.com> References: <90903C21C73202418A48BFBE80AEE5EB102CE5@xmb-aln-x06.cisco.com> <90903C21C73202418A48BFBE80AEE5EB102D5D@xmb-aln-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.74] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19174.001 x-tm-as-result: No--40.206700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] DHCPv4 INFORM Refresh Time Option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 03:53:24 -0000 Hi Andre, > As another option, did you consider using Lease Time/T1/T2 instead of hav= ing a completely new option for this? [Gaurav] This is on the lines of DHCPv6. DHCPv6 also has information refres= h time option. Moreover, Lease Time/T1/T2 does not make much sense in case = of INFORM and anyway standard also does not allow this. Thanks, Gaurav -----Original Message----- From: Andre Kostur [mailto:akostur@incognito.com]=20 Sent: Monday, September 10, 2012 9:01 AM To: Gaurav Halwasia (ghalwasi) Cc: Ted Lemon; dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv4 INFORM Refresh Time Option On Sun, Sep 9, 2012 at 7:24 PM, Gaurav Halwasia (ghalwasi) wrote: >>> Appreciate your comments and suggestions. We are also looking to have= the WG take this on as a work item. > >>Do we have any reasonable expectation that any clients will implement thi= s feature? > [Gaurav] Yes, I think so. Certainly not going to get implemented by most.= Moreover, DHCP INFORM apart from being used by literal end host devices, a= lso gets used in a lot of other deployments/scenarios. One of the vendor us= es it for network discovery. In one another use-case, local dhcp servers on= Hubs (in Hub and Spoke) kind of deployments needs to periodically refresh = the local config parameters from the central server which it can use while = replying to dhcp requests on it's LAN. As another option, did you consider using Lease Time/T1/T2 instead of havin= g a completely new option for this? -- Andre Kostur From ichiroumakino@gmail.com Mon Sep 10 02:03:02 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8D721F8575 for ; Mon, 10 Sep 2012 02:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUj3R6gFYep8 for ; Mon, 10 Sep 2012 02:03:02 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id B907921F845B for ; Mon, 10 Sep 2012 02:03:01 -0700 (PDT) Received: by eekb45 with SMTP id b45so920020eek.31 for ; Mon, 10 Sep 2012 02:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=qAZd4D2os4Tve1vRxJEDPldGDZewrwjvHzsJfAU9NBg=; b=nzA08mn0C3Ssv3sqanqKpThf+Z9YaLeC3SU3AvWAcr1/dPbELP/1LbtAkLWVON9D5z qItVeqFnGfPzAbN6Cxyi1OqaLu8xoSH/o1YQhxT0ftfQvUWUGjqmS1ALbECv8oMbpr3U 4PgY++1zwzKJYfB4skOGuF7q8hj69PaUN8Y8k4qiRtoKumsJsDqd8FjSMWf5AMM5hyNT tUzxvzFcgZ+FNcYBz0d4mdfbKz/GOBJ/hO61qtW86QD2sl/JbFgY+JfmkX8fXFikhJ2s j3uOhT+Okjz7o9UBRJ2bcnhIGWAD3lsEUUoIBekDJzC7BipHC+cj/Z+R5lXR4lF95FIa i8wQ== Received: by 10.14.199.67 with SMTP id w43mr18480769een.33.1347267780828; Mon, 10 Sep 2012 02:03:00 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-145.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id i41sm36222392eem.7.2012.09.10.02.02.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Sep 2012 02:02:59 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_3A2F8C84-EBD9-42BF-B3DA-A14A0F1E1D07"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <5049EC41.3080809@gmail.com> Date: Mon, 10 Sep 2012 11:02:59 +0200 Message-Id: References: <5049EC41.3080809@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1278) Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Comments on some aspects on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 09:03:02 -0000 --Apple-Mail=_3A2F8C84-EBD9-42BF-B3DA-A14A0F1E1D07 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Alex, [...] > One alternative solution may be to have a mechanism by which the Relay > itself first executes Requesting Router (before being a Relay) to = obtain > that short prefix, at which point we no longer talk 'snooping'. This > could be the Prefix Pool Option without snooping. I'm more in favour of that too. the Relay acts as a DHCP client and = requests a=20 "static route / prefix pool / aggregate route" whatever we choose to = call that option. you would still need snooping to populate the RIB in the Relay itself = though. cheers, Ole= --Apple-Mail=_3A2F8C84-EBD9-42BF-B3DA-A14A0F1E1D07 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwOTEwMDkwMjU5WjAjBgkqhkiG9w0BCQQxFgQUh7eHq2ToaeJr7KEs nJzAXyE5PbwwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAhgIdGxVkPoBvG32Tq3HD qAVaa5z2DTTUzv+W9I6zCb0yhGFjSof6pMQ7/VH+9hGiNmHtOsvm5IeniMIH4AneHGfyVR7xPfVB gPU5/8i0+unIfrsWXrvLVx31X8Ses8JLw+U7tORj60+xo8AR/5lAOoccNuv94tEHHrCAF+psa5va SvvPci761FaSc+cEst87yCEx0K6BS7GDPPh7YIL4UxS/GChxbiYntHsYsrq2w863B7HxAfbK004X pJarAtqSR+vmXPoL5/F2KvJ5y38eI5B+nfbwqWyMNPjlHcJ8qiQDPa1CZXjHotkuF9Ayi7O1e1/z 03jvQHR/VY4sMiFQcQAAAAAAAA== --Apple-Mail=_3A2F8C84-EBD9-42BF-B3DA-A14A0F1E1D07-- From shrinivas_ashok.joshi@alcatel-lucent.com Mon Sep 10 02:33:16 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69FF21F855F for ; Mon, 10 Sep 2012 02:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fv+DhvEy6QWd for ; Mon, 10 Sep 2012 02:33:16 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 336C521F853B for ; Mon, 10 Sep 2012 02:33:16 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q8A9XBTu029755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Sep 2012 04:33:13 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q8A9X8tg026905 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 10 Sep 2012 15:03:10 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Mon, 10 Sep 2012 15:03:08 +0530 From: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" To: =?iso-8859-1?Q?Ole_Tr=F8an?= , Alexandru Petrescu Date: Mon, 10 Sep 2012 15:03:06 +0530 Thread-Topic: [dhcwg] Comments on some aspects on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Thread-Index: Ac2PMx945+lUedSfTH2A15CQh9iI1gABBgUQ Message-ID: References: <5049EC41.3080809@gmail.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Comments on some aspects on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 09:33:16 -0000 Hi, I am in favor of this approach as well. -- Shree >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of = Ole >Tr=F8an >Sent: Monday, September 10, 2012 2:33 PM >To: Alexandru Petrescu >Cc: dhcwg@ietf.org >Subject: Re: [dhcwg] Comments on some aspects on draft-yeh-dhc-dhcpv6-pref= ix- >pool-opt-08 > >Alex, > >[...] > >> One alternative solution may be to have a mechanism by which the Relay >> itself first executes Requesting Router (before being a Relay) to >> obtain that short prefix, at which point we no longer talk 'snooping'. >> This could be the Prefix Pool Option without snooping. > >I'm more in favour of that too. the Relay acts as a DHCP client and reques= ts a >"static route / prefix pool / aggregate route" whatever we choose to call = that >option. > >you would still need snooping to populate the RIB in the Relay itself thou= gh. > >cheers, >Ole From leaf.y.yeh@huawei.com Mon Sep 10 02:53:54 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A3E21F8634 for ; Mon, 10 Sep 2012 02:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.887 X-Spam-Level: X-Spam-Status: No, score=-5.887 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyj+Vh0H78g7 for ; Mon, 10 Sep 2012 02:53:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AE5D921F8624 for ; Mon, 10 Sep 2012 02:53:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKN08824; Mon, 10 Sep 2012 09:53:52 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 10:53:46 +0100 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 10:53:51 +0100 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.119]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Mon, 10 Sep 2012 17:53:38 +0800 From: Leaf yeh To: =?iso-8859-1?Q?Ole_Tr=F8an?= , Alexandru Petrescu Thread-Topic: [dhcwg] Comments on some aspects on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Thread-Index: AQHNjPaZ/noCmbdMpUKqmJpndkWQkZeCxhyAgACILaA= Date: Mon, 10 Sep 2012 09:53:36 +0000 Message-ID: References: <5049EC41.3080809@gmail.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Comments on some aspects on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 09:53:54 -0000 Alex - > One alternative solution may be to have a mechanism by which the R= elay=20 > itself first executes Requesting Router (before being a Relay) to=20 > obtain that short prefix, at which point we no longer talk 'snooping'. =20 > This could be the Prefix Pool Option without snooping. Ole - I'm more in favour of that too. the Relay acts as a DHCP client and r= equests a "static route / prefix pool / aggregate route" whatever we choose= to call that option. The above sounds the mechanism introduced in 'draft-ietf-dhc-dhcpv6-tunnel-= 01' (https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-tunnel/ ), to i= ntroduce DHCPv6 client on the PE router particularly for the aggregation ro= ute (or prefix pool). But draft (OPTION_PREFIX_POOL) only use the similar e= xisting tech, bulk leasequery, for the case of power cycle occurred on the = relay. Draft (OPTION_PREFIX_POOL) proposes the solution called 'Piggyback', which = has the benefit to make it easier to sync the 'status' of prefix pools (or = aggregation routes) on the relay with that indicated on the server. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of O= le Tr?an Sent: Monday, September 10, 2012 5:03 PM To: Alexandru Petrescu Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Comments on some aspects on draft-yeh-dhc-dhcpv6-prefi= x-pool-opt-08 Alex, [...] > One alternative solution may be to have a mechanism by which the Relay=20 > itself first executes Requesting Router (before being a Relay) to=20 > obtain that short prefix, at which point we no longer talk 'snooping'. =20 > This could be the Prefix Pool Option without snooping. I'm more in favour of that too. the Relay acts as a DHCP client and request= s a "static route / prefix pool / aggregate route" whatever we choose to ca= ll that option. you would still need snooping to populate the RIB in the Relay itself thoug= h. cheers, Ole From ghalwasi@cisco.com Mon Sep 10 04:02:29 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E6521F84A6 for ; Mon, 10 Sep 2012 04:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.766 X-Spam-Level: X-Spam-Status: No, score=-9.766 tagged_above=-999 required=5 tests=[AWL=0.832, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehcNUsg+UqIK for ; Mon, 10 Sep 2012 04:02:28 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1A04E21F8634 for ; Mon, 10 Sep 2012 04:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5495; q=dns/txt; s=iport; t=1347274939; x=1348484539; h=from:to:subject:date:message-id:mime-version; bh=qoIWHw1crYGst73K+L03xzO9AObUwyxXlsX2mTyAEMY=; b=VJQjYYB2JsrsD6O46pRdpXPBTs3R4s4laBcUR6JAWJvRqdbUU6yH8m6A NyPK7QkqLnEXSUppEohq/DxxuMnN5LjNun+7FBmXA97X24mAc+JtvvVxg z1ISTUJveOPjcOYcA8gHJxuQxi5bdjhraKLo3FDf9Bzp+LtzU6jFbTaWZ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACfHTVCtJXG+/2dsb2JhbABFgku4dYEHgiIBBBIBGl4BKlYmAQQbGodumVqBKJ9ikGlgA6QTgWeCZg X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208,217";a="119965423" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 10 Sep 2012 11:02:18 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8AB2IbP018378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Sep 2012 11:02:18 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.246]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Mon, 10 Sep 2012 06:02:18 -0500 From: "Gaurav Halwasia (ghalwasi)" To: "dhcwg@ietf.org" Thread-Topic: Reg RFC6704 (Forcerenew Nonce Authentication) Thread-Index: Ac2PQ7WbKpbVbNLxRMad4YyhUAitEw== Date: Mon, 10 Sep 2012 11:02:17 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB103AF9@xmb-aln-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.105.209] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19174.005 x-tm-as-result: No--30.801100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_90903C21C73202418A48BFBE80AEE5EB103AF9xmbalnx06ciscocom_" MIME-Version: 1.0 Subject: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 11:02:29 -0000 --_000_90903C21C73202418A48BFBE80AEE5EB103AF9xmbalnx06ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was going through RFC6704 (Forcerenew Nonce Authentication) along with or= iginal Forcerenew spec RFC3203. If I look at the original spec, I see that = we can send Forcerenew to a host who has actually not got it's IPV4 address= through DHCP but instead it has got some of the config parameters through = DHCP using DHCP INFORM message. So as per original Forcerenew spec, client = can send INFORM message as a result of receiving Forcerenew message. But latest spec on NONCE authentication (RFC6704), I figured out that we ar= e only talking about including FORCERENEW_NONCE_CAPABLE option in DISCOVER/= REQUEST messages. We are not actually talking about INFORM callflow. Is there any deliberate reason why we have not talked about and included IN= FORM callflow. Well, I don't think this is deliberate, and In my opinion Fo= rcerenew Nonce Authentication should be applicable to the INFORM-ACK call f= low as well. Including INFORM-ACK is important. Appreciate if you can share= your thoughts on this. Thanks, Gaurav --_000_90903C21C73202418A48BFBE80AEE5EB103AF9xmbalnx06ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was going through RFC6704 (Forcerenew Nonce = Authentication) along with original Forcerenew spec RFC3203. If I look at t= he original spec, I see that we can send Forcerenew to a host who has actually not got it’s IPV4 address through DHCP bu= t instead it has got some of the config parameters through DHCP using DHCP = INFORM message. So as per original Forcerenew spec, client can send INFORM = message as a result of receiving Forcerenew message.

But latest spec on NONCE =
authentication (RFC6704), I figured out that we are only talking about incl=
uding FORCERENEW_NONCE_CAPABLE option in DISCOVER/REQUEST messages. We are =
not actually talking about INFORM callflow.
 <=
/pre>

Is there any deliberate r=
eason why we have not talked about and included INFORM callflow. Well, I do=
n’t think this is deliberate, and In my opinion Forcerenew Nonce Auth=
entication should be applicable to the INFORM-ACK call flow as well. Includ=
ing INFORM-ACK is important. Appreciate if you can share your thoughts on t=
his.


 <=
/pre>

Thanks,=



Gaurav<=
/pre>
--_000_90903C21C73202418A48BFBE80AEE5EB103AF9xmbalnx06ciscocom_-- From Ted.Lemon@nominum.com Mon Sep 10 07:57:37 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7FC21F8592 for ; Mon, 10 Sep 2012 07:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+vIN0r4bmqj for ; Mon, 10 Sep 2012 07:57:37 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8FE21F8498 for ; Mon, 10 Sep 2012 07:57:37 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUE3/4Ac+1qYJn+pGj/TFZOuioqjoDnZ6@postini.com; Mon, 10 Sep 2012 07:57:37 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4181EF8083 for ; Mon, 10 Sep 2012 07:57:36 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3938419005C for ; Mon, 10 Sep 2012 07:57:36 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Mon, 10 Sep 2012 07:57:36 -0700 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] Call for adoption: draft-boucadair-dhc-triggered-reconfigure Thread-Index: AQHNggw8RB5j9kIDsUGrLGIrni1hs5eEOnoA Date: Mon, 10 Sep 2012 14:57:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <5F2490AB07D41C47B6470C0901B9C5E9@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Call for adoption: draft-boucadair-dhc-triggered-reconfigure X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 14:57:38 -0000 On Aug 24, 2012, at 11:22 AM, Ted Lemon wrote: > If you think this is something the working group should work on, please r= eply to this message saying so. If you think the working group should not= do this work, please reply to this message saying so. We will evaluate c= onsensus to adopt on September 7. There was no controversy about this draft, and five people support adopting= it, so I'm going to say that we have consensus to adopt. So Med, yes, pl= ease go ahead and submit your -00. Thanks! From d3e3e3@gmail.com Mon Sep 10 08:52:15 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9312121E803C for ; Mon, 10 Sep 2012 08:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRvHntOx2Amt for ; Mon, 10 Sep 2012 08:52:15 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8BA21E8039 for ; Mon, 10 Sep 2012 08:52:14 -0700 (PDT) Received: by iabz21 with SMTP id z21so2068500iab.31 for ; Mon, 10 Sep 2012 08:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=s2Geb+h0QeqbrMxjzex6W+eFnbN/sKkGLCeUz4JzrAw=; b=Dv239eB9zzgYLm6L40kymnlfQ6QtlAcLOhr1i7G06me9jLamE6NEJoqH09vc3joTNz V6GR8XSBXbLsuDwx2Zf0PWmViSeOgOkq7iRpnSLLP3j/B33OS0ZJKB6xRICK53YgBiuw AV75Zomfq3oA6XTL4swGNnxELOwgPJIW9tSMduE/efRR3oFyFDBLbGUeDo7MxGVvtKvx 69XvToELW22hIAJB3vWHUg8hUXsgPugEImGVobvHR8toTZSm+pdSsmrn/+XAi+QYj6XL oFXK9q02BWfhWGNy1qVAUjYChoe9CFnQXjHc01/HiBAvoQCDMhECiqXXc4ttw0eVnB7c cf1w== Received: by 10.42.52.5 with SMTP id h5mr6401999icg.50.1347292334426; Mon, 10 Sep 2012 08:52:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.143.103 with HTTP; Mon, 10 Sep 2012 08:51:53 -0700 (PDT) In-Reply-To: References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> <5049C317.7090603@gmail.com> <94FA926F-2432-4AE7-BC20-AE7458AB40D9@cisco.com> <71F17433-B2D9-4366-9B32-F0E4D294EDB5@nominum.com> From: Donald Eastlake Date: Mon, 10 Sep 2012 11:51:53 -0400 Message-ID: To: Andre Kostur Content-Type: text/plain; charset=ISO-8859-1 Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 15:52:15 -0000 Moving this to a WG draft seems reasonable. It appears that it is hard for several different reasons (the grad student who did all the work is gone, Brian is now fully retired and about to go on a month's vacation, etc...) for Brian Carpenter to just run the same test on Pearson but he can probably do some lesser amount of testing. I'm continuing to converse with him on this... Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Sun, Sep 9, 2012 at 10:42 AM, Andre Kostur wrote: > On Sat, Sep 8, 2012 at 7:50 PM, Ted Lemon wrote: >> >> On Sep 8, 2012, at 7:35 PM, Donald Eastlake wrote: >> > How much of a rush is there on this? >> >> I don't think there's a huge rush, but Andre might disagree... :) >> > > Other than keeping the draft moving along.... > > Does the WG want to take this on as a working item? I think we can > get that part of the draft process resolved (and possibly publish > draft-ietf-dhc-loadbv6-00) while we're waiting for the results of > Pearson vs. FNV. > > -- > Andre Kostur From Ted.Lemon@nominum.com Mon Sep 10 12:37:48 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6237D11E808E for ; Mon, 10 Sep 2012 12:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.552 X-Spam-Level: X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7bIK2VGzbiI for ; Mon, 10 Sep 2012 12:37:47 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id AD1E411E808A for ; Mon, 10 Sep 2012 12:37:46 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUE5Bihjvi/UkbGw5zsQlwg7QzxmY7IQ3@postini.com; Mon, 10 Sep 2012 12:37:46 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id DD989128012 for ; Mon, 10 Sep 2012 12:00:31 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2C26419005C for ; Mon, 10 Sep 2012 12:00:31 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Mon, 10 Sep 2012 12:00:31 -0700 From: Ted Lemon To: dhc WG Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 Thread-Index: AQHNdvzipwaJ7NUE4EeU+hu4IXKgZZeElHiA Date: Mon, 10 Sep 2012 19:00:30 +0000 Message-ID: <470B56BA-429C-4D50-9056-B9F9178EC72A@nominum.com> References: <1939A7BF-5F90-4801-9956-A21161F1B024@nominum.com> In-Reply-To: <1939A7BF-5F90-4801-9956-A21161F1B024@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <12095050C8627F4986F8F88DE3EAF2AD@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 19:37:48 -0000 On Aug 10, 2012, at 9:34 AM, Ted Lemon wrote: > The authors have requested a working group last call for this draft. Th= is is the document that clarifies the use of the DHCP client identifier by = DHCP servers, particularly in cases where chaddr is zero. Please review t= he draft and indicate on the mailing list whether you support its advanceme= nt or oppose its advancement. This draft passed the working group last call with substantial review, at l= east five participants in favor and nobody opposed. I will be writing up = a shepherd doc and sending it to the IESG. Thanks! From internet-drafts@ietf.org Mon Sep 10 20:55:31 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E494321F8770; Mon, 10 Sep 2012 20:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCfseKvYUdVz; Mon, 10 Sep 2012 20:55:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5856021F876D; Mon, 10 Sep 2012 20:55:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120911035531.21727.8228.idtracker@ietfa.amsl.com> Date: Mon, 10 Sep 2012 20:55:31 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-client-id-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 03:55:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : Client Identifier Option in DHCP Server Replies Author(s) : Narasimha Swamy Gaurav Halwasia Prashant Jhingran Filename : draft-ietf-dhc-client-id-05.txt Pages : 6 Date : 2012-09-10 Abstract: This document updates RFC2131 [RFC2131]. The changes to [RFC2131] defined in this draft clarifies the use of 'client identifier' option by the DHCP servers. The clarification addresses the issues arising out of the point specified by [RFC2131] that the server 'MUST NOT' return client identifier' option to the client. Requirements The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-client-id There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-client-id-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-client-id-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Ted.Lemon@nominum.com Tue Sep 11 05:05:18 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819A321F87D5 for ; Tue, 11 Sep 2012 05:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROmrAh281GCN for ; Tue, 11 Sep 2012 05:05:18 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9847321F87D2 for ; Tue, 11 Sep 2012 05:05:17 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUE8o+PJ1luWCmDWT3qmQkFUxdj+z59Y2@postini.com; Tue, 11 Sep 2012 05:05:17 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id DC1441B8402 for ; Tue, 11 Sep 2012 05:05:11 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D557119005C; Tue, 11 Sep 2012 05:05:11 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Tue, 11 Sep 2012 05:05:05 -0700 From: Ted Lemon To: "Gaurav Halwasia (ghalwasi)" Thread-Topic: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) Thread-Index: Ac2PQ7WbKpbVbNLxRMad4YyhUAitEwBDKVEA Date: Tue, 11 Sep 2012 12:05:03 +0000 Message-ID: <9902D1B3-D5B6-4AE0-BA6A-B83F06074FAD@nominum.com> References: <90903C21C73202418A48BFBE80AEE5EB103AF9@xmb-aln-x06.cisco.com> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB103AF9@xmb-aln-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 12:05:18 -0000 On Sep 10, 2012, at 7:02 AM, "Gaurav Halwasia (ghalwasi)" wrote: > Is there any deliberate reason why we have not talked about and included = INFORM callflow. Well, I don=92t think this is deliberate, and In my opinio= n Forcerenew Nonce Authentication should be applicable to the INFORM-ACK ca= ll flow as well. Including INFORM-ACK is important. Appreciate if you can s= hare your thoughts on this. In general we don't expect DHCP servers to keep track of clients that do in= formation requests=97to do so would require a great deal more effort on the= part of the DHCP server. Consequently, there's no client record on which= to store the nonce, and the DHCP server doesn't know to send the client a = FORCERENEW. From internet-drafts@ietf.org Tue Sep 11 06:47:32 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F5E21F853A; Tue, 11 Sep 2012 06:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5ei8QGD2O6h; Tue, 11 Sep 2012 06:47:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF2F21F84A6; Tue, 11 Sep 2012 06:47:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120911134731.14301.54129.idtracker@ietfa.amsl.com> Date: Tue, 11 Sep 2012 06:47:31 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-triggered-reconfigure-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 13:47:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : RECONFIGURE Triggered by DHCPv6 Relay Agents Author(s) : Mohamed Boucadair Xavier Pougnard Filename : draft-ietf-dhc-triggered-reconfigure-00.txt Pages : 8 Date : 2012-09-11 Abstract: This document defines a new DHCPv6 message type: RECONFIGURE-REQUEST. This message is sent by a DHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a RECONFIGURE message accordingly. This document updates RFC3315 and RFC6422. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-triggered-reconfigure There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-triggered-reconfigure-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Ted.Lemon@nominum.com Tue Sep 11 06:52:42 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F8421F85F4 for ; Tue, 11 Sep 2012 06:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQxAgJf058Kh for ; Tue, 11 Sep 2012 06:52:41 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id C6B2321F861C for ; Tue, 11 Sep 2012 06:52:38 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUE9CJk/0//e81xNa7XNvYew7HSteSIAi@postini.com; Tue, 11 Sep 2012 06:52:38 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0EE51F809B for ; Tue, 11 Sep 2012 06:52:38 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 050BA19005C for ; Tue, 11 Sep 2012 06:52:38 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Tue, 11 Sep 2012 06:52:38 -0700 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] Call for adoption: draft-boucadair-dhc-triggered-reconfigure Thread-Index: AQHNggw8RB5j9kIDsUGrLGIrni1hs5eFuqYA Date: Tue, 11 Sep 2012 13:52:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <66EE01829867944B87E63F8BF9AA56F0@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Call for adoption: draft-boucadair-dhc-triggered-reconfigure X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 13:52:42 -0000 On Aug 24, 2012, at 11:22 AM, Ted Lemon wrote: > If you think this is something the working group should work on, please r= eply to this message saying so. If you think the working group should not= do this work, please reply to this message saying so. We will evaluate c= onsensus to adopt on September 7. We didn't actually get a huge response to this, so it may have been prematu= re of me to approve the draft submission. But we have at least three wo= rking group participants who think it's a good idea, and nobody reacted in = horror. If, reading this, you feel that it was a mistake for me to approv= e the draft, please say so. Otherwise, let's get to work on it! From Ted.Lemon@nominum.com Tue Sep 11 07:03:36 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A052621F87F3 for ; Tue, 11 Sep 2012 07:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.56 X-Spam-Level: X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6bF8K7TdmQf for ; Tue, 11 Sep 2012 07:03:36 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id B359921F8623 for ; Tue, 11 Sep 2012 07:03:30 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUE9Eshk8mzDX9zeS+4kicqGsfFWDlsVS@postini.com; Tue, 11 Sep 2012 07:03:30 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EFFDCF809B for ; Tue, 11 Sep 2012 07:03:29 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E7CA619005C for ; Tue, 11 Sep 2012 07:03:29 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Tue, 11 Sep 2012 07:03:30 -0700 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] Call for adoption: draft-boucadair-dhc-triggered-reconfigure Thread-Index: AQHNggw8RB5j9kIDsUGrLGIrni1hs5eFuqYAgAADCQA= Date: Tue, 11 Sep 2012 14:03:28 +0000 Message-ID: <50ACBB72-EA39-4E31-963B-77406E0D1807@nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Call for adoption: draft-boucadair-dhc-triggered-reconfigure X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 14:03:36 -0000 On Sep 11, 2012, at 9:52 AM, Ted Lemon wrote: > If, reading this, you feel that it was a mistake for me to approve the dr= aft, please say so To be more clear, what I mean by "approve this draft" is "click on the cont= rol button that allows it to be published as a working group draft," not "g= ive the draft my seal of approval." I had done a consensus evaluation on = a different draft, and mistakenly remembered it as having been this draft, = so that's why I clicked the approve button. But then I went back and chec= ked, and the response wasn't as big as I remembered, so that's why I sent t= he clarifying message out. I apologize for the verbose explanations, but = I feel that it's better to be verbose just in case anybody felt that I didn= 't do the right thing, so that we can be clear about precisely what right t= hing I didn't do. :) From Ted.Lemon@nominum.com Tue Sep 11 08:23:49 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7D221F87EA for ; Tue, 11 Sep 2012 08:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.261 X-Spam-Level: X-Spam-Status: No, score=-106.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6D1U6ShMr7Jb for ; Tue, 11 Sep 2012 08:23:48 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id B3F4221F87BC for ; Tue, 11 Sep 2012 08:23:48 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUE9Xg+9ighHnYrkDXaQUUs0gm0TzGAbk@postini.com; Tue, 11 Sep 2012 08:23:48 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5FAD01B8540 for ; Tue, 11 Sep 2012 08:23:47 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 570FA19005C for ; Tue, 11 Sep 2012 08:23:47 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Tue, 11 Sep 2012 08:23:47 -0700 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] Call for adoption: draft-boucadair-dhc-triggered-reconfigure Thread-Index: AQHNggw8RB5j9kIDsUGrLGIrni1hs5eFuqYAgAAZeQA= Date: Tue, 11 Sep 2012 15:23:46 +0000 Message-ID: <7508B5C2-6DA0-41DD-9637-17F5C7A00308@nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Call for adoption: draft-boucadair-dhc-triggered-reconfigure X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 15:23:49 -0000 On Sep 11, 2012, at 9:52 AM, Ted Lemon wrote: > We didn't actually get a huge response to this, so it may have been prema= ture of me to approve the draft submission. But we have at least three = working group participants who think it's a good idea, and nobody reacted i= n horror. If, reading this, you feel that it was a mistake for me to appr= ove the draft, please say so. Otherwise, let's get to work on it! Med pointed out that I was in fact not mistaken about this draft being the = one that I'd done a consensus evaluation on. The reason for my confusion = was the badly broken Mail.app, not a lack of response=97when I did a search= for this this morning, I only found three related messages, but when I did= it yesterday I found five. Frustrating. Sorry for the useless noise. From Ted.Lemon@nominum.com Tue Sep 11 13:39:28 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00C121F8713 for ; Tue, 11 Sep 2012 13:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.551 X-Spam-Level: X-Spam-Status: No, score=-106.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKKDEsAqP5Sm for ; Tue, 11 Sep 2012 13:39:27 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5559121F86FF for ; Tue, 11 Sep 2012 13:39:27 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUE+hfhNVB3fnirWKMi0+ysZKDHYYWmC9@postini.com; Tue, 11 Sep 2012 13:39:27 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7F8C81B85AC for ; Tue, 11 Sep 2012 13:39:26 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7108019005C; Tue, 11 Sep 2012 13:39:26 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Tue, 11 Sep 2012 13:39:26 -0700 From: Ted Lemon To: "" Thread-Topic: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) Thread-Index: AQHNkE8cKpbVbNLxRMad4YyhUAitE5eGD8kA Date: Tue, 11 Sep 2012 20:39:25 +0000 Message-ID: <5F1BEB17-0FC5-4C84-A189-90BFBE868D7B@nominum.com> References: <201209111856.q8BIuCJS024680@gateway1.orleans.occnc.com> In-Reply-To: <201209111856.q8BIuCJS024680@gateway1.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7E6866101963BD409305E144A792CFE6@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 20:39:28 -0000 I didn't say that FORCERENEW for DHCPINFORM clients was hard. I said it w= ould impact performance. We would go from DHCPINFORM being a lightweight = read-only operation to a heavyweight read/write operation. I guess we cou= ld forgo the sync-before-ack logic of stateful DHCP, but this would add a l= ot of complexity to a performance-critical code section. So yeah, from an implementation point of view, I don't really like this ide= a. It seems trivial until you think about the impact it has either on per= formance or on implementation complexity. If there's strong demand for it= with a clear use case, then I think that's fine. I wasn't able to tease= one out of your rather dense message=97could you try to state your use cas= e in a short paragraph or two? From curtis@occnc.com Tue Sep 11 11:56:18 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485B621F867A for ; Tue, 11 Sep 2012 11:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Mw7gZHRlsCB for ; Tue, 11 Sep 2012 11:56:17 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 5F95721F8608 for ; Tue, 11 Sep 2012 11:56:17 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8BIuCJS024680; Tue, 11 Sep 2012 14:56:13 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209111856.q8BIuCJS024680@gateway1.orleans.occnc.com> To: Ted Lemon From: Curtis Villamizar In-reply-to: Your message of "Tue, 11 Sep 2012 12:05:03 -0000." <9902D1B3-D5B6-4AE0-BA6A-B83F06074FAD@nominum.com> Date: Tue, 11 Sep 2012 14:56:12 -0400 X-Mailman-Approved-At: Tue, 11 Sep 2012 13:40:21 -0700 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 18:56:18 -0000 In message <9902D1B3-D5B6-4AE0-BA6A-B83F06074FAD@nominum.com> Ted Lemon writes: > On Sep 10, 2012, at 7:02 AM, "Gaurav Halwasia (ghalwasi)" > wrote: > > > Is there any deliberate reason why we have not talked about and > > included INFORM callflow. Well, I don’t think this is deliberate, > > and In my opinion Forcerenew Nonce Authentication should be > > applicable to the INFORM-ACK call flow as well. Including INFORM-ACK > > is important. Appreciate if you can share your thoughts on this. > > In general we don't expect DHCP servers to keep track of clients that > do information requests—to do so would require a great deal more > effort on the part of the DHCP server. Consequently, there's no > client record on which to store the nonce, and the DHCP server doesn't > know to send the client a FORCERENEW. With the exception of the massively bridged enterprise (a real bad idea IMHO, but all too common due to IT ignorance) and the highly centralized DHCP server with relays (also done in enterprise), there is no need for more than a few hundred bits of state to keep track of. Of course when the database is a flat file appended to (lease file), its a little less efficient, but doable. Regarding the centralization with excessive use of relays, rather than centrralize control, delegating prefixes and therefor better distributing DHCP server functionality would help. Having a better database than a flat file is also a real good idea IMHO, but that is an implementation issue, not a protocol problem. Transport equipment routinely keeps persistent state for tens of thousands of SNC (usually in flash) so that a crash of the control processor only affects new circuit setups. Even this is not hard and the problem for the DHCP server is a lot easier. You'd need state for any DHCPINFORM requests with no lease as well as those with a lease. Maybe applicability to INFORM-ACK can be made optional (SHOULD). It would be really nice to get a FORCERENEW if the default routers list, or static routes list, or DNS nameservers, or ... etc, are learned and have changed but the addresses are configured. In a way this isn't a renew but rather a repeated request for parameters. Right now AFAIK if the default router list changes or any parameter but not the set of addresses, each client has to be manually be poked to repeat the DHCP request. So part of the question is "is this useful". The answer is clearly "yes". The second part of the question is "is it hard to support". Ted says yes, I say it shouldn't be but I'm not supporting any DHCP server code. Making it a SHOULD allows for software that doesn't do Forcerenew Nonce Authentication on INFORM-ACK but also allows server and client software to support it and use it if the other side supports it. A SHOULD also says "would be nice". Note that RFC3203 already suggests that client who "obtained a network address through some other means" but sent a DHCP INFORM resend that INFORM if a FORCERENEW is received. There is an absense of mention of INFORM in RFC6704, and RFC6704 only says what should be done on an "initial DHCP ACK". RFC6704 doesn't explicitly say that FORCERENEW_NONCE_CAPABLE can not be sent with INFORM but it does say is "A DHCP client indicates DHCP Forcerenew Nonce Protocol capability by including a FORCERENEW_NONCE_CAPABLE (145) option in DHCP Discover and Request messages sent to the server." It would not be such a big deal to create a document that updates RFC6704 to indicate that FORCERENEW_NONCE_CAPABLE could also be sent on DHCP INFORM for the case in RFC3203 where a client "obtained a network address through some other means". Otherswise, those clients would need a configured key while others could learn the key in a DHCPACK with Auth-Proto=Forcerenew-Nonce. This could be a very short document because it updates one sentence in RFC6704 "3.1.1. Forcerenew Nonce Protocol Capability Option" (cited in paragraph above) and adds a reproduction of " Figure 2: Timeline Diagram of Messages Exchanged between DHCP Client and Servers Using the Forcerenew Nonce Authentication Protocol" that substitutes DHCPINFORM for DHCPREQUEST or states "DHCPREQUEST or DHCPINFORM". An implementation could decide to support RFC6704 but not to support the update to RFC6704 in this new document. Did Gaurav volunteer to write it? Curtis From curtis@ipv6.occnc.com Tue Sep 11 14:32:12 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C3721F86F3 for ; Tue, 11 Sep 2012 14:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIyYvGTCAeJ3 for ; Tue, 11 Sep 2012 14:32:12 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 1059621F86B3 for ; Tue, 11 Sep 2012 14:32:11 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8BLW5Yf025526; Tue, 11 Sep 2012 17:32:05 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201209112132.q8BLW5Yf025526@gateway1.orleans.occnc.com> To: Ted Lemon From: Curtis Villamizar In-reply-to: Your message of "Tue, 11 Sep 2012 20:39:25 -0000." <5F1BEB17-0FC5-4C84-A189-90BFBE868D7B@nominum.com> Date: Tue, 11 Sep 2012 17:32:05 -0400 Cc: "dhcwg@ietf.org" , "" Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 21:32:12 -0000 In message <5F1BEB17-0FC5-4C84-A189-90BFBE868D7B@nominum.com> Ted Lemon writes: > I didn't say that FORCERENEW for DHCPINFORM clients was hard. I said > it would impact performance. We would go from DHCPINFORM being a > lightweight read-only operation to a heavyweight read/write operation. > I guess we could forgo the sync-before-ack logic of stateful DHCP, but > this would add a lot of complexity to a performance-critical code > section. > > So yeah, from an implementation point of view, I don't really like > this idea. It seems trivial until you think about the impact it has > either on performance or on implementation complexity. If there's > strong demand for it with a clear use case, then I think that's fine. > I wasn't able to tease one out of your rather dense message—could you > try to state your use case in a short paragraph or two? Use cases include: list of default routers changes, list of static routes changes, list of nameservers changes. etc. That was in the email as examples. There is no need to make INFORM r/w. For example, the client change the list of default routers. All that is needed is to maintain a list of host for which an inform was sent and the nonce used. Then send a FORCERENEW is any config changes. Optioanlly also keep a list of parameters sent to avoid sending a FORCERENEW is none of the requested and provided parameters had changed. The minimal change is add the DHCPINFORM client and nonce to the leases database (if you can call appending to a flat file a database) and also keep that mapping in RAM. A certain DHCP server performance would be vastly improved if a flat file was not used as the database for the leases. Curtis btw- I sent the prior message as curtis@occnc.com and I'm subscribed to this list as curtis@ipv6.occnc.com so its in the moderator queue. My bad. I'll cancel and resend shortly. From ghalwasi@cisco.com Tue Sep 11 18:26:53 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE3921F869C for ; Tue, 11 Sep 2012 18:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.933 X-Spam-Level: X-Spam-Status: No, score=-9.933 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiItkxIrdrzc for ; Tue, 11 Sep 2012 18:26:52 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4026A21F868A for ; Tue, 11 Sep 2012 18:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5464; q=dns/txt; s=iport; t=1347413212; x=1348622812; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=v4tTGUho/49ihBqwnbxKZ/Tss/voT/XqnhDT5KeBqGo=; b=mSNyLa+vdLMphBzlNoWTv2cppYeU2mgxLG7IJ2ys23htLnodqUgCpU04 7ZJSji1XJi46rhamNR2vnN8MYULp8VCE2zFQr31wHUjUWbxSw7vEFDyfA X/7wl0jOpy4ccuOz2WRmIQhhpMP9BlKqvjM4yR1l+KAK46BUSGISm+ayg U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANrjT1CtJV2a/2dsb2JhbABFu1WBB4IgAQEBAwESASc/BQcEAgEIEQQBAQEKFAkHMhQJCAIEAQ0FCBqHaAabS6BbixCFRmADpBWBZ4JmgVoH X-IronPort-AV: E=Sophos;i="4.80,407,1344211200"; d="scan'208";a="120654261" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 12 Sep 2012 01:26:51 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8C1Qo29010167 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 01:26:51 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Tue, 11 Sep 2012 20:26:50 -0500 From: "Gaurav Halwasia (ghalwasi)" To: "curtis@occnc.com" , Ted Lemon Thread-Topic: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) Thread-Index: AQHNkE8ckuiEXtYUDkaNnWZTSjI1wpeF6Xaw Date: Wed, 12 Sep 2012 01:26:50 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB19240DFD@xmb-rcd-x06.cisco.com> References: Your message of "Tue, 11 Sep 2012 12:05:03 -0000." <9902D1B3-D5B6-4AE0-BA6A-B83F06074FAD@nominum.com> <201209111856.q8BIuCJS024680@gateway1.orleans.occnc.com> In-Reply-To: <201209111856.q8BIuCJS024680@gateway1.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.81.193] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.000 x-tm-as-result: No--55.892500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 01:26:53 -0000 Hi Curtis, > An implementation could decide to support RFC6704 but not to support the = update to RFC6704 in this new document. Did Gaurav volunteer to write it? Thanks for the reply and infact I do have a use-case (which I will reply se= parately on this thread) and that's the reason I was exploring for this. Ye= s, I was indeed thinking about writing a short I.D for this but just though= t to get some views on dhc/authors. So I will submit it soon. I do think th= is this proposed extension will further help the usability/deploy ability o= f Forcerenew as per Nonce Authentication. Thanks, Gaurav -----Original Message----- From: Curtis Villamizar [mailto:curtis@occnc.com]=20 Sent: Wednesday, September 12, 2012 12:26 AM To: Ted Lemon Cc: Gaurav Halwasia (ghalwasi); dhcwg@ietf.org Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) In message <9902D1B3-D5B6-4AE0-BA6A-B83F06074FAD@nominum.com> Ted Lemon writes: =20 > On Sep 10, 2012, at 7:02 AM, "Gaurav Halwasia (ghalwasi)"=20 > > wrote: > =20 > > Is there any deliberate reason why we have not talked about and=20 > > included INFORM callflow. Well, I don't think this is deliberate,=20 > > and In my opinion Forcerenew Nonce Authentication should be=20 > > applicable to the INFORM-ACK call flow as well. Including INFORM-ACK=20 > > is important. Appreciate if you can share your thoughts on this. > =20 > In general we don't expect DHCP servers to keep track of clients that=20 > do information requests-to do so would require a great deal more=20 > effort on the part of the DHCP server. Consequently, there's no=20 > client record on which to store the nonce, and the DHCP server doesn't=20 > know to send the client a FORCERENEW. With the exception of the massively bridged enterprise (a real bad idea IMH= O, but all too common due to IT ignorance) and the highly centralized DHCP = server with relays (also done in enterprise), there is no need for more tha= n a few hundred bits of state to keep track of. Of course when the database is a flat file appended to (lease file), its a = little less efficient, but doable. Regarding the centralization with excessive use of relays, rather than cent= rralize control, delegating prefixes and therefor better distributing DHCP = server functionality would help. Having a better database than a flat file= is also a real good idea IMHO, but that is an implementation issue, not a = protocol problem. Transport equipment routinely keeps persistent state for tens of thousands = of SNC (usually in flash) so that a crash of the control processor only aff= ects new circuit setups. Even this is not hard and the problem for the DHC= P server is a lot easier. You'd need state for any DHCPINFORM requests with no lease as well as those= with a lease. Maybe applicability to INFORM-ACK can be made optional (SHOULD). It would = be really nice to get a FORCERENEW if the default routers list, or static r= outes list, or DNS nameservers, or ... etc, are learned and have changed bu= t the addresses are configured. In a way this isn't a renew but rather a r= epeated request for parameters. Right now AFAIK if the default router list changes or any parameter but not= the set of addresses, each client has to be manually be poked to repeat th= e DHCP request. So part of the question is "is this useful". The answer is clearly "yes". = The second part of the question is "is it hard to support". Ted says yes, I say it shouldn't be but I'm not supporting any DHCP server = code. Making it a SHOULD allows for software that doesn't do Forcerenew No= nce Authentication on INFORM-ACK but also allows server and client software= to support it and use it if the other side supports it. A SHOULD also say= s "would be nice". Note that RFC3203 already suggests that client who "obtained a network addr= ess through some other means" but sent a DHCP INFORM resend that INFORM if = a FORCERENEW is received. There is an absense of mention of INFORM in RFC6= 704, and RFC6704 only says what should be done on an "initial DHCP ACK". R= FC6704 doesn't explicitly say that FORCERENEW_NONCE_CAPABLE can not be sent= with INFORM but it does say is "A DHCP client indicates DHCP Forcerenew No= nce Protocol capability by including a FORCERENEW_NONCE_CAPABLE (145) optio= n in DHCP Discover and Request messages sent to the server." It would not = be such a big deal to create a document that updates RFC6704 to indicate th= at FORCERENEW_NONCE_CAPABLE could also be sent on DHCP INFORM for the case = in RFC3203 where a client "obtained a network address through some other me= ans". Otherswise, those clients would need a configured key while others c= ould learn the key in a DHCPACK with Auth-Proto=3DForcerenew-Nonce. This could be a very short document because it updates one sentence in RFC6704 "3.1.1. Forcerenew Nonce Protocol Capability Option" (cited in par= agraph above) and adds a reproduction of " Figure 2: Timeline Diagram of Me= ssages Exchanged between DHCP Client and Servers Using the Forcerenew Nonce= Authentication Protocol" that substitutes DHCPINFORM for DHCPREQUEST or st= ates "DHCPREQUEST or DHCPINFORM". An implementation could decide to support RFC6704 but not to support the up= date to RFC6704 in this new document. Did Gaurav volunteer to write it? Curtis From ghalwasi@cisco.com Tue Sep 11 18:45:33 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F76421F855A for ; Tue, 11 Sep 2012 18:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.744 X-Spam-Level: X-Spam-Status: No, score=-9.744 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pdtmw-qLUywf for ; Tue, 11 Sep 2012 18:45:33 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 14A6521F8555 for ; Tue, 11 Sep 2012 18:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1826; q=dns/txt; s=iport; t=1347414333; x=1348623933; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BpLq49PiMnOickpxWp40FgR217m8PuVaXrBZnOH4pvU=; b=IxtxKy1Fq4I+TGc018XWfpsJYhdz6SWzPq+EXwSuLsEeuj9AOqXD7HT+ RSZVHnUvG5DwtWb6+P9/jeiRvOJfjW8h85YVYI1oLN1cHjyov9jJ26LEr V5dqVIBEhfiO8aNzLvieA4IgUtQ/+84aJcv2QZ3cJxnoAuW3mgWWDwIJM w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJjoT1CtJXHA/2dsb2JhbABFu1WBB4IgAQEBBBIBJz8MBAIBCBEEAQELFAkHMhQJCAIEAQ0FCBqHa5tMoF2LEIViYAOkFYFpgmaCFw X-IronPort-AV: E=Sophos;i="4.80,407,1344211200"; d="scan'208";a="120404292" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 12 Sep 2012 01:45:32 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8C1jWCO030816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 01:45:32 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0298.004; Tue, 11 Sep 2012 20:45:32 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Ted Lemon , "" Thread-Topic: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) Thread-Index: AQHNkE8ckuiEXtYUDkaNnWZTSjI1wpeF7kOA////THA= Date: Wed, 12 Sep 2012 01:45:30 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB19241E49@xmb-rcd-x06.cisco.com> References: <201209111856.q8BIuCJS024680@gateway1.orleans.occnc.com> <5F1BEB17-0FC5-4C84-A189-90BFBE868D7B@nominum.com> In-Reply-To: <5F1BEB17-0FC5-4C84-A189-90BFBE868D7B@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.81.193] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.000 x-tm-as-result: No--32.345600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 01:45:33 -0000 Hi Ted, Thanks for your comments. I am talking about a deployment where we do create *session* database for h= osts either based upon DHCP packet (Discover) or the normal IP packet in ca= se few of the hosts has not done DHCP but instead has just DONE DHCP INFORM= to get the config parameters. So in this kind of deployment we do anyways = maintain the session(or binding in terms of DHCP) database on the box. Havi= ng said that I don't think storing client information is a problem (at leas= t in this deployment). The only extra thing which we would need to store is= a 'nonce'.=20 So I think it will be really useful to have nonce in INFORM-ACK callflow as= it will also help in the usability of Forcerenew as per 6704. Thanks, Gaurav=20 -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Wednesday, September 12, 2012 2:09 AM To: Cc: Gaurav Halwasia (ghalwasi); dhcwg@ietf.org Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) I didn't say that FORCERENEW for DHCPINFORM clients was hard. I said it w= ould impact performance. We would go from DHCPINFORM being a lightweight = read-only operation to a heavyweight read/write operation. I guess we cou= ld forgo the sync-before-ack logic of stateful DHCP, but this would add a l= ot of complexity to a performance-critical code section. So yeah, from an implementation point of view, I don't really like this ide= a. It seems trivial until you think about the impact it has either on per= formance or on implementation complexity. If there's strong demand for it= with a clear use case, then I think that's fine. I wasn't able to tease= one out of your rather dense message-could you try to state your use case = in a short paragraph or two? From Ted.Lemon@nominum.com Tue Sep 11 19:52:45 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3558021F84D5 for ; Tue, 11 Sep 2012 19:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.253 X-Spam-Level: X-Spam-Status: No, score=-106.253 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvleTBeDRMdE for ; Tue, 11 Sep 2012 19:52:44 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 80C6421F84CD for ; Tue, 11 Sep 2012 19:52:44 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUE/4++frALgGVI5mY3+798f/4sHChjMC@postini.com; Tue, 11 Sep 2012 19:52:44 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5B05DF809D for ; Tue, 11 Sep 2012 19:52:43 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 52E6819005C; Tue, 11 Sep 2012 19:52:43 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Tue, 11 Sep 2012 19:52:43 -0700 From: Ted Lemon To: "Gaurav Halwasia (ghalwasi)" Thread-Topic: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) Thread-Index: AQHNkE8cKpbVbNLxRMad4YyhUAitE5eGD8kAgABVhgCAABLFgA== Date: Wed, 12 Sep 2012 02:52:42 +0000 Message-ID: References: <201209111856.q8BIuCJS024680@gateway1.orleans.occnc.com> <5F1BEB17-0FC5-4C84-A189-90BFBE868D7B@nominum.com> <90903C21C73202418A48BFBE80AEE5EB19241E49@xmb-rcd-x06.cisco.com> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB19241E49@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0FD6AACD7076524E87A1E6AADBCB0C13@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 02:52:45 -0000 On Sep 11, 2012, at 9:45 PM, "Gaurav Halwasia (ghalwasi)" wrote: > I am talking about a deployment where we do create *session* database for= hosts either based upon DHCP packet (Discover) or the normal IP packet in = case few of the hosts has not done DHCP but instead has just DONE DHCP INFO= RM to get the config parameters. So in this kind of deployment we do anyway= s maintain the session(or binding in terms of DHCP) database on the box. Ha= ving said that I don't think storing client information is a problem (at le= ast in this deployment). The only extra thing which we would need to store = is a 'nonce'.=20 This is a heavy burden for the working group to take on for a small deploym= ent. Can you go into some detail about why this is the right way to solve= the problem, and what bad things would happen if you didn't have FORCERENE= W? I'm sorry to be stubborn about this, but you're talking about a DHCPv4 prot= ocol extension, and as you know from another draft that just went to the IE= SG, bandwidth is limited for the DHC working group=97we've had presentation= marathons at the last two IETFs, and I've had to chivvy presenters mercile= ssly just to avoid running over the generous time slots we've been given. = I feel really bad about doing that, and so I'm going to push back on propo= sals like this if I don't have a clear sense of their broad utility. I sa= y this sort of wearing my working group co-chair hat and sort of wearing my= working group participant hat=97as a participant, I don't see the broad ut= ility in this proposal, and as a chair I see a lot of work in my future. = So please, give us a clear sales pitch for why we should feel good about ta= king on this work. From volz@cisco.com Tue Sep 11 19:56:57 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FE321E804A for ; Tue, 11 Sep 2012 19:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zs9RjbMkjsuv for ; Tue, 11 Sep 2012 19:56:57 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id DD37221E8048 for ; Tue, 11 Sep 2012 19:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3008; q=dns/txt; s=iport; t=1347418617; x=1348628217; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=LuYH2XC2+oq+/ibjyBi2mYiOxsaIukrBWQ1MsQjm+Uk=; b=kjcIL+6QO+kQE0EfeMtfjRZeYd4DMYTLUglo5ZzckzO2BbUWh/EWhptq fgrfLWoJtjARsabfLdbWyYo1gUJF5wqJ9jxe9aHkEjJXTwIgEz5l9aiyU eHIjBGfM2VNmjeDtAPaj4AhCNh0lrMIBzCCHCdOSeknrG5Vg1bODyZtiv A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFj5T1CtJV2c/2dsb2JhbABFu1aBB4IgAQEBBAEBAQ8BWwsMBgEIEQQBASguCxQJCAIEAQ0FIodrC5tIoFUEixCGQgOVX442gWmCZoIX X-IronPort-AV: E=Sophos;i="4.80,407,1344211200"; d="scan'208";a="120677356" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 12 Sep 2012 02:56:56 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8C2uth2006737 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 02:56:55 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Tue, 11 Sep 2012 21:56:55 -0500 From: "Bernie Volz (volz)" To: "Gaurav Halwasia (ghalwasi)" , Ted Lemon , "" Thread-Topic: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) Thread-Index: AQHNkE8ckuiEXtYUDkaNnWZTSjI1wpeF7kOA////THCAACcbAA== Date: Wed, 12 Sep 2012 02:56:54 +0000 Message-ID: In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB19241E49@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.250.25] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.000 x-tm-as-result: No--47.792700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 02:56:57 -0000 Just to extend Ted's comments a bit - one issue is how long does the server keep the information for the Inform only clients. When the reconfigure-key is associated with a lease, we have a lease time; there is no such item for Inform. This could be tied to draft-halwasia-dhc-inform-refresh-time-opt (obviously it should be kept longer than the refresh time), but that work might also reduce the need for this -- at least it bounds the period where information may be stale. While in theory having Reconfigure for Inform isn't a bad concept, it just strikes me as overkill - do we really have a problem? Especially for IPv4 which we hope deprecate. I'm also not sure how many clients do just Informs =8A yes, there are lots of clients that do send Informs but they've usually also done Discover/... It is interesting that RFC 3315 accommodates Information-Request; not sure why RFC 6704 didn't - I would guess because RFC 3318 didn't. - Bernie On 9/11/12 9:45 PM, "Gaurav Halwasia (ghalwasi)" wrote: >Hi Ted, > >Thanks for your comments. > >I am talking about a deployment where we do create *session* database for >hosts either based upon DHCP packet (Discover) or the normal IP packet in >case few of the hosts has not done DHCP but instead has just DONE DHCP >INFORM to get the config parameters. So in this kind of deployment we do >anyways maintain the session(or binding in terms of DHCP) database on the >box. Having said that I don't think storing client information is a >problem (at least in this deployment). The only extra thing which we >would need to store is a 'nonce'. >So I think it will be really useful to have nonce in INFORM-ACK callflow >as it will also help in the usability of Forcerenew as per 6704. > >Thanks, >Gaurav=20 > >-----Original Message----- >From: Ted Lemon [mailto:Ted.Lemon@nominum.com] >Sent: Wednesday, September 12, 2012 2:09 AM >To: >Cc: Gaurav Halwasia (ghalwasi); dhcwg@ietf.org >Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) > >I didn't say that FORCERENEW for DHCPINFORM clients was hard. I said it >would impact performance. We would go from DHCPINFORM being a >lightweight read-only operation to a heavyweight read/write operation. >I guess we could forgo the sync-before-ack logic of stateful DHCP, but >this would add a lot of complexity to a performance-critical code section. > >So yeah, from an implementation point of view, I don't really like this >idea. It seems trivial until you think about the impact it has either >on performance or on implementation complexity. If there's strong >demand for it with a clear use case, then I think that's fine. I >wasn't able to tease one out of your rather dense message-could you try >to state your use case in a short paragraph or two? > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Tue Sep 11 20:01:24 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8526A21F8539 for ; Tue, 11 Sep 2012 20:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpTDcVvHw8Rt for ; Tue, 11 Sep 2012 20:01:23 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BD89521F8534 for ; Tue, 11 Sep 2012 20:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2217; q=dns/txt; s=iport; t=1347418883; x=1348628483; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=5pgIvDDWKS1pXOqqOAKugeNZ8op/DAEz0rdUYVhaRDo=; b=FLeOSgSveDoyhd56fwYzMnKaxrwzJihkUe5FjlLLZQ/NEJ+ZZXVlboZU nxTIfVVK72V9Qk4G6JwNGn/dPCNUFjD1bpU47PHa4LcTD6Z8Ibd6VLMsB OOufnnnL+Nj0sFjAVVTrXMthMWeJwm03W5wIYN9D9NAao8gd9Euh5LGiH w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPj5T1CtJV2c/2dsb2JhbABFu1eBB4IgAQEBBAEBAQ8BWwsSAQgYVQslAgQBDQUih2sLm0igUQSLEBSGLgOVX442gWmCZoFaPQ X-IronPort-AV: E=Sophos;i="4.80,407,1344211200"; d="scan'208";a="120637430" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 12 Sep 2012 03:01:23 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8C31NHk009896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 03:01:23 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Tue, 11 Sep 2012 22:01:22 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , "Gaurav Halwasia (ghalwasi)" Thread-Topic: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) Thread-Index: AQHNkE8ckuiEXtYUDkaNnWZTSjI1wpeF7kOA////THCAAGj/AP//v1kA Date: Wed, 12 Sep 2012 03:01:22 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.250.25] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.000 x-tm-as-result: No--47.304500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <8B1260EE301FCD4296D02BBBA078F6B9@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 03:01:24 -0000 Ted =8A I think you are spot on. We really have to prioritize and handle th= e major issues and also focus on the future - IPv6 and getting there. Marginal extensions to IPv4 should be very low priority (or even better dropped). - Bernie On 9/11/12 10:52 PM, "Ted Lemon" wrote: >On Sep 11, 2012, at 9:45 PM, "Gaurav Halwasia (ghalwasi)" > > wrote: >> I am talking about a deployment where we do create *session* database >>for hosts either based upon DHCP packet (Discover) or the normal IP >>packet in case few of the hosts has not done DHCP but instead has just >>DONE DHCP INFORM to get the config parameters. So in this kind of >>deployment we do anyways maintain the session(or binding in terms of >>DHCP) database on the box. Having said that I don't think storing client >>information is a problem (at least in this deployment). The only extra >>thing which we would need to store is a 'nonce'. > >This is a heavy burden for the working group to take on for a small >deployment. Can you go into some detail about why this is the right way >to solve the problem, and what bad things would happen if you didn't have >FORCERENEW? > >I'm sorry to be stubborn about this, but you're talking about a DHCPv4 >protocol extension, and as you know from another draft that just went to >the IESG, bandwidth is limited for the DHC working group=8Bwe've had >presentation marathons at the last two IETFs, and I've had to chivvy >presenters mercilessly just to avoid running over the generous time slots >we've been given. I feel really bad about doing that, and so I'm going >to push back on proposals like this if I don't have a clear sense of >their broad utility. I say this sort of wearing my working group >co-chair hat and sort of wearing my working group participant hat=8Bas a >participant, I don't see the broad utility in this proposal, and as a >chair I see a lot of work in my future. So please, give us a clear >sales pitch for why we should feel good about taking on this work. > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From ghalwasi@cisco.com Tue Sep 11 22:03:36 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D2E21E8064 for ; Tue, 11 Sep 2012 22:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.744 X-Spam-Level: X-Spam-Status: No, score=-9.744 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17p1Z3cwEX04 for ; Tue, 11 Sep 2012 22:03:35 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 623B621E8056 for ; Tue, 11 Sep 2012 22:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4428; q=dns/txt; s=iport; t=1347426215; x=1348635815; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=m97pPRlFfL+8B/nQR7CtTn8TZ4RbDJR6qFed3GfAorw=; b=NcbL5efqmU4zw2It8axAWkKe5lTfjt77H5S+jbjDTjqYtMfsDTsXSjMe puxKx/QFhxI4NIXH3nVCvKTcLmp6cFKvBUronV8QIYmIl76p/2+stDnpd pdAKFbaZTFXFT8ieoJmfXqnuAGgGryVpNxAMqaUZIrELGmTAjQw5GP1JR 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAoXUFCtJXG+/2dsb2JhbABFu1eBB4IgAQEBAwEBAQEPAVsLBQcEAgEIEQQBAQsdBycLFAkIAgQBDQUIGodlBgubP6BEBIsQhWJgA6QVgWmCZoIX X-IronPort-AV: E=Sophos;i="4.80,407,1344211200"; d="scan'208";a="120660334" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 12 Sep 2012 05:03:34 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8C53Yrr018831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 05:03:34 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Wed, 12 Sep 2012 00:03:33 -0500 From: "Gaurav Halwasia (ghalwasi)" To: "Bernie Volz (volz)" , Ted Lemon , "" Thread-Topic: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) Thread-Index: AQHNkE8ckuiEXtYUDkaNnWZTSjI1wpeF7kOA////THCAACcbAIAAD8pA Date: Wed, 12 Sep 2012 05:03:32 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB19242188@xmb-rcd-x06.cisco.com> References: <90903C21C73202418A48BFBE80AEE5EB19241E49@xmb-rcd-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.88] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.004 x-tm-as-result: No--49.264800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 05:03:36 -0000 Hi Ted, Bernie, Thanks for your thoughts. I think nobody can deny (including me) at this po= int of time that our focus should be on IPv6 and we should be willing to dr= op any minor DHCPv4 nits. I am with you on this.=20 > It is interesting that RFC 3315 accommodates Information-Request; not sur= e why RFC 6704 didn't - I would guess because RFC 3318 didn't. Are you sure you are referring to the correct spec. (3318.?) In case you me= ant RFC3203, I wanted to clarify that original Forcerenew spec indeed accom= modates DHCP INFORM triggered by Forcerenew as RFC 3315 accommodates Inform= ation-Request. So i was surprised to find no reference of INFORM in 6704. T= his is want I wanted to clarify. I am not particularly stressing to take t= his work right now but still finding it little confusing to find that as p= er current standards we are saying that we can use Forcerenew Nonce Authent= ication for RENEW triggered by FORCERENEW but we still have to use original= DHCP authentication for INFORM triggered by FORCERENEW. Anyways thanks for your clarifications. Thanks, Gaurav -----Original Message----- From: Bernie Volz (volz)=20 Sent: Wednesday, September 12, 2012 8:27 AM To: Gaurav Halwasia (ghalwasi); Ted Lemon; Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) Just to extend Ted's comments a bit - one issue is how long does the server= keep the information for the Inform only clients. When the reconfigure-key= is associated with a lease, we have a lease time; there is no such item fo= r Inform. This could be tied to draft-halwasia-dhc-inform-refresh-time-opt = (obviously it should be kept longer than the refresh time), but that work m= ight also reduce the need for this -- at least it bounds the period where i= nformation may be stale. While in theory having Reconfigure for Inform isn't a bad concept, it just = strikes me as overkill - do we really have a problem? Especially for IPv4 w= hich we hope deprecate. I'm also not sure how many clients do just Informs =A9 yes, there are lots = of clients that do send Informs but they've usually also done Discover/... It is interesting that RFC 3315 accommodates Information-Request; not sure = why RFC 6704 didn't - I would guess because RFC 3318 didn't. - Bernie On 9/11/12 9:45 PM, "Gaurav Halwasia (ghalwasi)" wrote: >Hi Ted, > >Thanks for your comments. > >I am talking about a deployment where we do create *session* database=20 >for hosts either based upon DHCP packet (Discover) or the normal IP=20 >packet in case few of the hosts has not done DHCP but instead has just=20 >DONE DHCP INFORM to get the config parameters. So in this kind of=20 >deployment we do anyways maintain the session(or binding in terms of=20 >DHCP) database on the box. Having said that I don't think storing=20 >client information is a problem (at least in this deployment). The only=20 >extra thing which we would need to store is a 'nonce'. >So I think it will be really useful to have nonce in INFORM-ACK=20 >callflow as it will also help in the usability of Forcerenew as per 6704. > >Thanks, >Gaurav > >-----Original Message----- >From: Ted Lemon [mailto:Ted.Lemon@nominum.com] >Sent: Wednesday, September 12, 2012 2:09 AM >To: >Cc: Gaurav Halwasia (ghalwasi); dhcwg@ietf.org >Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) > >I didn't say that FORCERENEW for DHCPINFORM clients was hard. I said it >would impact performance. We would go from DHCPINFORM being a >lightweight read-only operation to a heavyweight read/write operation. >I guess we could forgo the sync-before-ack logic of stateful DHCP, but=20 >this would add a lot of complexity to a performance-critical code section. > >So yeah, from an implementation point of view, I don't really like this >idea. It seems trivial until you think about the impact it has either >on performance or on implementation complexity. If there's strong >demand for it with a clear use case, then I think that's fine. I >wasn't able to tease one out of your rather dense message-could you try=20 >to state your use case in a short paragraph or two? > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Wed Sep 12 04:28:13 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F0A21F85F0 for ; Wed, 12 Sep 2012 04:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGG5LfxlU24p for ; Wed, 12 Sep 2012 04:28:12 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 12B5121F85ED for ; Wed, 12 Sep 2012 04:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4775; q=dns/txt; s=iport; t=1347449292; x=1348658892; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PMA+4jUJYji/avJiqmskMg2eHf8N9pAuotqvIkQX+UE=; b=AbASp/47x1ebluSq2DyXPj1rTizWyz7ahe6I+y/6CSzsmMHjhMXYDFGR WNnXa1nML5sOCA2vtg56JmKdILK7Z5S/HowPEKjbsKVj/QpwQ7ZibmpVw tP2i0wDdzdXoXDou0zxZhGv7NGW8O+Q6UwqqWDpW89DE+Zc6utF6h3k+0 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAK1wUFCtJXHA/2dsb2JhbABFu0CBB4IgAQEBAwEBAQEPARRHCwUHBAIBCBEEAQEBJwcnCxQJCAIEDgUih2UGC5t0oEAEixCFYmADlV+ONoFpgmY X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="117751406" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 12 Sep 2012 11:28:11 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8CBSBm5014475 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 11:28:11 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Wed, 12 Sep 2012 06:28:11 -0500 From: "Bernie Volz (volz)" To: "Gaurav Halwasia (ghalwasi)" Thread-Topic: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) Thread-Index: AQHNkE8ckuiEXtYUDkaNnWZTSjI1wpeF7kOA////THCAACcbAIAAD8pAgABuTuE= Date: Wed, 12 Sep 2012 11:28:10 +0000 Message-ID: <5F34B086-D5C8-4628-AAE4-1D3CBDEDF24E@cisco.com> References: <90903C21C73202418A48BFBE80AEE5EB19241E49@xmb-rcd-x06.cisco.com> , <90903C21C73202418A48BFBE80AEE5EB19242188@xmb-rcd-x06.cisco.com> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB19242188@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.005 x-tm-as-result: No--51.373700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Ted Lemon , "" Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 11:28:13 -0000 3318 --> 3118. Sorry for typo. - Bernie On Sep 12, 2012, at 1:03 AM, "Gaurav Halwasia (ghalwasi)" wrote: > Hi Ted, Bernie, >=20 > Thanks for your thoughts. I think nobody can deny (including me) at this = point of time that our focus should be on IPv6 and we should be willing to = drop any minor DHCPv4 nits. I am with you on this.=20 >=20 >> It is interesting that RFC 3315 accommodates Information-Request; not su= re why RFC 6704 didn't - I would guess because RFC 3318 didn't. >=20 > Are you sure you are referring to the correct spec. (3318.?) In case you = meant RFC3203, I wanted to clarify that original Forcerenew spec indeed acc= ommodates DHCP INFORM triggered by Forcerenew as RFC 3315 accommodates Info= rmation-Request. So i was surprised to find no reference of INFORM in 6704.= This is want I wanted to clarify. I am not particularly stressing to take= this work right now but still finding it little confusing to find that as= per current standards we are saying that we can use Forcerenew Nonce Authe= ntication for RENEW triggered by FORCERENEW but we still have to use origin= al DHCP authentication for INFORM triggered by FORCERENEW. >=20 > Anyways thanks for your clarifications. >=20 > Thanks, > Gaurav > -----Original Message----- > From: Bernie Volz (volz)=20 > Sent: Wednesday, September 12, 2012 8:27 AM > To: Gaurav Halwasia (ghalwasi); Ted Lemon; > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) >=20 > Just to extend Ted's comments a bit - one issue is how long does the serv= er keep the information for the Inform only clients. When the reconfigure-k= ey is associated with a lease, we have a lease time; there is no such item = for Inform. This could be tied to draft-halwasia-dhc-inform-refresh-time-op= t (obviously it should be kept longer than the refresh time), but that work= might also reduce the need for this -- at least it bounds the period where= information may be stale. >=20 > While in theory having Reconfigure for Inform isn't a bad concept, it jus= t strikes me as overkill - do we really have a problem? Especially for IPv4= which we hope deprecate. >=20 > I'm also not sure how many clients do just Informs =8A yes, there are lot= s of clients that do send Informs but they've usually also done Discover/..= . >=20 > It is interesting that RFC 3315 accommodates Information-Request; not sur= e why RFC 6704 didn't - I would guess because RFC 3318 didn't. >=20 > - Bernie >=20 > On 9/11/12 9:45 PM, "Gaurav Halwasia (ghalwasi)" > wrote: >=20 >> Hi Ted, >>=20 >> Thanks for your comments. >>=20 >> I am talking about a deployment where we do create *session* database=20 >> for hosts either based upon DHCP packet (Discover) or the normal IP=20 >> packet in case few of the hosts has not done DHCP but instead has just=20 >> DONE DHCP INFORM to get the config parameters. So in this kind of=20 >> deployment we do anyways maintain the session(or binding in terms of=20 >> DHCP) database on the box. Having said that I don't think storing=20 >> client information is a problem (at least in this deployment). The only= =20 >> extra thing which we would need to store is a 'nonce'. >> So I think it will be really useful to have nonce in INFORM-ACK=20 >> callflow as it will also help in the usability of Forcerenew as per 6704= . >>=20 >> Thanks, >> Gaurav >>=20 >> -----Original Message----- >> From: Ted Lemon [mailto:Ted.Lemon@nominum.com] >> Sent: Wednesday, September 12, 2012 2:09 AM >> To: >> Cc: Gaurav Halwasia (ghalwasi); dhcwg@ietf.org >> Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) >>=20 >> I didn't say that FORCERENEW for DHCPINFORM clients was hard. I said i= t >> would impact performance. We would go from DHCPINFORM being a >> lightweight read-only operation to a heavyweight read/write operation. >> I guess we could forgo the sync-before-ack logic of stateful DHCP, but=20 >> this would add a lot of complexity to a performance-critical code sectio= n. >>=20 >> So yeah, from an implementation point of view, I don't really like this >> idea. It seems trivial until you think about the impact it has either >> on performance or on implementation complexity. If there's strong >> demand for it with a clear use case, then I think that's fine. I >> wasn't able to tease one out of your rather dense message-could you try= =20 >> to state your use case in a short paragraph or two? >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 From Ted.Lemon@nominum.com Wed Sep 12 05:34:09 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2EE21F859B for ; Wed, 12 Sep 2012 05:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.543 X-Spam-Level: X-Spam-Status: No, score=-106.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtB-oqv1avCV for ; Wed, 12 Sep 2012 05:34:08 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5B09921F85A2 for ; Wed, 12 Sep 2012 05:34:08 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUFCBPaLpQiZVpnCCkD0Yc2BnWpK0Dn0v@postini.com; Wed, 12 Sep 2012 05:34:08 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 11925F80A3 for ; Wed, 12 Sep 2012 05:33:56 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 06DAC19005C; Wed, 12 Sep 2012 05:33:56 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 12 Sep 2012 05:33:50 -0700 From: Ted Lemon To: "Gaurav Halwasia (ghalwasi)" Thread-Topic: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) Thread-Index: AQHNkE8cKpbVbNLxRMad4YyhUAitE5eGD8kAgABVhgCAABPzAIAAI2EAgAB9z4A= Date: Wed, 12 Sep 2012 12:33:48 +0000 Message-ID: <5B2EA53A-C3C9-4B6B-BE17-1B51B8BD5E44@nominum.com> References: <90903C21C73202418A48BFBE80AEE5EB19241E49@xmb-rcd-x06.cisco.com> <90903C21C73202418A48BFBE80AEE5EB19242188@xmb-rcd-x06.cisco.com> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB19242188@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" , "" Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 12:34:09 -0000 On Sep 12, 2012, at 1:03 AM, "Gaurav Halwasia (ghalwasi)" wrote: > Are you sure you are referring to the correct spec. (3318.?) In case you = meant RFC3203, I wanted to clarify that original Forcerenew spec indeed acc= ommodates DHCP INFORM triggered by Forcerenew as RFC 3315 accommodates Info= rmation-Request. So i was surprised to find no reference of INFORM in 6704.= This is want I wanted to clarify. I am not particularly stressing to take= this work right now but still finding it little confusing to find that as= per current standards we are saying that we can use Forcerenew Nonce Authe= ntication for RENEW triggered by FORCERENEW but we still have to use origin= al DHCP authentication for INFORM triggered by FORCERENEW. Okay, now I understand why you raised this now. I still think it's not wo= rk we ought to take on right now, but it makes more sense now. BTW, having given you a bit of a hard time about proposing new work for the= working group, I would like to commend you for raising this on the mailing= list between meetings. Now is a really good time to be proposing new wor= k, so that we can discuss it and decide whether it needs a presentation at = the next IETF. I hope others will follow your example, and that my reacti= on won't discourage this. From john_brzozowski@cable.comcast.com Wed Sep 12 12:30:10 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF2B21F8674 for ; Wed, 12 Sep 2012 12:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.064 X-Spam-Level: X-Spam-Status: No, score=-103.064 tagged_above=-999 required=5 tests=[AWL=2.167, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ysj-D8XKO6W9 for ; Wed, 12 Sep 2012 12:30:10 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 5463121F8620 for ; Wed, 12 Sep 2012 12:30:10 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.33092787; Wed, 12 Sep 2012 13:08:38 -0600 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.230]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0309.002; Wed, 12 Sep 2012 15:30:05 -0400 From: "Brzozowski, John" Thread-Topic: [dhcwg] SOL MAX RT Thread-Index: AQHNkR0BaQGOcCBbNkS5TFR4leqD8Q== Date: Wed, 12 Sep 2012 19:29:22 +0000 Message-ID: References: <867F4B6A1672E541A94676D556793ACD16E4DC56E6@MOPESMBX01.eu.thmulti.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD16E4DC56E6@MOPESMBX01.eu.thmulti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="us-ascii" Content-ID: <9FFAB2208C4C1348AEBD3271DB556525@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: Wuyts Carl Cc: dhc WG Subject: Re: [dhcwg] SOL MAX RT X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 19:30:11 -0000 Carl, I do not think this is possible, I will check and get back to you unless so= meone beats me to it on the list. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) +1-609-377-6594 e) mailto:john_brzozowski@cable.comcast.com o) +1-484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Sep 4, 2012, at 7:08 AM, Wuyts Carl wrote: > All, > =20 > Anyone an idea when an option number will be assigned for this oro (as it= still says TBD in below draft) ? > (I-D.droms-dhc-dhcpv6-solmaxrt-update) > =20 > Thx and regs > Carl > =20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Wed Sep 12 20:05:07 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A53C21F850D for ; Wed, 12 Sep 2012 20:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.419 X-Spam-Level: X-Spam-Status: No, score=-10.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZe40fIdoqAY for ; Wed, 12 Sep 2012 20:05:06 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A7A0421F84FE for ; Wed, 12 Sep 2012 20:05:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2054; q=dns/txt; s=iport; t=1347505506; x=1348715106; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pUqoqhNi4KR1aZCiE9gDnhFn70IM398BtQYjfxubAQE=; b=Np+RTywMmOuqDkhIoRnS/7Tm4A4McKln0uUzbediM7RSVtaIxm746RU1 kPJGrNCR/1sDYLDJD3CpqCAo3qfb6k8pCaSJKhPXSRLn7+Ou3UH6o2Uih ZX7MRz7QQcXAPzugH3TRjnXDY/TX3IwIpnp2q+WduuLiGGjr8XFlmVhUX c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADJNUVCtJV2Y/2dsb2JhbABCA7tygQeCIAEBAQMBAQEBDwEnMQMLBQcEAgEIEQQBAQsUCQcnCxQJCAIEAQ0FCBqHZQYLm1WgOYsQgx6CRGADpBWBaYJmghc X-IronPort-AV: E=Sophos;i="4.80,413,1344211200"; d="scan'208";a="121029341" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 13 Sep 2012 03:05:06 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8D356OY022840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Sep 2012 03:05:06 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Wed, 12 Sep 2012 22:05:05 -0500 From: "Bernie Volz (volz)" To: "Brzozowski, John" , Wuyts Carl Thread-Topic: [dhcwg] SOL MAX RT Thread-Index: AQHNkR0BaQGOcCBbNkS5TFR4leqD8ZeHlYhA Date: Thu, 13 Sep 2012 03:05:04 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F4FDE8B@xmb-rcd-x04.cisco.com> References: <867F4B6A1672E541A94676D556793ACD16E4DC56E6@MOPESMBX01.eu.thmulti.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.215] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19180.000 x-tm-as-result: No--43.892100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] SOL MAX RT X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 03:05:07 -0000 Option numbers are assigned once the IESG has approved the document for pub= lication (IANA then does its work). This isn't yet an IESG work item (it is= still an individual submission, not even a WG document). Not really sure what the hold-up is as I thought this was pretty cut and dr= y. RFC 3315 actually permits early assignment (Section 24), so not sure if the= DHC WG wants to consider that approach if this case: New DHCP option codes are tentatively assigned after the specification for the associated option, published as an Internet Draft, has received expert review by a designated expert [11]. The final assignment of DHCP option codes is through Standards Action, as defined in RFC 2434 [11]. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= rzozowski, John Sent: Wednesday, September 12, 2012 3:29 PM To: Wuyts Carl Cc: dhc WG Subject: Re: [dhcwg] SOL MAX RT Carl, I do not think this is possible, I will check and get back to you unless so= meone beats me to it on the list. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) +1-609-377-6594 e) mailto:john_brzozowski@cable.comcast.com o) +1-484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Sep 4, 2012, at 7:08 AM, Wuyts Carl wrote: > All, > =20 > Anyone an idea when an option number will be assigned for this oro (as it= still says TBD in below draft) ? > (I-D.droms-dhc-dhcpv6-solmaxrt-update) > =20 > Thx and regs > Carl > =20 > _______________________________________________ > 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 volz@cisco.com Wed Sep 12 20:15:53 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4353D21E803A for ; Wed, 12 Sep 2012 20:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wLebRzGZBIX for ; Wed, 12 Sep 2012 20:15:52 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8892C21E8034 for ; Wed, 12 Sep 2012 20:15:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2114; q=dns/txt; s=iport; t=1347506152; x=1348715752; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XDS+zgfFIJMinMbhxAwuSfowlYi5d+RjZy+87dZTOMQ=; b=izGBlIHhdBNCyZ6rGa7pnvv12I/kfgdBFBYNhtv6RgEKBxp7V0i1QGuH cKuWcv/AJYm7DN+UlfkGEh4Onc0oWaWbcjdFh76YLbNizVEck3oVvWQ9u T0k5vdWoHWjvbssgqJ1LTUjjN7abj+GBwRFAGI95HOYWmEZo9zwebGLP+ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAK5OUVCtJV2b/2dsb2JhbABCA7tygQeCIAEBAQQBAQEPASc0CwwEAgEIDgMEAQEBChQJByEGCxQJCAIEAQ0FCBqHXAMMC5tWllgNiU8Eii1jgx6CRGADlAqMaoMhgWmCZoIX X-IronPort-AV: E=Sophos;i="4.80,413,1344211200"; d="scan'208";a="121092041" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 13 Sep 2012 03:15:52 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8D3FptQ027206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Sep 2012 03:15:51 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Wed, 12 Sep 2012 22:15:51 -0500 From: "Bernie Volz (volz)" To: Donald Eastlake , Andre Kostur Thread-Topic: [dhcwg] Load Balancing for DHCPv6 Thread-Index: AQHNj2xDaJ+khP2NkUiXQs2wUqwOeJeHnBuA Date: Thu, 13 Sep 2012 03:15:50 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F4FDEBC@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> <5049C317.7090603@gmail.com> <94FA926F-2432-4AE7-BC20-AE7458AB40D9@cisco.com> <71F17433-B2D9-4366-9B32-F0E4D294EDB5@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.215] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19180.000 x-tm-as-result: No--48.841700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 03:15:53 -0000 One comment on the draft is that I think it needs to be clear that load bal= ancing is ONLY used for DHCPv6 client messages that do not include a server= -identifier option (this is Solicit, Information-Request (if no server-iden= tifier option), Rebind, and Confirm). Load balancing MUST NOT be used if a = server-identifier option exists in the client's message, as then only that = server should respond. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of D= onald Eastlake Sent: Monday, September 10, 2012 11:52 AM To: Andre Kostur Cc: dhcwg@ietf.org; Ted Lemon Subject: Re: [dhcwg] Load Balancing for DHCPv6 Moving this to a WG draft seems reasonable. It appears that it is hard for several different reasons (the grad student = who did all the work is gone, Brian is now fully retired and about to go on= a month's vacation, etc...) for Brian Carpenter to just run the same test = on Pearson but he can probably do some lesser amount of testing. I'm contin= uing to converse with him on this... Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Sun, Sep 9, 2012 at 10:42 AM, Andre Kostur wrote= : > On Sat, Sep 8, 2012 at 7:50 PM, Ted Lemon wrote: >> >> On Sep 8, 2012, at 7:35 PM, Donald Eastlake wrote: >> > How much of a rush is there on this? >> >> I don't think there's a huge rush, but Andre might disagree... :) >> > > Other than keeping the draft moving along.... > > Does the WG want to take this on as a working item? I think we can=20 > get that part of the draft process resolved (and possibly publish > draft-ietf-dhc-loadbv6-00) while we're waiting for the results of=20 > Pearson vs. FNV. > > -- > Andre Kostur _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Wed Sep 12 20:19:07 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4335B21E8042 for ; Wed, 12 Sep 2012 20:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwZvP9jyymWa for ; Wed, 12 Sep 2012 20:19:06 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5078E21E8034 for ; Wed, 12 Sep 2012 20:19:06 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUFFQqfZZXe6Xj895HFJh2Qd1Uk77MTKQ@postini.com; Wed, 12 Sep 2012 20:19:06 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 84C5C108005 for ; Wed, 12 Sep 2012 20:19:05 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 798C219005C; Wed, 12 Sep 2012 20:19:05 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Wed, 12 Sep 2012 20:19:05 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] SOL MAX RT Thread-Index: Ac2KjY71PtWS24h1QXS6kMDArPK2SwGygaIAAA/qRwAAAH0rAA== Date: Thu, 13 Sep 2012 03:19:04 +0000 Message-ID: References: <867F4B6A1672E541A94676D556793ACD16E4DC56E6@MOPESMBX01.eu.thmulti.com> <489D13FBFA9B3E41812EA89F188F018E0F4FDE8B@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F4FDE8B@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <9F18DCEF402A92428A76113A9BF8069D@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] SOL MAX RT X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 03:19:07 -0000 On Sep 12, 2012, at 11:05 PM, Bernie Volz (volz) wrote: > Not really sure what the hold-up is as I thought this was pretty cut and = dry. The responsible AD (Jari) was succeeded by a new AD (Brian Haberman). The= draft then fell between the cracks. This is a really good reason to just= do drafts in the working group... From mohamed.boucadair@orange.com Wed Sep 12 23:07:19 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148F121E8047 for ; Wed, 12 Sep 2012 23:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1xVSpXD9nAW for ; Wed, 12 Sep 2012 23:07:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5D121E8042 for ; Wed, 12 Sep 2012 23:07:18 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 31BB12DC42D for ; Thu, 13 Sep 2012 08:07:17 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1638735C11C for ; Thu, 13 Sep 2012 08:07:17 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 13 Sep 2012 08:07:11 +0200 From: To: "dhcwg@ietf.org WG" Date: Thu, 13 Sep 2012 08:07:10 +0200 Thread-Topic: draft-ietf-dhc-triggered-reconfigure: discussion points Thread-Index: Ac2RdgKbWGMEY7pxQDWB7H+aM3m9Vw== Message-ID: <94C682931C08B048B7A8645303FDC9F36E5A10C549@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E5A10C549PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.13.53319 Subject: [dhcwg] draft-ietf-dhc-triggered-reconfigure: discussion points X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 06:07:19 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E5A10C549PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I would like to prepare -01 which solves two open issues we had in -00: Discussion #1: Should the document specify the behavior of intermediate relay agents if any? Discussion #2: What to do when all clients bound to the same relay agent are impacted by a configuration change? Should the document indicate the relay MUST include Relay-ID Option (RFC5460)? Any opinion on how to proceed with these two points? Thanks. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F36E5A10C549PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D= ear=20 all,
 
I= would like=20 to prepare -01 which solves two open issues we had in=20 -00:
 
RFC5460)?
 
A= ny opinion=20 on how to proceed with these two points?
 
T= hanks.=20
 
Cheers,
Med
 
 
--_000_94C682931C08B048B7A8645303FDC9F36E5A10C549PUEXCB1Bnante_-- From Carl.Wuyts@technicolor.com Wed Sep 12 23:36:34 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FB621E8047 for ; Wed, 12 Sep 2012 23:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.146 X-Spam-Level: X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAfFWiAHYwAX for ; Wed, 12 Sep 2012 23:36:34 -0700 (PDT) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with ESMTP id 52C6421F8496 for ; Wed, 12 Sep 2012 23:36:32 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKUFF+7+gxGl+pl8e7D0yzR/oKWwPwM2wU@postini.com; Wed, 12 Sep 2012 23:36:33 PDT Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.264.0; Thu, 13 Sep 2012 08:34:37 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.14]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Thu, 13 Sep 2012 08:34:49 +0200 From: Wuyts Carl To: "Brzozowski, John" Date: Thu, 13 Sep 2012 08:34:48 +0200 Thread-Topic: [dhcwg] SOL MAX RT Thread-Index: AQHNkR0BaQGOcCBbNkS5TFR4leqD8ZeH0D7w Message-ID: <867F4B6A1672E541A94676D556793ACD16E4E8D555@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD16E4DC56E6@MOPESMBX01.eu.thmulti.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: dhc WG Subject: Re: [dhcwg] SOL MAX RT X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 06:36:34 -0000 Thx John, Thing is that it get referred to from RFC6204, making it impossible for a C= PE to meet the requirement of course. We could take a proprietary option, = but then every implementation would/could use a different number, which is = to avoid I'd say. In fact, this already happened before with DSLite option= . I've bumped into some implementation some time ago which was using a dif= ferent number for the DSLite option, hence making the setup fail initially.= =20 =20 Regs Carl -----Original Message----- From: Brzozowski, John [mailto:John_Brzozowski@Cable.Comcast.com]=20 Sent: woensdag 12 september 2012 21:29 To: Wuyts Carl Cc: dhc WG Subject: Re: [dhcwg] SOL MAX RT Carl, I do not think this is possible, I will check and get back to you unless so= meone beats me to it on the list. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) +1-609-377-6594 e) mailto:john_brzozowski@cable.comcast.com o) +1-484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Sep 4, 2012, at 7:08 AM, Wuyts Carl wrote: > All, > =20 > Anyone an idea when an option number will be assigned for this oro (as it= still says TBD in below draft) ? > (I-D.droms-dhc-dhcpv6-solmaxrt-update) > =20 > Thx and regs > Carl > =20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From internet-drafts@ietf.org Thu Sep 13 01:53:20 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C33E21F852C; Thu, 13 Sep 2012 01:53:20 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hO2C2XwzK+a4; Thu, 13 Sep 2012 01:53:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136A721F859C; Thu, 13 Sep 2012 01:53:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120913085320.22965.11088.idtracker@ietfa.amsl.com> Date: Thu, 13 Sep 2012 01:53:20 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 08:53:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : DHCPv4 over IPv6 Transport Author(s) : Yong Cui Peng Wu Jianping Wu Ted Lemon Filename : draft-ietf-dhc-dhcpv4-over-ipv6-04.txt Pages : 14 Date : 2012-09-13 Abstract: In IPv6 networks, there remains a need to provide IPv4 service for some residual devices. This document describes a mechanism for allocating IPv4 addresses to such devices, using DHCPv4 with an IPv6 transport. It is done by putting a special relay agent function (Client Relay Agent) on the client side, as well as extending the behavior of the server; in the case where DHCP server only supports IPv4 transport, a relay agent is extended to support IPv6 transport (IPv6-Transport Relay Agent) and relay DHCP traffic for the server, with a new Relay Agent Information sub-option added to carry the IPv6 address of the Client Relay Agent. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-ipv6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-ipv6-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv4-over-ipv6-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pengwu.thu@gmail.com Thu Sep 13 02:31:13 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C5621F856F for ; Thu, 13 Sep 2012 02:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwN7S-EhujsL for ; Thu, 13 Sep 2012 02:31:13 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5829D21F8554 for ; Thu, 13 Sep 2012 02:31:13 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so3579095vbb.31 for ; Thu, 13 Sep 2012 02:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=AuWNDfX4WddffDIHajzZS8m9TThiucs41nGRpsi1c0g=; b=IgmE5EVSefknlRNwu6k3RwVgl2Xzdk73UGF7GOzyWJUy4Fnttag/iCL6q9cmsbibI/ IISAeMDKogrSo6f7BrDrBpzjf/lgx7/A1MH3m+47JWe+t3OcXicUETNdLnWQ/y8GIp1M vt3IbuwDHMN2QjrbUCFeEV30wCLPdCJOLGSaZ3fYtZTgz1GvLLCS41JuE0nPmB3gKwRo /eY7wQoPysWjQU/nCNs8kCtQ4TW8LxwraMlUpWX8j97B4pGTY0AWS8pgMxye5YgyoBkq wY7QhKcVqu5PAp23Akbxlvrr1QC50xYIxsZ2sw258BjKqv9d0ZqEW6MDBl8/TrsKhSLw wGBA== MIME-Version: 1.0 Received: by 10.220.155.3 with SMTP id q3mr910497vcw.11.1347528672496; Thu, 13 Sep 2012 02:31:12 -0700 (PDT) Received: by 10.58.35.168 with HTTP; Thu, 13 Sep 2012 02:31:12 -0700 (PDT) In-Reply-To: <20120913085320.22965.11088.idtracker@ietfa.amsl.com> References: <20120913085320.22965.11088.idtracker@ietfa.amsl.com> Date: Thu, 13 Sep 2012 17:31:12 +0800 Message-ID: From: Peng Wu To: dhc WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 09:31:14 -0000 Hi all, This is mainly a "polishing" update of the draft. Most of the technical specifications remains the same as last version. The main updates are: a)substential edits b)Re-structure the contents of choosing between DHCPv4 over IPv6/DHCPv4 over tunnel/DHCPv6 c)Make the usage of relay-encapsulation clear through the document, rather than just reference the draft. Thanks Ted for so many valuable inputs. On Thu, Sep 13, 2012 at4:53 PM, wrote: > > 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 : DHCPv4 over IPv6 Transport > Author(s) : Yong Cui > Peng Wu > Jianping Wu > Ted Lemon > Filename : draft-ietf-dhc-dhcpv4-over-ipv6-04.txt > Pages : 14 > Date : 2012-09-13 > > Abstract: > In IPv6 networks, there remains a need to provide IPv4 service for > some residual devices. This document describes a mechanism for > allocating IPv4 addresses to such devices, using DHCPv4 with an IPv6 > transport. It is done by putting a special relay agent function > (Client Relay Agent) on the client side, as well as extending the > behavior of the server; in the case where DHCP server only supports > IPv4 transport, a relay agent is extended to support IPv6 transport > (IPv6-Transport Relay Agent) and relay DHCP traffic for the server, > with a new Relay Agent Information sub-option added to carry the IPv6 > address of the Client Relay Agent. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-ipv6 > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-ipv6-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv4-over-ipv6-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Thu Sep 13 05:17:33 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B69721F8462 for ; Thu, 13 Sep 2012 05:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rlGynuOuHPa for ; Thu, 13 Sep 2012 05:17:32 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 49DA121F845B for ; Thu, 13 Sep 2012 05:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2066; q=dns/txt; s=iport; t=1347538652; x=1348748252; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NHRB/TPbCWN88bhLMkKJmgz9Rx1Lvy8fXA8boHVhpro=; b=mIRp989Pm05st0rtZPP6Tmf0SV7Zcc7vL4JgmSH6PhDae6PbrjwVEeax xl0zfF33mN2WcM53oBu9elMSWQM61IgiVA1IGFy4wNLf0UuAvn+kt/dn6 Nv7HAkPAXYofBw0UmDGVGzhIUnUDS5nIirukEtsT4siwFPMfUMRt40S+3 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAK3OUVCtJV2b/2dsb2JhbABCA7tvgQeCIAEBAQMBAQEBDwEnNAsFBwQCAQgRBAEBAR4JBycLFAkIAgQOBSKHZQYLm2mgOosQgxOCRGADlV+ONoFpgmY X-IronPort-AV: E=Sophos;i="4.80,416,1344211200"; d="scan'208";a="120959317" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 13 Sep 2012 12:17:32 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8DCHVVL013987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Sep 2012 12:17:31 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Thu, 13 Sep 2012 07:17:31 -0500 From: "Bernie Volz (volz)" To: Wuyts Carl Thread-Topic: [dhcwg] SOL MAX RT Thread-Index: AQHNkR0BaQGOcCBbNkS5TFR4leqD8ZeH0D7wgABhBpU= Date: Thu, 13 Sep 2012 12:17:31 +0000 Message-ID: <4C08562B-0B94-48EC-9651-193143EF4BDF@cisco.com> References: <867F4B6A1672E541A94676D556793ACD16E4DC56E6@MOPESMBX01.eu.thmulti.com> , <867F4B6A1672E541A94676D556793ACD16E4E8D555@MOPESMBX01.eu.thmulti.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD16E4E8D555@MOPESMBX01.eu.thmulti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19180.005 x-tm-as-result: No--47.666900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] SOL MAX RT X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 12:17:33 -0000 If you want to make it proprietary, use a Vendor Information Option (17). Sent from my iPad On Sep 13, 2012, at 2:36 AM, "Wuyts Carl" wrot= e: > Thx John, >=20 > Thing is that it get referred to from RFC6204, making it impossible for a= CPE to meet the requirement of course. We could take a proprietary option= , but then every implementation would/could use a different number, which i= s to avoid I'd say. In fact, this already happened before with DSLite opti= on. I've bumped into some implementation some time ago which was using a d= ifferent number for the DSLite option, hence making the setup fail initiall= y.=20 >=20 > Regs > Carl >=20 >=20 >=20 >=20 > -----Original Message----- > From: Brzozowski, John [mailto:John_Brzozowski@Cable.Comcast.com]=20 > Sent: woensdag 12 september 2012 21:29 > To: Wuyts Carl > Cc: dhc WG > Subject: Re: [dhcwg] SOL MAX RT >=20 > Carl, >=20 > I do not think this is possible, I will check and get back to you unless = someone beats me to it on the list. >=20 > John > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > John Jason Brzozowski > Comcast Cable > m) +1-609-377-6594 > e) mailto:john_brzozowski@cable.comcast.com > o) +1-484-962-0060 > w) http://www.comcast6.net > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > On Sep 4, 2012, at 7:08 AM, Wuyts Carl wrote: >=20 >> All, >>=20 >> Anyone an idea when an option number will be assigned for this oro (as i= t still says TBD in below draft) ? >> (I-D.droms-dhc-dhcpv6-solmaxrt-update) >>=20 >> Thx and regs >> Carl >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From john_brzozowski@cable.comcast.com Thu Sep 13 05:22:44 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFAE21F85A7 for ; Thu, 13 Sep 2012 05:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.148 X-Spam-Level: X-Spam-Status: No, score=-104.148 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-FmJO5ELSdI for ; Thu, 13 Sep 2012 05:22:44 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 010EA21F85A4 for ; Thu, 13 Sep 2012 05:22:43 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.33166760; Thu, 13 Sep 2012 06:01:10 -0600 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.230]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0309.002; Thu, 13 Sep 2012 08:22:39 -0400 From: "Brzozowski, John" To: Wuyts Carl Thread-Topic: [dhcwg] SOL MAX RT Thread-Index: AQHNkR0BaQGOcCBbNkS5TFR4leqD8ZeH0D7wgACleIA= Date: Thu, 13 Sep 2012 12:21:55 +0000 Message-ID: References: <867F4B6A1672E541A94676D556793ACD16E4DC56E6@MOPESMBX01.eu.thmulti.com> <867F4B6A1672E541A94676D556793ACD16E4E8D555@MOPESMBX01.eu.thmulti.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD16E4E8D555@MOPESMBX01.eu.thmulti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="us-ascii" Content-ID: <30C9FEECCCDFFD42A989E8DF97D8ABC8@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] SOL MAX RT X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 12:22:45 -0000 You will see some follow up mail from me on this draft today or tomorrow. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) +1-609-377-6594 e) mailto:john_brzozowski@cable.comcast.com o) +1-484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Sep 13, 2012, at 2:34 AM, Wuyts Carl wrote: > Thx John, >=20 > Thing is that it get referred to from RFC6204, making it impossible for a= CPE to meet the requirement of course. We could take a proprietary option= , but then every implementation would/could use a different number, which i= s to avoid I'd say. In fact, this already happened before with DSLite opti= on. I've bumped into some implementation some time ago which was using a d= ifferent number for the DSLite option, hence making the setup fail initiall= y.=20 >=20 > Regs > Carl >=20 >=20 >=20 >=20 > -----Original Message----- > From: Brzozowski, John [mailto:John_Brzozowski@Cable.Comcast.com]=20 > Sent: woensdag 12 september 2012 21:29 > To: Wuyts Carl > Cc: dhc WG > Subject: Re: [dhcwg] SOL MAX RT >=20 > Carl, >=20 > I do not think this is possible, I will check and get back to you unless = someone beats me to it on the list. >=20 > John > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > John Jason Brzozowski > Comcast Cable > m) +1-609-377-6594 > e) mailto:john_brzozowski@cable.comcast.com > o) +1-484-962-0060 > w) http://www.comcast6.net > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > On Sep 4, 2012, at 7:08 AM, Wuyts Carl wrote: >=20 >> All, >>=20 >> Anyone an idea when an option number will be assigned for this oro (as i= t still says TBD in below draft) ? >> (I-D.droms-dhc-dhcpv6-solmaxrt-update) >>=20 >> Thx and regs >> Carl >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 From Carl.Wuyts@technicolor.com Thu Sep 13 06:06:38 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A9821F85A3 for ; Thu, 13 Sep 2012 06:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.202 X-Spam-Level: X-Spam-Status: No, score=-6.202 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id li8HGHv4ityp for ; Thu, 13 Sep 2012 06:06:37 -0700 (PDT) Received: from na3sys009aog127.obsmtp.com (na3sys009aog127.obsmtp.com [74.125.149.107]) by ietfa.amsl.com (Postfix) with ESMTP id 4264821F85C4 for ; Thu, 13 Sep 2012 06:06:36 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob127.postini.com ([74.125.148.12]) with SMTP ID DSNKUFHaWqbvzkrKsc1aujAelFh+Xyr5uDFX@postini.com; Thu, 13 Sep 2012 06:06:37 PDT Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.264.0; Thu, 13 Sep 2012 15:03:36 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.14]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Thu, 13 Sep 2012 15:03:49 +0200 From: Wuyts Carl To: "Brzozowski, John" Date: Thu, 13 Sep 2012 15:03:47 +0200 Thread-Topic: [dhcwg] SOL MAX RT Thread-Index: AQHNkR0BaQGOcCBbNkS5TFR4leqD8ZeH0D7wgACleID//8gP4A== Message-ID: <867F4B6A1672E541A94676D556793ACD16E4E8D740@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD16E4DC56E6@MOPESMBX01.eu.thmulti.com> <867F4B6A1672E541A94676D556793ACD16E4E8D555@MOPESMBX01.eu.thmulti.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: dhc WG Subject: Re: [dhcwg] SOL MAX RT X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 13:06:38 -0000 Thx John @Bernie: you mention " If you want to make it proprietary, use a Vendor Inf= ormation Option (17)." This is correct, but does not help solving interop issues of course (which = is one of the points I'm trying to make) Regs Carl -----Original Message----- From: Brzozowski, John [mailto:John_Brzozowski@Cable.Comcast.com]=20 Sent: donderdag 13 september 2012 14:22 To: Wuyts Carl Cc: dhc WG Subject: Re: [dhcwg] SOL MAX RT You will see some follow up mail from me on this draft today or tomorrow. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) +1-609-377-6594 e) mailto:john_brzozowski@cable.comcast.com o) +1-484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Sep 13, 2012, at 2:34 AM, Wuyts Carl wrote: > Thx John, >=20 > Thing is that it get referred to from RFC6204, making it impossible for a= CPE to meet the requirement of course. We could take a proprietary option= , but then every implementation would/could use a different number, which i= s to avoid I'd say. In fact, this already happened before with DSLite opti= on. I've bumped into some implementation some time ago which was using a d= ifferent number for the DSLite option, hence making the setup fail initiall= y.=20 >=20 > Regs > Carl >=20 >=20 >=20 >=20 > -----Original Message----- > From: Brzozowski, John [mailto:John_Brzozowski@Cable.Comcast.com]=20 > Sent: woensdag 12 september 2012 21:29 > To: Wuyts Carl > Cc: dhc WG > Subject: Re: [dhcwg] SOL MAX RT >=20 > Carl, >=20 > I do not think this is possible, I will check and get back to you unless = someone beats me to it on the list. >=20 > John > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > John Jason Brzozowski > Comcast Cable > m) +1-609-377-6594 > e) mailto:john_brzozowski@cable.comcast.com > o) +1-484-962-0060 > w) http://www.comcast6.net > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > On Sep 4, 2012, at 7:08 AM, Wuyts Carl wrote: >=20 >> All, >>=20 >> Anyone an idea when an option number will be assigned for this oro (as i= t still says TBD in below draft) ? >> (I-D.droms-dhc-dhcpv6-solmaxrt-update) >>=20 >> Thx and regs >> Carl >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 From wbeebee@cisco.com Thu Sep 13 06:34:39 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BEF21F8534 for ; Thu, 13 Sep 2012 06:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jK-Y3ehHmivg for ; Thu, 13 Sep 2012 06:34:38 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1BD21F8533 for ; Thu, 13 Sep 2012 06:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6988; q=dns/txt; s=iport; t=1347543278; x=1348752878; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=yhpYKbfJiGguR2bL7JsWH1OCnAKdRmSh22QJHB1xmkg=; b=eBaiyjLaZFPouEqjzuf5L27Z3CDVdB5yKvW+JZQIzhL1zEySPOsNO44g lRL0Ynux0uFYdjrU1Y0l9bVGx63nqB4OO4ZuoPeYskHcmpsREIyeBZOz+ VxO4Eq53xSb/HibJnD6jFOrP1jY4SzvmQSElNNv8VtB/T0pMBbrCXxWnw s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPLfUVCtJV2d/2dsb2JhbABABbtvgQeCIAEBAQQSAVQLBwwGAQgRBAEBASc5FAkIAgQBDQUbB4drm3igM4sQKIYPA4ggjT+ONoFpgmaBYzQ X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="121212301" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 13 Sep 2012 13:34:37 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8DDYbMB017546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Sep 2012 13:34:37 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.212]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Thu, 13 Sep 2012 08:34:37 -0500 From: "Wes Beebee (wbeebee)" To: "Bernie Volz (volz)" , Ted Lemon Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpd/JdswgAB/xoD//5GrgIAJVTGA Date: Thu, 13 Sep 2012 13:34:37 +0000 Message-ID: In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F4F857F@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [161.44.175.143] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19180.005 x-tm-as-result: No--50.281300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3AD36804C59EC443A5CF69DAC33B76BD@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG , "Ole Troan \(otroan\)" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 13:34:39 -0000 My comments fall under the category of "optimization". Certainly the client can drop the original transaction and issue another Information-Request set of messages for the rest of the information already contained in the original transaction. Just out of curiosity, why is this behavior mandated? While I think this work is very important, I would like to see more comments from others on the significant changes to the protocol that are contained in the document. - Wes On 9/7/12 12:18 PM, "Bernie Volz (volz)" wrote: >I believe Wes' and Hemant's issues were: > >Wes (message on Thu 8/16/2012): > > Why MUST the client ignore an Advertise message with no bindings? > What if stateful and stateless options are carried in the same message? > Does this mean the stateless options will be ignored just because the >stateful Options failed? > >--- > >Ole's answer was that basically this is how RFC 3315 operates today and >we didn't want to change this (we are fixing what happens if IA_NA and >IA_PD are requested in a Solicit and only one of these is available) -- >which is different than the no bindings at all case. RFC 3315 basically >expects clients to use Information-Request in this case. > >A while back, Ralph and I considered that this might be a good change - >especially given the case when M says to use stateful but the server is >not configured to give (the requesting client) any stateful bindings. >Server could effectively respond with the other configuration options. >But an Advertise is not the same as a Reply, so if the client was going >to do a Request/Reply, we'd have to change that processing to and so why >doesn=B9t the client just do an Information-Request? (Sure, if Rapid Commi= t >is requested, server would just Reply and client would be done.) > >If the WG feels that would be a useful change, we can certainly do this >change. But for this particular work, we didn't feel that change was >warranted. And, it might be best to do under a separate document? Or >something for a 3315bis? > > >Hemant (message on 8/17/2012) and Ole's response (using Ole's email on >8/20/2012): > >> +1 to Wes' comment that this document is addressing a very important >>problem space and the solutions are needed urgently. However, more >>thought is required for the solutions. >>=20 >> In regards to section 4.4, if the server only checks the network >>configuration to reply to a Confirm message, how is it possible for most >>network configurations that the server determines an IA_PD is on-link? >>I suspect that is why RFC 3633 prohibited use of the Confirm for the >>IA_PD. In any case this document should explain why did RFC 3633 have a >>restriction on using the Confirm for the IA_PD. Or does network >>configuration include looking up the prefix pool configured on the >>server for allocation? In contrast, to make an on-link determination >>for an IA_NA IA_Address, all the server has to do is match >>(longest-prefix match) all IPv6 addresses configured on the machine that >>the server is running on. These addresses are clearly network >>configuration. =20 > >right, either the server has the binding, or the server has configuration >that it can look up in, to verify if the client has moved or not. if it >has no information it MUST not reply. > >> Section 4.1: =20 >>=20 >> # In relation to the first paragraph the document is addressing the >>fact that one server replies with, say, an IA_NA, while another server >>replies back with only the IA_PD. Then why in section 4.7 the case of >>section 4.1 is deemed out of scope? I also do not understand what does >>"equal" in section 4.7 mean. Does it mean each server replies with all >>IAs that the deployment needs? > >the assumption in 3315/3633 is that a client is connected to a single >administrative dhc domain on an interface. >scenarios where a client finds two DHCP servers, that are administered by >two different entities, are outside of the scope of 3315/3633 and >therefore also outside the scope of this update. there is as far as I >know separate work in progress on this. > >> # In relation to the text in the last paragraph of section 4.1, if the >>client does not restart the Solicit retransmissions timers, what does >>the client do? > >continues with the timers it has. >otherwise as the text says, a received advertise with a consequent >restart of solicit timers would result in a solicit storm. > >>=20 >> # Other comment: Shouldn't the header of the document have an Updates >>tag to signify this document updates RFC 3315? > >good point. both 3315 and 3633. > >--- > >I guess the one change that I see is to assure we update the document >header. We can respin the document for this change. > >Section 4.4 is just extending the Confirm to include prefixes - this >issue is already covered in RFC 3315 for Confirm processing: > > If the >server is unable to perform > this test (for example, the server does not have information about > prefixes on the link to which the client is connected), or there were > no addresses in any of the IAs sent by the client, the server MUST > NOT send a reply to the client. > >The section 4.1 / 4.7 issue is the single vs multiple provisioning >domains - we assume a single in this document. > > >If Wes or Hemant would like other changes to clarify any of their >concerns, we would appreciate text to be added/modified. > >- Bernie > >-----Original Message----- >From: Ted Lemon [mailto:Ted.Lemon@nominum.com] >Sent: Friday, September 07, 2012 11:38 AM >To: Bernie Volz (volz) >Cc: dhc WG >Subject: Re: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 > >On Sep 7, 2012, at 11:09 AM, Bernie Volz (volz) wrote: >> Where does this Last Call stand? August 24th has passed ... > >There were a lot of comments in the WGLC, and lot of support for what is >to be accomplished here, but several people raised concerns as well. >There were a few responses in favor of advancing the current document; >Hemant Singh had some suggestions, to which Ole responded. I do not >know if the responses satisfied Hemant's concerns. I raised some >concerns which were not really addressed. Wes Beebe raised a concern >which Ole responded to, but again I don't know if Wes was satisfied with >Ole's response. > > >So I think this is borderline. There's clearly widespread support for >what this draft is trying to do; I would like to hear from Hemant and Wes >as to whether they are satisfied with Ole's responses. I tend to agree >with Wes' sentiment that we need to think this through very carefully; I >would like to see a new draft that addresses Hemant's and Wes' concerns, >if possible, and then do a second last call to get more review. Does >that work for the authors? From curtis@occnc.com Thu Sep 13 20:13:28 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E179821F861C for ; Thu, 13 Sep 2012 20:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoHS0jCoZ060 for ; Thu, 13 Sep 2012 20:13:28 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 4A26E21F8600 for ; Thu, 13 Sep 2012 20:13:28 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q8E3DK2H049568; Thu, 13 Sep 2012 23:13:20 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209140313.q8E3DK2H049568@gateway1.orleans.occnc.com> To: "Bernie Volz (volz)" From: Curtis Villamizar In-reply-to: Your message of "Wed, 12 Sep 2012 03:01:22 -0000." Date: Thu, 13 Sep 2012 23:13:20 -0400 Cc: "dhcwg@ietf.org WG" , Ted Lemon Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 03:13:29 -0000 In message "Bernie Volz (volz)" writes: > > Ted - I think you are spot on. We really have to prioritize and > handle the major issues and also focus on the future - IPv6 and > getting there. Marginal extensions to IPv4 should be very low > priority (or even better dropped). > > - Bernie Bernie, FORCERENEW and Forcerenew Nonce Authentication apply to IPv6 as well as IPv4. A short draft saying the RFC6704 also applies to INFORM would not be a big distraction. A statement could even be short enough to be an errata if we were willing to change RFC6704 with an errata (though I don't suggest we do this as an errata). Curtis > On 9/11/12 10:52 PM, "Ted Lemon" wrote: > > >On Sep 11, 2012, at 9:45 PM, "Gaurav Halwasia (ghalwasi)" > > > > wrote: > >> I am talking about a deployment where we do create *session* database > >>for hosts either based upon DHCP packet (Discover) or the normal IP > >>packet in case few of the hosts has not done DHCP but instead has just > >>DONE DHCP INFORM to get the config parameters. So in this kind of > >>deployment we do anyways maintain the session(or binding in terms of > >>DHCP) database on the box. Having said that I don't think storing client > >>information is a problem (at least in this deployment). The only extra > >>thing which we would need to store is a 'nonce'. > > > >This is a heavy burden for the working group to take on for a small > >deployment. Can you go into some detail about why this is the right way > >to solve the problem, and what bad things would happen if you didn't have > >FORCERENEW? > > > >I'm sorry to be stubborn about this, but you're talking about a DHCPv4 > >protocol extension, and as you know from another draft that just went to > >the IESG, bandwidth is limited for the DHC working group - we've had > >presentation marathons at the last two IETFs, and I've had to chivvy > >presenters mercilessly just to avoid running over the generous time slots > >we've been given. I feel really bad about doing that, and so I'm going > >to push back on proposals like this if I don't have a clear sense of > >their broad utility. I say this sort of wearing my working group > >co-chair hat and sort of wearing my working group participant hat - as a > >participant, I don't see the broad utility in this proposal, and as a > >chair I see a lot of work in my future. So please, give us a clear > >sales pitch for why we should feel good about taking on this work. From internet-drafts@ietf.org Fri Sep 14 01:54:10 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F7521F8549; Fri, 14 Sep 2012 01:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e22mteR+4i-z; Fri, 14 Sep 2012 01:54:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AC121F8526; Fri, 14 Sep 2012 01:54:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120914085409.32571.73330.idtracker@ietfa.amsl.com> Date: Fri, 14 Sep 2012 01:54:09 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-secure-dhcpv6-07.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 08:54:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : Secure DHCPv6 Using CGAs Author(s) : Sheng Jiang Sean Shen Filename : draft-ietf-dhc-secure-dhcpv6-07.txt Pages : 18 Date : 2012-09-14 Abstract: The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCPv6 servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks, particularly spoofing attacks. This document analyzes the security issues of DHCPv6 and specifies a Secure DHCPv6 mechanism based on using CGAs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-secure-dhcpv6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-secure-dhcpv6-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-secure-dhcpv6-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From volz@cisco.com Fri Sep 14 06:54:11 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E576921F8523 for ; Fri, 14 Sep 2012 06:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HIq85ku0sAn for ; Fri, 14 Sep 2012 06:54:10 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9A14B21F851E for ; Fri, 14 Sep 2012 06:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8973; q=dns/txt; s=iport; t=1347630850; x=1348840450; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MDB5f2+kqinH7LOMnjlzUsr2BQO9mkFL5zTgDycN9PQ=; b=Mf35f2Mk77/rLWD09UNYtp7HVuaG9NRu9q5JHha3I+DIT55UZ8FAebDB QL7kN9W0dlPe8HgQyVnLi94r+PGJWuGviRrQMqQUDllRhTmxZ2692jLIc HIxNmHxsNOd5k/D4v8rSfrVz0TOE+zRm6g3chrTyDnwweZXV62y11QlSU k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADM2U1CtJXG+/2dsb2JhbABABbt9gQeCIAEBAQMBEgFUCwcFBwQCAQgRBAEBAScHMhQJCAIEDgUUBweHZQabJKAWixUohWBgA4ghjUCOOIFpgmaBYw X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="121661594" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 14 Sep 2012 13:53:58 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8EDrviM015467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Sep 2012 13:53:57 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Fri, 14 Sep 2012 08:53:57 -0500 From: "Bernie Volz (volz)" To: "Wes Beebee (wbeebee)" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpd/JdswgAB/xoD//5GrgIAJVTGAgAGG+qw= Date: Fri, 14 Sep 2012 13:53:56 +0000 Message-ID: References: <489D13FBFA9B3E41812EA89F188F018E0F4F857F@xmb-rcd-x04.cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19182.004 x-tm-as-result: No--53.193500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG , Ted Lemon , "Ole Troan \(otroan\)" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 13:54:12 -0000 Again, one reason is that Advertise response to a Solicit is not necessaril= y the "final" information the client is allowed to use - Reply is used to c= ommunicate that (after Request or Information-Request). And the Request, Re= new, Rebind are all about communicating bindings - for example if Solicit/A= dvertise is same as Information-Request/Reply, if client wants to refresh o= ptions, does it use Renew/Reply or Information-Request/Reply. With the proposed changes we are actually a bit closer to supporting this b= ecause if the client wants addresses or bindings but only got other config = options earlier, it would perhaps be acceptable to let it Request or Renew = or Rebind with the bindings to attempt to get those bindings. But we did no= t take this step as it would require a few more tweaks. (Rebind may be the = best choice here as that allows other servers to respond.) But this needs t= o be more carefully thought through and I am not sure it is worth it to do = this. And in any case, perhaps done as a separate work. --- Agreed that more review / comments especially from client implementers as t= o whether the changes proposed in the draft are appropriate. As the CableLa= bs (DOCSIS) community were pushing for this, we really need more of them to= respond. If they don't, perhaps it means there is no issue and this work i= sn't needed as current client implementations have already figured out how = to deal with the situation in an acceptable mannor. - Bernie On Sep 13, 2012, at 9:34 AM, "Wes Beebee (wbeebee)" wro= te: > My comments fall under the category of "optimization". >=20 > Certainly the client can drop the original transaction and issue another > Information-Request set of messages for the rest of the information > already contained in the original transaction. Just out of curiosity, wh= y > is this behavior mandated? >=20 > While I think this work is very important, I would like to see more > comments from others on the significant changes to the protocol that are > contained in the document. >=20 > - Wes >=20 > On 9/7/12 12:18 PM, "Bernie Volz (volz)" wrote: >=20 >> I believe Wes' and Hemant's issues were: >>=20 >> Wes (message on Thu 8/16/2012): >>=20 >> Why MUST the client ignore an Advertise message with no bindings? >> What if stateful and stateless options are carried in the same message? >> Does this mean the stateless options will be ignored just because the >> stateful Options failed? >>=20 >> --- >>=20 >> Ole's answer was that basically this is how RFC 3315 operates today and >> we didn't want to change this (we are fixing what happens if IA_NA and >> IA_PD are requested in a Solicit and only one of these is available) -- >> which is different than the no bindings at all case. RFC 3315 basically >> expects clients to use Information-Request in this case. >>=20 >> A while back, Ralph and I considered that this might be a good change - >> especially given the case when M says to use stateful but the server is >> not configured to give (the requesting client) any stateful bindings. >> Server could effectively respond with the other configuration options. >> But an Advertise is not the same as a Reply, so if the client was going >> to do a Request/Reply, we'd have to change that processing to and so why >> doesn=B9t the client just do an Information-Request? (Sure, if Rapid Com= mit >> is requested, server would just Reply and client would be done.) >>=20 >> If the WG feels that would be a useful change, we can certainly do this >> change. But for this particular work, we didn't feel that change was >> warranted. And, it might be best to do under a separate document? Or >> something for a 3315bis? >>=20 >>=20 >> Hemant (message on 8/17/2012) and Ole's response (using Ole's email on >> 8/20/2012): >>=20 >>> +1 to Wes' comment that this document is addressing a very important >>> problem space and the solutions are needed urgently. However, more >>> thought is required for the solutions. >>>=20 >>> In regards to section 4.4, if the server only checks the network >>> configuration to reply to a Confirm message, how is it possible for mos= t >>> network configurations that the server determines an IA_PD is on-link? >>> I suspect that is why RFC 3633 prohibited use of the Confirm for the >>> IA_PD. In any case this document should explain why did RFC 3633 have = a >>> restriction on using the Confirm for the IA_PD. Or does network >>> configuration include looking up the prefix pool configured on the >>> server for allocation? In contrast, to make an on-link determination >>> for an IA_NA IA_Address, all the server has to do is match >>> (longest-prefix match) all IPv6 addresses configured on the machine tha= t >>> the server is running on. These addresses are clearly network >>> configuration. =20 >>=20 >> right, either the server has the binding, or the server has configuratio= n >> that it can look up in, to verify if the client has moved or not. if it >> has no information it MUST not reply. >>=20 >>> Section 4.1: =20 >>>=20 >>> # In relation to the first paragraph the document is addressing the >>> fact that one server replies with, say, an IA_NA, while another server >>> replies back with only the IA_PD. Then why in section 4.7 the case of >>> section 4.1 is deemed out of scope? I also do not understand what doe= s >>> "equal" in section 4.7 mean. Does it mean each server replies with all >>> IAs that the deployment needs? >>=20 >> the assumption in 3315/3633 is that a client is connected to a single >> administrative dhc domain on an interface. >> scenarios where a client finds two DHCP servers, that are administered b= y >> two different entities, are outside of the scope of 3315/3633 and >> therefore also outside the scope of this update. there is as far as I >> know separate work in progress on this. >>=20 >>> # In relation to the text in the last paragraph of section 4.1, if the >>> client does not restart the Solicit retransmissions timers, what does >>> the client do? >>=20 >> continues with the timers it has. >> otherwise as the text says, a received advertise with a consequent >> restart of solicit timers would result in a solicit storm. >>=20 >>>=20 >>> # Other comment: Shouldn't the header of the document have an Updates >>> tag to signify this document updates RFC 3315? >>=20 >> good point. both 3315 and 3633. >>=20 >> --- >>=20 >> I guess the one change that I see is to assure we update the document >> header. We can respin the document for this change. >>=20 >> Section 4.4 is just extending the Confirm to include prefixes - this >> issue is already covered in RFC 3315 for Confirm processing: >>=20 >> If the >> server is unable to perform >> this test (for example, the server does not have information about >> prefixes on the link to which the client is connected), or there were >> no addresses in any of the IAs sent by the client, the server MUST >> NOT send a reply to the client. >>=20 >> The section 4.1 / 4.7 issue is the single vs multiple provisioning >> domains - we assume a single in this document. >>=20 >>=20 >> If Wes or Hemant would like other changes to clarify any of their >> concerns, we would appreciate text to be added/modified. >>=20 >> - Bernie >>=20 >> -----Original Message----- >> From: Ted Lemon [mailto:Ted.Lemon@nominum.com] >> Sent: Friday, September 07, 2012 11:38 AM >> To: Bernie Volz (volz) >> Cc: dhc WG >> Subject: Re: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 >>=20 >> On Sep 7, 2012, at 11:09 AM, Bernie Volz (volz) wrote: >>> Where does this Last Call stand? August 24th has passed ... >>=20 >> There were a lot of comments in the WGLC, and lot of support for what is >> to be accomplished here, but several people raised concerns as well. >> There were a few responses in favor of advancing the current document; >> Hemant Singh had some suggestions, to which Ole responded. I do not >> know if the responses satisfied Hemant's concerns. I raised some >> concerns which were not really addressed. Wes Beebe raised a concern >> which Ole responded to, but again I don't know if Wes was satisfied with >> Ole's response. >>=20 >>=20 >> So I think this is borderline. There's clearly widespread support for >> what this draft is trying to do; I would like to hear from Hemant and We= s >> as to whether they are satisfied with Ole's responses. I tend to agree >> with Wes' sentiment that we need to think this through very carefully; I >> would like to see a new draft that addresses Hemant's and Wes' concerns, >> if possible, and then do a second last call to get more review. Does >> that work for the authors? >=20 From anuvasud@cisco.com Fri Sep 14 00:44:49 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E6021F8584 for ; Fri, 14 Sep 2012 00:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYnZAFzd6lLD for ; Fri, 14 Sep 2012 00:44:48 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 14A2D21F851E for ; Fri, 14 Sep 2012 00:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5094; q=dns/txt; s=iport; t=1347608688; x=1348818288; h=from:to:cc:subject:date:message-id:mime-version; bh=hIWWQQ/nsHBA5C75nbTMtwIVQQ7Q5RYDIgq3GCsoMhk=; b=LgzdcUBNSUyoqVrJlOJV35/VFJ+F/gNLiP4YnzgDr7pFFc+ZDOy9EffX xxQP1ak/YeYzuRREVZffpagK4GKkP8TRgi23SFSnL+21ZJPTDTrXkFLY4 zM1ZsCWUq1C6bqmD8JTuq3CdfU48RIetHSm927fVRxOkpKgR5sSgloGrP A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADjfUlCtJV2d/2dsb2JhbAA7CoJLsE4BiF+BB4InEgFmEgEMdCcEDieHawubEaANiyWGJwOVYIEUjSSBaYJmghc X-IronPort-AV: E=Sophos;i="4.80,421,1344211200"; d="scan'208,217";a="118530855" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 14 Sep 2012 07:44:47 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8E7ilAO010999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 14 Sep 2012 07:44:47 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.26]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0298.004; Fri, 14 Sep 2012 02:44:47 -0500 From: "Anup Kumar Vasudevan (anuvasud)" To: "dhcwg@ietf.org" Thread-Topic: Reg. Use of Link-Address Field for DHCPv6 Thread-Index: AQHNkkzP+5tdKtJ+Kke3DzPsRIaW9g== Date: Fri, 14 Sep 2012 07:44:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.65.76.217] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19182.004 x-tm-as-result: No--27.593800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC78DE44178D9anuvasudciscocom_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 14 Sep 2012 10:09:48 -0700 Cc: "G Murali Krishna \(gunkrish\)" Subject: [dhcwg] Reg. Use of Link-Address Field for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 07:44:49 -0000 --_000_CC78DE44178D9anuvasudciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi We have a query on the Link-Address field in DHCPv6 =96 for Relay Agents. F= rom the RFC - 20.1.1. Relaying a Messa= ge from a Client If the relay agent received the message to be relayed from a client, the relay agent places a global or site-scoped address with a prefix assigned to the link on which the client should be assigned an address in the link-address field. This address will be used by the server to determine the link from which the client should be assigned an address and other configuration information. The hop-count in the Relay-forward message is set to 0. If the relay agent cannot use the address in the link-address field to identify the interface through which the response to the client will be relayed, the relay agent MUST include an Interface-id option (see section 22.18) in= the Relay-forward message. The server will include the Interface-id option in its Relay-reply message. The relay agent fills in the link-address field as described in the previous paragraph regardless of whether the relay agent includes an Interface-id option in the Relay-forward message. Is the Link-Address field Mandatory? Should Relay-Agents always fill it? Al= so is it mandatory for Server to use the Link-Address field for Assigning c= lient addresses? If the Server does not have addresses that match the Link-= Address field , should it fail the Allocation requests? We have seen in testing that some of the third party servers don't really u= se this field for Address Assignment =96 but I think the ISC implementation= is dependent on this field. Thanks Anup --_000_CC78DE44178D9anuvasudciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi 

We have a query on the Li= nk-Address field in DHCPv6 =96 for Relay Agents. From the RFC - 

20.1.1. Relaying a Messag=
e from a Client


   If the relay agent received the message to be relayed from a client,
   the relay agent places a global or site-scoped address with a prefix
   assigned to the link on which the client should be assigned an
   address in the link-address field.  This address will be used by the
   server to determine the link from which the client should be assigned
   an address and other configuration information.  The hop-count in the
   Relay-forward message is set to 0.

   If the relay agent cannot use the address in the link-address field
   to identify the interface through which the response to the client
   will be relayed, the relay agent MUST include an Interface-id option
   (see sectio=
n 22.18) in the Relay-forward message.  The server will
   include the Interface-id option in its Relay-reply message.  The
   relay agent fills in the link-address field as described in the
   previous paragraph regardless of whether the relay agent includes an
   Interface-id option in the Relay-forward message.



Is=
 the Link-Address field Mandatory? Should Relay-Agents always fill it? Also=
 is it mandatory for Server to use the Link-Address field for Assigning cli=
ent addresses? If the Server does not have addresses that match the Link-Ad=
dress field , should it fail the Allocation requests? 


We=
 have seen in testing that some of the third party servers don't really use=
 this field for Address Assignment =96 but I think the ISC implementation i=
s dependent on this field. 


Th=
anks


An=
up
--_000_CC78DE44178D9anuvasudciscocom_-- From wwwrun@rfc-editor.org Fri Sep 14 10:03:46 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E9521F850D for ; Fri, 14 Sep 2012 10:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.393 X-Spam-Level: X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtLehjhuJhin for ; Fri, 14 Sep 2012 10:03:45 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF6921F852C for ; Fri, 14 Sep 2012 10:03:43 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1E5CAB1E002; Fri, 14 Sep 2012 10:00:23 -0700 (PDT) To: davidmiles@google.com, wdec@cisco.com, James.Bristow@swisscom.com, roberta.maglione@telecomitalia.it, rdroms.ietf@gmail.com, brian@innovationslab.net, ted.lemon@nominum.com, john_brzozowski@cable.comcast.com From: RFC Errata System Message-Id: <20120914170024.1E5CAB1E002@rfc-editor.org> Date: Fri, 14 Sep 2012 10:00:23 -0700 (PDT) X-Mailman-Approved-At: Fri, 14 Sep 2012 10:09:48 -0700 Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] [Editorial Errata Reported] RFC6704 (3353) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 17:03:46 -0000 The following errata report has been submitted for RFC6704, "Forcerenew Nonce Authentication". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6704&eid=3353 -------------------------------------- Type: Editorial Reported by: Gaurav Halwasia Section: 5.1 Original Text ------------- The mechanism described in this document is vulnerable to a denial- of-service (DoS) attack through flooding a client with bogus FORCERENEW messages. The calculations involved in authenticating the bogus FORECERENEW messages may overwhelm the device on which the client is running. Corrected Text -------------- The mechanism described in this document is vulnerable to a denial- of-service (DoS) attack through flooding a client with bogus FORCERENEW messages. The calculations involved in authenticating the bogus FORCERENEW messages may overwhelm the device on which the client is running. Notes ----- Spelling of "FORECERENEW" is incorrect. It should be "FORCERENEW" Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6704 (draft-ietf-dhc-forcerenew-nonce-07) -------------------------------------- Title : Forcerenew Nonce Authentication Publication Date : August 2012 Author(s) : D. Miles, W. Dec, J. Bristow, R. Maglione Category : PROPOSED STANDARD Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG From shemant@cisco.com Fri Sep 14 18:09:24 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A67521F85A8 for ; Fri, 14 Sep 2012 18:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9015EjNjBr0 for ; Fri, 14 Sep 2012 18:09:23 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7419721F85C3 for ; Fri, 14 Sep 2012 18:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2741; q=dns/txt; s=iport; t=1347671363; x=1348880963; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6ruRH5mp6EGbPozejbcoISC9bDlBqQl7Ij10lU07rjM=; b=NKu8BA2gS2sNPExqw5EgRCND5IUTGg4JzEGUl0Fg+c5ylIMmGKh0CVMl WCkAofI7AlznfQtUWAE0TKjNojXUKu86FHYkMsh+PHwD6wVUZvkBpisQ7 bIGWCwQROgzA8frn+GA5hBV9DPQSzpY6xUGSf7VRqGsp51Z1VufvOkrxV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAG3UU1CtJXG+/2dsb2JhbABFvAuBB4IgAQEBBBIBJz8MBAIBCBEEAQELFAkHMhQJCAIEAQ0FCBqHa5sAoBuGJIR7hghgA6QZgWmCZoFjNA X-IronPort-AV: E=Sophos;i="4.80,425,1344211200"; d="scan'208";a="121867547" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 15 Sep 2012 01:09:20 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8F19KsN017327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 15 Sep 2012 01:09:20 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Fri, 14 Sep 2012 20:09:19 -0500 From: "Hemant Singh (shemant)" To: Ted Lemon , "Bernie Volz (volz)" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpd/JdswgAB/xoD//5GrgIAAeqgAgAsV/xA= Date: Sat, 15 Sep 2012 01:09:19 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B8908A7CF@xmb-rcd-x06.cisco.com> References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F83D1@xmb-rcd-x04.cisco.com> <21C54D57-372F-46B0-892B-398919992546@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F857F@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.128] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19182.004 x-tm-as-result: No--29.297800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG , "Ole Troan \(otroan\)" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 01:09:24 -0000 Ted/Bernie/Ole, Humble apologies I was buried with other priorities and did not check my DH= C WG email folder in a while. I actually replied to the xlat document in v6= ops during my 10 days of PTO up till the Labor Day. Bernie kindly reminded= me this week of this document. Most of my comments have been addressed. = Some pending are included below. Why was the CONFIRM message deliberately specified by RFC 3633 as not suppo= rted for the IA_PD? =20 It would be good to reply to this question. Otherwise the IESG is likely t= o ask the same question and the answer to such a question may uncover issue= s for us. =20 For one, it is easy for a server to respond to a CONFIRM to an IA_MA by jus= t matching the IPv6 address configured on the machine the server is running= on. I am always reminded by some authors of RFC 3315 that the server dist= inctly does not consult its client bindings to respond to a CONFIRM for an = IA_NA. The server just relies on the machine IPv6 configuration to compute= a status of on-link or not-on-link. Thus why it is not a sea-change to su= pport the CONFIRM for the IA_PD option and we may need to step gingerly? I= f the server has to respond to a CONFIRM for an IA_PD, the server now consu= lts with its bindings (I think Bernie alluded to in his reply to this threa= d) which the server did not do before for the IA_NA. Searching thru bindin= gs has delay implications and additional server computations. Or as I had = already said in my earlier reply that the server checks what prefixes are c= onfigured on the server to determine on-link status. However checking pref= ixes for IA_PD at a server has to exclude prefixes that are used for alloca= tion of IA_NA. So now the server maintains two types of prefixes. =20 Thus I will try and propose some text over the weekend that IA_PD support i= n CONFIRM can't suffice with network configuration. Some other data in the= server needs checking and we should try and be little specific about the d= ata. Just saying something like "the sever checks network configuration" d= oesn't cut it for the IA_PD. =20 Let me see what I can do over this weekend and propose some text as to how = the server checks for on-link or not for the IA_PD to respond to a CONFIRM.= I will also catch up with other emails on this document and reply, if nec= essary. Regards, Hemant -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Friday, September 07, 2012 12:22 PM To: Bernie Volz (volz) Cc: dhc WG; Wes Beebee (wbeebee); Hemant Singh (shemant); Ole Troan (otroan= ) Subject: Re: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Was that a yes or a no? From shemant@cisco.com Sat Sep 15 09:36:29 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADEE21F84CF for ; Sat, 15 Sep 2012 09:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNnR1WC17EDz for ; Sat, 15 Sep 2012 09:36:28 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DBDCA21F84B5 for ; Sat, 15 Sep 2012 09:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1171; q=dns/txt; s=iport; t=1347726988; x=1348936588; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OpxTxXEj2ILFINTSS8RSC7HLFZsLU7VqiashhncKqF8=; b=Hqa+zJ0Weey5++7z6AWOK+QIk5yMMsMbZ4SMrZTMLUmfvjJ9NZjHzPXy QFiP0uT064hrff//XxJ339oDK+q2GEwwgPm7+YnQepD2spb1jcmoBL6Xa xjasiIrjk+O3ox2BKUuEGV4rw7AKXOmhnT+uEaLFIbsR8Avch4M299xk5 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJStVFCtJXHB/2dsb2JhbABFuE6DPYEHgiABAQEEEgEnPwwEAgEIEQQBAQsUEDIdCAIEAQ0NGodrmnifXYshhghgA6QZgWmCZoIX X-IronPort-AV: E=Sophos;i="4.80,428,1344211200"; d="scan'208";a="121941159" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 15 Sep 2012 16:36:27 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8FGaRXK032700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 15 Sep 2012 16:36:27 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Sat, 15 Sep 2012 11:36:26 -0500 From: "Hemant Singh (shemant)" To: "Bernie Volz (volz)" , Ted Lemon Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpd/JdswgAB/xoD//5GrgIAMmf4Q Date: Sat, 15 Sep 2012 16:36:26 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B8908A93F@xmb-rcd-x06.cisco.com> References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F83D1@xmb-rcd-x04.cisco.com> <21C54D57-372F-46B0-892B-398919992546@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F857F@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F4F857F@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19184.002 x-tm-as-result: No--37.400100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG , "Ole Troan \(otroan\)" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 16:36:29 -0000 Bernie, -----Original Message----- From: Bernie Volz (volz)=20 Sent: Friday, September 07, 2012 12:18 PM To: Ted Lemon Cc: dhc WG; Wes Beebee (wbeebee); Hemant Singh (shemant); Ole Troan (otroan= ) Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 >Ole's answer was that basically this is how RFC 3315 operates today and we= didn't want to change this (we are fixing what happens if IA_NA and IA_PD = are >requested in a Solicit and only one of these is available) -- which is= different than the no bindings at all case. RFC 3315 basically expects cli= ents to >use Information-Request in this case. I agree with use of the Information-Request message rather than changing th= e behavior for Request/Reply processing. Now, when the Information-Request= message is sent to the server, don't we expect an Information-Request stor= m at the server akin to a Solicit storm because INF_MAX_RT is 120 secs? If= yes, the SOL_MAX_RT is also 120 secs which is getting changed in Ralph's= SOL_MAX_RT draft. So shouldn't Ralph's document now also address the INF_= MAX_RT if the document does not already do so? Thanks, Hemant From volz@cisco.com Sat Sep 15 17:16:38 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED1E21F84A5 for ; Sat, 15 Sep 2012 17:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pN3xIN0uCTJE for ; Sat, 15 Sep 2012 17:16:37 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC0C21F84A1 for ; Sat, 15 Sep 2012 17:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1629; q=dns/txt; s=iport; t=1347754597; x=1348964197; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6kJihSsR/coglYWGNSabJGgrEpd9CZ2ke9UnKFw4e8c=; b=NKeXTMrxuFUksMme++SdhsQHZbJrM1UjUfaj4DEdhvXXJBFPlrQQYi7Q 4GSwwf/FvE1kLoUD3mfoIFkM8gqIakjaP0CkSmVUIg46/+awUDGTFeoOo uyMH1JVLu65tW9DCBehxm2uElNpnOnf52qR6V5erAHakJDhg9UhxSaPHq E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABAZVVCtJV2d/2dsb2JhbABFvA6BB4IgAQEBAwESASc/BQcEAgEIEQQBAR8QMh0IAgQOBSKHWAaadp8tiyGGCGADlWKOOIFpgmY X-IronPort-AV: E=Sophos;i="4.80,428,1344211200"; d="scan'208";a="118985895" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 16 Sep 2012 00:16:37 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8G0Gb30029278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 16 Sep 2012 00:16:37 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Sat, 15 Sep 2012 19:16:36 -0500 From: "Bernie Volz (volz)" To: "Hemant Singh (shemant)" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpd/JdswgAB/xoD//5GrgIAMmf4QgACCejg= Date: Sun, 16 Sep 2012 00:16:36 +0000 Message-ID: References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F83D1@xmb-rcd-x04.cisco.com> <21C54D57-372F-46B0-892B-398919992546@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F857F@xmb-rcd-x04.cisco.com>, <75B6FA9F576969419E42BECB86CB1B8908A93F@xmb-rcd-x06.cisco.com> In-Reply-To: <75B6FA9F576969419E42BECB86CB1B8908A93F@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19184.002 x-tm-as-result: No--40.347800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG , Ralph Droms , Ted Lemon , "Ole Troan \(otroan\)" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 00:16:38 -0000 I have included Ralph. Not sure exactly which situation will cause an Infor= mation-Request storm (just other-config)? I generally would expect a server= , if it exists, to respond to Information-Request even if it returns "no" c= onfig info. But yes should be discussed with respect to Ralphs's draft. - Bernie On Sep 15, 2012, at 12:36 PM, "Hemant Singh (shemant)" = wrote: > Bernie, >=20 > -----Original Message----- > From: Bernie Volz (volz)=20 > Sent: Friday, September 07, 2012 12:18 PM > To: Ted Lemon > Cc: dhc WG; Wes Beebee (wbeebee); Hemant Singh (shemant); Ole Troan (otro= an) > Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 >=20 >=20 >> Ole's answer was that basically this is how RFC 3315 operates today and = we didn't want to change this (we are fixing what happens if IA_NA and IA_P= D are >requested in a Solicit and only one of these is available) -- which = is different than the no bindings at all case. RFC 3315 basically expects c= lients to >use Information-Request in this case. >=20 > I agree with use of the Information-Request message rather than changing = the behavior for Request/Reply processing. Now, when the Information-Reque= st message is sent to the server, don't we expect an Information-Request st= orm at the server akin to a Solicit storm because INF_MAX_RT is 120 secs? = If yes, the SOL_MAX_RT is also 120 secs which is getting changed in Ralph= 's SOL_MAX_RT draft. So shouldn't Ralph's document now also address the IN= F_MAX_RT if the document does not already do so? >=20 > Thanks, >=20 > Hemant From shemant@cisco.com Sun Sep 16 09:17:27 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD1621F8413 for ; Sun, 16 Sep 2012 09:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql2sFgPdOf0x for ; Sun, 16 Sep 2012 09:17:26 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4D31821F8523 for ; Sun, 16 Sep 2012 09:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4376; q=dns/txt; s=iport; t=1347812246; x=1349021846; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ev1tyXl4YBhLLM2wdYYTRImAWlh4PGF5J+JJQ5IL1wQ=; b=SPd8E1vMkHe2SvvyvASEoKZJD+cKRi+LN97gIISHmGYOHjn3jmgIOXEP tiHS7Hoj3JKomUwKS4w87+WEt4ykW8cfDyVYvaMglHTCjmfpCmq8/mzfD 0Kg7fMK1Pdtl9Sv7EtrrjDGUwJrjxr9YpKHdFD84FjC0+kzdKKwS2wUB+ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHv6VVCtJV2c/2dsb2JhbABFvBKBB4IgAQEBBBIBJz8MBAIBCBEEAQELFAkHMhQJCAIEAQ0FCBqHXppCnwaGJYR8hghgA6QagWmCZoFjNA X-IronPort-AV: E=Sophos;i="4.80,431,1344211200"; d="scan'208";a="122128168" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 16 Sep 2012 16:17:25 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8GGHPfW005248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 16 Sep 2012 16:17:25 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Sun, 16 Sep 2012 11:17:25 -0500 From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , Ted Lemon , "Bernie Volz (volz)" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpd/JdswgAB/xoD//5GrgIAAeqgAgAsV/xCAAo6qwA== Date: Sun, 16 Sep 2012 16:17:25 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B8908AAC6@xmb-rcd-x06.cisco.com> References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F83D1@xmb-rcd-x04.cisco.com> <21C54D57-372F-46B0-892B-398919992546@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F857F@xmb-rcd-x04.cisco.com> <75B6FA9F576969419E42BECB86CB1B8908A7CF@xmb-rcd-x06.cisco.com> In-Reply-To: <75B6FA9F576969419E42BECB86CB1B8908A7CF@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.252.137] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19186.002 x-tm-as-result: No--36.757900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG , "Ole Troan \(otroan\)" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 16:17:27 -0000 Bernie, Here is what I prefer for text for section 4.4 of the document. All other = text in the current section 4.4 is redundant with RFC 3315. The Confirm message, as described in [RFC3315], is specific to address assignment. Note a server processing a Confirm message that includes only IA_NAs does not have to look up any client bindings. This document extends the Confirm to include other=20 IA option types. It is desirable other IA option=20 types do not enforce the server to look up any client bindings=20 to respond to a Confirm. Another IA option type is the IA_PD.=20 The server uses configured prefixes to determine if a prefix in=20 the IA_PD option is on-link to respond to a Confirm. Another issue I'd like to bring up for the Confirm section of this document= . I realize the document only supports the case of one server replying to = both the IA_NA and the IA_PD. However, after a client has completed DHCPv6= for both the IA_NA and the IA_PD, some configuration on the server changes= . Later the client issues a Confirm and the server configuration change ca= uses one IA type to fail the on-link check. If the Status code option in t= he Reply is global, the Reply has a failed on-link code and the client move= s to Solicit processing and the Solicits may continue indefinitely. I reco= mmend using the Status code option per IA option type. Then for an IA opti= on type not on-link status, the client can now use Information-request rath= er than moving to a Solicit transaction. Thus more text changes to RFC 331= 5 are required. =20 Hemant -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of H= emant Singh (shemant) Sent: Friday, September 14, 2012 9:09 PM To: Ted Lemon; Bernie Volz (volz) Cc: dhc WG; Ole Troan (otroan) Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Ted/Bernie/Ole, Humble apologies I was buried with other priorities and did not check my DH= C WG email folder in a while. I actually replied to the xlat document in v6= ops during my 10 days of PTO up till the Labor Day. Bernie kindly reminded= me this week of this document. Most of my comments have been addressed. = Some pending are included below. Why was the CONFIRM message deliberately specified by RFC 3633 as not suppo= rted for the IA_PD? =20 It would be good to reply to this question. Otherwise the IESG is likely t= o ask the same question and the answer to such a question may uncover issue= s for us. =20 For one, it is easy for a server to respond to a CONFIRM to an IA_MA by jus= t matching the IPv6 address configured on the machine the server is running= on. I am always reminded by some authors of RFC 3315 that the server dist= inctly does not consult its client bindings to respond to a CONFIRM for an = IA_NA. The server just relies on the machine IPv6 configuration to compute= a status of on-link or not-on-link. Thus why it is not a sea-change to su= pport the CONFIRM for the IA_PD option and we may need to step gingerly? I= f the server has to respond to a CONFIRM for an IA_PD, the server now consu= lts with its bindings (I think Bernie alluded to in his reply to this threa= d) which the server did not do before for the IA_NA. Searching thru bindin= gs has delay implications and additional server computations. Or as I had = already said in my earlier reply that the server checks what prefixes are c= onfigured on the server to determine on-link status. However checking pref= ixes for IA_PD=20 at a server has to exclude prefixes that are used for allocation of IA_NA.= So now the server maintains two types of prefixes. =20 Thus I will try and propose some text over the weekend that IA_PD support i= n CONFIRM can't suffice with network configuration. Some other data in the= server needs checking and we should try and be little specific about the d= ata. Just saying something like "the sever checks network configuration" d= oesn't cut it for the IA_PD. =20 Let me see what I can do over this weekend and propose some text as to how = the server checks for on-link or not for the IA_PD to respond to a CONFIRM.= I will also catch up with other emails on this document and reply, if nec= essary. Regards, Hemant From volz@cisco.com Sun Sep 16 17:26:51 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD6721F8527 for ; Sun, 16 Sep 2012 17:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-Z8T9c-3lEB for ; Sun, 16 Sep 2012 17:26:50 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDF221F8510 for ; Sun, 16 Sep 2012 17:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6387; q=dns/txt; s=iport; t=1347841610; x=1349051210; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4YGaJ5b2VZIVD+g32zHwZ3P63F0ytWwRi1XcBulRh9M=; b=cuTDl9TyAM1JAaGwI/eAWRuIlVoOvcM882iDB4QA9TBI+tERO8CYUgDa j8tmgr/9saEdJgRCNXT8K4u/JCek3DPUDfUysWC9NmXwHUKkJDsS2TcZe GSz+Eop8x5x+z9Cfcb/ybkK9S9SddhUWhMx/PgSZUpcvgsew0T8lkLvbl g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAARuVlCtJV2b/2dsb2JhbABFvBOBB4IgAQEBAwESASc/BQcEAgEIEQQBAR8JBzIUCQgCBA4FIodYBppYnxiGJYR8hghgA5VijjiBaYJmgWM X-IronPort-AV: E=Sophos;i="4.80,432,1344211200"; d="scan'208";a="122151366" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 17 Sep 2012 00:26:49 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8H0QnnG032306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Sep 2012 00:26:49 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Sun, 16 Sep 2012 19:26:48 -0500 From: "Bernie Volz (volz)" To: "Hemant Singh (shemant)" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpd/JdswgAB/xoD//5GrgIAAeqgAgAsV/xCAAo6qwIAAkkea Date: Mon, 17 Sep 2012 00:26:36 +0000 Message-ID: <56DD5F8D-D04D-40F6-B5BA-A5673E2264F8@cisco.com> References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F83D1@xmb-rcd-x04.cisco.com> <21C54D57-372F-46B0-892B-398919992546@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F857F@xmb-rcd-x04.cisco.com> <75B6FA9F576969419E42BECB86CB1B8908A7CF@xmb-rcd-x06.cisco.com>, <75B6FA9F576969419E42BECB86CB1B8908AAC6@xmb-rcd-x06.cisco.com> In-Reply-To: <75B6FA9F576969419E42BECB86CB1B8908AAC6@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19186.002 x-tm-as-result: No--51.711200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG , Ted Lemon , "Ole Troan \(otroan\)" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 00:26:51 -0000 The server I work on does not look up bindings for Confirming IAPREFIX (the= server has allowed Confirm on prefixes since day one) so this text is fals= e and is not required. The server does the same processing it does for addr= esses. It looks up the link and prefix configuration and if the delegated p= refix sent by the client (or address sent by the client) is contained by a = configured prefix the client is told success. If it can't tell (this is mos= tly the case for addresses that are link-local but also in cases where the = clients "location" can not be determined from one of the addresses or prefi= xes provided by the client) it doesn't respond. Otherwise the client is tol= d not-on-link. Confirm never says a particular address or prefix is leased to the client. = It just says whether the client has clearly moved or not (no response means= the server can't determine). So, I do not agree with this text change at all. Regarding the second issue ... If the configuration has changed to remove p= refix delegation or addresses, but not the other, and the Confirm returns N= ot-On-Link, client would move back to Solicit but why would Solicits contin= ue forever? Are you thinking a client would implement some, but not all cha= nges? I would think that is wrong - this is a package of changes the client= and server need to implement. So, the other changes would prevent the cont= inous Solicits? We have no good way to return separate status codes for pre= fix vs address and I don't see this as needed per what I just wrote? Note that likely the client will get back the same address or prefix when i= t Solicits, just won't get the other that is no longer configured. Perhaps Ole has a different view or there is something I am missing here? - Bernie On Sep 16, 2012, at 12:17 PM, "Hemant Singh (shemant)" = wrote: > Bernie, >=20 > Here is what I prefer for text for section 4.4 of the document. All othe= r text in the current section 4.4 is redundant with RFC 3315. >=20 > The Confirm message, as described in [RFC3315], is specific to > address assignment. Note a server processing a Confirm message > that includes only IA_NAs does not have to look up any client > bindings. This document extends the Confirm to include other=20 > IA option types. It is desirable other IA option=20 > types do not enforce the server to look up any client bindings=20 > to respond to a Confirm. Another IA option type is the IA_PD.=20 > The server uses configured prefixes to determine if a prefix in=20 > the IA_PD option is on-link to respond to a Confirm. >=20 > Another issue I'd like to bring up for the Confirm section of this docume= nt. I realize the document only supports the case of one server replying t= o both the IA_NA and the IA_PD. However, after a client has completed DHCP= v6 for both the IA_NA and the IA_PD, some configuration on the server chang= es. Later the client issues a Confirm and the server configuration change = causes one IA type to fail the on-link check. If the Status code option in= the Reply is global, the Reply has a failed on-link code and the client mo= ves to Solicit processing and the Solicits may continue indefinitely. I re= commend using the Status code option per IA option type. Then for an IA op= tion type not on-link status, the client can now use Information-request ra= ther than moving to a Solicit transaction. Thus more text changes to RFC 3= 315 are required. >=20 > Hemant >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of= Hemant Singh (shemant) > Sent: Friday, September 14, 2012 9:09 PM > To: Ted Lemon; Bernie Volz (volz) > Cc: dhc WG; Ole Troan (otroan) > Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 >=20 > Ted/Bernie/Ole, >=20 > Humble apologies I was buried with other priorities and did not check my = DHC WG email folder in a while. I actually replied to the xlat document in = v6ops during my 10 days of PTO up till the Labor Day. Bernie kindly remind= ed me this week of this document. Most of my comments have been addressed.= Some pending are included below. >=20 > Why was the CONFIRM message deliberately specified by RFC 3633 as not sup= ported for the IA_PD? =20 >=20 > It would be good to reply to this question. Otherwise the IESG is likely= to ask the same question and the answer to such a question may uncover iss= ues for us. =20 >=20 > For one, it is easy for a server to respond to a CONFIRM to an IA_MA by j= ust matching the IPv6 address configured on the machine the server is runni= ng on. I am always reminded by some authors of RFC 3315 that the server di= stinctly does not consult its client bindings to respond to a CONFIRM for a= n IA_NA. The server just relies on the machine IPv6 configuration to compu= te a status of on-link or not-on-link. Thus why it is not a sea-change to = support the CONFIRM for the IA_PD option and we may need to step gingerly? = If the server has to respond to a CONFIRM for an IA_PD, the server now con= sults with its bindings (I think Bernie alluded to in his reply to this thr= ead) which the server did not do before for the IA_NA. Searching thru bind= ings has delay implications and additional server computations. Or as I ha= d already said in my earlier reply that the server checks what prefixes are= configured on the server to determine on-link status. However checking pr= efixes for IA_PD=20 > at a server has to exclude prefixes that are used for allocation of IA_NA= . So now the server maintains two types of prefixes. =20 >=20 > Thus I will try and propose some text over the weekend that IA_PD support= in CONFIRM can't suffice with network configuration. Some other data in t= he server needs checking and we should try and be little specific about the= data. Just saying something like "the sever checks network configuration"= doesn't cut it for the IA_PD. =20 >=20 > Let me see what I can do over this weekend and propose some text as to ho= w the server checks for on-link or not for the IA_PD to respond to a CONFIR= M. I will also catch up with other emails on this document and reply, if n= ecessary. >=20 > Regards, >=20 > Hemant >=20 From volz@cisco.com Sun Sep 16 17:58:29 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D19021F8499 for ; Sun, 16 Sep 2012 17:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tBfFSYYEfFb for ; Sun, 16 Sep 2012 17:58:27 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 11F8321F847F for ; Sun, 16 Sep 2012 17:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16956; q=dns/txt; s=iport; t=1347843507; x=1349053107; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=coHHYX+/Sp181T8QlclX0m0L/Hx3uJtLCf1GcERndYk=; b=amLjIv8KNpRPew/PggCMjtx5R22dF1VegQpfMsh4ugZiTQZB8XoCXxXz pIVArquJ7ovG0PbhNaFwe4yEl902F+58Ist+EQWtQwAcMxmDceTlxgNYF dekwmte4cwVjD34JQUNtlbMGbumSOkcZ4BwxwGKE5dGazBnz8Ig/c67d0 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAJF0VlCtJXG8/2dsb2JhbAA7CoJLsGQBiGOBB4IgAQEBBBIBGkwQAgEIEQQBAQsdBzIUCQgCBAENBQgah14LmlOfGoshEIV4YAOSMYRFjSSBaYJmghc X-IronPort-AV: E=Sophos;i="4.80,432,1344211200"; d="scan'208,217";a="121933186" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 17 Sep 2012 00:58:26 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8H0wQmt019503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 17 Sep 2012 00:58:26 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Sun, 16 Sep 2012 19:58:25 -0500 From: "Bernie Volz (volz)" To: "Anup Kumar Vasudevan (anuvasud)" , "dhcwg@ietf.org" Thread-Topic: Reg. Use of Link-Address Field for DHCPv6 Thread-Index: AQHNkkzP+5tdKtJ+Kke3DzPsRIaW9peNuWJA Date: Mon, 17 Sep 2012 00:58:25 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F4FFC62@xmb-rcd-x04.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.87] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19186.002 x-tm-as-result: No--32.303600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E0F4FFC62xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "G Murali Krishna \(gunkrish\)" Subject: Re: [dhcwg] Reg. Use of Link-Address Field for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 00:58:29 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E0F4FFC62xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ideally all relay agents would fill in this value. If they don't, it should= be set to all 0's (128 bits of 0). If no address is specified in the link-address field, a server would try an= outer Relay-Forw to see if it has a link-address (and so on). If no relay = specified the link-address, the server only has either the source address o= f the packet or the interface on which it was received in order to determin= e where the client is located. Neither of these is probably correct. The bottom line is that a relay agent should fill in the link-address field= with information about where the client is located that the server can use= to assign appropriate addresses or delegate appropriate prefixes. - Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of A= nup Kumar Vasudevan (anuvasud) Sent: Friday, September 14, 2012 3:45 AM To: dhcwg@ietf.org Cc: G Murali Krishna (gunkrish) Subject: [dhcwg] Reg. Use of Link-Address Field for DHCPv6 Hi We have a query on the Link-Address field in DHCPv6 - for Relay Agents. Fro= m the RFC - 20.1.1. Relaying a Messa= ge from a Client If the relay agent received the message to be relayed from a client, the relay agent places a global or site-scoped address with a prefix assigned to the link on which the client should be assigned an address in the link-address field. This address will be used by the server to determine the link from which the client should be assigned an address and other configuration information. The hop-count in the Relay-forward message is set to 0. If the relay agent cannot use the address in the link-address field to identify the interface through which the response to the client will be relayed, the relay agent MUST include an Interface-id option (see section 22.18) in= the Relay-forward message. The server will include the Interface-id option in its Relay-reply message. The relay agent fills in the link-address field as described in the previous paragraph regardless of whether the relay agent includes an Interface-id option in the Relay-forward message. Is the Link-Address field Mandatory? Should Relay-Agents always fill it? Al= so is it mandatory for Server to use the Link-Address field for Assigning c= lient addresses? If the Server does not have addresses that match the Link-= Address field , should it fail the Allocation requests? We have seen in testing that some of the third party servers don't really u= se this field for Address Assignment - but I think the ISC implementation i= s dependent on this field. Thanks Anup --_000_489D13FBFA9B3E41812EA89F188F018E0F4FFC62xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ideally all relay agents = would fill in this value. If they don’t, it should be set to all 0= 217;s (128 bits of 0).

 <= /p>

If no address is specifie= d in the link-address field, a server would try an outer Relay-Forw to see = if it has a link-address (and so on). If no relay specified the link-address, the server only has either the source address of the pac= ket or the interface on which it was received in order to determine where t= he client is located. Neither of these is probably correct.

 <= /p>

The bottom line is that a= relay agent should fill in the link-address field with information about w= here the client is located that the server can use to assign appropriate addresses or delegate appropriate prefixes.<= /p>

 <= /p>

- =          Bernie=

 <= /p>

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Anup Kumar Vasudevan (anuvasud)
Sent: Friday, September 14, 2012 3:45 AM
To: dhcwg@ietf.org
Cc: G Murali Krishna (gunkrish)
Subject: [dhcwg] Reg. Use of Link-Address Field for DHCPv6

 

Hi <= /p>

 

We have a query on the Link= -Address field in DHCPv6 – for Relay Agents. From the RFC - 

 

20.1.1. Relaying a Message from a Clie= nt

 
 
   If the relay agent received the message to be rel=
ayed from a client,
   the relay agent places a global or site-scoped ad=
dress with a prefix
   assigned to the link on which the client should b=
e assigned an
   address in the link-address field.  This add=
ress will be used by the
   server to determine the link from which the clien=
t should be assigned
   an address and other configuration information.&n=
bsp; The hop-count in the
   Relay-forward message is set to 0.
 
   If the relay agent cannot use the address in the =
link-address field
   to identify the interface through which the respo=
nse to the client
   will be relayed, the relay agent MUST include an =
Interface-id option
   (see section 22.18) in the Relay-forward message.  The=
 server will
   include the Interface-id option in its Relay-repl=
y message.  The
   relay agent fills in the link-address field as de=
scribed in the
   previous paragraph regardless of whether the rela=
y agent includes an
   Interface-id option in the Relay-forward message.=

 
Is the Link-Address field Mandatory? Should Relay-Agents alway=
s fill it? Also is it mandatory for Server to use the Link-Address field fo=
r Assigning client addresses? If the Server does not have addresses that ma=
tch the Link-Address field , should it fail the Allocation requests? 
We have seen in testing that some of the third party servers d=
on't really use this field for Address Assignment – but I think the I=
SC implementation is dependent on this field. 
Thanks

Anup
--_000_489D13FBFA9B3E41812EA89F188F018E0F4FFC62xmbrcdx04ciscoc_-- From internet-drafts@ietf.org Sun Sep 16 21:15:59 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0752221F84F9; Sun, 16 Sep 2012 21:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOu+nsAjPCvO; Sun, 16 Sep 2012 21:15:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8B121F841E; Sun, 16 Sep 2012 21:15:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120917041558.21836.74237.idtracker@ietfa.amsl.com> Date: Sun, 16 Sep 2012 21:15:58 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 04:15:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : DHCPv4 over IPv6 Transport Author(s) : Yong Cui Peng Wu Jianping Wu Ted Lemon Filename : draft-ietf-dhc-dhcpv4-over-ipv6-05.txt Pages : 14 Date : 2012-09-16 Abstract: In IPv6 networks, there remains a need to provide IPv4 service for some residual devices. This document describes a mechanism for allocating IPv4 addresses to such devices, using DHCPv4 with an IPv6 transport. It is done by putting a special relay agent function (Client Relay Agent) on the client side, as well as extending the behavior of the server; in the case where DHCP server only supports IPv4 transport, a relay agent is extended to support IPv6 transport (IPv6-Transport Relay Agent) and relay DHCP traffic for the server, with a new Relay Agent Information sub-option added to carry the IPv6 address of the Client Relay Agent. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-ipv6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-ipv6-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv4-over-ipv6-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pengwu.thu@gmail.com Sun Sep 16 21:48:16 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6934421F84CE; Sun, 16 Sep 2012 21:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1FOiqxWuAzP; Sun, 16 Sep 2012 21:48:15 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5A321F845B; Sun, 16 Sep 2012 21:48:15 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so7464296vbb.31 for ; Sun, 16 Sep 2012 21:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d51IyJbzbMd8p4Sny2q4GyVlQ87BMbrQ66zJE12unt8=; b=BTRpBWHhIBjWSLTw7ti87lrA5YWREQj++6gegrKZsTBylJY2JQgU71sVBhUVgf/XJF MBaCM8VmVM4AK3LK4lg+pbOOtwuU4la3O1avxFiqcqmyfnVsCywqu3Bt0Igob7RR+EJp zlMloJiquqNJhDEyilwDczy0I/AcVjLVxnWz9OeyyouQpr9qhwCz32m9bwyi7g/cWKuT owUZ/1ChvK8ynURQfyg/O/OydD3JAzw1znKlxNP1pTofxSORoQPs2hKCuyUQb6qTDG8F O3xJ/qH+7xm5VekArjfkFo7I4Vd3iEsdw0NIN9qmCwEyGS/COxY0pH0xhNkzppZWp+3I Xwiw== MIME-Version: 1.0 Received: by 10.52.34.162 with SMTP id a2mr1206638vdj.19.1347857294318; Sun, 16 Sep 2012 21:48:14 -0700 (PDT) Received: by 10.58.35.168 with HTTP; Sun, 16 Sep 2012 21:48:14 -0700 (PDT) In-Reply-To: <20120917041558.21836.74237.idtracker@ietfa.amsl.com> References: <20120917041558.21836.74237.idtracker@ietfa.amsl.com> Date: Mon, 17 Sep 2012 12:48:14 +0800 Message-ID: From: Peng Wu To: internet-drafts@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: dhcwg@ietf.org, i-d-announce@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 04:48:16 -0000 Hi all, This version is pretty much identical to the -04 version in content. Only three, non-technical modifications: 1)adjust the section numbers for the appendix part 2)change the reference on the client-id draft to be Normative 3)remove a redundant sentence on relay encapsulation in section 6. On Mon, Sep 17, 2012 at 12:15 PM, wrote: > > 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 : DHCPv4 over IPv6 Transport > Author(s) : Yong Cui > Peng Wu > Jianping Wu > Ted Lemon > Filename : draft-ietf-dhc-dhcpv4-over-ipv6-05.txt > Pages : 14 > Date : 2012-09-16 > > Abstract: > In IPv6 networks, there remains a need to provide IPv4 service for > some residual devices. This document describes a mechanism for > allocating IPv4 addresses to such devices, using DHCPv4 with an IPv6 > transport. It is done by putting a special relay agent function > (Client Relay Agent) on the client side, as well as extending the > behavior of the server; in the case where DHCP server only supports > IPv4 transport, a relay agent is extended to support IPv6 transport > (IPv6-Transport Relay Agent) and relay DHCP traffic for the server, > with a new Relay Agent Information sub-option added to carry the IPv6 > address of the Client Relay Agent. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-ipv6 > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-ipv6-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv4-over-ipv6-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From ichiroumakino@gmail.com Mon Sep 17 01:02:41 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412C421F8437 for ; Mon, 17 Sep 2012 01:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zw0HSpvpyEyj for ; Mon, 17 Sep 2012 01:02:40 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8433321F841E for ; Mon, 17 Sep 2012 01:02:40 -0700 (PDT) Received: by qadz3 with SMTP id z3so1327524qad.10 for ; Mon, 17 Sep 2012 01:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=1X3jfnuCXVzU7CXHKW5hAiZH+aKyDem3kF6oLQ0VBno=; b=qhr/VzEuIUTV5jaxNCDnuoDWR0bpfSFcPFdq8aLe1HPRtMbR75AuP3H7yfyzTQeP6p UV9b5yRaQw9vwu2q9UJh0GjctbbPkYHXvuUzhTlhf5KDtezXFLJJxD82IZ9SCsuzg4kK 44q0vf8ptnzELe5nzuGDLfRxfUVriDRflCpa5CNE+LfJ2hrjxVvKbMuY/JvCkSrSMVp0 Zjhn/KYoljj2Tdt9aWNSqbA2QHAfYBkFT1r+ial8DnVXaVS7d51dGK06qVZeuVx0wZHP 9j/pdLaCyZDgDwjAlcoqDfeV99lJbCA8rPovX9U2XRTVOsYZkUA4bA4OCF6rp5KO2MQY qBgA== Received: by 10.224.31.210 with SMTP id z18mr25486625qac.95.1347868959985; Mon, 17 Sep 2012 01:02:39 -0700 (PDT) Received: from ?IPv6:2001:420:44ff:fd17:3147:b135:2325:5da3? ([2001:420:44ff:fd17:3147:b135:2325:5da3]) by mx.google.com with ESMTPS id fy1sm903243qab.10.2012.09.17.01.02.36 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Sep 2012 01:02:38 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_ED113C09-DB2F-48BD-B00F-2294242DE8E4"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <56DD5F8D-D04D-40F6-B5BA-A5673E2264F8@cisco.com> Date: Mon, 17 Sep 2012 10:02:45 +0200 Message-Id: References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F83D1@xmb-rcd-x04.cisco.com> <21C54D57-372F-46B0-892B-398919992546@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F857F@xmb-rcd-x04.cisco.com> <75B6FA9F576969419E42BECB86CB1B8908A7CF@xmb-rcd-x06.cisco.com>, <75B6FA9F576969419E42BECB86CB1B8908AAC6@xmb-rcd-x06.cisco.com> <56DD5F8D-D04D-40F6-B5BA-A5673E2264F8@cisco.com> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.1278) Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 08:02:41 -0000 --Apple-Mail=_ED113C09-DB2F-48BD-B00F-2294242DE8E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Bernie, > The server I work on does not look up bindings for Confirming IAPREFIX = (the server has allowed Confirm on prefixes since day one) so this text = is false and is not required. The server does the same processing it = does for addresses. It looks up the link and prefix configuration and if = the delegated prefix sent by the client (or address sent by the client) = is contained by a configured prefix the client is told success. If it = can't tell (this is mostly the case for addresses that are link-local = but also in cases where the clients "location" can not be determined = from one of the addresses or prefixes provided by the client) it doesn't = respond. Otherwise the client is told not-on-link. >=20 > Confirm never says a particular address or prefix is leased to the = client. It just says whether the client has clearly moved or not (no = response means the server can't determine). >=20 > So, I do not agree with this text change at all. >=20 > Regarding the second issue ... If the configuration has changed to = remove prefix delegation or addresses, but not the other, and the = Confirm returns Not-On-Link, client would move back to Solicit but why = would Solicits continue forever? Are you thinking a client would = implement some, but not all changes? I would think that is wrong - this = is a package of changes the client and server need to implement. So, the = other changes would prevent the continous Solicits? We have no good way = to return separate status codes for prefix vs address and I don't see = this as needed per what I just wrote? >=20 > Note that likely the client will get back the same address or prefix = when it Solicits, just won't get the other that is no longer configured. >=20 > Perhaps Ole has a different view or there is something I am missing = here? I have the same view as well. (the reason we did what we did in 3633 with regards to Confirm, was = because of the text around "Onlink". in hindsight we've realised that = having different behaviour per IA was a bad idea, and Bernie came up = with a simple fix for how to use Confirm for IA_PD also.) cheers, Ole= --Apple-Mail=_ED113C09-DB2F-48BD-B00F-2294242DE8E4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwOTE3MDgwMjQ1WjAjBgkqhkiG9w0BCQQxFgQUlWTOHRixhztlh8kl piNPUA0i2MMwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAtMWLcnREtftvFXENeROf NuhxtJ6Dywrn8L+AIVnjR9YfxD76SBxjKBaPu/2hTpDeVRHQNvDgpSFKl2YSHui4nim/hJ6vumkh gEAaQmFQGHsBogeC6siAeLUyoRghuBBdmtv1whVlvlZ/rv4RZF4703/PlRVMFRt3JSZLt+lmdVf0 FFRV1HXfN03A6c1lYigs54vn5DmI26WV+SwKOX7WnALuPsE3hZxKxLyuwTI+cJv7GDfK06bnEsoE NwO6AvcqPe+cmJDC+UL5WX1LVFuUcAiX5tOttMb7IqUPgtKtucJ7gwKXdPxwrxGq+LiZp1M2CKi6 TJfPGWYhYtteZoKhLQAAAAAAAA== --Apple-Mail=_ED113C09-DB2F-48BD-B00F-2294242DE8E4-- From akostur@incognito.com Tue Sep 18 09:04:11 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74E821F84D8 for ; Tue, 18 Sep 2012 09:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0KmyBJ--Iin for ; Tue, 18 Sep 2012 09:04:11 -0700 (PDT) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with SMTP id 0DFED21F84AF for ; Tue, 18 Sep 2012 09:04:10 -0700 (PDT) Received: from mail-qa0-f51.google.com ([209.85.216.51]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKUFibdySrZxLIN7w8fIRy77U69kG62Oj+@postini.com; Tue, 18 Sep 2012 09:04:11 PDT Received: by qadz3 with SMTP id z3so149818qad.10 for ; Tue, 18 Sep 2012 09:04:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=gkBFX3X1ZPTSLPvY8nXnckqHRrd8AlWC1/vcShJvs9g=; b=LC0oJZRLoqA5fE+zdXwWd6N1IxS/uFSlF6C+vimD+Mj/uUeukY2PvjF61yMn1e7NUU J1AzUMaVRZlhMIm33hwUz6RpY0zUuNoID1GPazp+4VV1mQJNY3zvoqdpiVJ6PthMbm4D Ina+/ax2r0BhmICy4p6xX2gcPf16KUIDFVCm3BGDbuHM+EfP9qyCCkmJuIB2vhAXfmCi Pif62D6OJkrM1oo1klr/bXjVQ9AGevciNASwL/l8gojhzbLvx2du0hdDL5TKdJzPqM6o eFQc9BBVaCNqpDoy/OiiOuJ2q53fic0Gf8hZxHZ3FpAjPJmILedzzWxA+TVY8kQZCp3i gJtQ== MIME-Version: 1.0 Received: by 10.229.69.31 with SMTP id x31mr162682qci.101.1347984246289; Tue, 18 Sep 2012 09:04:06 -0700 (PDT) Received: by 10.229.54.16 with HTTP; Tue, 18 Sep 2012 09:04:06 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F4FDEBC@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> <5049C317.7090603@gmail.com> <94FA926F-2432-4AE7-BC20-AE7458AB40D9@cisco.com> <71F17433-B2D9-4366-9B32-F0E4D294EDB5@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4FDEBC@xmb-rcd-x04.cisco.com> Date: Tue, 18 Sep 2012 09:04:06 -0700 Message-ID: From: Andre Kostur To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk0j41d03LavLxql3EvEXTlXkwegDq2f5vbcUJ/bp+iu3y6xJ0YcNE55aFjVatyfGiOQqWh Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:04:11 -0000 On Wed, Sep 12, 2012 at 8:15 PM, Bernie Volz (volz) wrote: > > One comment on the draft is that I think it needs to be clear that load > balancing is ONLY used for DHCPv6 client messages that do not include a > server-identifier option (this is Solicit, Information-Request (if no > server-identifier option), Rebind, and Confirm). Load balancing MUST NOT be > used if a server-identifier option exists in the client's message, as then > only that server should respond. I've been mulling this over for a while in the context of the following problem: Let us assume that there are two cooperating (through some additional mechanism external to load balancing) DHCPv6 servers A and B. At some point, server A goes away for a while and the entire population eventually binds to server B (whether rebooting, or Rebinding to it). Now server A returns to service. Until the members do a reboot or Rebind, server A will not be handling any traffic (other than about 1/2 of the new clients) as server B is receiving and answering all of the Renews. What I'd like is that over time, the population will migrate around to splitting between server A and server B again. I think for this reason we shouldn't force the server to answer (well, consider) every request aimed at it. -- Andre Kostur From volz@cisco.com Tue Sep 18 09:24:12 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AC921F851C for ; Tue, 18 Sep 2012 09:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfKKhROy9QoT for ; Tue, 18 Sep 2012 09:24:11 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 43B0921F8518 for ; Tue, 18 Sep 2012 09:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4038; q=dns/txt; s=iport; t=1347985451; x=1349195051; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=AktEOJxKYHx/2ILzjj/b0z3PL0pwRjPTllpbcULNnBk=; b=ltrmmxO/B0DQWk05qgerrIgJ6BHJ/Rdx7iK+0hx5meFnXyou3Ova6wam 6XJVlq977bqBNi71T0cyHLOFi7JCEVWuMpibYTcVUHm+LdQt04mMZUW+y DXXVdekCoAV2C0EhTtdRoyBapkYyYVUG8Xk6LNRxqZwpdzcT/lcawCwrX s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABmfWFCtJXHB/2dsb2JhbABFvD+BCIInEgEUSgEHEgEIDmolAgQOBSKHXpoqoDuLGxWGWwOVY444gWmCZoFbPA X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="122604928" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 18 Sep 2012 16:24:10 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8IGO9V2028405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Sep 2012 16:24:09 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Tue, 18 Sep 2012 11:24:07 -0500 From: "Bernie Volz (volz)" To: Andre Kostur Thread-Topic: [dhcwg] Load Balancing for DHCPv6 Thread-Index: AQHNj2xDaJ+khP2NkUiXQs2wUqwOeJeHnBuAgAkHUwD//8KGAA== Date: Tue, 18 Sep 2012 16:24:06 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [161.44.65.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19190.004 x-tm-as-result: No--58.536400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <2346551E61B1064E8CD200C953DBD366@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:24:12 -0000 First, I think this would be a rather bad change to DHCPv6 operation. Client may be checking the server-identifier option they get back and so you would have to lie about that in the response which just seems like a very bad thing to do. (I don't believe RFC 3315 actually ever states the clients should be checking the server-identifier, but I could be wrong -- section 15 does say they check for the presence of the option, but do not check the contents). One could also think of situations where a relay agent might forward the packet to explicit destinations based on the server identifier (though again, I doubt anyone does this) -- much like switches limit traffic based on mac-addresses. Second, the following assumes load balancing is being used for failover ... There is one 'trick' that I had been thinking about for a long time and is perhaps still an open issue for failover for v6 =8A and that is why not hav= e both failover partners use the same server-identifier value (you can think of the server-identifier belonging to that failover relationship) -- then the servers can always use load balancing or other 'policy' to decide which one responds and you don't violate the concept that the server-identifer is the one that the client expects. It also means that Renew packets can be handled by either partner. However, it does complicate Request packets because failover doesn't usually exchange tentative bindings from a Solicit and so you really would only want the server that Solicited to respond to the Request (this could be done by looking to see if you had a tentative binding - but if neither server does, the client has to suffer a Request timeout to get back to the Solicit phase). --> That is the main reason why I think this fails to work and I have not proposed it. Also, note that you would potentially have this same issue for your proposal when=20 For v4, the current operation has not really caused operational issues. We have thought about how to 'force' traffic back to the original server but as it hasn't caused any issues, we haven't bothered? New v4 clients (i.e. those that do a discover), will get back to their server and most clients seem to do so over a reasonable period of time. Anyway, I think this needs to be thought through much more carefully as to the potential consequences and I think the best is to keep it simple - once a client has 'bound' to a server, it stays with that server until it issues a request message which does not contain a server-identifier option. - Bernie On 9/18/12 12:04 PM, "Andre Kostur" wrote: >On Wed, Sep 12, 2012 at 8:15 PM, Bernie Volz (volz) >wrote: >> >> One comment on the draft is that I think it needs to be clear that load >> balancing is ONLY used for DHCPv6 client messages that do not include a >> server-identifier option (this is Solicit, Information-Request (if no >> server-identifier option), Rebind, and Confirm). Load balancing MUST >>NOT be >> used if a server-identifier option exists in the client's message, as >>then >> only that server should respond. > >I've been mulling this over for a while in the context of the following >problem: > >Let us assume that there are two cooperating (through some additional >mechanism external to load balancing) DHCPv6 servers A and B. At some >point, server A goes away for a while and the entire population >eventually binds to server B (whether rebooting, or Rebinding to it). > Now server A returns to service. Until the members do a reboot or >Rebind, server A will not be handling any traffic (other than about >1/2 of the new clients) as server B is receiving and answering all of >the Renews. What I'd like is that over time, the population will >migrate around to splitting between server A and server B again. > >I think for this reason we shouldn't force the server to answer (well, >consider) every request aimed at it. > >-- >Andre Kostur From akostur@incognito.com Tue Sep 18 09:42:47 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E1C21F860D for ; Tue, 18 Sep 2012 09:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilmUe7ZaNar2 for ; Tue, 18 Sep 2012 09:42:46 -0700 (PDT) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by ietfa.amsl.com (Postfix) with SMTP id 9048621F8600 for ; Tue, 18 Sep 2012 09:42:45 -0700 (PDT) Received: from mail-qa0-f51.google.com ([209.85.216.51]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKUFikhJIQJg67UMVHzsiaLHCnrEtb0tzC@postini.com; Tue, 18 Sep 2012 09:42:46 PDT Received: by qadz3 with SMTP id z3so186986qad.10 for ; Tue, 18 Sep 2012 09:42:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=RUYIXZJXocoG3z8gJwSIlemnJ59yALUhwFHmpVIXDdg=; b=W5h0rkMHcyYTu8YBnBL1Eu0sX0z+piV9RjmJUoIGK9VcjZKaVi4lvCddJzL9Z3eD28 oT+qmAMeRqhlbxfik7VInDCmZTgOoCtl+ZJjV2sgfpQB0Jugau13ASf1gZBgsUx0Lfa9 29dc6XImUCQu+eGpH+ZSuro9/MkD2R3gzEsCQzuv46tU3rTbiGYMWs2Zze1mIvDbmHYE ZxOOqKMquxRhgVA6fKv3blnx6QCIU4iVz9z1Tug8xhdGhQiB7BEXSB03Q7z0Wq+U5aO2 qOTKhQxWGNK92KuMQnFJKdRw9R9zvajTQ2qgPyRCOgyDLp+D4/r0L7CislAgB/fC9CgM eNQw== MIME-Version: 1.0 Received: by 10.224.181.70 with SMTP id bx6mr725204qab.79.1347986564185; Tue, 18 Sep 2012 09:42:44 -0700 (PDT) Received: by 10.229.54.16 with HTTP; Tue, 18 Sep 2012 09:42:44 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Sep 2012 09:42:44 -0700 Message-ID: From: Andre Kostur To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmSI6+i0y93Vuw8WGjmxilAL1zD+rw9w9kmh0bsvJQ9pXWWpx0CGHc3OBDhDJ3CH8Qa0uNp Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:42:47 -0000 On Tue, Sep 18, 2012 at 9:24 AM, Bernie Volz (volz) wrote: > First, I think this would be a rather bad change to DHCPv6 operation. > Client may be checking the server-identifier option they get back and so > you would have to lie about that in the response which just seems like a > very bad thing to do. (I don't believe RFC 3315 actually ever states the > clients should be checking the server-identifier, but I could be wrong -- > section 15 does say they check for the presence of the option, but do not > check the contents). One could also think of situations where a relay > agent might forward the packet to explicit destinations based on the > server identifier (though again, I doubt anyone does this) -- much like > switches limit traffic based on mac-addresses. Note that I didn't suggest that server A preemptively answer the Renew coming in from the client (or impersonate server B). Under my suggestion, the Renew would arrive at both servers A and B. B would ignore it due to load balancing, and A would also ignore it due to the server ID. The client continues to retry the Renews for the appropriate time, until it is time to Rebind. At that point server B is still ignoring the client, but now A can answer the client as the Rebind isn't carrying a Server ID. (And if we are talking about a Failover pair, then server A would already have a lease record for this client, and can extend that same lease.) For the relay piece, it would still need to forward the Rebind to both servers. [snip] > Anyway, I think this needs to be thought through much more carefully as to > the potential consequences and I think the best is to keep it simple - > once a client has 'bound' to a server, it stays with that server until it > issues a request message which does not contain a server-identifier option. My scenario doesn't result in a client switching servers except under already defined RFC 3315 behaviour when the client has transitioned into Rebind. One piece that may have funny consequences is if the pair of DHCP servers aren't in some sort of cooperation mode, and this scenario would result in the client possibly changing IP addresses. Client has to rebind, and server A does the DHCPv6 equivalent of a NAK and forces the client to come back to get a new IP. Perhaps a server MAY skip the load balancing if the packet contains a Server ID (or even limiting it to the server's Server ID)? -- Andre Kostur From volz@cisco.com Tue Sep 18 10:44:06 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1E421F8522 for ; Tue, 18 Sep 2012 10:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeQ9kavnDE-N for ; Tue, 18 Sep 2012 10:44:06 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2168421F851C for ; Tue, 18 Sep 2012 10:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3064; q=dns/txt; s=iport; t=1347990245; x=1349199845; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=qevywG1pd0Rmzos5+/0nI4lruB192QYWSvR3OVHPRUE=; b=gaqdDAzIH+NaTFKXGbS2TsXxvI3eBSCaELH7yXk1Vo7rst3tNVMzFc2r ATZaVpazEe+eprNQFzK3jKFFrIvCuvz1m6GssC93IpmnXpgSJ1/92w69G 1rrBJ9KtfQP+PmoeNW8WmZvCjgbtPn+RPkNiGvFs0cug39JgBeLQTzXcO s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAA2yWFCtJXG8/2dsb2JhbABFvEKBCIInEgFmEgEIDmolAgQOBSKHXpofoDiLGxQBhlsDlWOOOIFpgmaBWgE8 X-IronPort-AV: E=Sophos;i="4.80,444,1344211200"; d="scan'208";a="122859294" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 18 Sep 2012 17:44:04 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8IHi4Pp006563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Sep 2012 17:44:04 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Tue, 18 Sep 2012 12:44:04 -0500 From: "Bernie Volz (volz)" To: Andre Kostur Thread-Topic: [dhcwg] Load Balancing for DHCPv6 Thread-Index: AQHNj2xDaJ+khP2NkUiXQs2wUqwOeJeHnBuAgAkHUwD//8KGAIAASEUA///OD4A= Date: Tue, 18 Sep 2012 17:44:03 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [161.44.65.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19190.004 x-tm-as-result: No--50.956700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 17:44:06 -0000 OK =8A though having the client send lots of Renews seems less than optimal to me (and the limited processing required by the load balancing servers for these packets may be more than if the targeted server just answered the first time). I think this could always be an optional feature. Even if the servers had different settings with respect to handling Renews, things would still work correctly. - Bernie On 9/18/12 12:42 PM, "Andre Kostur" wrote: >On Tue, Sep 18, 2012 at 9:24 AM, Bernie Volz (volz) >wrote: >> First, I think this would be a rather bad change to DHCPv6 operation. >> Client may be checking the server-identifier option they get back and so >> you would have to lie about that in the response which just seems like a >> very bad thing to do. (I don't believe RFC 3315 actually ever states the >> clients should be checking the server-identifier, but I could be wrong >>-- >> section 15 does say they check for the presence of the option, but do >>not >> check the contents). One could also think of situations where a relay >> agent might forward the packet to explicit destinations based on the >> server identifier (though again, I doubt anyone does this) -- much like >> switches limit traffic based on mac-addresses. > >Note that I didn't suggest that server A preemptively answer the Renew >coming in from the client (or impersonate server B). Under my >suggestion, the Renew would arrive at both servers A and B. B would >ignore it due to load balancing, and A would also ignore it due to the >server ID. The client continues to retry the Renews for the >appropriate time, until it is time to Rebind. At that point server B >is still ignoring the client, but now A can answer the client as the >Rebind isn't carrying a Server ID. (And if we are talking about a >Failover pair, then server A would already have a lease record for >this client, and can extend that same lease.) > >For the relay piece, it would still need to forward the Rebind to both >servers. > >[snip] > >> Anyway, I think this needs to be thought through much more carefully as >>to >> the potential consequences and I think the best is to keep it simple - >> once a client has 'bound' to a server, it stays with that server until >>it >> issues a request message which does not contain a server-identifier >>option. > >My scenario doesn't result in a client switching servers except under >already defined RFC 3315 behaviour when the client has transitioned >into Rebind. > >One piece that may have funny consequences is if the pair of DHCP >servers aren't in some sort of cooperation mode, and this scenario >would result in the client possibly changing IP addresses. Client has >to rebind, and server A does the DHCPv6 equivalent of a NAK and forces >the client to come back to get a new IP. Perhaps a server MAY skip >the load balancing if the packet contains a Server ID (or even >limiting it to the server's Server ID)? > >--=20 >Andre Kostur From Ted.Lemon@nominum.com Wed Sep 19 14:45:35 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D91C21E80B4 for ; Wed, 19 Sep 2012 14:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.551 X-Spam-Level: X-Spam-Status: No, score=-106.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0Z9n0qzZx0O for ; Wed, 19 Sep 2012 14:45:34 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id A638B21E80AD for ; Wed, 19 Sep 2012 14:45:24 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUFo885UNjuRonDbb+vgnu3n3md3SYozQ@postini.com; Wed, 19 Sep 2012 14:45:24 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A45FA1B80AA for ; Wed, 19 Sep 2012 14:45:21 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9BBF619005C for ; Wed, 19 Sep 2012 14:45:21 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Wed, 19 Sep 2012 14:45:21 -0700 From: Ted Lemon To: dhc WG Thread-Topic: Call for adoption: draft-lemon-dhc-pd-01 Thread-Index: AQHNlrARAq1IuhHT2UasbuE4rMIyjw== Date: Wed, 19 Sep 2012 21:45:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <3A9652CA81F8B3479B95EAF4D0D716E0@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] Call for adoption: draft-lemon-dhc-pd-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 21:45:35 -0000 I'd like the working group to work on this document. The point of the doc= ument is to provide a mechanism whereby DHCP requesting routers can indicat= e their preference to the DHCP delegating router as to how the reverse zone= for a delegated prefix should be handled, and to provide a mechanism where= by the delegating router can communicate back to the requesting router the = mechanism that was chosen. John will be evaluating consensus, since I'm the author of the draft. He = will evaluate consensus some time after October 2. If you are in favor of= adopting this draft, please say so on the mailing list. If you think it'= s a bad idea, please say so on the list. Thanks! From mellon@fugue.com Wed Sep 19 15:12:03 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C664A21F8508 for ; Wed, 19 Sep 2012 15:12:03 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qx82eiEQ9zN8 for ; Wed, 19 Sep 2012 15:12:03 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 68F0721F8501 for ; Wed, 19 Sep 2012 15:12:03 -0700 (PDT) Received: from [192.168.1.4] (81.sub-70-192-64.myvzw.com [70.192.64.81]) by toccata.fugue.com (Postfix) with ESMTPSA id 6CE4E238093B for ; Wed, 19 Sep 2012 18:12:01 -0400 (EDT) From: Ted Lemon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <8FCDD643-4720-4F47-8366-7BD623CE874D@fugue.com> Date: Wed, 19 Sep 2012 18:11:59 -0400 To: dhc WG Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) X-Mailer: Apple Mail (2.1486) Subject: [dhcwg] Meeting minutes for IETF 84 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 22:12:03 -0000 I just uploaded them=97sorry for taking so long. Thanks to Jason Weil = for taking notes. There's not really time for corrections, but if you = see something wrong please let me know. Thanks! http://www.ietf.org/proceedings/84/minutes/minutes-84-dhc= From d3e3e3@gmail.com Wed Sep 19 22:27:31 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0C221F86B0 for ; Wed, 19 Sep 2012 22:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kW0GxiMnhrg5 for ; Wed, 19 Sep 2012 22:27:30 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B455221F8678 for ; Wed, 19 Sep 2012 22:27:30 -0700 (PDT) Received: by iabz21 with SMTP id z21so1554326iab.31 for ; Wed, 19 Sep 2012 22:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=WapE9RsoGh0hmjz4agI/UZ9Vd2m+rQ9zipFmHPpRpso=; b=EB4vtnxMulTmNlSPebI6DPY/+Ih/t7gmC1TdOxCr12rvtMVp6n70kTN8UeIy0RT4rI 2r9Tb3/o3368Z+5I55BXxyKc3ewoeOViXmUmujr8Zo91znUoMQ+FAVs/aqimWdo5+SYH xnx0oBqmD/7UQL59nZCqIUIARUw9Azzg9OvI3QOibs7l+QbdlGnbZAUZDDh4+nd2Bypi CB1XaxCGAl5C3cmjp+oUx1hg8CVOrYF8hVnj+yaIOXuyJGeFKtvU5g2HB8Lpb/igOqB4 AlPJ0a9bc3Q+S2BnjV9zzSjksTQ+jnzY/kTk2jacW4R5ZC51TR287uTC23KlU6Xiny0o 5EQw== Received: by 10.50.184.129 with SMTP id eu1mr730690igc.0.1348118850097; Wed, 19 Sep 2012 22:27:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.113 with HTTP; Wed, 19 Sep 2012 22:27:09 -0700 (PDT) In-Reply-To: References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> <5049C317.7090603@gmail.com> <94FA926F-2432-4AE7-BC20-AE7458AB40D9@cisco.com> <71F17433-B2D9-4366-9B32-F0E4D294EDB5@nominum.com> From: Donald Eastlake Date: Thu, 20 Sep 2012 01:27:09 -0400 Message-ID: To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 05:27:31 -0000 Well, I have some more statistics. One my co-authors on the draft whipped up some code that I then extended. The data hashed consisted of 2,560,000 strings calculated as follows: #define RUN 10000 for(i =3D 0; i < 256*RUN; ++i) { sprintf(str, "%08d^^%08d", i, i); {do hashes, etc} } Each string was hashed with Pearson and with 32-bit FNV-1a. Three arrays of 256 counters were incremented based on the Pearson hash, based on the bottom byte of the 32-bit FNV after one 16-bit fold ( hash2 =3D (hash&0xffff) ^ (hash >> 16) ), and based on the bottom byte of the 32-bit FNV after an additional 8-bit fold (hash3 =3D (hash2&0xff) ^ (hash2 >> 8); the equivalent of xor'ing all four bytes together). The expected number of hits on each bucket with perfect hashing would be 10,000. Here are the minimum and maximum number of hits and the standard deviation: Pearson: min=3D9678 max=3D19938 std-dev=3D630.72 FNV-32 1-fold: min=3D9699 max=3D10331 std-dev=3D103.06 FNV-32 2-folds: min=3D9662 max=3D10247 std-dev=3D90.78 So you now have Brian Carpenter's results, showing FNV to be much better than a variety of other methods, but not Pearson, on fairly realistic data. And you have these results showing FNV to be much better than Pearson on somewhat unrealistic data. ... Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Fri, Sep 7, 2012 at 6:29 PM, Ted Lemon wrote: > On Sep 7, 2012, at 5:37 PM, Donald Eastlake wrote: >> FNV takes a little more effort than Pearson. It also has a smaller >> footprint in memory. And I believe it will produce statistically >> better results. What are the relative weights of these or other >> factors in this case? > > Unfortunately, as far as I can tell neither of the studies you cite compa= res FNV to Pearson, although the results from Brian Carpenter's study are c= ertainly pretty impressive. I think more work is worse, smaller footprin= t probably doesn't matter (this algorithm is being run in DHCP servers, whi= ch typically aren't seriously memory-constrained), and statistically better= results only matter if it's a pretty big difference, so it's frustrating t= hat we don't have a comparison to the existing algorithm. > > To me, the biggest win of using FNV would be if there were an RFC to refe= r to, but it looks like this is not quite there yet. So my conclusion is = that I certainly don't oppose using FNV instead of Pearson, but I don't see= a strong reason to support it either. > From pjhingra@cisco.com Wed Sep 19 23:39:21 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B701321F867E for ; Wed, 19 Sep 2012 23:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wez+URU+lTv for ; Wed, 19 Sep 2012 23:39:21 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E65C221F867B for ; Wed, 19 Sep 2012 23:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1138; q=dns/txt; s=iport; t=1348123161; x=1349332761; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=PdpsoVDOKqW4SB5ulBvul9D5xDUBMy1tl4hxDG1cAVg=; b=hNLeLAYp673nUZEGX3toKWKcbFRjuWnDekQyzSTm/7GdNuV3ODtxqeQ7 0svlKT71Z65RJGrzu2Gknmys1EQrdfJKup9q8NW1Scfwjoihmchkohsjr cWtxC4+oQLAPO46ka+IGL8IlEwg5Q2WTUaqOuLThim9TuUOzh1QZ6wTLP I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD+5WlCtJXG8/2dsb2JhbABFvRSBCIIgAQEBBAEBAQ8BCh00FwQCAQgRBAEBCxQJBycLFAkIAgQBEggah2ELmX6gCgSLHIVhYAOkHIFpgmaCFw X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="123450350" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 20 Sep 2012 06:39:20 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8K6dKgD018044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Sep 2012 06:39:20 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.3]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Thu, 20 Sep 2012 01:39:19 -0500 From: "Prashant Jhingran (pjhingra)" To: Ted Lemon , dhc WG Thread-Topic: Call for adoption: draft-lemon-dhc-pd-01 Thread-Index: AQHNlrARAq1IuhHT2UasbuE4rMIyj5eSr/JA Date: Thu, 20 Sep 2012 06:39:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.78.28] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19194.004 x-tm-as-result: No--42.859500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Call for adoption: draft-lemon-dhc-pd-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 06:39:21 -0000 I support this document. - Regards, Prashant Jhingran -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Thursday, September 20, 2012 3:15 AM To: dhc WG Subject: [dhcwg] Call for adoption: draft-lemon-dhc-pd-01 I'd like the working group to work on this document. The point of the doc= ument is to provide a mechanism whereby DHCP requesting routers can indicat= e their preference to the DHCP delegating router as to how the reverse zone= for a delegated prefix should be handled, and to provide a mechanism where= by the delegating router can communicate back to the requesting router the = mechanism that was chosen. John will be evaluating consensus, since I'm the author of the draft. He = will evaluate consensus some time after October 2. If you are in favor of= adopting this draft, please say so on the mailing list. If you think it'= s a bad idea, please say so on the list. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From hansliu@gmail.com Wed Sep 19 23:56:34 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9A421F84F8 for ; Wed, 19 Sep 2012 23:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIhXH+SViOml for ; Wed, 19 Sep 2012 23:56:33 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 77AE321F8668 for ; Wed, 19 Sep 2012 23:56:33 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so103716wgb.13 for ; Wed, 19 Sep 2012 23:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5j5ost/5ei46m0yibnO+iY0OjxPTJTLnM6w1M/AMg84=; b=tzbHjqRepxRSMksxjJsFDNXHizBVqzbq91OEDHZrvlHrBs1Mo24jpE5H7SnxlSCoXR kd9HuH+O/bNM2+h+TyuFJ3CUWthk9qNesY00vrYKiKpDZfA333SRsXFeNMivAyLiIc1u qbIxK6HsbsiHzkQrf1vqAo+Af8UrCs1NHLNm6eBYN5Empr6ZGXqa3L0rW5WswtodBD/N ZvRUYeiKG3zC6H7rI1Fipg9olRRLkNIBDzhlX6x4jR8zcTrt/63yip5Wu3+crkFMeLKx LUyDE5E4sH6TaGf/YLvt5EMjmJIekSY4/cZ81QufIB/EOzTyxDqCpLzmXc2h0YrVrpXm TARg== MIME-Version: 1.0 Received: by 10.180.105.6 with SMTP id gi6mr2321408wib.4.1348124192475; Wed, 19 Sep 2012 23:56:32 -0700 (PDT) Received: by 10.223.74.195 with HTTP; Wed, 19 Sep 2012 23:56:32 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Sep 2012 14:56:32 +0800 Message-ID: From: Hans Liu To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dhc WG Subject: Re: [dhcwg] Call for adoption: draft-lemon-dhc-pd-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 06:56:34 -0000 I'm in favor of adopting this draft. Thanks! Best regards, Hans On Thu, Sep 20, 2012 at 5:45 AM, Ted Lemon wrote: > I'd like the working group to work on this document. The point of the d= ocument is to provide a mechanism whereby DHCP requesting routers can indic= ate their preference to the DHCP delegating router as to how the reverse zo= ne for a delegated prefix should be handled, and to provide a mechanism whe= reby the delegating router can communicate back to the requesting router th= e mechanism that was chosen. > > John will be evaluating consensus, since I'm the author of the draft. H= e will evaluate consensus some time after October 2. If you are in favor = of adopting this draft, please say so on the mailing list. If you think i= t's a bad idea, please say so on the list. > > Thanks! > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From jiangsheng@huawei.com Wed Sep 19 23:58:39 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CFA11E808D for ; Wed, 19 Sep 2012 23:58:39 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SbRdVRsa5Jb for ; Wed, 19 Sep 2012 23:58:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E9B7521F847A for ; Wed, 19 Sep 2012 23:58:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKW28882; Thu, 20 Sep 2012 06:58:35 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Sep 2012 07:57:42 +0100 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Sep 2012 07:58:15 +0100 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.98]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Thu, 20 Sep 2012 14:58:11 +0800 From: Sheng Jiang To: Ted Lemon , dhc WG Thread-Topic: Call for adoption: draft-lemon-dhc-pd-01 Thread-Index: AQHNlrARAq1IuhHT2UasbuE4rMIyj5eSzR9A Date: Thu, 20 Sep 2012 06:58:10 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F49C89@szxeml545-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] Call for adoption: draft-lemon-dhc-pd-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 06:58:39 -0000 U3VwcG9ydCBhZG9wdGlvbi4NCg0KQmVzdCByZWdhcmRzLA0KDQpTaGVuZw0KDQo+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+T2YgVGVkIExlbW9uDQo+U2VudDog VGh1cnNkYXksIFNlcHRlbWJlciAyMCwgMjAxMiA1OjQ1IEFNDQo+VG86IGRoYyBXRw0KPlN1Ympl Y3Q6IFtkaGN3Z10gQ2FsbCBmb3IgYWRvcHRpb246IGRyYWZ0LWxlbW9uLWRoYy1wZC0wMQ0KPg0K PkknZCBsaWtlIHRoZSB3b3JraW5nIGdyb3VwIHRvIHdvcmsgb24gdGhpcyBkb2N1bWVudC4gICBU aGUgcG9pbnQgb2YgdGhlDQo+ZG9jdW1lbnQgaXMgdG8gcHJvdmlkZSBhIG1lY2hhbmlzbSB3aGVy ZWJ5IERIQ1AgcmVxdWVzdGluZyByb3V0ZXJzIGNhbg0KPmluZGljYXRlIHRoZWlyIHByZWZlcmVu Y2UgdG8gdGhlIERIQ1AgZGVsZWdhdGluZyByb3V0ZXIgYXMgdG8gaG93IHRoZSByZXZlcnNlDQo+ em9uZSBmb3IgYSBkZWxlZ2F0ZWQgcHJlZml4IHNob3VsZCBiZSBoYW5kbGVkLCBhbmQgdG8gcHJv dmlkZSBhIG1lY2hhbmlzbQ0KPndoZXJlYnkgdGhlIGRlbGVnYXRpbmcgcm91dGVyIGNhbiBjb21t dW5pY2F0ZSBiYWNrIHRvIHRoZSByZXF1ZXN0aW5nDQo+cm91dGVyIHRoZSBtZWNoYW5pc20gdGhh dCB3YXMgY2hvc2VuLg0KPg0KPkpvaG4gd2lsbCBiZSBldmFsdWF0aW5nIGNvbnNlbnN1cywgc2lu Y2UgSSdtIHRoZSBhdXRob3Igb2YgdGhlIGRyYWZ0LiAgIEhlIHdpbGwNCj5ldmFsdWF0ZSBjb25z ZW5zdXMgc29tZSB0aW1lIGFmdGVyIE9jdG9iZXIgMi4gICBJZiB5b3UgYXJlIGluIGZhdm9yIG9m DQo+YWRvcHRpbmcgdGhpcyBkcmFmdCwgcGxlYXNlIHNheSBzbyBvbiB0aGUgbWFpbGluZyBsaXN0 LiAgIElmIHlvdSB0aGluayBpdCdzIGEgYmFkDQo+aWRlYSwgcGxlYXNlIHNheSBzbyBvbiB0aGUg bGlzdC4NCj4NCj5UaGFua3MhDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj5kaGN3ZyBtYWlsaW5nIGxpc3QNCj5kaGN3Z0BpZXRmLm9yZw0KPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCg== From ichiroumakino@gmail.com Thu Sep 20 02:49:46 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B8D21F8780 for ; Thu, 20 Sep 2012 02:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQHrKah0IlS0 for ; Thu, 20 Sep 2012 02:49:46 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A3A2621F8773 for ; Thu, 20 Sep 2012 02:49:40 -0700 (PDT) Received: by lboj14 with SMTP id j14so1845828lbo.31 for ; Thu, 20 Sep 2012 02:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=KkWFFU3DVlO+GtFhQtEUlD3IcWYZaUNsAw4ZYGoIiUo=; b=m84wlVhrSW91caQ8XXPwAnPqlBpfymHSh/tbSS2tg0Lnq4AqXwZv8iSS92vJBi8eDJ ITzJEapCdNaZwtUMPvtGMh4FYTmjShQWQXwh0q4DJw2KysmdAAKKi6uZ0nJZU0Mxywa9 Goy+2aSunqFYBhmh/abNSbMKISCWKs4zAHSdGC/ks5UwwWFy9zckDwN4zZuT30brtpaN bsJDdOsmA0FCGApC9ViqLeaxVjK8uCbe43gUQscD1C5Ub33e6Kr2zsqwha2GcXhkojDK rmmj8VtpTxk9v7m/2d1+TmQbVvLqjSbIu5O1UYtlJMiMKerZuJYaCvElGBPgpZbrUjH7 dOjA== Received: by 10.152.131.68 with SMTP id ok4mr1094351lab.47.1348134579560; Thu, 20 Sep 2012 02:49:39 -0700 (PDT) Received: from ?IPv6:2001:700:700:20:71c6:a7ee:65e9:7af5? ([2001:700:700:20:71c6:a7ee:65e9:7af5]) by mx.google.com with ESMTPS id sw5sm1311569lab.14.2012.09.20.02.49.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Sep 2012 02:49:38 -0700 (PDT) Sender: Ole Troan Content-Type: multipart/signed; boundary="Apple-Mail=_A8C87756-20F5-4771-9AAC-E989F4721AF3"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Thu, 20 Sep 2012 11:49:35 +0200 Message-Id: <3F72DAD4-A8BE-48F5-A640-73915189554F@employees.org> References: To: Ted Lemon X-Mailer: Apple Mail (2.1498) Cc: dhc WG Subject: Re: [dhcwg] Call for adoption: draft-lemon-dhc-pd-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 09:49:46 -0000 --Apple-Mail=_A8C87756-20F5-4771-9AAC-E989F4721AF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > I'd like the working group to work on this document. The point of = the document is to provide a mechanism whereby DHCP requesting routers = can indicate their preference to the DHCP delegating router as to how = the reverse zone for a delegated prefix should be handled, and to = provide a mechanism whereby the delegating router can communicate back = to the requesting router the mechanism that was chosen. >=20 > John will be evaluating consensus, since I'm the author of the draft. = He will evaluate consensus some time after October 2. If you are in = favor of adopting this draft, please say so on the mailing list. If = you think it's a bad idea, please say so on the list. I'm in favour of working on the problem. I'm not convinced that the work should be done in DHC though. dnsext? cheers, Ole= --Apple-Mail=_A8C87756-20F5-4771-9AAC-E989F4721AF3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwOTIwMDk0OTM1WjAjBgkqhkiG9w0BCQQxFgQU2AYOZY5l/7W/aB5W igjDFvfhpQ8wggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEADwaw+C5KlRSyhSZX6TsC NhpsPYUosv4jYX/ngI6zekiXbTqaL67Ei8eUrOh690xwcxG0JS/oJCVpjQddCXWJ9I5qXQPCU3gv K4NQR8iJ12c2DpPvkUbFgHZdj13wUrBTNP9hp22mj3Zn4xGevWHImDDBY3V0BetZZ1gKbAnpZnHc HhYlM0+AwgJ6zy9t4N6Of4CHGsF2Yh4vtgv4IUoBR4KfkkdVml6T0W1EaNgR2HD3hNmNGfoWmy6q wz92WNVUEt8wDbvkDamugaYrn9mpy+BkO/gZq9QEzI51wbkWgQvEAqpJTepkfrKZCYbTp+nuRX9N 4QfSZcWw/UmlTx9TUwAAAAAAAA== --Apple-Mail=_A8C87756-20F5-4771-9AAC-E989F4721AF3-- From Ted.Lemon@nominum.com Thu Sep 20 04:52:52 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18A521F84AE for ; Thu, 20 Sep 2012 04:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.402 X-Spam-Level: X-Spam-Status: No, score=-106.402 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1u3blCwBrnk for ; Thu, 20 Sep 2012 04:52:51 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id CFFB421F84A5 for ; Thu, 20 Sep 2012 04:52:50 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUFsDkpos9JAUPkJdoT4sPihDvCanQ+G2@postini.com; Thu, 20 Sep 2012 04:52:50 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D7C9A1B8338 for ; Thu, 20 Sep 2012 04:52:49 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id CDB0819005C; Thu, 20 Sep 2012 04:52:49 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 20 Sep 2012 04:52:49 -0700 From: Ted Lemon To: =?Windows-1252?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] Call for adoption: draft-lemon-dhc-pd-01 Thread-Index: AQHNlrARAq1IuhHT2UasbuE4rMIyj5eTcnSA//+tFsU= Date: Thu, 20 Sep 2012 11:52:49 +0000 Message-ID: References: , <3F72DAD4-A8BE-48F5-A640-73915189554F@employees.org> In-Reply-To: <3F72DAD4-A8BE-48F5-A640-73915189554F@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] Call for adoption: draft-lemon-dhc-pd-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 11:52:52 -0000 On Sep 20, 2012, at 5:49 AM, "Ole Tr=F8an" wrote: > I'm not convinced that the work should be done in DHC though. dnsext?=20 Didn't they disband again? Also, why would they work on a DHCP protocol ex= tension? I fully agree that the draft should be reviewed by a DNS working group=96I = would have suggested DNSOP. = From volz@cisco.com Thu Sep 20 04:59:04 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B45121F87EE for ; Thu, 20 Sep 2012 04:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.411 X-Spam-Level: X-Spam-Status: No, score=-10.411 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwCFJB1YZ8z1 for ; Thu, 20 Sep 2012 04:59:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8B05721F871D for ; Thu, 20 Sep 2012 04:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1284; q=dns/txt; s=iport; t=1348142343; x=1349351943; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=K0DKOwjHfFQCyr9h/BzmoYkmqLLOfZKUXxxxSwStJsg=; b=EFJvnea+uNdxby1D/4i7gRIzZQv1jNpNyGoM7//t69VaKXpF6vPdmLkG FT9qWVsvozLi8bDn0gRUtO2AIna0BioTocojzBKh7pHyEFywLcfgG3Mgc cnjHGuln9QM1AAAIXYIcJ8Y15pRLkU8lvSiQdZdBykutic7F3h5zNDd3o I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAK4DW1CtJXHA/2dsb2JhbABFvROBCIIgAQEBAwEBAQEPAQpRCxACAQhGJwslAgQOBSKHWwYLmXmgBwSLHIVhYAOIIY1DjjiBaYJm X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="123311193" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 20 Sep 2012 11:59:03 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8KBx3qG016301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Sep 2012 11:59:03 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Thu, 20 Sep 2012 06:59:02 -0500 From: "Bernie Volz (volz)" To: =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] Call for adoption: draft-lemon-dhc-pd-01 Thread-Index: AQHNlxU9Vr2+6HvilE6Y9nyy8JztXpeTIHzb Date: Thu, 20 Sep 2012 11:59:02 +0000 Message-ID: <69147484-436D-4A79-AABF-A59F48F83C8B@cisco.com> References: , <3F72DAD4-A8BE-48F5-A640-73915189554F@employees.org> In-Reply-To: <3F72DAD4-A8BE-48F5-A640-73915189554F@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19194.004 x-tm-as-result: No--52.123500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-lemon-dhc-pd-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 11:59:04 -0000 I am in favor of adopting. Not exactly sure of DNSEXT WG as I believe it is trying to shutdown? This work definitely should be reviewed by DNS folks at some point - dnsext= or dnsops? Sent from my iPad On Sep 20, 2012, at 5:49 AM, "Ole Tr=F8an" wrote: >> I'd like the working group to work on this document. The point of the = document is to provide a mechanism whereby DHCP requesting routers can indi= cate their preference to the DHCP delegating router as to how the reverse z= one for a delegated prefix should be handled, and to provide a mechanism wh= ereby the delegating router can communicate back to the requesting router t= he mechanism that was chosen. >>=20 >> John will be evaluating consensus, since I'm the author of the draft. = He will evaluate consensus some time after October 2. If you are in favor= of adopting this draft, please say so on the mailing list. If you think = it's a bad idea, please say so on the list. >=20 > I'm in favour of working on the problem. > I'm not convinced that the work should be done in DHC though. dnsext? >=20 > cheers, > Ole > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Thu Sep 20 05:05:18 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB3A21F8686 for ; Thu, 20 Sep 2012 05:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.57 X-Spam-Level: X-Spam-Status: No, score=-9.57 tagged_above=-999 required=5 tests=[AWL=-0.771, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5292v6Ah9Z6F for ; Thu, 20 Sep 2012 05:05:17 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id AB05421F867E for ; Thu, 20 Sep 2012 05:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3198; q=dns/txt; s=iport; t=1348142717; x=1349352317; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gfafvf+T2x9FG5ED8kkgQpEerl7ZSQUaT2GHgtIlud4=; b=aw0q5l52Wxi1rGJvxAfA+lntlgi5kc5gfOUoRlJpxlJucvDg6eaXUPqh Sey6Es3XqAQh15kt3WhC3aDZeYgzh54uQqfsr/YZdDgHV5RrhM+CqGR+q RkxHWZpPZJlrPFFhNh9L5rnzFFKV+V/QpkfCm+N1DzcxO9pH6zjOgTz1F s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACcFW1CtJV2b/2dsb2JhbABCA70TgQiCIAEBAQMBAQEBDwEnNAsFCwIBCA4KHhAhBgslAgQOBR4Eh08DCQYLmXSWKw2JTwSKOmIUgwmCRGADlA+BVYsXgyGBaYJmgVo X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="123531785" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 20 Sep 2012 12:05:17 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8KC5HCl024251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Sep 2012 12:05:17 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Thu, 20 Sep 2012 07:05:17 -0500 From: "Bernie Volz (volz)" To: Donald Eastlake Thread-Topic: [dhcwg] Load Balancing for DHCPv6 Thread-Index: AQHNlvCUaJ+khP2NkUiXQs2wUqwOeJeTIoPt Date: Thu, 20 Sep 2012 12:05:16 +0000 Message-ID: <1BB5EDFF-BBA9-4335-BE55-058FACEE30EB@cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> <5049C317.7090603@gmail.com> <94FA926F-2432-4AE7-BC20-AE7458AB40D9@cisco.com> <71F17433-B2D9-4366-9B32-F0E4D294EDB5@nominum.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19194.004 x-tm-as-result: No--52.235900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 12:05:18 -0000 Bad test - This is a very limited character set. The data usually used for dhcp is binary data. Sent from my iPad On Sep 20, 2012, at 1:27 AM, "Donald Eastlake" wrote: > Well, I have some more statistics. One my co-authors on the draft > whipped up some code that I then extended. The data hashed consisted > of 2,560,000 strings calculated as follows: > #define RUN 10000 > for(i =3D 0; i < 256*RUN; ++i) > { > sprintf(str, "%08d^^%08d", i, i); > {do hashes, etc} > } >=20 > Each string was hashed with Pearson and with 32-bit FNV-1a. Three > arrays of 256 counters were incremented based on the Pearson hash, > based on the bottom byte of the 32-bit FNV after one 16-bit fold ( > hash2 =3D (hash&0xffff) ^ (hash >> 16) ), and based on the bottom byte > of the 32-bit FNV after an additional 8-bit fold (hash3 =3D (hash2&0xff) > ^ (hash2 >> 8); the equivalent of xor'ing all four bytes together). > The expected number of hits on each bucket with perfect hashing would > be 10,000. Here are the minimum and maximum number of hits and the > standard deviation: >=20 > Pearson: min=3D9678 max=3D19938 std-dev=3D630.72 > FNV-32 1-fold: min=3D9699 max=3D10331 std-dev=3D103.06 > FNV-32 2-folds: min=3D9662 max=3D10247 std-dev=3D90.78 >=20 > So you now have Brian Carpenter's results, showing FNV to be much > better than a variety of other methods, but not Pearson, on fairly > realistic data. And you have these results showing FNV to be much > better than Pearson on somewhat unrealistic data. ... >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com >=20 >=20 > On Fri, Sep 7, 2012 at 6:29 PM, Ted Lemon wrote: >> On Sep 7, 2012, at 5:37 PM, Donald Eastlake wrote: >>> FNV takes a little more effort than Pearson. It also has a smaller >>> footprint in memory. And I believe it will produce statistically >>> better results. What are the relative weights of these or other >>> factors in this case? >>=20 >> Unfortunately, as far as I can tell neither of the studies you cite comp= ares FNV to Pearson, although the results from Brian Carpenter's study are = certainly pretty impressive. I think more work is worse, smaller footpri= nt probably doesn't matter (this algorithm is being run in DHCP servers, wh= ich typically aren't seriously memory-constrained), and statistically bette= r results only matter if it's a pretty big difference, so it's frustrating = that we don't have a comparison to the existing algorithm. >>=20 >> To me, the biggest win of using FNV would be if there were an RFC to ref= er to, but it looks like this is not quite there yet. So my conclusion is= that I certainly don't oppose using FNV instead of Pearson, but I don't se= e a strong reason to support it either. >>=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From internet-drafts@ietf.org Fri Sep 21 03:34:04 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B826A21F8690; Fri, 21 Sep 2012 03:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tz3+FRaxw-he; Fri, 21 Sep 2012 03:34:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA17121F8747; Fri, 21 Sep 2012 03:34:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120921103403.10090.70019.idtracker@ietfa.amsl.com> Date: Fri, 21 Sep 2012 03:34:03 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 10:34:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : Client Link-layer Address Option in DHCPv6 Author(s) : Gaurav Halwasia Shwetha Bhandari Wojciech Dec Filename : draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt Pages : 6 Date : 2012-09-21 Abstract: This document specifies the format and mechanism that is to be used for encoding client link-layer address in DHCPv6 relay forward messages by defining a new DHCPv6 Client Link-layer Address option. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-ad= dr-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt= -02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-client-link-layer-= addr-opt-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ghalwasi@cisco.com Fri Sep 21 04:13:00 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6102B21F8508 for ; Fri, 21 Sep 2012 04:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.179 X-Spam-Level: X-Spam-Status: No, score=-10.179 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuS3XcTRNjpl for ; Fri, 21 Sep 2012 04:12:59 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9258421F842A for ; Fri, 21 Sep 2012 04:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2214; q=dns/txt; s=iport; t=1348225979; x=1349435579; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=D4ejuBh285/UeWLZiBkJfgW+DqxMpEdpCENNXADjvzk=; b=ZjculZ6dESZJz8ps4Ygbn63rArBf7SEM5sKHeArJqEHN3/h+GyWxHr8h Nrr6dxHKu3eHcCkhhgmeYOXalUvdL7dFOyoEglKMiy3443o+gu72lJx9K 7Q+OvWbL+gbEYmk0G99g4VRg7DElSUSt//J6kIOW1uN6iZRbCqmTvyEbZ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFdLXFCtJV2d/2dsb2JhbABFvhCBCIIgAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCQgCBBMIARmHYwuZD6AVixyFRmADlnmNJIFpgmeCFw X-IronPort-AV: E=Sophos;i="4.80,462,1344211200"; d="scan'208";a="123931018" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 21 Sep 2012 11:12:59 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8LBCxRg017158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 21 Sep 2012 11:12:59 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.33]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Fri, 21 Sep 2012 06:12:58 -0500 From: "Gaurav Halwasia (ghalwasi)" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt Thread-Index: AQHNl+S9NIcNYjKE+0GFA4wX5IPS9peUoiDQ Date: Fri, 21 Sep 2012 11:12:57 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB1926050F@xmb-aln-x06.cisco.com> References: <20120921103403.10090.70019.idtracker@ietfa.amsl.com> In-Reply-To: <20120921103403.10090.70019.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.142] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19200.001 x-tm-as-result: No--29.767200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 11:13:00 -0000 Hi DHC WG Members, Thanks for your support/comments on this document. We have published a new = version after taking care of the review comments from the last WGLC. Follow= ing are the main points which are clarified in this document:- 1.) Explicitly mentioned what Relay Agents are going to include in Client L= ink-layer Address option based upon the text suggested by Ted and other WG = members. 2.) Also added some text on the behavior of the DHCPv6 server in case of di= rectly connected clients. Thanks, Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Friday, September 21, 2012 4:04 PM To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-o= pt-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : Client Link-layer Address Option in DHCPv6 Author(s) : Gaurav Halwasia Shwetha Bhandari Wojciech Dec Filename : draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt Pages : 6 Date : 2012-09-21 Abstract: This document specifies the format and mechanism that is to be used for encoding client link-layer address in DHCPv6 relay forward messages by defining a new DHCPv6 Client Link-layer Address option. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-ad= dr-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt= -02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-client-link-layer-= addr-opt-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Fri Sep 21 05:08:51 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4FF21F8634 for ; Fri, 21 Sep 2012 05:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.247 X-Spam-Level: X-Spam-Status: No, score=-106.247 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-hAGmLWeiRz for ; Fri, 21 Sep 2012 05:08:50 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id C038A21F86F3 for ; Fri, 21 Sep 2012 05:08:50 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUFxY0urUC01fsVIvqxHx8Jf10aqx2LCm@postini.com; Fri, 21 Sep 2012 05:08:50 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 89BC91B829B for ; Fri, 21 Sep 2012 05:08:48 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7992E19005C for ; Fri, 21 Sep 2012 05:08:48 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 21 Sep 2012 05:08:42 -0700 From: Ted Lemon To: dhc WG Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt Thread-Index: Ac2X8ddMOw/OIH/tQHCVi0DiBXN4ZA== Date: Fri, 21 Sep 2012 12:08:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 12:08:51 -0000 The authors have sub,tired a new version of this document to address concer= ns raised in the previous WGLC. If you participated in the previous WGLC or= want to participate now, please review the (short) draft and send comments= to the mailing list if you have any. Also please indicate whether you sup= port advancing the draft at this time or not. We will evaluate consensus on October 5. = From linux@thehobsons.co.uk Fri Sep 21 05:20:22 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0DB21F877C for ; Fri, 21 Sep 2012 05:20:22 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nM2SG+W-9ump for ; Fri, 21 Sep 2012 05:20:21 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [IPv6:2001:470:1f09:baa::21]) by ietfa.amsl.com (Postfix) with ESMTP id 935A621F871C for ; Fri, 21 Sep 2012 05:20:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 91B9C29F16 for ; Fri, 21 Sep 2012 13:20:19 +0100 (BST) Received: from patsy.thehobsons.co.uk ([127.0.0.1]) by localhost (patsy.thehobsons.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAf--MQCJwBD for ; Fri, 21 Sep 2012 13:20:19 +0100 (BST) Received: from simon.thehobsons.co.uk (patsy.thehobsons.co.uk [192.168.0.33]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 1088929F0C for ; Fri, 21 Sep 2012 13:20:18 +0100 (BST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20120921103403.10090.70019.idtracker@ietfa.amsl.com> References: <20120921103403.10090.70019.idtracker@ietfa.amsl.com> Date: Fri, 21 Sep 2012 13:20:07 +0100 To: dhcwg@ietf.org From: Simon Hobson Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 12:20:22 -0000 Looks good to me. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From dankney@network1.net Fri Sep 21 05:58:07 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE77221F8705 for ; Fri, 21 Sep 2012 05:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju8OhcRIUypq for ; Fri, 21 Sep 2012 05:58:07 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 66EE521F8661 for ; Fri, 21 Sep 2012 05:58:07 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 9F19D541102; Fri, 21 Sep 2012 08:58:05 -0400 (EDT) Date: Fri, 21 Sep 2012 08:58:05 -0400 (EDT) From: perl-list To: "Gaurav Halwasia (ghalwasi)" Message-ID: <2115445966.222280.1348232285568.JavaMail.root@network1.net> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB1926050F@xmb-aln-x06.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_222279_393156134.1348232285568" X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC21 (Mac)/7.2.0_GA_2669) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 12:58:08 -0000 ------=_Part_222279_393156134.1348232285568 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > 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 : Client Link-layer Address Option in DHCPv6 > Author(s) : Gaurav Halwasia > Shwetha Bhandari > Wojciech Dec > Filename : draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt > Pages : 6 > Date : 2012-09-21 This looks good to me as well... Hoping this hits standard soon so that we will start seeing implementation in relay agents. ------=_Part_222279_393156134.1348232285568 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>

A New Internet-Draft is available from the on-line = Internet-Drafts directories.
 This draft is a work item of the Dyna= mic Host Configuration Working Group of the IETF.

   =      Title           : Cl= ient Link-layer Address Option in DHCPv6
     &= nbsp;  Author(s)       : Gaurav Halwasia
 =                      = ;    Shwetha Bhandari
          =                Wojciech Dec
&nb= sp;       Filename       =  : draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt
 &n= bsp;      Pages         &= nbsp; : 6
        Date   &n= bsp;        : 2012-09-21


This l= ooks good to me as well...  Hoping this hits standard soon so that we = will start seeing implementation in relay agents.
------=_Part_222279_393156134.1348232285568-- From cra@WPI.EDU Fri Sep 21 06:05:08 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D38421F8575 for ; Fri, 21 Sep 2012 06:05:08 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlrIw3e3ZXhK for ; Fri, 21 Sep 2012 06:05:07 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id BBF2B21F8797 for ; Fri, 21 Sep 2012 06:05:06 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q8LD56P7011593 for ; Fri, 21 Sep 2012 09:05:06 -0400 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU q8LD56P7011593 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1348232706; bh=PKaiBvr9bJukdzd3PY2ZWXAuthTWF5JjdiM4BNZwtJA=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=DRJnhGKsnDn8gWHGDElgkdICttKJ/fLzP/2Mf6RS+DVpbaA/1xgS4NXsOnnVNTmtV uK4MjANE9eCBdyM2hQCO3KLz8uGo4HHo/7hDhata5ee2L4jo9wAz22ws5X7qEbQgRq ThprvAJhCxln3jEk1NQhRvcWKpPblOpTTHAQj15U= Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q8LD55vV011590 for ; Fri, 21 Sep 2012 09:05:05 -0400 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id q8LD54DD030110 for ; Fri, 21 Sep 2012 09:05:04 -0400 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (localhost [127.0.0.1]) by angus.ind.WPI.EDU (8.14.4/8.14.4) with ESMTP id q8LD537N021997 for ; Fri, 21 Sep 2012 09:05:03 -0400 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.4/8.14.4/Submit) id q8LD53bY021996 for dhcwg@ietf.org; Fri, 21 Sep 2012 09:05:03 -0400 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Fri, 21 Sep 2012 09:05:03 -0400 From: Chuck Anderson To: dhcwg@ietf.org Message-ID: <20120921130503.GV12327@angus.ind.WPI.EDU> Mail-Followup-To: dhcwg@ietf.org References: <20120921103403.10090.70019.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120921103403.10090.70019.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.20 (2009-12-10) Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:05:08 -0000 > Title : Client Link-layer Address Option in DHCPv6 > Author(s) : Gaurav Halwasia > Shwetha Bhandari > Wojciech Dec > Filename : draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt > Pages : 6 > Date : 2012-09-21 I support advancing this draft as-is. From Ted.Lemon@nominum.com Fri Sep 21 06:09:06 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5E521F8770 for ; Fri, 21 Sep 2012 06:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.538 X-Spam-Level: X-Spam-Status: No, score=-106.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v43PuSwW3MNG for ; Fri, 21 Sep 2012 06:09:05 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 61ECB21F875C for ; Fri, 21 Sep 2012 06:09:05 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUFxm8Iy4R7wb4yZvk3jWFFdr5SIvw/Nv@postini.com; Fri, 21 Sep 2012 06:09:05 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5822E1B829C for ; Fri, 21 Sep 2012 06:09:04 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 4F9A219005C for ; Fri, 21 Sep 2012 06:09:04 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 21 Sep 2012 06:08:59 -0700 From: Ted Lemon To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt Thread-Index: AQHNl/jC9ehl0QSZJUqgys0tLXC5sZeVOeuA Date: Fri, 21 Sep 2012 13:08:58 +0000 Message-ID: References: <2115445966.222280.1348232285568.JavaMail.root@network1.net> In-Reply-To: <2115445966.222280.1348232285568.JavaMail.root@network1.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <793290A302986045B20576AEFBE41F16@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:09:06 -0000 Folks, if you want your responses to be included in the consensus evaluatio= n, please reply to the WGLC message, not to Guarav's message. Otherwise w= hen the time comes in two weeks, your response will be difficult to track d= own and will probably be ignored. From dankney@network1.net Fri Sep 21 06:24:05 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B4321F86F3 for ; Fri, 21 Sep 2012 06:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhDo6IbKL+9j for ; Fri, 21 Sep 2012 06:24:05 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id E3C6321F847B for ; Fri, 21 Sep 2012 06:24:04 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id C24DF541072; Fri, 21 Sep 2012 09:24:03 -0400 (EDT) Date: Fri, 21 Sep 2012 09:24:03 -0400 (EDT) From: perl-list To: Ted Lemon Message-ID: <267824392.222401.1348233843754.JavaMail.root@network1.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_222400_454888416.1348233843753" X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC21 (Mac)/7.2.0_GA_2669) Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:24:06 -0000 ------=_Part_222400_454888416.1348233843753 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I support this draft moving forward. ----- Original Message ----- > From: "Ted Lemon" > To: "dhc WG" > Sent: Friday, September 21, 2012 8:08:41 AM > Subject: [dhcwg] WGLC: > draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt > The authors have sub,tired a new version of this document to address > concerns raised in the previous WGLC. If you participated in the > previous WGLC or want to participate now, please review the (short) > draft and send comments to the mailing list if you have any. Also > please indicate whether you support advancing the draft at this time > or not. > We will evaluate consensus on October 5. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg ------=_Part_222400_454888416.1348233843753 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>I support this draft moving forward.

From: = "Ted Lemon" <Ted.Lemon@nominum.com>
To: "dhc WG" <dh= cwg@ietf.org>
Sent: Friday, September 21, 2012 8:08:41 AM
<= b>Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-o= pt

The authors have sub,tired a new version of this document to addr= ess concerns raised in the previous WGLC. If you participated in the previo= us WGLC or want to participate now, please review the (short) draft and sen= d comments to the mailing list if you have any.  Also please indicate = whether you support advancing the draft at this time or not.

We will= evaluate consensus on October 5.
_____________________________________= __________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/= mailman/listinfo/dhcwg


------=_Part_222400_454888416.1348233843753-- From linux@thehobsons.co.uk Fri Sep 21 06:31:38 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F83F21F8797 for ; Fri, 21 Sep 2012 06:31:38 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp7PnsJpnu-S for ; Fri, 21 Sep 2012 06:31:37 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [IPv6:2001:470:1f09:baa::21]) by ietfa.amsl.com (Postfix) with ESMTP id 7F87121F878B for ; Fri, 21 Sep 2012 06:31:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 1543B29F16; Fri, 21 Sep 2012 14:31:34 +0100 (BST) Received: from patsy.thehobsons.co.uk ([127.0.0.1]) by localhost (patsy.thehobsons.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xERZnnC+UQ0; Fri, 21 Sep 2012 14:31:33 +0100 (BST) Received: from simon.thehobsons.co.uk (patsy.thehobsons.co.uk [192.168.0.33]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 88C9429EFD; Fri, 21 Sep 2012 14:31:33 +0100 (BST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 21 Sep 2012 14:31:21 +0100 To: Ted Lemon , dhc WG From: Simon Hobson Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:31:38 -0000 Looks good to me. Has my support. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From cra@WPI.EDU Fri Sep 21 06:32:35 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D3F21F878B for ; Fri, 21 Sep 2012 06:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehLY39wj9KEF for ; Fri, 21 Sep 2012 06:32:34 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4384821F875C for ; Fri, 21 Sep 2012 06:32:34 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q8LDWXoa004913 for ; Fri, 21 Sep 2012 09:32:33 -0400 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU q8LDWXoa004913 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1348234353; bh=bUTve8IJ/tiWrd1EC1HkSZMHFEwIzMwNhVjYbviR35A=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=uvwO++7QaKclEfUHBRm4eIupHI4DLseVt/KcOD/YIuWP47MbLNO8z+XToJ2X6ekQC twQJwKuEvKpV0hn8l8OiRTW3wZ0Dj+2xKGU/0ByAUyUw/BoJU0NtpPXkZH0uL78hMd GQNS1XpReqSJeJWdT6nmznLkkCCSfOdSg2EIUKkc= Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q8LDWXXL004910 for ; Fri, 21 Sep 2012 09:32:33 -0400 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id q8LDWWLb010561 for ; Fri, 21 Sep 2012 09:32:33 -0400 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (localhost [127.0.0.1]) by angus.ind.WPI.EDU (8.14.4/8.14.4) with ESMTP id q8LDWWb7023538 for ; Fri, 21 Sep 2012 09:32:32 -0400 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.4/8.14.4/Submit) id q8LDWWm2023537 for dhcwg@ietf.org; Fri, 21 Sep 2012 09:32:32 -0400 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Fri, 21 Sep 2012 09:32:32 -0400 From: Chuck Anderson To: dhcwg@ietf.org Message-ID: <20120921133231.GW12327@angus.ind.WPI.EDU> Mail-Followup-To: dhcwg@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:32:35 -0000 On Fri, Sep 21, 2012 at 12:08:41PM +0000, Ted Lemon wrote: > The authors have sub,tired a new version of this document to address concerns raised in the previous WGLC. If you participated in the previous WGLC or want to participate now, please review the (short) draft and send comments to the mailing list if you have any. Also please indicate whether you support advancing the draft at this time or not. > > We will evaluate consensus on October 5. I support moving this draft forward as-is. From budmillwood@gmail.com Fri Sep 21 06:32:58 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD4F21F845C for ; Fri, 21 Sep 2012 06:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISIQHDKBlIKV for ; Fri, 21 Sep 2012 06:32:58 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id C2BF521F87F3 for ; Fri, 21 Sep 2012 06:32:46 -0700 (PDT) Received: by iec9 with SMTP id 9so6192831iec.31 for ; Fri, 21 Sep 2012 06:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nqjoHltghy5pvi19eSPqLolUpsPDvNUi9beExzXib6k=; b=GvElZJ+7LCWIR/5gz2X/UMNWpkws9bt579S/MShbah0tGKdV+aOSeqafjLcdrWsPrL yhhnlYs9on0oN0lqY23Q1yjzYlaGGseCLrtRPWabpPfLah6w9KCJvsS6YTiPD/eCfCvy TzklQDPNpf49pjLJcpuCGJDBZ0hpQQ6TrvU/nNP2hhBdjLBsSXS9Jm3jHLs3nT50Ugj0 U/+5HcKM28Qg/+V5+OW0nWzjLtKkyYMz9eX4KvSQ0bCpqc8QzN4egC2yajgV9Ig02SXV jQ9oTOtz4BX/jXdGpwjjuJd6uIkKec0quaiLFx3I007iIwmO3fNHwiLximzuqQ9+WATY G03A== MIME-Version: 1.0 Received: by 10.50.190.197 with SMTP id gs5mr1658453igc.32.1348234365897; Fri, 21 Sep 2012 06:32:45 -0700 (PDT) Received: by 10.64.35.198 with HTTP; Fri, 21 Sep 2012 06:32:45 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 Sep 2012 15:32:45 +0200 Message-ID: From: Bud Millwood To: Andre Kostur Content-Type: text/plain; charset=ISO-8859-1 Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" , Ted Lemon Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:32:59 -0000 Andre: I think the only reasonable way to move clients back to server A is what you suggest. You are essentially doing the same thing as the failed server A did when it failed - going offline - but you're just doing it administratively, and just for a subset of clients. It causes a degraded performance mode on your network, but you have to balance that against the desire to split the load after server A has come back online. It's not a failover problem so much as it's a load balancing problem. For example, suppose you wanted to change the load balancing split to 70/30 instead of 50/50 on a running network - you'd use the same mechanism. Bernie: > However, it does complicate Request packets because failover doesn't > usually exchange tentative bindings from a Solicit and so you really would > only want the server that Solicited to respond to the Request (this could > be done by looking to see if you had a tentative binding - but if neither > server does, the client has to suffer a Request timeout to get back to the > Solicit phase). Is this a problem because under normal circumstances, the server could allocate a lease on the spot in response to the Request (i.e., without having seen a Solicit)? It seems like a reasonable tradeoff - to disallow a failover partner from short-circuiting the full lease transaction. - Bud On Tue, Sep 18, 2012 at 6:42 PM, Andre Kostur wrote: > On Tue, Sep 18, 2012 at 9:24 AM, Bernie Volz (volz) wrote: >> First, I think this would be a rather bad change to DHCPv6 operation. >> Client may be checking the server-identifier option they get back and so >> you would have to lie about that in the response which just seems like a >> very bad thing to do. (I don't believe RFC 3315 actually ever states the >> clients should be checking the server-identifier, but I could be wrong -- >> section 15 does say they check for the presence of the option, but do not >> check the contents). One could also think of situations where a relay >> agent might forward the packet to explicit destinations based on the >> server identifier (though again, I doubt anyone does this) -- much like >> switches limit traffic based on mac-addresses. > > Note that I didn't suggest that server A preemptively answer the Renew > coming in from the client (or impersonate server B). Under my > suggestion, the Renew would arrive at both servers A and B. B would > ignore it due to load balancing, and A would also ignore it due to the > server ID. The client continues to retry the Renews for the > appropriate time, until it is time to Rebind. At that point server B > is still ignoring the client, but now A can answer the client as the > Rebind isn't carrying a Server ID. (And if we are talking about a > Failover pair, then server A would already have a lease record for > this client, and can extend that same lease.) > > For the relay piece, it would still need to forward the Rebind to both servers. > > [snip] > >> Anyway, I think this needs to be thought through much more carefully as to >> the potential consequences and I think the best is to keep it simple - >> once a client has 'bound' to a server, it stays with that server until it >> issues a request message which does not contain a server-identifier option. > > My scenario doesn't result in a client switching servers except under > already defined RFC 3315 behaviour when the client has transitioned > into Rebind. > > One piece that may have funny consequences is if the pair of DHCP > servers aren't in some sort of cooperation mode, and this scenario > would result in the client possibly changing IP addresses. Client has > to rebind, and server A does the DHCPv6 equivalent of a NAK and forces > the client to come back to get a new IP. Perhaps a server MAY skip > the load balancing if the packet contains a Server ID (or even > limiting it to the server's Server ID)? > > -- > Andre Kostur > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From farmer@umn.edu Fri Sep 21 06:54:03 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC6A21F8839 for ; Fri, 21 Sep 2012 06:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQx23RgGoph2 for ; Fri, 21 Sep 2012 06:54:03 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 8385521F8838 for ; Fri, 21 Sep 2012 06:53:56 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 21 Sep 2012 08:52:06 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ie0-f172.google.com [209.85.223.172] #+LO+TR X-Umn-Classification: local Received: by iec9 with SMTP id 9so6245402iec.31 for ; Fri, 21 Sep 2012 06:51:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=1nhpPGwwATThM+EKHhpTQTAnX8az4H3frWen+nJvBO8=; b=YsXSfVeI3lMU8pWfPOFJ5TdSL1ojNzzRC3s3Zc0dJAbppuP7nxY8IjVQZrFgxDGfV4 GtqkR00ymxY9wS90pfvROEmTGjMKgmfNy6Zoytvp/n+lzaJsUrazI5PWwi54p26Gi+pf hx/5UfnJ0n1OdM8Hl4tz3V6kwuUbUZDlSdHuUMbbbF0Q3ygcKyjl1piOyTQV4gPMSlaG +R2Sxey4n74xGI+j2OPMn4axMnTRgnNm2BAetHMty6Xx7+0cji/eIsdYUYyP6hiZVcCb ar+pJfXpwzi/aOAGjF1O/s4Nd98AbR7XNnSRO2NitbeqK7YytRunRoDy40zzIZTYedYV ahMA== Received: by 10.50.186.169 with SMTP id fl9mr1752616igc.9.1348235501666; Fri, 21 Sep 2012 06:51:41 -0700 (PDT) Received: from oit200959392.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPS id nh1sm17268977igc.11.2012.09.21.06.51.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Sep 2012 06:51:40 -0700 (PDT) Message-ID: <505C70EC.4030501@umn.edu> Date: Fri, 21 Sep 2012 08:51:40 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Ted Lemon References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl7RN/tkqrb+vDkw6x6ke8KnV53xIx9yX0pLBXwXkYPyCbThXGDZzfmlhP9Ff9agAAoD3ks Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:54:03 -0000 On 9/21/12 07:08 CDT, Ted Lemon wrote: > The authors have sub,tired a new version of this document to address concerns raised in the previous WGLC. If you participated in the previous WGLC or want to participate now, please review the (short) draft and send comments to the mailing list if you have any. Also please indicate whether you support advancing the draft at this time or not. I support this draft as-is and hope it is expeditiously moved forward both within the IETF and for implementation by vendors of both DHCPv6 Relay Agents and Servers. This issue is holding back broader deployment of IPv6, especially in enterprise environments, where MAC address tracking is a very common part of network security and management practice. This will align DHCPv6 with such practices and hopefully remove one more road block in the way of deployment of IPv6 in many environments. Thanks -- =============================================== David Farmer Email:farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From budmillwood@gmail.com Fri Sep 21 06:55:26 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843FD21F883E; Fri, 21 Sep 2012 06:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-et3JdmsbWf; Fri, 21 Sep 2012 06:55:26 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF96821F883D; Fri, 21 Sep 2012 06:55:25 -0700 (PDT) Received: by iec9 with SMTP id 9so6255780iec.31 for ; Fri, 21 Sep 2012 06:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7/kw381BJxlvqNRJo+4FeJhpbGctWm6/YlHhGPLJ/PY=; b=035oT5YT429v/stTuCPI/BXbLwOGBNng+NzzMPU7c4bjpb1xqti8vBiV5sM5m1E2t2 V5qa8lHGgYlnJoe8mWj7YlUFKb3n6qAjyN2V0mVU5n5Ivlu6a59EwmwDEIHhqYhlnCZ2 xOhLQmF75CWq5cPQBJHrZzLmKCFtFwj8Rl17a8jeieu8FVlqf0nDn+ZVhvvJ7ws3cgn6 ok+uNjNN+mUbPWmxSnMnxfxqk6PEFKYz9xGT+ZlHiE/RDgKPTF4BTQzx3oG8clZXzciC IBbm+NK39LrqVZ/M7I++omY5CoQEhqqVYmw5+LWeobddz9KmwgKvdX/NnyaKg0lMA+b3 DwDw== MIME-Version: 1.0 Received: by 10.50.180.169 with SMTP id dp9mr1719618igc.8.1348235725332; Fri, 21 Sep 2012 06:55:25 -0700 (PDT) Sender: budmillwood@gmail.com Received: by 10.64.35.198 with HTTP; Fri, 21 Sep 2012 06:55:25 -0700 (PDT) In-Reply-To: <20120921103403.10090.70019.idtracker@ietfa.amsl.com> References: <20120921103403.10090.70019.idtracker@ietfa.amsl.com> Date: Fri, 21 Sep 2012 15:55:25 +0200 X-Google-Sender-Auth: y9mbDxDrFC_FBEfyKy-FDivS6a8 Message-ID: From: Bud Millwood To: internet-drafts@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: dhcwg@ietf.org, i-d-announce@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:55:26 -0000 5. DHCPv6 Server Behavior > If DHCPv6 Server is configured to store or use client link-layer address, it SHOULD look for the client link-layer address option in the RELAY-FORW DHCP message of the DHCPv6 Relay agent closest to the client. Although I understand what "closest to the client" means (I use that term myself), is that the correct terminology? It could also be referred to as the inner-most RELAY-FORW message, or the first RELAY-FORW message. Is there even a standard terminology for this? I just glanced through 3315 and don't see anything. Also, the server "SHOULD" look for the link-layer address in the closest RELAY-FORW message. What are the ramifications of changing this to MUST? Is there any scenario where a second-hop relay would know the link-layer address, but the first hop wouldn't know it or support this RFC? Do we gain anything by enforcing that a conveyed link-layer address is only valid or to be trusted if it's from the first-hop relay? - Bud On Fri, Sep 21, 2012 at 12:34 PM, wrote: > > 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 : Client Link-layer Address Option in DHCPv6 > Author(s) : Gaurav Halwasia > Shwetha Bhandari > Wojciech Dec > Filename : draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt > Pages : 6 > Date : 2012-09-21 > > Abstract: > This document specifies the format and mechanism that is to be used > for encoding client link-layer address in DHCPv6 relay forward > messages by defining a new DHCPv6 Client Link-layer Address option. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From tjc@ecs.soton.ac.uk Fri Sep 21 07:00:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF9821F85F7 for ; Fri, 21 Sep 2012 07:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXH-J3t0Lv63 for ; Fri, 21 Sep 2012 07:00:00 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9A521F8564 for ; Fri, 21 Sep 2012 06:59:59 -0700 (PDT) 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 q8LDxsat027707 for ; Fri, 21 Sep 2012 14:59:54 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q8LDxsat027707 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1348235994; bh=D4TZq+iLAVqIh/8bKy354ZHsBqc=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=CtxzOlZgXErL9jWtmli51gVklpROquKrOZJjkW8E1OVhQ7/652/DZjQ68bADoNiAI Xs1i/R1gTrDruLKCDOUEJ4Ywx6AjB+oUxgVehAsCbSDO9xwfMpXw7hhHWCNG5TkdsQ ARV2o65HhQrZkNV3CPRo5Q8LW+q1tpsoMjgAPZ+E= 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 (valid=N/A) id o8KExs0430631357bA ret-id none; Fri, 21 Sep 2012 14:59:54 +0100 Received: from ip-204-019.eduroam.soton.ac.uk (ip-204-019.eduroam.soton.ac.uk [152.78.204.19]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q8LDxqqN000440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 21 Sep 2012 14:59:53 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Tim Chown In-Reply-To: Date: Fri, 21 Sep 2012 14:59:52 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5A94443D-DF8E-4AA3-888B-96AC97E45D23@ecs.soton.ac.uk> To: dhc WG X-Mailer: Apple Mail (2.1486) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o8KExs043063135700; tid=o8KExs0430631357bA; 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: q8LDxsat027707 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 14:00:01 -0000 Hi, This also has my support. It would be something we would use in our = deployment. A little nit though... =20 The text says: "Similarly DHCPv6 Relay or Server cannot glean client link-layer address = from the contents of DHCPv6 message received." and then later in Section 5 the text that's been added in the latest = version says: "This specification does not specify the mechanism for DHCPv6 Server to = find out link-layer address of the directly connected clients as a DHCP = option as it can obtain it directly from the received message." This seems a bit contradictory - should the first text say "Similarly = DHCPv6 Relay or DHCPv6 Server receiving a relayed message cannot = glean"...? Tim On 21 Sep 2012, at 14:31, Simon Hobson wrote: > Looks good to me. Has my support. >=20 > --=20 > Simon Hobson >=20 > Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed > author Gladys Hobson. Novels - poetry - short stories - ideal as > Christmas stocking fillers. Some available as e-books. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From ghalwasi@cisco.com Fri Sep 21 07:16:53 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8221721F885C for ; Fri, 21 Sep 2012 07:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.08 X-Spam-Level: X-Spam-Status: No, score=-10.08 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BM1fNLTAhRBm for ; Fri, 21 Sep 2012 07:16:53 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E174621F8849 for ; Fri, 21 Sep 2012 07:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2075; q=dns/txt; s=iport; t=1348237013; x=1349446613; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=BIpARngfM27V63P0uzyiWyTvsT2KwiYH9a6aI1uXp84=; b=HvqgDzNoKOlsK/oVelofess+Bah/S6kKujfkYumCmwU4BdL/7zIqd6Xi Xl6su0FSQG0bGt3E3Adz52ZVNatNiNnqsV7ZCAk5eWGsEzt5v3wRwGy5K ZM18oWj0eCnMtoxTF9aNla31a63fEkS24hXxYAn2khyZ3xrqb71onRt2X 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGl2XFCtJXG9/2dsb2JhbABFDr4DgQiCIAEBAQMBAQEBDwEnNBAHBAIBCA4DBAEBCxQJBycLFAkIAQEEARIIGoddBguZMaARixyFRmADpB2BaYIsO4IX X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="123964187" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 21 Sep 2012 14:16:42 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8LEGg2W023013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Sep 2012 14:16:42 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.33]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Fri, 21 Sep 2012 09:16:41 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Tim Chown , dhc WG Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt Thread-Index: Ac2X8ddMOw/OIH/tQHCVi0DiBXN4ZAANXS2AAAD+9gAACmhikA== Date: Fri, 21 Sep 2012 14:16:41 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB1926098B@xmb-aln-x06.cisco.com> References: <5A94443D-DF8E-4AA3-888B-96AC97E45D23@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.105.209] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19200.001 x-tm-as-result: No--41.511100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 14:16:53 -0000 Hi Tim, Thanks for supporting the document. I think the first text which you referred is mentioned in the "Problem Stat= ement" where in we really don't have a way to find out the link-layer addre= ss form the "DHCPv6 message header/options."=20 Whereas the next text (section 5) is talking about server extracting it fro= m DHCPv6 message L2 header. Not from the DHCPv6 message/options. Please let me know if you still find it confusing. Thanks, Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= im Chown Sent: Friday, September 21, 2012 7:30 PM To: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt Hi, This also has my support. It would be something we would use in our deploy= ment. A little nit though... =20 The text says: "Similarly DHCPv6 Relay or Server cannot glean client link-layer address fr= om the contents of DHCPv6 message received." and then later in Section 5 the text that's been added in the latest versio= n says: "This specification does not specify the mechanism for DHCPv6 Server to fin= d out link-layer address of the directly connected clients as a DHCP option= as it can obtain it directly from the received message." This seems a bit contradictory - should the first text say "Similarly DHCPv= 6 Relay or DHCPv6 Server receiving a relayed message cannot glean"...? Tim On 21 Sep 2012, at 14:31, Simon Hobson wrote: > Looks good to me. Has my support. >=20 > -- > Simon Hobson >=20 > Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed=20 > author Gladys Hobson. Novels - poetry - short stories - ideal as=20 > Christmas stocking fillers. Some available as e-books. > _______________________________________________ > 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 tjc@ecs.soton.ac.uk Fri Sep 21 07:21:59 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3E221F884E for ; Fri, 21 Sep 2012 07:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQ77DV3tjpjY for ; Fri, 21 Sep 2012 07:21:58 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id BC58821F8819 for ; Fri, 21 Sep 2012 07:21:55 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q8LELmIC000577 for ; Fri, 21 Sep 2012 15:21:52 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q8LELmIC000577 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1348237312; bh=PTPDIRRay/hJVqn2uksKeQmZtAI=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=C96XUATkJv7SOpARXDeO/ekpcTcwhc3hetmnWx4m02cbchavB7fbjcyTWFe6EYWfW xb1BvVkCZUGGwaBqGGHst/HAQDu/3iDtyz/GAQv3wzWasWwEzLIxDYopU2ap9vI5mo F1YY86DmAzNPtKqjsbnRHZgujIzNDQsnKlfYm99I= 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 (valid=N/A) id o8KFLm0430631549dE ret-id none; Fri, 21 Sep 2012 15:21:52 +0100 Received: from ip-204-019.eduroam.soton.ac.uk (ip-204-019.eduroam.soton.ac.uk [152.78.204.19]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q8LELjvV007019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 21 Sep 2012 15:21:46 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Tim Chown In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB1926098B@xmb-aln-x06.cisco.com> Date: Fri, 21 Sep 2012 15:21:45 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5A94443D-DF8E-4AA3-888B-96AC97E45D23@ecs.soton.ac.uk> <90903C21C73202418A48BFBE80AEE5EB1926098B@xmb-aln-x06.cisco.com> To: dhc WG X-Mailer: Apple Mail (2.1486) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o8KFLm043063154900; tid=o8KFLm0430631549dE; 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: q8LELmIC000577 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 14:21:59 -0000 OK, perhaps clarify that then.... "as it can obtain it directly from = the L2 header of the received DHCP message" ? Tim On 21 Sep 2012, at 15:16, "Gaurav Halwasia (ghalwasi)" = wrote: > Hi Tim, >=20 > Thanks for supporting the document. >=20 > I think the first text which you referred is mentioned in the "Problem = Statement" where in we really don't have a way to find out the = link-layer address form the "DHCPv6 message header/options."=20 >=20 > Whereas the next text (section 5) is talking about server extracting = it from DHCPv6 message L2 header. Not from the DHCPv6 message/options. >=20 > Please let me know if you still find it confusing. >=20 > Thanks, > Gaurav >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Tim Chown > Sent: Friday, September 21, 2012 7:30 PM > To: dhc WG > Subject: Re: [dhcwg] WGLC: = draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt >=20 > Hi, >=20 > This also has my support. It would be something we would use in our = deployment. >=20 > A little nit though... =20 >=20 > The text says: > "Similarly DHCPv6 Relay or Server cannot glean client link-layer = address from the contents of DHCPv6 message received." >=20 >=20 > and then later in Section 5 the text that's been added in the latest = version says: > "This specification does not specify the mechanism for DHCPv6 Server = to find out link-layer address of the directly connected clients as a = DHCP option as it can obtain it directly from the received message." >=20 > This seems a bit contradictory - should the first text say "Similarly = DHCPv6 Relay or DHCPv6 Server receiving a relayed message cannot = glean"...? >=20 > Tim >=20 > On 21 Sep 2012, at 14:31, Simon Hobson wrote: >=20 >> Looks good to me. Has my support. >>=20 >> -- >> Simon Hobson >>=20 >> Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed=20= >> author Gladys Hobson. Novels - poetry - short stories - ideal as=20 >> Christmas stocking fillers. Some available as e-books. >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From ghalwasi@cisco.com Fri Sep 21 07:28:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D36021F8688 for ; Fri, 21 Sep 2012 07:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.239 X-Spam-Level: X-Spam-Status: No, score=-10.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDxy2pY1uamn for ; Fri, 21 Sep 2012 07:28:00 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B65D321F85F7 for ; Fri, 21 Sep 2012 07:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3168; q=dns/txt; s=iport; t=1348237680; x=1349447280; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=0yYEEbPqvgd1sq3KoPRWiUj36lPbwPPHti5pNzCh6bo=; b=QgTSp0IpP1nM7M8PD2mjADA6fLzPUr1/TSbO6XuiqEGs7OYIc2DhcP3a y5I0092ERe8MdX2MbP4OIIVxSymIHQulTje2ejOzT+JVdZJ5tK9N9rOks EyOe1IojxVx1FTXrGSpd9QPhdihdKV0+pQKqnuC++mG3jJnKyNdDaaPXb Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJ14XFCtJXG9/2dsb2JhbABFDr4DgQiCIAEBAQMBAQEBDwEnNBAHBAIBCA4DBAEBAQoUCQcnCxQJCAEBBAESCBqHXQYLmTCgFYschUZgA6QdgWmCLDuCFw X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="123986411" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 21 Sep 2012 14:27:59 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8LERx5e030587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Sep 2012 14:27:59 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.33]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Fri, 21 Sep 2012 09:27:59 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Tim Chown , dhc WG Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt Thread-Index: Ac2X8ddMOw/OIH/tQHCVi0DiBXN4ZAANXS2AAAD+9gAACmhikP//stqAgABTGtA= Date: Fri, 21 Sep 2012 14:27:58 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB192609EE@xmb-aln-x06.cisco.com> References: <5A94443D-DF8E-4AA3-888B-96AC97E45D23@ecs.soton.ac.uk> <90903C21C73202418A48BFBE80AEE5EB1926098B@xmb-aln-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.105.209] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19200.001 x-tm-as-result: No--47.472200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 14:28:01 -0000 Tim, Sure, perhaps, I could change the present text to the following:- "This specification does not specify the mechanism for DHCPv6 Server to fin= d out link-layer address of the directly connected clients as a DHCP option= as it can obtain it directly from the link-layer source address of the rec= eived DHCPv6 message" Thanks, Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= im Chown Sent: Friday, September 21, 2012 7:52 PM To: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt OK, perhaps clarify that then.... "as it can obtain it directly from the L= 2 header of the received DHCP message" ? Tim On 21 Sep 2012, at 15:16, "Gaurav Halwasia (ghalwasi)" = wrote: > Hi Tim, >=20 > Thanks for supporting the document. >=20 > I think the first text which you referred is mentioned in the "Problem St= atement" where in we really don't have a way to find out the link-layer add= ress form the "DHCPv6 message header/options."=20 >=20 > Whereas the next text (section 5) is talking about server extracting it f= rom DHCPv6 message L2 header. Not from the DHCPv6 message/options. >=20 > Please let me know if you still find it confusing. >=20 > Thanks, > Gaurav >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf=20 > Of Tim Chown > Sent: Friday, September 21, 2012 7:30 PM > To: dhc WG > Subject: Re: [dhcwg] WGLC:=20 > draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt >=20 > Hi, >=20 > This also has my support. It would be something we would use in our depl= oyment. >=20 > A little nit though... =20 >=20 > The text says: > "Similarly DHCPv6 Relay or Server cannot glean client link-layer address = from the contents of DHCPv6 message received." >=20 >=20 > and then later in Section 5 the text that's been added in the latest vers= ion says: > "This specification does not specify the mechanism for DHCPv6 Server to f= ind out link-layer address of the directly connected clients as a DHCP opti= on as it can obtain it directly from the received message." >=20 > This seems a bit contradictory - should the first text say "Similarly DHC= Pv6 Relay or DHCPv6 Server receiving a relayed message cannot glean"...? >=20 > Tim >=20 > On 21 Sep 2012, at 14:31, Simon Hobson wrote: >=20 >> Looks good to me. Has my support. >>=20 >> -- >> Simon Hobson >>=20 >> Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed=20 >> author Gladys Hobson. Novels - poetry - short stories - ideal as=20 >> Christmas stocking fillers. Some available as e-books. >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > 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 ghalwasi@cisco.com Fri Sep 21 07:35:12 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21A721F8714; Fri, 21 Sep 2012 07:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.284 X-Spam-Level: X-Spam-Status: No, score=-10.284 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGse7vguOG13; Fri, 21 Sep 2012 07:35:12 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id EDE2821F870B; Fri, 21 Sep 2012 07:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1332; q=dns/txt; s=iport; t=1348238112; x=1349447712; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tlH8j68zHD8gZyAlZVvVCDesJEdFDPrxqFq5hjA29Dw=; b=GmfRnXRlaqoOY/KL2zy68C5pXQ24UehalE2KFiw11sSO+CqeOmjrQsoG lAeLLIKdjBmsiNl+bpQzb3db3DEGp4mUHHldlml0WxGfn6P00V57x0yAv +nDx0n3RGw8+E1sPcRCOMYKiIDCezXes4IhR0c60+twOzdPfVCNmnJOFK s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAB16XFCtJXG//2dsb2JhbABFvhGBCIIgAQEBAwESAScyCgMFCwIBCCIUEDIlAgQBDQ0ah10GmTSgFZBiYAOkHYFpgmeCFw X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="123998611" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 21 Sep 2012 14:35:11 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8LEZBk2005522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Sep 2012 14:35:11 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.33]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Fri, 21 Sep 2012 09:35:11 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Bud Millwood , "internet-drafts@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt Thread-Index: AQHNl+S9NIcNYjKE+0GFA4wX5IPS9peVJYeA//+zSwA= Date: Fri, 21 Sep 2012 14:35:10 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB19260A21@xmb-aln-x06.cisco.com> References: <20120921103403.10090.70019.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.105.209] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19200.001 x-tm-as-result: No--28.613200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 14:35:13 -0000 Hi Bud, > If DHCPv6 Server is configured to store or use client link-layer address,= it SHOULD look for the client link-layer address option in the RELAY-FORW = DHCP message of the DHCPv6 Relay agent closest to the client. >Although I understand what "closest to the client" means (I use that term = myself), is that the correct terminology? It could also be referred to as t= he inner-most RELAY-FORW message, or the first RELAY-FORW message. Is there= even a standard terminology for this? I just glanced through 3315 and don'= t see anything. [Gaurav] We could change that to "inner-most RELAY-FORW". >Also, the server "SHOULD" look for the link-layer address in the closest R= ELAY-FORW message. What are the ramifications of changing this to MUST? Is = there any scenario where a second-hop relay would know the link-layer addre= ss, but the first hop wouldn't know it or support this RFC? Do we gain anyt= hing by enforcing that a conveyed link-layer address is only valid or to be= trusted if it's from the first-hop relay? [Gaurav] Well the purpose of this spec is to enforce relay agent to add cli= ent link-layer address option in the relay forward message. Whereas we don'= t really want to enforce anything on the server on how it should extract/us= e this option.=20 Thanks, Gaurav From volz@cisco.com Fri Sep 21 07:37:19 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4396621F86FD for ; Fri, 21 Sep 2012 07:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13FeEcLRAPpG for ; Fri, 21 Sep 2012 07:36:58 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1606D21F845D for ; Fri, 21 Sep 2012 07:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6193; q=dns/txt; s=iport; t=1348238218; x=1349447818; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0dUcIiDp8YTTE7EGNURZn6fasVX6K54R9GQd7eTdRtU=; b=eEu1CXKzXfYNlXpJzOfgOE7RUzKWvJDVa5vDAWFJ9bXPkPEtWaOG5UdL qOX/DbgD2okQivk5rXLwHSlntqmrHEl+qWb94HDCtEfFfa2hKnw7KYGWl IrRdVBg+I61yvlETMk99tBCDFHqJpQAMXYuYogfv4P9xpfAv4ORpLrnj3 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKN6XFCtJV2c/2dsb2JhbABFvhGBCIIgAQEBAwEBAQELBAEnKwkDCAUHBAIBCBEEAQEBChQJByEGCxQJCAIEAQ0FCBqHUQMJBguZKpY1DYlPBIo6YhQBhTFgA5QPjG2DIYFpgmeBWgE8 X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="124031491" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 21 Sep 2012 14:36:57 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8LEavnB023000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Sep 2012 14:36:57 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Fri, 21 Sep 2012 09:36:57 -0500 From: "Bernie Volz (volz)" To: Bud Millwood , Andre Kostur Thread-Topic: [dhcwg] Load Balancing for DHCPv6 Thread-Index: AQHNl/2VaJ+khP2NkUiXQs2wUqwOeJeU1mtw Date: Fri, 21 Sep 2012 14:36:56 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F50321D@xmb-rcd-x04.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.250.189] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19200.001 x-tm-as-result: No--59.264900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 14:37:19 -0000 Bud: > the server could allocate a lease on the spot in response to the Request = (i.e., without having seen a Solicit)? Correct. As this address (or prefix) is likely in other-available, the server would = not be able to assign it. But with DHCPv6, it can provide an alternative --= it is the Reply that matters (this is one difference over DHCPv4 where the= server would be forced to NAK - or just drop the packet). --- However, Andre's proposal would be that if the server-duid matches but load= balancing says that this is not the server that should be responding, to d= rop the request. This would thus force the client to return to Solicit (whe= n the Requesting times out) or to advance to Rebind (when renewing between = T1 and T2). This would work to move the client to the "correct" server but = it does increase the traffic and load for those packets that are dropped. This would generally only impact Request and Renew packets. I would think t= hat the server should always process Release and Decline since those are li= mited in their retransmissions (and the client fallback is to stop sending)= . So, I think when both failover partners are responsive the load balancing p= rocessing would be: - If server-duid not represent in request (Solicit, Rebind, Confirm, Inform= ation-Request), use load balancing to determine if server responds. - If server-duid present and doesn't match this server, drop packet (standa= rd RFC 3315). - (server-duid present and matches server), if Request or Renew still use l= oad balancing to determine if server responds. - Otherwise respond to client. - Bernie -----Original Message----- From: Bud Millwood [mailto:budmillwood@gmail.com]=20 Sent: Friday, September 21, 2012 9:33 AM To: Andre Kostur Cc: Bernie Volz (volz); dhcwg@ietf.org; Ted Lemon Subject: Re: [dhcwg] Load Balancing for DHCPv6 Andre: I think the only reasonable way to move clients back to server A is what yo= u suggest. You are essentially doing the same thing as the failed server A = did when it failed - going offline - but you're just doing it administrativ= ely, and just for a subset of clients. It causes a degraded performance mod= e on your network, but you have to balance that against the desire to split= the load after server A has come back online. It's not a failover problem so much as it's a load balancing problem. For example, suppose you wanted to change the load balancing split to 70/30 instead of 50/50 on a running network - you'd use the same mechanism. Bernie: > However, it does complicate Request packets because failover doesn't=20 > usually exchange tentative bindings from a Solicit and so you really=20 > would only want the server that Solicited to respond to the Request=20 > (this could be done by looking to see if you had a tentative binding -=20 > but if neither server does, the client has to suffer a Request timeout=20 > to get back to the Solicit phase). Is this a problem because under normal circumstances, the server could allo= cate a lease on the spot in response to the Request (i.e., without having s= een a Solicit)? It seems like a reasonable tradeoff - to disallow a failove= r partner from short-circuiting the full lease transaction. - Bud On Tue, Sep 18, 2012 at 6:42 PM, Andre Kostur wrote= : > On Tue, Sep 18, 2012 at 9:24 AM, Bernie Volz (volz) wrot= e: >> First, I think this would be a rather bad change to DHCPv6 operation. >> Client may be checking the server-identifier option they get back and=20 >> so you would have to lie about that in the response which just seems=20 >> like a very bad thing to do. (I don't believe RFC 3315 actually ever=20 >> states the clients should be checking the server-identifier, but I=20 >> could be wrong -- section 15 does say they check for the presence of=20 >> the option, but do not check the contents). One could also think of=20 >> situations where a relay agent might forward the packet to explicit=20 >> destinations based on the server identifier (though again, I doubt=20 >> anyone does this) -- much like switches limit traffic based on mac-addre= sses. > > Note that I didn't suggest that server A preemptively answer the Renew=20 > coming in from the client (or impersonate server B). Under my=20 > suggestion, the Renew would arrive at both servers A and B. B would=20 > ignore it due to load balancing, and A would also ignore it due to the=20 > server ID. The client continues to retry the Renews for the=20 > appropriate time, until it is time to Rebind. At that point server B=20 > is still ignoring the client, but now A can answer the client as the=20 > Rebind isn't carrying a Server ID. (And if we are talking about a=20 > Failover pair, then server A would already have a lease record for=20 > this client, and can extend that same lease.) > > For the relay piece, it would still need to forward the Rebind to both se= rvers. > > [snip] > >> Anyway, I think this needs to be thought through much more carefully=20 >> as to the potential consequences and I think the best is to keep it=20 >> simple - once a client has 'bound' to a server, it stays with that=20 >> server until it issues a request message which does not contain a server= -identifier option. > > My scenario doesn't result in a client switching servers except under=20 > already defined RFC 3315 behaviour when the client has transitioned=20 > into Rebind. > > One piece that may have funny consequences is if the pair of DHCP=20 > servers aren't in some sort of cooperation mode, and this scenario=20 > would result in the client possibly changing IP addresses. Client has=20 > to rebind, and server A does the DHCPv6 equivalent of a NAK and forces > the client to come back to get a new IP. Perhaps a server MAY skip > the load balancing if the packet contains a Server ID (or even=20 > limiting it to the server's Server ID)? > > -- > Andre Kostur > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Fri Sep 21 07:46:40 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B46C21F8787; Fri, 21 Sep 2012 07:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBBoL7tCE0m9; Fri, 21 Sep 2012 07:46:39 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 61BE421F8573; Fri, 21 Sep 2012 07:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3774; q=dns/txt; s=iport; t=1348238799; x=1349448399; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=s9Y92aJHgGvsX7nzY6bnQyKqUCdQgBpl3rx6rvyFccQ=; b=SBKVbLl6ODfoz/ayjOdH8YLukVweve8j3mokIfR11pG22L7UVp2MYsKs rYZ+EQBOy0Km10N+B/CnSiAXki6Wq0jmWryd10OqxL23JQFU1PHpkGXN2 TgKZR66MH6qSGDnk7p4MvqKv4mL1NjtWy4U0HTrtQHup31L1l2Szhd9LW 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEp9XFCtJV2d/2dsb2JhbABFvhGBCIIgAQEBAwEBAQEPAScyAggDBQcEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQgBGYddBguZJaAXixyFRmADlnmNJIFpgmeCFw X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="124027347" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 21 Sep 2012 14:46:39 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8LEkcS0015561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Sep 2012 14:46:38 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Fri, 21 Sep 2012 09:46:38 -0500 From: "Bernie Volz (volz)" To: Bud Millwood , "internet-drafts@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt Thread-Index: AQHNmADDJHF2/BOLqUmBR8gLtdibXJeU3W/Q Date: Fri, 21 Sep 2012 14:46:38 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F503257@xmb-rcd-x04.cisco.com> References: <20120921103403.10090.70019.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.250.189] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19200.001 x-tm-as-result: No--36.440800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 14:46:40 -0000 I do like "inner-most Relay-Forw" (i.e. the relay that received the client'= s packet [msg-type !=3D Relay-Forw]). While in theory a MUST is probably correct, there might be cases where that= doesn't work? So, I would lean towards SHOULD to potentially support cases= where there might be a second (the next) relay that has this information [= and the first does not]? Certainly the MUST is correct for traditional appl= ications (i.e. corporate Ethernet based networks or CableLabs DOCSIS). I can't give you a specific example, but perhaps there are some from networ= ks that don't support multicast or where a relay proxy is needed on the dev= ice itself (as then you'd have the client providing this information)? - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ud Millwood Sent: Friday, September 21, 2012 9:55 AM To: internet-drafts@ietf.org Cc: dhcwg@ietf.org; i-d-announce@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-ad= dr-opt-02.txt 5. DHCPv6 Server Behavior > If DHCPv6 Server is configured to store or use client link-layer address,= it SHOULD look for the client link-layer address option in the RELAY-FORW = DHCP message of the DHCPv6 Relay agent closest to the client. Although I understand what "closest to the client" means (I use that term m= yself), is that the correct terminology? It could also be referred to as th= e inner-most RELAY-FORW message, or the first RELAY-FORW message. Is there = even a standard terminology for this? I just glanced through 3315 and don't= see anything. Also, the server "SHOULD" look for the link-layer address in the closest RE= LAY-FORW message. What are the ramifications of changing this to MUST? Is t= here any scenario where a second-hop relay would know the link-layer addres= s, but the first hop wouldn't know it or support this RFC? Do we gain anyth= ing by enforcing that a conveyed link-layer address is only valid or to be = trusted if it's from the first-hop relay? - Bud On Fri, Sep 21, 2012 at 12:34 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Dynamic Host Configuration Working Grou= p of the IETF. > > Title : Client Link-layer Address Option in DHCPv6 > Author(s) : Gaurav Halwasia > Shwetha Bhandari > Wojciech Dec > Filename : draft-ietf-dhc-dhcpv6-client-link-layer-addr-op= t-02.txt > Pages : 6 > Date : 2012-09-21 > > Abstract: > This document specifies the format and mechanism that is to be used > for encoding client link-layer address in DHCPv6 relay forward > messages by defining a new DHCPv6 Client Link-layer Address option. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-lay > er-addr-opt > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-add > r-opt-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-client-link-lay > er-addr-opt-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 akostur@incognito.com Fri Sep 21 07:52:59 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A239621F8319 for ; Fri, 21 Sep 2012 07:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KY4ALcKJgbYC for ; Fri, 21 Sep 2012 07:52:47 -0700 (PDT) Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by ietfa.amsl.com (Postfix) with SMTP id E6E2221F8797 for ; Fri, 21 Sep 2012 07:52:46 -0700 (PDT) Received: from mail-ie0-f172.google.com ([209.85.223.172]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKUFx/Paq1Uo2URxMfM23tCm2fxaWMQhh+@postini.com; Fri, 21 Sep 2012 07:52:46 PDT Received: by iec9 with SMTP id 9so6442627iec.31 for ; Fri, 21 Sep 2012 07:52:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=vfVUkXfo+sT1O5ADqM/sKa/qAfquTYbDV2+RJJCTLqQ=; b=MggC0Dn2I6LPGU4kNt8klw7iUQtziLaxE5pi0O1WhaVqpX9NyBp3Yj6GvBL9PRmjDp B5BuMQ55mFj86OptX0BUDT7226LOy4cpZ9sSMi1LJq52Iz9NSl9DNhKo5JTuI22qln91 0msuK4BSTj7m578JO0kq559T5J+H2Z03EERXyZDf7d7Nh0uO4Spd7knMhe5fzrB8eF63 cNLJ+2JG6lsc2KpPDn08RXIL3Zw6Pzq253b3nHI6XYzJFRTxR9ydb03+/LCy+rFC/Bsn dVww2zO90SwJJCGeNyk4WT78Rz8s9H7kGbRJEO1gU2kiEbR4TTBf6+Y1EKacpP093AGR 9EJw== MIME-Version: 1.0 Received: by 10.50.184.196 with SMTP id ew4mr1944546igc.5.1348239165462; Fri, 21 Sep 2012 07:52:45 -0700 (PDT) Received: by 10.64.100.137 with HTTP; Fri, 21 Sep 2012 07:52:45 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F50321D@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E0F50321D@xmb-rcd-x04.cisco.com> Date: Fri, 21 Sep 2012 07:52:45 -0700 Message-ID: From: Andre Kostur To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkfEDS/uManvfJA/IhV/TDXGDNpdm98YSc1VRLqI5The8xuWyBHHqzxEIlRz667iuTKlpeQ Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 14:52:59 -0000 One note about the failover part of this dicussion. I note that the v4 load balancing was split away from the failover discussion (and this draft is trying to follow v4 load balancing), and as such the load balancing needs to be able to work in the absence of failover. Perhaps the two servers are sharing IP space, say a 50/50 split of a /64. On Fri, Sep 21, 2012 at 7:36 AM, Bernie Volz (volz) wrote: > However, Andre's proposal would be that if the server-duid matches but > load balancing says that this is not the server that should be responding, > to drop the request. This would thus force the client to return to Solicit > (when the Requesting times out) or to advance to Rebind (when renewing The Solicit to Request should be a pretty rare problem. This would have to occur if the server that had answered the Solicit failed before the device managed to get its Request in. And in that case, I don't think making it retry the Solicit is unreasonable. > between T1 and T2). This would work to move the client to the "correct" > server but it does increase the traffic and load for those packets that are > dropped. It may increase the total traffic load, but functions to migrate the load away from one server to split it again to two. (Or as Bud had mentioned, make a new division instead of 50/50) > This would generally only impact Request and Renew packets. I would think > that the server should always process Release and Decline since those are > limited in their retransmissions (and the client fallback is to stop > sending). > > So, I think when both failover partners are responsive the load balancing > processing would be: > - If server-duid not represent in request (Solicit, Rebind, Confirm, > Information-Request), use load balancing to determine if server responds. Yep. > - If server-duid present and doesn't match this server, drop packet > (standard RFC 3315). Yep. > - (server-duid present and matches server), if Request or Renew still use > load balancing to determine if server responds. Yep, contemplating the other packet types. > - Otherwise respond to client. > > - Bernie One thing that I think has been overlooked, what about the Relay that may be doing Load Balancing? It doesn't have the server's DUID to make this comparison at all, and thus cannot do this determination. -- Andre Kostur From budmillwood@gmail.com Fri Sep 21 08:03:49 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B7521F884D; Fri, 21 Sep 2012 08:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koGuiN1fDlVJ; Fri, 21 Sep 2012 08:03:49 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 04FD321F884C; Fri, 21 Sep 2012 08:03:48 -0700 (PDT) Received: by iec9 with SMTP id 9so6477913iec.31 for ; Fri, 21 Sep 2012 08:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0jdABJg0TXZ3E2bNws2oRkFtc2+4rsokHmxih8Nb3cw=; b=Trr3PR/lkQRLTCuU2t5hnQalVzE5lQnlDwJU+8RUWmIIPsyGKfhNU+fxrSBXZDDRYq MKJye7Z/OUS//6FX39ucBtrJu8JfmyT7k+FPPMEx636GpMDvPH/aICFbeCNT2jIr3Rgy 2yJQf1D6XN+nBErrb+Idina7iXb4I+dEKnvZgT75lBNcIAo8MKoCjZcWBVKdL2ZtBsNG SblGo2xjbK8kFL7rqj8sxp8JSkOLQeZTroiWl1/AarK3KfUKGFxKfOFuu8mBmgsvdSTF e3o89a4XxdpyzDgpI8S41vfTPr/3tJrusDM8RC/LQpy5+Cmxi1bKi+W6E3BDlWFxor/7 64dg== MIME-Version: 1.0 Received: by 10.50.188.130 with SMTP id ga2mr1936460igc.32.1348239828512; Fri, 21 Sep 2012 08:03:48 -0700 (PDT) Sender: budmillwood@gmail.com Received: by 10.64.35.198 with HTTP; Fri, 21 Sep 2012 08:03:48 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F503257@xmb-rcd-x04.cisco.com> References: <20120921103403.10090.70019.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E0F503257@xmb-rcd-x04.cisco.com> Date: Fri, 21 Sep 2012 17:03:48 +0200 X-Google-Sender-Auth: 0-g-TkfAO33G4Fx-QxpQ5ZIAK1Q Message-ID: From: Bud Millwood To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dhcwg@ietf.org" , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 15:03:50 -0000 On Fri, Sep 21, 2012 at 4:46 PM, Bernie Volz (volz) wrote: > I do like "inner-most Relay-Forw" (i.e. the relay that received the clien= t's packet [msg-type !=3D Relay-Forw]). Sounds fine to me. > While in theory a MUST is probably correct, there might be cases where th= at doesn't work? So, I would lean towards SHOULD to potentially support cas= es where there might be a second (the next) relay that has this information= [and the first does not]? Certainly the MUST is correct for traditional ap= plications (i.e. corporate Ethernet based networks or CableLabs DOCSIS). > > I can't give you a specific example, but perhaps there are some from netw= orks that don't support multicast or where a relay proxy is needed on the d= evice itself (as then you'd have the client providing this information)? Put in reverse, the question is basically "What could go wrong"? I can't see spoofing being an issue, so I suppose we can't think of any downside. I'm ok with SHOULD. - Bud > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of= Bud Millwood > Sent: Friday, September 21, 2012 9:55 AM > To: internet-drafts@ietf.org > Cc: dhcwg@ietf.org; i-d-announce@ietf.org > Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-= addr-opt-02.txt > > 5. DHCPv6 Server Behavior > >> If DHCPv6 Server is configured to store or use client link-layer address= , it SHOULD look for the client link-layer address option in the RELAY-FORW= DHCP message of the DHCPv6 Relay agent closest to the client. > > Although I understand what "closest to the client" means (I use that term= myself), is that the correct terminology? It could also be referred to as = the inner-most RELAY-FORW message, or the first RELAY-FORW message. Is ther= e even a standard terminology for this? I just glanced through 3315 and don= 't see anything. > > Also, the server "SHOULD" look for the link-layer address in the closest = RELAY-FORW message. What are the ramifications of changing this to MUST? Is= there any scenario where a second-hop relay would know the link-layer addr= ess, but the first hop wouldn't know it or support this RFC? Do we gain any= thing by enforcing that a conveyed link-layer address is only valid or to b= e trusted if it's from the first-hop relay? > > - Bud > > > > On Fri, Sep 21, 2012 at 12:34 PM, wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Dynamic Host Configuration Working Gro= up of the IETF. >> >> Title : Client Link-layer Address Option in DHCPv6 >> Author(s) : Gaurav Halwasia >> Shwetha Bhandari >> Wojciech Dec >> Filename : draft-ietf-dhc-dhcpv6-client-link-layer-addr-o= pt-02.txt >> Pages : 6 >> Date : 2012-09-21 >> >> Abstract: >> This document specifies the format and mechanism that is to be used >> for encoding client link-layer address in DHCPv6 relay forward >> messages by defining a new DHCPv6 Client Link-layer Address option. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-lay >> er-addr-opt >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-add >> r-opt-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-client-link-lay >> er-addr-opt-02 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 volz@cisco.com Fri Sep 21 08:26:41 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE4021F87A8 for ; Fri, 21 Sep 2012 08:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2TSFhzsaSNN for ; Fri, 21 Sep 2012 08:26:40 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7290E21F86E5 for ; Fri, 21 Sep 2012 08:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2608; q=dns/txt; s=iport; t=1348241200; x=1349450800; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sOweXEljynVsT0f+HZVCChfqsp/zn+/7qyumnH1V2no=; b=d/mU0AAT2pTFVPOuxYAKu+Y5IrVVl8CfnPKRxBcrSbUz9OwdEdFNCt9m xM3a8151wl9aU2rn32fKnYW32zz+NQEXMHZF4dPzGJX//pbjuik0TKUsa 92jS1aOHsmnC3Mp5Kmt4ngjGHPIXnf0V+olJSMQFBzebXR8fsbFPIF7Gw 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAuGXFCtJXG9/2dsb2JhbABFvhSBCIIgAQEBAwESAWYFBwQCAQgRBAEBCx0HMhQJCAIEAQ0FCBqHXQaZKKAeixyFRmADiCGbfIFpgmeCFw X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="124009991" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 21 Sep 2012 15:26:40 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8LFQda9017590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Sep 2012 15:26:39 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Fri, 21 Sep 2012 10:26:39 -0500 From: "Bernie Volz (volz)" To: "Hemant Singh (shemant)" , =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpd/JdswgAB/xoD//5GrgIAAeqgAgAsV/xCAAo6qwIAAkkeagADTRICABnD/QA== Date: Fri, 21 Sep 2012 15:26:38 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F50335F@xmb-rcd-x04.cisco.com> References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F83D1@xmb-rcd-x04.cisco.com> <21C54D57-372F-46B0-892B-398919992546@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F857F@xmb-rcd-x04.cisco.com> <75B6FA9F576969419E42BECB86CB1B8908A7CF@xmb-rcd-x06.cisco.com>, <75B6FA9F576969419E42BECB86CB1B8908AAC6@xmb-rcd-x06.cisco.com> <56DD5F8D-D04D-40F6-B5BA-A5673E2264F8@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.250.189] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19200.001 x-tm-as-result: No--42.763500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 15:26:41 -0000 Hemant: Where do you stand on this? Is the Confirm still an issue for you? Is there= something to add to the draft to help clarify things? - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of O= le Tr=F8an Sent: Monday, September 17, 2012 4:03 AM To: Bernie Volz (volz) Cc: dhc WG; Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Bernie, > The server I work on does not look up bindings for Confirming IAPREFIX (t= he server has allowed Confirm on prefixes since day one) so this text is fa= lse and is not required. The server does the same processing it does for ad= dresses. It looks up the link and prefix configuration and if the delegated= prefix sent by the client (or address sent by the client) is contained by = a configured prefix the client is told success. If it can't tell (this is m= ostly the case for addresses that are link-local but also in cases where th= e clients "location" can not be determined from one of the addresses or pre= fixes provided by the client) it doesn't respond. Otherwise the client is t= old not-on-link. >=20 > Confirm never says a particular address or prefix is leased to the client= . It just says whether the client has clearly moved or not (no response mea= ns the server can't determine). >=20 > So, I do not agree with this text change at all. >=20 > Regarding the second issue ... If the configuration has changed to remove= prefix delegation or addresses, but not the other, and the Confirm returns= Not-On-Link, client would move back to Solicit but why would Solicits cont= inue forever? Are you thinking a client would implement some, but not all c= hanges? I would think that is wrong - this is a package of changes the clie= nt and server need to implement. So, the other changes would prevent the co= ntinous Solicits? We have no good way to return separate status codes for p= refix vs address and I don't see this as needed per what I just wrote? >=20 > Note that likely the client will get back the same address or prefix when= it Solicits, just won't get the other that is no longer configured. >=20 > Perhaps Ole has a different view or there is something I am missing here? I have the same view as well. (the reason we did what we did in 3633 with regards to Confirm, was because= of the text around "Onlink". in hindsight we've realised that having diffe= rent behaviour per IA was a bad idea, and Bernie came up with a simple fix = for how to use Confirm for IA_PD also.) cheers, Ole From akostur@incognito.com Fri Sep 21 09:44:02 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA0F21F87D5 for ; Fri, 21 Sep 2012 09:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.077 X-Spam-Level: X-Spam-Status: No, score=-5.077 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFaPduhmFvln for ; Fri, 21 Sep 2012 09:44:01 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with SMTP id 6C6BB21F87E6 for ; Fri, 21 Sep 2012 09:44:00 -0700 (PDT) Received: from mail-ie0-f172.google.com ([209.85.223.172]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKUFyZUGsq/1Oh79a51yXLqWnFyTgigHJq@postini.com; Fri, 21 Sep 2012 09:44:01 PDT Received: by iec9 with SMTP id 9so6776429iec.31 for ; Fri, 21 Sep 2012 09:44:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=z0LRJ4gNpYglArXvEvdG1om5QmHavf1USOjFsHBfMu0=; b=HpHTjtFZ+V62ayUSGFV78OdgzfErZIHV86eCzgfmXcu8pGqWZ1azGDLc/xlafWElH2 yv0hrFSdbGoG6hdFIfOry3jTaaEz+PgXWU+c3zOWOB41SLBRa0jZVpoRa5kvqHTR/sP5 JNwm+dWB00lpbUyrFBtb86V087JkJcnyuAhuBTuzZi5mRWVl+twnqW7agSXF12hLz+d+ MMTsJetl4TLaiMBtSIohizB8KN9l+lcxoPzeOuPLNutdLYGxJWbAf69R9Pu4t4Kurl/J EUp7aCXneNUBOsjp0MZiaQyV14Iho4ZmnH7qT6Hm28d3p6Q6A+hJmpxqPEgLhEtm6jyh 9g/g== MIME-Version: 1.0 Received: by 10.50.152.137 with SMTP id uy9mr1517150igb.62.1348245839597; Fri, 21 Sep 2012 09:43:59 -0700 (PDT) Received: by 10.64.100.137 with HTTP; Fri, 21 Sep 2012 09:43:59 -0700 (PDT) In-Reply-To: <1BB5EDFF-BBA9-4335-BE55-058FACEE30EB@cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> <5049C317.7090603@gmail.com> <94FA926F-2432-4AE7-BC20-AE7458AB40D9@cisco.com> <71F17433-B2D9-4366-9B32-F0E4D294EDB5@nominum.com> <1BB5EDFF-BBA9-4335-BE55-058FACEE30EB@cisco.com> Date: Fri, 21 Sep 2012 09:43:59 -0700 Message-ID: From: Andre Kostur To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnSnYeL+UOV8EdmjfRqQAmKxze7GC2uhHcKP6J6tb89XiobRreC7Phu1Cq8+X0PDW9uFdpj Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 16:44:02 -0000 I've crafted up a test rig for Pearson vs. FNV1a (Pearson code from the RFC, FNV1a from http://isthe.com/chongo/tech/comp/fnv/#FNV-reference-source, with the XOR-folding at http://www.isthe.com/chongo/tech/comp/fnv/index.html#xor-fol= d). I generated my DUIDs as a set of DUID-LLs (so the first four bytes are 00, 03, 00, 06). The next three were taken randomly from IEEE's list of registered OUIs. The remaining three are rand(). Running those through both Pearson and FNV1a 5 times each (on a set of 2,560,000 DUID-LLs) resulted in: Pearson: Min: 9637 - 9750, Max: 10220 - 10318, StdDev: 92.91 - 102.28 FNV1a: Min: 9691 - 9754, Max: 10221 - 10379, Stdev: 93.27 - 107.66 This seems to suggest that Pearson is better than FNV1a over DUID-LLs. On Thu, Sep 20, 2012 at 5:05 AM, Bernie Volz (volz) wrote: > Bad test - This is a very limited character set. > > The data usually used for dhcp is binary data. > > Sent from my iPad > > On Sep 20, 2012, at 1:27 AM, "Donald Eastlake" wrote: > >> Well, I have some more statistics. One my co-authors on the draft >> whipped up some code that I then extended. The data hashed consisted >> of 2,560,000 strings calculated as follows: >> #define RUN 10000 >> for(i =3D 0; i < 256*RUN; ++i) >> { >> sprintf(str, "%08d^^%08d", i, i); >> {do hashes, etc} >> } >> >> Each string was hashed with Pearson and with 32-bit FNV-1a. Three >> arrays of 256 counters were incremented based on the Pearson hash, >> based on the bottom byte of the 32-bit FNV after one 16-bit fold ( >> hash2 =3D (hash&0xffff) ^ (hash >> 16) ), and based on the bottom byte >> of the 32-bit FNV after an additional 8-bit fold (hash3 =3D (hash2&0xff) >> ^ (hash2 >> 8); the equivalent of xor'ing all four bytes together). >> The expected number of hits on each bucket with perfect hashing would >> be 10,000. Here are the minimum and maximum number of hits and the >> standard deviation: >> >> Pearson: min=3D9678 max=3D19938 std-dev=3D630.72 >> FNV-32 1-fold: min=3D9699 max=3D10331 std-dev=3D103.06 >> FNV-32 2-folds: min=3D9662 max=3D10247 std-dev=3D90.78 >> >> So you now have Brian Carpenter's results, showing FNV to be much >> better than a variety of other methods, but not Pearson, on fairly >> realistic data. And you have these results showing FNV to be much >> better than Pearson on somewhat unrealistic data. ... >> >> Thanks, >> Donald >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e3e3@gmail.com >> >> >> On Fri, Sep 7, 2012 at 6:29 PM, Ted Lemon wrote: >>> On Sep 7, 2012, at 5:37 PM, Donald Eastlake wrote: >>>> FNV takes a little more effort than Pearson. It also has a smaller >>>> footprint in memory. And I believe it will produce statistically >>>> better results. What are the relative weights of these or other >>>> factors in this case? >>> >>> Unfortunately, as far as I can tell neither of the studies you cite com= pares FNV to Pearson, although the results from Brian Carpenter's study are= certainly pretty impressive. I think more work is worse, smaller footpr= int probably doesn't matter (this algorithm is being run in DHCP servers, w= hich typically aren't seriously memory-constrained), and statistically bett= er results only matter if it's a pretty big difference, so it's frustrating= that we don't have a comparison to the existing algorithm. >>> >>> To me, the biggest win of using FNV would be if there were an RFC to re= fer to, but it looks like this is not quite there yet. So my conclusion i= s that I certainly don't oppose using FNV instead of Pearson, but I don't s= ee a strong reason to support it either. >>> >> _______________________________________________ >> 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 --=20 Andre Kostur Distinguished Software Architect & Engineer P: 604-678-2864 E: akostur@incognito.com Toll-Free: 1-800-877-1856 F: 604-678-2864 VoIP: sip:864@sip.incognito.com From volz@cisco.com Fri Sep 21 10:04:51 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3E721F8726 for ; Fri, 21 Sep 2012 10:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.639 X-Spam-Level: X-Spam-Status: No, score=-9.639 tagged_above=-999 required=5 tests=[AWL=-0.840, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+o3G5a8e4rw for ; Fri, 21 Sep 2012 10:04:50 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC0E21F871C for ; Fri, 21 Sep 2012 10:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5210; q=dns/txt; s=iport; t=1348247090; x=1349456690; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PouoMTspm8FyPz8NsAxfMUijTCK+fTq2RQMraMY+yf0=; b=SqQakyni1yCgdQfygGrFKnHOgCKbexYvBn9WcoPkE5+BVEfJH85q00xz IBQPr53fwpi5wCUmD5gEr6QYiVl7iJuz9MxCp1GeG2X63T0QMAK41Cz/+ gYXgS4n5U0jo0TzjarrO/r2O2Ekz3tfOOY/kJk3reJSHNKF0E3T0aVKfz s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAedXFCtJXG9/2dsb2JhbABCA74YgQiCIAEBAQQBAQEPASc0CwwEAgEIDgMEAQEBCgoKCQchBgsUCQcBAgEDDgUIARUEh1EDDwuZF5Y/DYlTijpiFAEQglyCRWADlA+CaooDgyGBaYIaTYFaATw X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="121048913" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 21 Sep 2012 17:04:49 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8LH4n2X011788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Sep 2012 17:04:49 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Fri, 21 Sep 2012 12:04:49 -0500 From: "Bernie Volz (volz)" To: Andre Kostur Thread-Topic: [dhcwg] Load Balancing for DHCPv6 Thread-Index: AQHNlvCUaJ+khP2NkUiXQs2wUqwOeJeTIoPtgAI0BoD//68foA== Date: Fri, 21 Sep 2012 17:04:48 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F5033D6@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> <5049C317.7090603@gmail.com> <94FA926F-2432-4AE7-BC20-AE7458AB40D9@cisco.com> <71F17433-B2D9-4366-9B32-F0E4D294EDB5@nominum.com> <1BB5EDFF-BBA9-4335-BE55-058FACEE30EB@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.250.189] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19200.001 x-tm-as-result: No--62.518600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 17:04:51 -0000 Thanks Andre. While it would make no difference, it is always a mystery whether DUID will= use a hardware type of 1 or 6. Per http://www.iana.org/assignments/arp-par= ameters/arp-parameters.xml, type 1 is for Ethernet whereas 6 is for IEEE 80= 2.3. It may well be for a more limited data set (i.e. ASCII strings), FNV1a coul= d be better. I think Pearson was optimized for binary data. My feeling is we should stick with Pearson and use the entire DUID (no leng= th limit). - Bernie -----Original Message----- From: Andre Kostur [mailto:akostur@incognito.com]=20 Sent: Friday, September 21, 2012 12:44 PM To: Bernie Volz (volz) Cc: Donald Eastlake; dhcwg@ietf.org; Ted Lemon Subject: Re: [dhcwg] Load Balancing for DHCPv6 I've crafted up a test rig for Pearson vs. FNV1a (Pearson code from the RFC, FNV1a from http://isthe.com/chongo/tech/comp/fnv/#FNV-reference-source, with the XOR-f= olding at http://www.isthe.com/chongo/tech/comp/fnv/index.html#xor-fold). I generated my DUIDs as a set of DUID-LLs (so the first four bytes are 00, = 03, 00, 06). The next three were taken randomly from IEEE's list of regist= ered OUIs. The remaining three are rand(). Running those through both Pearson and FNV1a 5 times each (on a set of 2,560,000 DUID-LLs) resulted in: Pearson: Min: 9637 - 9750, Max: 10220 - 10318, StdDev: 92.91 - 102.28 FNV1a: Min: 9691 - 9754, Max: 10221 - 10379, Stdev: 93.27 - 107.66 This seems to suggest that Pearson is better than FNV1a over DUID-LLs. On Thu, Sep 20, 2012 at 5:05 AM, Bernie Volz (volz) wrote: > Bad test - This is a very limited character set. > > The data usually used for dhcp is binary data. > > Sent from my iPad > > On Sep 20, 2012, at 1:27 AM, "Donald Eastlake" wrote: > >> Well, I have some more statistics. One my co-authors on the draft=20 >> whipped up some code that I then extended. The data hashed consisted=20 >> of 2,560,000 strings calculated as follows: >> #define RUN 10000 >> for(i =3D 0; i < 256*RUN; ++i) >> { >> sprintf(str, "%08d^^%08d", i, i); >> {do hashes, etc} >> } >> >> Each string was hashed with Pearson and with 32-bit FNV-1a. Three=20 >> arrays of 256 counters were incremented based on the Pearson hash,=20 >> based on the bottom byte of the 32-bit FNV after one 16-bit fold ( >> hash2 =3D (hash&0xffff) ^ (hash >> 16) ), and based on the bottom byte=20 >> of the 32-bit FNV after an additional 8-bit fold (hash3 =3D=20 >> (hash2&0xff) ^ (hash2 >> 8); the equivalent of xor'ing all four bytes to= gether). >> The expected number of hits on each bucket with perfect hashing would=20 >> be 10,000. Here are the minimum and maximum number of hits and the=20 >> standard deviation: >> >> Pearson: min=3D9678 max=3D19938 std-dev=3D630.72 >> FNV-32 1-fold: min=3D9699 max=3D10331 std-dev=3D103.06 >> FNV-32 2-folds: min=3D9662 max=3D10247 std-dev=3D90.78 >> >> So you now have Brian Carpenter's results, showing FNV to be much=20 >> better than a variety of other methods, but not Pearson, on fairly=20 >> realistic data. And you have these results showing FNV to be much=20 >> better than Pearson on somewhat unrealistic data. ... >> >> Thanks, >> Donald >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com >> >> >> On Fri, Sep 7, 2012 at 6:29 PM, Ted Lemon wrote: >>> On Sep 7, 2012, at 5:37 PM, Donald Eastlake wrote: >>>> FNV takes a little more effort than Pearson. It also has a smaller >>>> footprint in memory. And I believe it will produce statistically >>>> better results. What are the relative weights of these or other >>>> factors in this case? >>> >>> Unfortunately, as far as I can tell neither of the studies you cite com= pares FNV to Pearson, although the results from Brian Carpenter's study are= certainly pretty impressive. I think more work is worse, smaller footpr= int probably doesn't matter (this algorithm is being run in DHCP servers, w= hich typically aren't seriously memory-constrained), and statistically bett= er results only matter if it's a pretty big difference, so it's frustrating= that we don't have a comparison to the existing algorithm. >>> >>> To me, the biggest win of using FNV would be if there were an RFC to re= fer to, but it looks like this is not quite there yet. So my conclusion i= s that I certainly don't oppose using FNV instead of Pearson, but I don't s= ee a strong reason to support it either. >>> >> _______________________________________________ >> 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 --=20 Andre Kostur Distinguished Software Architect & Engineer P: 604-678-2864 E: akostur@incognito.com Toll-Free: 1-800-877-1856 F: 604-678-2864 VoIP: sip:864@sip.incognito.com From akostur@incognito.com Fri Sep 21 10:12:23 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8311C21F8751 for ; Fri, 21 Sep 2012 10:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.948 X-Spam-Level: X-Spam-Status: No, score=-4.948 tagged_above=-999 required=5 tests=[AWL=-0.771, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7u91-CHjzaPT for ; Fri, 21 Sep 2012 10:12:22 -0700 (PDT) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with SMTP id 4D56721F8748 for ; Fri, 21 Sep 2012 10:12:21 -0700 (PDT) Received: from mail-ie0-f172.google.com ([209.85.223.172]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKUFyf9e4Om48TTwzop4T7Cs5rFibNjeuR@postini.com; Fri, 21 Sep 2012 10:12:22 PDT Received: by iec9 with SMTP id 9so6858923iec.31 for ; Fri, 21 Sep 2012 10:12:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=FLaqVTqY3Xlm07ugNlb7AtIwXupTrxnv6mAW8RGIDHo=; b=Qvz8JnM+tGfwVP6/WebGuyd9tLuRhkVpfM0jGim7ewLWHTYqreEJfO5pUrKC3yGBQP 0Ttuvt50zbNaJwR4tAVhJjTUELmHIpVz2kDsq7bKsQH5SD00NYFtPGoQ4FkagQM7EGNv 8HGtFw/ZLREMbroVvbzuSbM51iRRnaQb6W71juHpVUwRy1YBFhHjsoSnpHbfhDXW6Xgb L7Bz78M3GG1VFG06VNVocHjfribrnoKKFEPEZFmQDRyZ7vt0Mh6ctz7i/10EoQfo9wdz KN8L0nyHeOTPa0O5AkDKVLep5+EIjGU5wFQWO7wqtrt1EDUzfvsXB6rPk9AZxfzQisA0 br5A== MIME-Version: 1.0 Received: by 10.50.47.227 with SMTP id g3mr2343896ign.5.1348247540932; Fri, 21 Sep 2012 10:12:20 -0700 (PDT) Received: by 10.64.100.137 with HTTP; Fri, 21 Sep 2012 10:12:20 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F5033D6@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> <5049C317.7090603@gmail.com> <94FA926F-2432-4AE7-BC20-AE7458AB40D9@cisco.com> <71F17433-B2D9-4366-9B32-F0E4D294EDB5@nominum.com> <1BB5EDFF-BBA9-4335-BE55-058FACEE30EB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E0F5033D6@xmb-rcd-x04.cisco.com> Date: Fri, 21 Sep 2012 10:12:20 -0700 Message-ID: From: Andre Kostur To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm9j243QGawJhz/INa+BSQUkuYbGyyWL2Nde3P0iCC2P6vQsl0QMQpzPYW79C3lY4+pJ/bX Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 17:12:23 -0000 Whups, yep. Changed that to a 1, and no significant different in the stddev. Both still in that 95 - 105 range. I'm also of the opinion that Pearson is the way to go. Seems to give a pretty good spread of values, it's already documented in RFC (complete with implementation), and any servers or relays that may have already been doing load balancing for v4 will already have this algorithm implemented. On Fri, Sep 21, 2012 at 10:04 AM, Bernie Volz (volz) wrote= : > Thanks Andre. > > While it would make no difference, it is always a mystery whether DUID wi= ll use a hardware type of 1 or 6. Per http://www.iana.org/assignments/arp-p= arameters/arp-parameters.xml, type 1 is for Ethernet whereas 6 is for IEEE = 802.3. > > It may well be for a more limited data set (i.e. ASCII strings), FNV1a co= uld be better. I think Pearson was optimized for binary data. > > My feeling is we should stick with Pearson and use the entire DUID (no le= ngth limit). > > - Bernie > > -----Original Message----- > From: Andre Kostur [mailto:akostur@incognito.com] > Sent: Friday, September 21, 2012 12:44 PM > To: Bernie Volz (volz) > Cc: Donald Eastlake; dhcwg@ietf.org; Ted Lemon > Subject: Re: [dhcwg] Load Balancing for DHCPv6 > > I've crafted up a test rig for Pearson vs. FNV1a (Pearson code from > the RFC, FNV1a from > http://isthe.com/chongo/tech/comp/fnv/#FNV-reference-source, with the XOR= -folding at http://www.isthe.com/chongo/tech/comp/fnv/index.html#xor-fold). > > I generated my DUIDs as a set of DUID-LLs (so the first four bytes are 00= , 03, 00, 06). The next three were taken randomly from IEEE's list of regi= stered OUIs. The remaining three are rand(). > > Running those through both Pearson and FNV1a 5 times each (on a set of > 2,560,000 DUID-LLs) resulted in: > > Pearson: > Min: 9637 - 9750, Max: 10220 - 10318, StdDev: 92.91 - 102.28 > > FNV1a: > Min: 9691 - 9754, Max: 10221 - 10379, Stdev: 93.27 - 107.66 > > > This seems to suggest that Pearson is better than FNV1a over DUID-LLs. > > > On Thu, Sep 20, 2012 at 5:05 AM, Bernie Volz (volz) wrot= e: >> Bad test - This is a very limited character set. >> >> The data usually used for dhcp is binary data. >> >> Sent from my iPad >> >> On Sep 20, 2012, at 1:27 AM, "Donald Eastlake" wrote: >> >>> Well, I have some more statistics. One my co-authors on the draft >>> whipped up some code that I then extended. The data hashed consisted >>> of 2,560,000 strings calculated as follows: >>> #define RUN 10000 >>> for(i =3D 0; i < 256*RUN; ++i) >>> { >>> sprintf(str, "%08d^^%08d", i, i); >>> {do hashes, etc} >>> } >>> >>> Each string was hashed with Pearson and with 32-bit FNV-1a. Three >>> arrays of 256 counters were incremented based on the Pearson hash, >>> based on the bottom byte of the 32-bit FNV after one 16-bit fold ( >>> hash2 =3D (hash&0xffff) ^ (hash >> 16) ), and based on the bottom byte >>> of the 32-bit FNV after an additional 8-bit fold (hash3 =3D >>> (hash2&0xff) ^ (hash2 >> 8); the equivalent of xor'ing all four bytes t= ogether). >>> The expected number of hits on each bucket with perfect hashing would >>> be 10,000. Here are the minimum and maximum number of hits and the >>> standard deviation: >>> >>> Pearson: min=3D9678 max=3D19938 std-dev=3D630.72 >>> FNV-32 1-fold: min=3D9699 max=3D10331 std-dev=3D103.06 >>> FNV-32 2-folds: min=3D9662 max=3D10247 std-dev=3D90.78 >>> >>> So you now have Brian Carpenter's results, showing FNV to be much >>> better than a variety of other methods, but not Pearson, on fairly >>> realistic data. And you have these results showing FNV to be much >>> better than Pearson on somewhat unrealistic data. ... >>> >>> Thanks, >>> Donald >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>> 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com >>> >>> >>> On Fri, Sep 7, 2012 at 6:29 PM, Ted Lemon wrote= : >>>> On Sep 7, 2012, at 5:37 PM, Donald Eastlake wrote: >>>>> FNV takes a little more effort than Pearson. It also has a smaller >>>>> footprint in memory. And I believe it will produce statistically >>>>> better results. What are the relative weights of these or other >>>>> factors in this case? >>>> >>>> Unfortunately, as far as I can tell neither of the studies you cite co= mpares FNV to Pearson, although the results from Brian Carpenter's study ar= e certainly pretty impressive. I think more work is worse, smaller footp= rint probably doesn't matter (this algorithm is being run in DHCP servers, = which typically aren't seriously memory-constrained), and statistically bet= ter results only matter if it's a pretty big difference, so it's frustratin= g that we don't have a comparison to the existing algorithm. >>>> >>>> To me, the biggest win of using FNV would be if there were an RFC to r= efer to, but it looks like this is not quite there yet. So my conclusion = is that I certainly don't oppose using FNV instead of Pearson, but I don't = see a strong reason to support it either. >>>> > > -- > Andre Kostur --=20 Andre Kostur From akostur@incognito.com Fri Sep 21 11:05:38 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B657E21E80B7 for ; Fri, 21 Sep 2012 11:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.452 X-Spam-Level: X-Spam-Status: No, score=-5.452 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhBmG2V18pH2 for ; Fri, 21 Sep 2012 11:05:33 -0700 (PDT) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with SMTP id 5848D21F84A7 for ; Fri, 21 Sep 2012 11:05:32 -0700 (PDT) Received: from mail-ie0-f172.google.com ([209.85.223.172]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKUFysbEyIszfjb/zEntUQ/lCXcMbt7bWO@postini.com; Fri, 21 Sep 2012 11:05:33 PDT Received: by iec9 with SMTP id 9so6998092iec.31 for ; Fri, 21 Sep 2012 11:05:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=04PEGYwhXfjUkmFATx+50IWGT4QKN2e+0IlHt3/l7dk=; b=PlUXfD/d8e1QSqwtHfABdz47tnjfqGR5I3kAjFGWzh8uBjN7fJ5jGefxX24r0/L2i3 dMDIjWzvRFDh/QHYQ2kxuiFgnxNtpUj3DsbiqtzYpsrppftSLRCZgxsbZLRTIWBYxtS5 bidRHeij91Pdn7i53kiZQJwPJM6YV8w9oUjqsgDT3IyxZksIOB6K7qxp7Xzc37qacCcX DQ3RfxbHL2IG4k8//YzVKv2VxJY6BHBVeEdagbNxznbtIOT3AZXxi1hfSBwPkZ+7Q08Y Jzz8vi9+3h8l2Ia1bSHXHPswrFljVV7w1BDIiS9r5gGPMEYQn/KzZi/VT4bsWY7mA0Y3 essg== MIME-Version: 1.0 Received: by 10.50.158.194 with SMTP id ww2mr2441580igb.40.1348250731939; Fri, 21 Sep 2012 11:05:31 -0700 (PDT) Received: by 10.64.100.137 with HTTP; Fri, 21 Sep 2012 11:05:31 -0700 (PDT) In-Reply-To: References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> <5049C317.7090603@gmail.com> <94FA926F-2432-4AE7-BC20-AE7458AB40D9@cisco.com> <71F17433-B2D9-4366-9B32-F0E4D294EDB5@nominum.com> <1BB5EDFF-BBA9-4335-BE55-058FACEE30EB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E0F5033D6@xmb-rcd-x04.cisco.com> Date: Fri, 21 Sep 2012 11:05:31 -0700 Message-ID: From: Andre Kostur To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmlDOOKCzBDLW9zNWvp+5g1P0UdMRCYQLAyTU3F/8XIa4xDEVzd4jq6JhPPfDDKBiJlt3tp Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] Load Balancing for DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 18:05:39 -0000 Bernie had asked off-list (and I was kinda curious myself) as to the relative performance of the two algorithms as well. So I put it under a performance analyzer, and it came back with Pearson taking on average 0.67 usecs per invocation, where FNV1a took 1.50 usecs per invocation. (That is on an optimized build of the algorithms, not debug builds.) Add this to all of the other reasons already mentioned, I think Person is definitively the way to go. (Unless someone can point out a flaw in my methodology....) On Fri, Sep 21, 2012 at 10:12 AM, Andre Kostur wrote: > Whups, yep. Changed that to a 1, and no significant different in the > stddev. Both still in that 95 - 105 range. > > I'm also of the opinion that Pearson is the way to go. Seems to give > a pretty good spread of values, it's already documented in RFC > (complete with implementation), and any servers or relays that may > have already been doing load balancing for v4 will already have this > algorithm implemented. -- Andre Kostur From shemant@cisco.com Sat Sep 22 05:48:30 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E949D21F85C4 for ; Sat, 22 Sep 2012 05:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGewuLFmjq6v for ; Sat, 22 Sep 2012 05:48:26 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A54B321F85B8 for ; Sat, 22 Sep 2012 05:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4276; q=dns/txt; s=iport; t=1348318106; x=1349527706; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=59aW+KaQfrM3HTknzWpcwO/kJin9/FJce1mtlDP15Fc=; b=GkMx0SucTLh+sRQglgcUQyUAupZIF84nWVq+onN2P2YA48PgEqUBGG4f LsOLO5ViY77c/kcw8g3CyYaG1wt+d6Njm2f789ypUw3xZY/iFjkcCIPel jamkEvLc2GJRBP90rVvVfbrSQ1yj9yeylVGGiyC+NrzpiaUCKhPQq4hKV Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGmzXVCtJXG+/2dsb2JhbABFviuBCIIgAQEBBBIBFBM/DAQCAQgRBAEBCxQQMh0IAgQODRqHY5hUn3+LHIVKYAOkHoFpgmeBYzQ X-IronPort-AV: E=Sophos;i="4.80,467,1344211200"; d="scan'208";a="124255406" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 22 Sep 2012 12:48:21 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8MCmKh1012604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Sep 2012 12:48:20 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Sat, 22 Sep 2012 07:48:20 -0500 From: "Hemant Singh (shemant)" To: "Bernie Volz (volz)" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpd/JdswgAB/xoD//5GrgIAAeqgAgAsV/xCAAo6qwIAAkkeagAiZUBA= Date: Sat, 22 Sep 2012 12:48:19 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89090180@xmb-rcd-x06.cisco.com> References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F83D1@xmb-rcd-x04.cisco.com> <21C54D57-372F-46B0-892B-398919992546@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F857F@xmb-rcd-x04.cisco.com> <75B6FA9F576969419E42BECB86CB1B8908A7CF@xmb-rcd-x06.cisco.com>, <75B6FA9F576969419E42BECB86CB1B8908AAC6@xmb-rcd-x06.cisco.com> <56DD5F8D-D04D-40F6-B5BA-A5673E2264F8@cisco.com> In-Reply-To: <56DD5F8D-D04D-40F6-B5BA-A5673E2264F8@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.251.15] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19202.004 x-tm-as-result: No--49.177900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG , Ted Lemon , "Ole Troan \(otroan\)" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 12:48:31 -0000 Bernie & Ole, Sorry for the delay. Please see in line below. Also, let's talk sometime = next week at work and we can resolve the issues offline and then let the ma= iler know. -----Original Message----- From: Bernie Volz (volz)=20 Sent: Sunday, September 16, 2012 8:27 PM To: Hemant Singh (shemant) Cc: Ted Lemon; dhc WG; Ole Troan (otroan) Subject: Re: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 >The server I work on does not look up bindings for Confirming IAPREFIX (th= e server has allowed Confirm on prefixes since day one) so this text is fal= se >and is not required.=20 That's one server. We could use text that has generic requirements for all= servers. I wrote a bunch of text including text that says client bindings= should not be looked up. I also said most of the text in the Confirm sect= ion of your document is redundant with RFC 3315. Thus it makes sense to re= tain most of the text I proposed. I think the text you say is false is thi= s. "The server uses configured prefixes to determine if a prefix in the IA_PD = option is on-link to respond to a Confirm." >The server does the same processing it does for addresses. It looks up the= link and prefix configuration and if the delegated prefix sent by the clie= nt >(or address sent by the client) is contained by a configured prefix the= client is told success. If it can't tell (this is mostly the case for addr= esses >that are link-local but also in cases where the clients "location" c= an not be determined from one of the addresses or prefixes provided by the = client) it >doesn't respond. Otherwise the client is told not-on-link. Hmm, does DHCPv6 assign a link-local address to a client that a client will= issue a Confirm for a link-local address? I am also replying to Ole in th= is email. Ole said=20 "(the reason we did what we did in 3633 with regards to Confirm, was becaus= e of the text around "Onlink"."=20 It makes sense that OnLink is defined in some document. Both RFC 3315 and = RFC 4861 have identical definition for "link". This definition says nodes = on the link can communicate below the IP layer. So how is a globally routa= ble IPv6 address in an IA_NA or a prefix in the IA_PD determined to be OnLi= nk when both entities communicate at the IP layer? I know you have given d= etails on how does your server determines OnLink. But those are details an= d internal constructs of one server. We need an example for how do all ser= vers determine what is OnLink for the IA_PD prefix. =20 >Confirm never says a particular address or prefix is leased to the client.= It just says whether the client has clearly moved or not (no response mean= s >the server can't determine).=20 > >So, I do not agree with this text change at all. Looking up a link matching a prefix configuration does not work for all cas= es. The client moves and another link on the server can serve the same pre= fix. So now the server has to look up a collection of prefixes. How are p= refixes collected? Based on what metric?=20 >Regarding the second issue ... If the configuration has changed to remove = prefix delegation or addresses, but not the other, and the Confirm returns = Not->On-Link, client would move back to Solicit but why would Solicits cont= inue forever? Are you thinking a client would implement some, but not all c= hanges? >I would think that is wrong - this is a package of changes the cli= ent and server need to implement. So, the other changes would prevent the c= ontinous >Solicits? We have no good way to return separate status codes for= prefix vs address and I don't see this as needed per what I just wrote? If you don't have a good way to return separate status codes for prefix vs.= address, then I doubt if the sever has a good way to determine if each of = the prefix and address is NotOnLink? Why would the Solicit not continue fo= rever. Then network has only one server. The server has removed one IA ty= pe and the client 's Solicit will not be responded by the server any more. = Thus if Reply received to a Confirm has one IA type as NotOnLink, the clie= nt switches to the Information-Request with that IA type.=20 Thanks, Hemant From pjhingra@cisco.com Sun Sep 23 20:43:33 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C5E21F846C for ; Sun, 23 Sep 2012 20:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+fulFj8a96P for ; Sun, 23 Sep 2012 20:43:33 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E138721F8464 for ; Sun, 23 Sep 2012 20:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=849; q=dns/txt; s=iport; t=1348458213; x=1349667813; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=tCg66x6cyhIJHKxPyi1Lqfrab4mOTJrWbJLRVfMR8no=; b=JTJVXoyedPfnJNkZPvtBwz3IaQ5JLdTdph/JnkB/aGkk3PzZDmWis9Of oPXVJJRGsuIyVUKkc3Dn0DEOZK67BHmLnHMnHVnujlPCRGiJhi4dLCqZ/ +nP/CHRmmMt0ExW/kTtB2f9BSKC7OrkZkngv97TL5rf4vADLelyBoeUV5 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAEjWX1CtJXHA/2dsb2JhbABFhUS4a4EIgiABAQEEAQEBDwEnNBcEAgEIEQQBAQsUCQcnCxQJCAEBBAESCBqHYwuYap8WBIschUpgA6QfgWmCZ4IX X-IronPort-AV: E=Sophos;i="4.80,473,1344211200"; d="scan'208";a="124514028" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 24 Sep 2012 03:43:32 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8O3hWwO020950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Sep 2012 03:43:32 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.3]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Sun, 23 Sep 2012 22:43:32 -0500 From: "Prashant Jhingran (pjhingra)" To: Ted Lemon , dhc WG Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt Thread-Index: Ac2X8ddMOw/OIH/tQHCVi0DiBXN4ZACFNfbA Date: Mon, 24 Sep 2012 03:43:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.105.34] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19204.004 x-tm-as-result: No--27.115200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 03:43:33 -0000 +1 , I support this draft. - Regards, Prashant Jhingran -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Friday, September 21, 2012 5:39 PM To: dhc WG Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt The authors have sub,tired a new version of this document to address concer= ns raised in the previous WGLC. If you participated in the previous WGLC or= want to participate now, please review the (short) draft and send comments= to the mailing list if you have any. Also please indicate whether you sup= port advancing the draft at this time or not. We will evaluate consensus on October 5.=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From sthaug@nethelp.no Sun Sep 23 23:21:56 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966CC21F8587 for ; Sun, 23 Sep 2012 23:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rH7zaBDidR0o for ; Sun, 23 Sep 2012 23:21:55 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 2E51521F8555 for ; Sun, 23 Sep 2012 23:21:54 -0700 (PDT) Received: (qmail 74623 invoked from network); 24 Sep 2012 06:21:53 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 24 Sep 2012 06:21:53 -0000 Date: Mon, 24 Sep 2012 08:21:52 +0200 (CEST) Message-Id: <20120924.082152.74680594.sthaug@nethelp.no> To: Ted.Lemon@nominum.com From: sthaug@nethelp.no In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 06:21:56 -0000 > The authors have sub,tired a new version of this document to address concerns raised in the previous WGLC. If you participated in the previous WGLC or want to participate now, please review the (short) draft and send comments to the mailing list if you have any. Also please indicate whether you support advancing the draft at this time or not. I support this draft. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From Ted.Lemon@nominum.com Mon Sep 24 09:00:31 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C99D21F87E3 for ; Mon, 24 Sep 2012 09:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.53 X-Spam-Level: X-Spam-Status: No, score=-106.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBl2uxhO6VfI for ; Mon, 24 Sep 2012 09:00:30 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 5E54521F8628 for ; Mon, 24 Sep 2012 09:00:30 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUGCDnUghok7OeEVEiLsdIEnFYFWkgV+B@postini.com; Mon, 24 Sep 2012 09:00:30 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2500D1B82D8 for ; Mon, 24 Sep 2012 09:00:29 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 078B9190043; Mon, 24 Sep 2012 09:00:29 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Mon, 24 Sep 2012 09:00:29 -0700 From: Ted Lemon To: Leaf yeh Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Thread-Index: AQHNeWDyHUsxdHhkUUml/eENyUzBb5dt5P4AgCx5BwA= Date: Mon, 24 Sep 2012 16:00:29 +0000 Message-ID: <8AC1BB64-BA6D-4395-ABA7-1F317C3550D0@nominum.com> References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EA3B4@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 16:00:31 -0000 First of all, I apologize for having taken so long to look at this draft. = The working group is doing quite a bit of work, and it's hard to stay on t= op of it all. I just gave the draft a thorough read, and I have come away with it not kno= wing how I would write a shepherd doc for the draft, because I don't really= understand what it's supposed to do. The motivation for the draft is to = be able to get a DHCP packet up through a tunnel to a DHCP server on the fa= r end of the tunnel. The solution is to use a relay agent to get the pack= et through the tunnel. But how does this work? The relay agent is co-located with the client, ri= ght? So the client sends a DHCP packet, and the relay agent receives it, = and then it relays it up the tunnel, right? But on what interface does th= e client send the packet? On what interface does the relay agent listen? If the answer is that the client sends the packet on the tunnel interface, = you haven't solved the stated problem, because you still are out of spec wi= th respect to RFC3315: you still don't have a link-local address to use as = a source address. If the answer is that the client sends the packet on so= me other interface, that has several problems. The first problem is that now the relay agent has to listen on the interfac= e the client will transmit on. But that interface is a configurable inter= face in its own right. How do we distinguish between DHCP packets intended= to configure that interface, and DHCP packets intended to go up the tunnel= ? Second, how does the relay avoid relaying packets from _other_ hosts? Third, how does the DHCP server know what configuration information to send= ? I think it's quite possible that I have simply failed to understand what th= is draft is trying to do, and that if I did understand, all of these questi= ons would be satisfactorily answered. But the point of writing a draft is= to allow a new reader to understand the proposed solution to the problem; = since I haven't been able to accurately glean that answer from the draft as= written, I think the draft needs more work. As for the question of consensus, Bernie Volz also raised some questions ab= out the draft which Leaf tried to answer, but as far as I can tell did not = actually answer. Although we do seem to have a consensus to advance the d= raft, without answering Bernie's questions and mine, we aren't actually rea= dy to advance yet. So I would appreciate it if the authors and the people who said they wanted= the draft to advance, and whom I assume therefore carefully reviewed the d= raft, would make an effort to fix the draft so that it's possible for a nai= ve reader like me to understand what it says to do. Thanks! From akostur@incognito.com Mon Sep 24 11:57:10 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A123621F8877 for ; Mon, 24 Sep 2012 11:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.744 X-Spam-Level: X-Spam-Status: No, score=-5.744 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fUgLPGgTnAq for ; Mon, 24 Sep 2012 11:57:10 -0700 (PDT) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with SMTP id 7446921F8873 for ; Mon, 24 Sep 2012 11:57:08 -0700 (PDT) Received: from mail-qa0-f51.google.com ([209.85.216.51]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKUGCtBO8jio87gDBIyyHkKS7gU+wvMuRH@postini.com; Mon, 24 Sep 2012 11:57:09 PDT Received: by qabj40 with SMTP id j40so3426670qab.10 for ; Mon, 24 Sep 2012 11:57:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=tlZWg3CNsnp/bAddB5EkJBmRnyGuVitSnO4Iy6HzGS8=; b=gb8qaGDbtCKZf3+0DI1AXAmFvueWzAKYtjJqhDdqEsp5KdZoRz8CO3I6Vc30+287jH wiCZBbMEKqGU/9Gf4OdYCpSp8vCzdHy7WyCgevwDY1VeZ2KiICgJiMp+0fNYX7kN5k8m Y0MCJ8QKIrsWOD6R9xoiJEVYOzBFnkGkveioe0MODZjrBijFUnUF+yW0RE8NaXVoDQpf XOK+UhZ2qQVYnuPmtsTuYHMjtKvuVUzV+IDbH1P3zY8wNEVl6wKgCq9OlXTpiYTqJve8 KN77Ge4SHpDUTbTOJgDTkJ7CYDtU3hN2U9nthpPrjOXeZ7ubKo08kOoA9n5x8yWvKFM8 cW5w== MIME-Version: 1.0 Received: by 10.229.252.196 with SMTP id mx4mr8723887qcb.16.1348513027734; Mon, 24 Sep 2012 11:57:07 -0700 (PDT) Received: by 10.229.65.67 with HTTP; Mon, 24 Sep 2012 11:57:07 -0700 (PDT) Date: Mon, 24 Sep 2012 11:57:07 -0700 Message-ID: From: Andre Kostur To: dhcwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkIVCTbYABQCqUasronCGl7aIQzlx8zvzQuJVVJRB7gd7m+WGHawWe+dcK2Qh2uTKCRt+3T Subject: [dhcwg] Load Balancing for DHCPv6 -01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 18:57:10 -0000 Dear all: I have submitted an updated I-D updating RFC 3074 to apply to DHCPv6. The text is available at: http://www.ietf.org/internet-drafts/draft-kostur-dhc-loadbv6-01.txt Major changes: Added a new Section 3.1 to discuss the requests with a Server ID specified. Modified the specification of the STID to remove the restriction to 16 bytes. Remaining currently outstanding item: There is still outstanding discussion around whether section 3.1 may apply to all messages, vs. whether a server should always answer a Release and/or Decline. See discussion between myself and Bernie. Comments and suggestions welcome. I am looking to have the WG take this on as a work item. -- Andre Kostur From leaf.y.yeh@huawei.com Tue Sep 25 00:48:05 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681B721F890F for ; Tue, 25 Sep 2012 00:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJS54ELt3Y46 for ; Tue, 25 Sep 2012 00:48:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7B18521F8905 for ; Tue, 25 Sep 2012 00:48:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALA15924; Tue, 25 Sep 2012 07:48:02 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 25 Sep 2012 08:47:07 +0100 Received: from SZXEML432-HUB.china.huawei.com (10.72.61.60) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 25 Sep 2012 08:47:44 +0100 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.119]) by SZXEML432-HUB.china.huawei.com ([10.72.61.60]) with mapi id 14.01.0323.003; Tue, 25 Sep 2012 15:47:41 +0800 From: Leaf yeh To: Ted Lemon Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Thread-Index: AQHNdvWqSDMOAnuzpUmlatl1eCUEGJdX0gXAgBWNlcCALAfOgIABToyQ Date: Tue, 25 Sep 2012 07:47:41 +0000 Message-ID: References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EA3B4@xmb-rcd-x04.cisco.com> <8AC1BB64-BA6D-4395-ABA7-1F317C3550D0@nominum.com> In-Reply-To: <8AC1BB64-BA6D-4395-ABA7-1F317C3550D0@nominum.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 07:48:05 -0000 Ted - But how does this work? The relay agent is co-located with the clie= nt, right? So the client sends a DHCP packet, and the relay agent receive= s it, and then it relays it up the tunnel, right? But on what interface d= oes the client send the packet? On what interface does the relay agent li= sten? My reading from the draft sounds: a. The relay is co-located with the clie= nt on the 6rd CE; b. The relay got the packet from the client internally w= ithin the 6rd CE; Ted - If the answer is that the client sends the packet on the tunnel inter= face, you haven't solved the stated problem, because you still are out of s= pec with respect to RFC3315: you still don't have a link-local address to u= se as a source address. I suppose the draft intends to use the address of the relay to communicate = with the server, then avoids the requirement for the LLA of the client. But= the client and the relay sounds in the same device, there is no explicit i= nterface between the client and the relay. Ted - Second, how does the relay avoid relaying packets from _other_ hosts? I guess CE might relay packet from other host, but the peer address in the = Relay-Forward message will not be the unspecified address (::). Ted - Third, how does the DHCP server know what configuration information t= o send? I guess the server might assign the configuration to the client per the add= ress of the relay, while the peer address in the Relay-Forward message will= be the unspecified address (::). Pls. the authors of the draft correct me if I got something wrong. Best Regards, Leaf -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Tuesday, September 25, 2012 12:00 AM To: Leaf yeh Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt First of all, I apologize for having taken so long to look at this draft. = The working group is doing quite a bit of work, and it's hard to stay on t= op of it all. I just gave the draft a thorough read, and I have come away with it not kno= wing how I would write a shepherd doc for the draft, because I don't really= understand what it's supposed to do. The motivation for the draft is to = be able to get a DHCP packet up through a tunnel to a DHCP server on the fa= r end of the tunnel. The solution is to use a relay agent to get the pack= et through the tunnel. But how does this work? The relay agent is co-located with the client, ri= ght? So the client sends a DHCP packet, and the relay agent receives it, = and then it relays it up the tunnel, right? But on what interface does th= e client send the packet? On what interface does the relay agent listen? If the answer is that the client sends the packet on the tunnel interface, = you haven't solved the stated problem, because you still are out of spec wi= th respect to RFC3315: you still don't have a link-local address to use as = a source address. If the answer is that the client sends the packet on so= me other interface, that has several problems. The first problem is that now the relay agent has to listen on the interfac= e the client will transmit on. But that interface is a configurable inter= face in its own right. How do we distinguish between DHCP packets intended= to configure that interface, and DHCP packets intended to go up the tunnel= ? Second, how does the relay avoid relaying packets from _other_ hosts? Third, how does the DHCP server know what configuration information to send= ? I think it's quite possible that I have simply failed to understand what th= is draft is trying to do, and that if I did understand, all of these questi= ons would be satisfactorily answered. But the point of writing a draft is= to allow a new reader to understand the proposed solution to the problem; = since I haven't been able to accurately glean that answer from the draft as= written, I think the draft needs more work. As for the question of consensus, Bernie Volz also raised some questions ab= out the draft which Leaf tried to answer, but as far as I can tell did not = actually answer. Although we do seem to have a consensus to advance the d= raft, without answering Bernie's questions and mine, we aren't actually rea= dy to advance yet. So I would appreciate it if the authors and the people who said they wanted= the draft to advance, and whom I assume therefore carefully reviewed the d= raft, would make an effort to fix the draft so that it's possible for a nai= ve reader like me to understand what it says to do. Thanks! From otroan@employees.org Tue Sep 25 02:55:11 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A344121F88C3 for ; Tue, 25 Sep 2012 02:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3j5TZqtjA9b for ; Tue, 25 Sep 2012 02:55:11 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 76A9921F8823 for ; Tue, 25 Sep 2012 02:55:10 -0700 (PDT) X-Files: smime.p7s : 4351 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAD5+YVCQ/khN/2dsb2JhbABFvmiBCIIgAQEBAwESAWYFCwtGAlUGLgeHXQYLmD2PV5B/kH1gA45riA+NJoFpgmk X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="p7s'?scan'208";a="8299273" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 25 Sep 2012 09:55:06 +0000 Received: from dhcp-lys01-vla250-10-147-112-179.cisco.com (dhcp-lys01-vla250-10-147-112-179.cisco.com [10.147.112.179]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8P9t6hR024715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Sep 2012 09:55:06 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_93EFE4B9-5818-405C-9C7C-E8D3B5A65739"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <8AC1BB64-BA6D-4395-ABA7-1F317C3550D0@nominum.com> Date: Tue, 25 Sep 2012 11:55:05 +0200 Message-Id: References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EA3B4@xmb-rcd-x04.cisco.com> <8AC1BB64-BA6D-4395-ABA7-1F317C3550D0@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1498) Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 09:55:11 -0000 --Apple-Mail=_93EFE4B9-5818-405C-9C7C-E8D3B5A65739 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ted, > First of all, I apologize for having taken so long to look at this = draft. The working group is doing quite a bit of work, and it's hard = to stay on top of it all. >=20 > I just gave the draft a thorough read, and I have come away with it = not knowing how I would write a shepherd doc for the draft, because I = don't really understand what it's supposed to do. The motivation for = the draft is to be able to get a DHCP packet up through a tunnel to a = DHCP server on the far end of the tunnel. The solution is to use a = relay agent to get the packet through the tunnel. >=20 > But how does this work? The relay agent is co-located with the = client, right? So the client sends a DHCP packet, and the relay agent = receives it, and then it relays it up the tunnel, right? But on what = interface does the client send the packet? On what interface does the = relay agent listen? this is quite similar to how = http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-ipv6-05 works (I = think). > If the answer is that the client sends the packet on the tunnel = interface, you haven't solved the stated problem, because you still are = out of spec with respect to RFC3315: you still don't have a link-local = address to use as a source address. If the answer is that the client = sends the packet on some other interface, that has several problems. a global source address is used by the relay. or are you thinking of the link-address field in the relay message? > The first problem is that now the relay agent has to listen on the = interface the client will transmit on. But that interface is a = configurable interface in its own right. How do we distinguish between = DHCP packets intended to configure that interface, and DHCP packets = intended to go up the tunnel? the use of a relay message is purely to get around the 3315 restriction = of using a link-local address. the client is local to the node. assume for arguments sake that in the = implementation the client is acting also as the relay. > Second, how does the relay avoid relaying packets from _other_ hosts? it isn't a relay, it is a client using the relay message. we should make = this clearer I think. >=20 > Third, how does the DHCP server know what configuration information to = send? >=20 > I think it's quite possible that I have simply failed to understand = what this draft is trying to do, and that if I did understand, all of = these questions would be satisfactorily answered. But the point of = writing a draft is to allow a new reader to understand the proposed = solution to the problem; since I haven't been able to accurately glean = that answer from the draft as written, I think the draft needs more = work. >=20 > As for the question of consensus, Bernie Volz also raised some = questions about the draft which Leaf tried to answer, but as far as I = can tell did not actually answer. Although we do seem to have a = consensus to advance the draft, without answering Bernie's questions and = mine, we aren't actually ready to advance yet. >=20 > So I would appreciate it if the authors and the people who said they = wanted the draft to advance, and whom I assume therefore carefully = reviewed the draft, would make an effort to fix the draft so that it's = possible for a naive reader like me to understand what it says to do. cheers, Ole --Apple-Mail=_93EFE4B9-5818-405C-9C7C-E8D3B5A65739 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwOTI1MDk1NTA2WjAjBgkqhkiG9w0BCQQxFgQUOUa8J1lj8+F9ES0t V1W2R8lzhyIwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAfLjaKIJMM5VnytXMLgod w9uJ/+nE4hQ3saUcg8BHhZeoPCyf19CA+pFSJGXXpVi7vp3pap7vvQQCU+8QIhxrG+bunR/Lwfow OoQs7biOBhYVBJo4LZp8Awo93Espx4vDed2l4vE9AvtXTOJ0947BpuCVdBVgSJI44OY5eMp/+o86 OIogxQ/3uD9WezNoFTfnB429m2+OiF8NP83iWHcQ6vsbWJRxvTpLRY5LSZ+WeOMSCQwwzS2pLCO7 CD/gXHaIldkaVb4ZjbletyLcVoPgoeviJQP2PqaqvhCwm8hpQRplBkWHuCCgwOaRqYwN+nJXMyoC 7uK++wTHiEYEMyZdUgAAAAAAAA== --Apple-Mail=_93EFE4B9-5818-405C-9C7C-E8D3B5A65739-- From Ted.Lemon@nominum.com Tue Sep 25 07:18:00 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55F221F8557 for ; Tue, 25 Sep 2012 07:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.381 X-Spam-Level: X-Spam-Status: No, score=-106.381 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvJhIq0KZQYC for ; Tue, 25 Sep 2012 07:17:59 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4A12F21F8570 for ; Tue, 25 Sep 2012 07:17:59 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUGG9Fle2iO0VHtYj299b0XL3RvOqnOnt@postini.com; Tue, 25 Sep 2012 07:17:59 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7B0671B8301 for ; Tue, 25 Sep 2012 07:17:58 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6E75219005C; Tue, 25 Sep 2012 07:17:58 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Tue, 25 Sep 2012 07:17:58 -0700 From: Ted Lemon To: =?Windows-1252?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Thread-Index: AQHNeWDyHUsxdHhkUUml/eENyUzBb5dt5P4AgCx5BwCAASw+gIAASXKA Date: Tue, 25 Sep 2012 14:17:57 +0000 Message-ID: References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EA3B4@xmb-rcd-x04.cisco.com> <8AC1BB64-BA6D-4395-ABA7-1F317C3550D0@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8BB5EC10418F74418F67594D584ABF81@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 14:18:00 -0000 On Sep 25, 2012, at 5:55 AM, Ole Tr=F8an wrote: > the use of a relay message is purely to get around the 3315 restriction o= f using a link-local address. > the client is local to the node. assume for arguments sake that in the im= plementation the client is acting also as the relay. I suspected as much. IMHO, this is the wrong thing to do. Just use the = tunnel endpoint address instead of the link-local address in the case where= there is no link-local address. You'd have to make this standards-track = and update RFC3315, but I think that's okay. There's no magic to using th= e link-local address on broadcast interfaces=97it's just the one address we= can always count on the client having. Of course, in this case we can't = count on that, and if you look at section 1.1 of RFC3315 and section 11, yo= u can see that the standard already accounts for cases where the link-local= address is not used. Actually, it looks like the spec may have a bug wit= h respect to unicast that needs to be fixed. From xuxiaohu@huawei.com Wed Sep 26 01:12:47 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2AF21F87E5 for ; Wed, 26 Sep 2012 01:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.47 X-Spam-Level: X-Spam-Status: No, score=-4.47 tagged_above=-999 required=5 tests=[AWL=1.829, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbLC+lPEUfch for ; Wed, 26 Sep 2012 01:12:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A8BA821F87CB for ; Wed, 26 Sep 2012 01:12:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKA51973; Wed, 26 Sep 2012 08:12:43 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 26 Sep 2012 09:11:37 +0100 Received: from SZXEML426-HUB.china.huawei.com (10.72.61.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 26 Sep 2012 09:12:27 +0100 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.168]) by szxeml426-hub.china.huawei.com ([10.72.61.34]) with mapi id 14.01.0323.003; Wed, 26 Sep 2012 16:12:24 +0800 From: Xuxiaohu To: Ted Lemon , =?utf-8?B?T2xlIFRyw7hhbg==?= Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Thread-Index: AQHNeWDySDMOAnuzpUmlatl1eCUEGJdt5P4AgCx5BwCAADDJgIAASXKAgAGR98A= Date: Wed, 26 Sep 2012 08:12:24 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0755CBD0@szxeml525-mbx.china.huawei.com> References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EA3B4@xmb-rcd-x04.cisco.com> <8AC1BB64-BA6D-4395-ABA7-1F317C3550D0@nominum.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.24] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 08:12:47 -0000 DQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IGRoY3dnLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSDku6PooaggVGVkDQo+IExl bW9uDQo+IOWPkemAgeaXtumXtDogMjAxMuW5tDnmnIgyNeaXpSAyMjoxOA0KPiDmlLbku7bkuro6 IE9sZSBUcsO4YW4NCj4g5oqE6YCBOiBkaGMgV0cNCj4g5Li76aKYOiBSZTogW2RoY3dnXSBXR0xD OiBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtdHVubmVsLTAxLnR4dA0KPiANCj4gT24gU2VwIDI1LCAy MDEyLCBhdCA1OjU1IEFNLCBPbGUgVHLDuGFuIDxvdHJvYW5AZW1wbG95ZWVzLm9yZz4gd3JvdGU6 DQo+ID4gdGhlIHVzZSBvZiBhIHJlbGF5IG1lc3NhZ2UgaXMgcHVyZWx5IHRvIGdldCBhcm91bmQg dGhlIDMzMTUgcmVzdHJpY3Rpb24gb2YNCj4gdXNpbmcgYSBsaW5rLWxvY2FsIGFkZHJlc3MuDQo+ ID4gdGhlIGNsaWVudCBpcyBsb2NhbCB0byB0aGUgbm9kZS4gYXNzdW1lIGZvciBhcmd1bWVudHMg c2FrZSB0aGF0IGluIHRoZQ0KPiBpbXBsZW1lbnRhdGlvbiB0aGUgY2xpZW50IGlzIGFjdGluZyBh bHNvIGFzIHRoZSByZWxheS4NCj4gDQo+IEkgc3VzcGVjdGVkIGFzIG11Y2guICAgSU1ITywgdGhp cyBpcyB0aGUgd3JvbmcgdGhpbmcgdG8gZG8uICAgSnVzdCB1c2UgdGhlDQo+IHR1bm5lbCBlbmRw b2ludCBhZGRyZXNzIGluc3RlYWQgb2YgdGhlIGxpbmstbG9jYWwgYWRkcmVzcyBpbiB0aGUgY2Fz ZSB3aGVyZQ0KPiB0aGVyZSBpcyBubyBsaW5rLWxvY2FsIGFkZHJlc3MuICAgWW91J2QgaGF2ZSB0 byBtYWtlIHRoaXMgc3RhbmRhcmRzLXRyYWNrIGFuZA0KPiB1cGRhdGUgUkZDMzMxNSwgYnV0IEkg dGhpbmsgdGhhdCdzIG9rYXkuICAgVGhlcmUncyBubyBtYWdpYyB0byB1c2luZyB0aGUNCg0KSGkg VGVkLA0KDQpJbiBmYWN0LCBvbmUgb2YgdGhlIGNvLWF1dGhvcnMgaGFkIGV2ZXIgcHJvcG9zZWQg dG8gdXBkYXRlIFJGQzMzMTUgZm9yIHRoZSBwdXJwb3NlIG9mIHJlbGF4aW5nIHRoYXQgbGltaXRh dGlvbiBvZiB1c2luZyBsaW5rLWxvY2FsIGFkZHJlc3Nlcy4gSG93ZXZlciwgc2luY2UgaXQgd2ls bCBjYXVzZSBjaGFuZ2VzIHRvIHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucyBhbmQgZXNwZWNp YWxseSB0aGUgaW1wbGVtZW50YXRpb25zIG9mIERIQ1Agc2VydmVycywgd2UgY28tYXV0aG9ycyBm aW5hbGx5IHJlYWNoZWQgYSBjb25zZW5zdXMgdGhhdCB3ZSdkIGJldHRlciBhdm9pZCB1cGRhdGlu ZyBSRkMzMzE1IGlmIHBvc3NpYmxlLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiBsaW5r LWxvY2FsIGFkZHJlc3Mgb24gYnJvYWRjYXN0IGludGVyZmFjZXPigJRpdCdzIGp1c3QgdGhlIG9u ZSBhZGRyZXNzIHdlIGNhbg0KPiBhbHdheXMgY291bnQgb24gdGhlIGNsaWVudCBoYXZpbmcuICAg T2YgY291cnNlLCBpbiB0aGlzIGNhc2Ugd2UgY2FuJ3QgY291bnQgb24NCj4gdGhhdCwgYW5kIGlm IHlvdSBsb29rIGF0IHNlY3Rpb24gMS4xIG9mIFJGQzMzMTUgYW5kIHNlY3Rpb24gMTEsIHlvdSBj YW4gc2VlIHRoYXQJDQo+IHRoZSBzdGFuZGFyZCBhbHJlYWR5IGFjY291bnRzIGZvciBjYXNlcyB3 aGVyZSB0aGUgbGluay1sb2NhbCBhZGRyZXNzIGlzIG5vdA0KPiB1c2VkLiAgIEFjdHVhbGx5LCBp dCBsb29rcyBsaWtlIHRoZSBzcGVjIG1heSBoYXZlIGEgYnVnIHdpdGggcmVzcGVjdCB0byB1bmlj YXN0DQo+IHRoYXQgbmVlZHMgdG8gYmUgZml4ZWQuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBkaGN3ZyBtYWlsaW5nIGxpc3QNCj4gZGhj d2dAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3 Zw0K From otroan@employees.org Wed Sep 26 01:48:47 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C338121F87D5 for ; Wed, 26 Sep 2012 01:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTMWKO8Ff9PE for ; Wed, 26 Sep 2012 01:48:47 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 27A1E21F87CF for ; Wed, 26 Sep 2012 01:48:47 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id BA0F45E24; Wed, 26 Sep 2012 01:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=x9z7f9JfloiSuje+/WeJO JEc++4=; b=WKH8t1SHHLcDhCjT5wo85WHWQai9IbibZVHmsgYakl9ejNwWyzqKe Vd3vql/ecBIaSHQnR6ZdMi2SiLq1fh7pYmE/Q8FvDfFqV6OfWkD5owhMgcg5AK3f dGGSocUDHx+GO9fpq5x6ElBwXaS0chEhWFCIOse+oEIdXhid+lP/PY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=OXEGHIZg2mO+M66 3VMLqkjtULOgg06pXpcZOcwhpnFJSX1iJTtoYUfOu3b/508bTQeF/PG7dcuooGSn 7onylgs6UUFGWihLh5pdypVleboRnjz/XTfEqaz2NoCOqLkDRZ88Exao1a9EbZgg VfBvoMNgc8ss7Yb5JXCYB4mWwSeY= Received: from dhcp-lys01-vla250-10-147-112-179.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id B8C6F5E1D; Wed, 26 Sep 2012 01:48:45 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_B7AA5CCA-2CF6-4EC4-BD37-940D506093ED"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Wed, 26 Sep 2012 10:48:39 +0200 Message-Id: <39714EDD-C5DA-4DDF-AD10-E06A934EEDAE@employees.org> References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EA3B4@xmb-rcd-x04.cisco.com> <8AC1BB64-BA6D-4395-ABA7-1F317C3550D0@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1498) Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 08:48:47 -0000 --Apple-Mail=_B7AA5CCA-2CF6-4EC4-BD37-940D506093ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ted, >> the use of a relay message is purely to get around the 3315 = restriction of using a link-local address. >> the client is local to the node. assume for arguments sake that in = the implementation the client is acting also as the relay. >=20 > I suspected as much. IMHO, this is the wrong thing to do. Just use = the tunnel endpoint address instead of the link-local address in the = case where there is no link-local address. You'd have to make this = standards-track and update RFC3315, but I think that's okay. There's = no magic to using the link-local address on broadcast interfaces=97it's = just the one address we can always count on the client having. Of = course, in this case we can't count on that, and if you look at section = 1.1 of RFC3315 and section 11, you can see that the standard already = accounts for cases where the link-local address is not used. Actually, = it looks like the spec may have a bug with respect to unicast that needs = to be fixed. I think we should do this too. let us make sure we get that into the = RFC3315bis that I clearly remember you volunteered to write. ;-) this draft proposes a solution that only affects the client = implementation though (that is changing anyway), so I think we need this = for a deployable solution. cheers, Ole= --Apple-Mail=_B7AA5CCA-2CF6-4EC4-BD37-940D506093ED Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwOTI2MDg0ODQwWjAjBgkqhkiG9w0BCQQxFgQU6JofS4SL2J0N85FI poBEfyQGMYkwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAi/m0mMmgQFztPTu/ReGq bteULAQonfzNQcM8OdATZBXnltOXFiwUKQihRZMePn0ZYhlU484gmQulMQKhuokx4miAOCEGnfdo Zo/RcVjeHmJFsDq3qD8azMtQ4L3CBucmB9WMa6ZmR8XBNwjvXzDVY7lrF8TOx8rzoHVSOyQptf78 CU75ifUE52KYTykva4KcHQGP32fRhEDM9xwTo2xgQLTXNdB3sGIoFBd8dS9/CntpPBlXgROgfu/e amvLnzdniqApWmmHGpL64AgJ/GwcT+WSQWMNaxM7um4V7+gR5+hNfyOv1SVrnhlMUS6Ao98Ks6IP UjHo+AcZXV0dR4GiXgAAAAAAAA== --Apple-Mail=_B7AA5CCA-2CF6-4EC4-BD37-940D506093ED-- From Ted.Lemon@nominum.com Wed Sep 26 05:41:41 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B58021F8853 for ; Wed, 26 Sep 2012 05:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.502 X-Spam-Level: X-Spam-Status: No, score=-106.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdeYAdoPFwZV for ; Wed, 26 Sep 2012 05:41:41 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id EE42521F8817 for ; Wed, 26 Sep 2012 05:41:40 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUGL4BB1oXls1bu+kBA/UdYvVpdCBv/yA@postini.com; Wed, 26 Sep 2012 05:41:41 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 102391B8322 for ; Wed, 26 Sep 2012 05:41:40 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0309119005C; Wed, 26 Sep 2012 05:41:40 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Wed, 26 Sep 2012 05:41:34 -0700 From: Ted Lemon To: Xuxiaohu Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Thread-Index: AQHNeWDyHUsxdHhkUUml/eENyUzBb5dt5P4AgCx5BwCAASw+gIAASXKAgAEsMwCAAEswgA== Date: Wed, 26 Sep 2012 12:41:32 +0000 Message-ID: <2F7703E0-D017-4CCC-8AF8-CDFA8644040F@nominum.com> References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EA3B4@xmb-rcd-x04.cisco.com> <8AC1BB64-BA6D-4395-ABA7-1F317C3550D0@nominum.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0755CBD0@szxeml525-mbx.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0755CBD0@szxeml525-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <82780169F887B04A8C410978EE486FA6@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 12:41:41 -0000 On Sep 26, 2012, at 4:12 AM, Xuxiaohu wrote: > In fact, one of the co-authors had ever proposed to update RFC3315 for th= e purpose of relaxing that limitation of using link-local addresses. Howeve= r, since it will cause changes to the protocol specifications and especiall= y the implementations of DHCP servers, we co-authors finally reached a cons= ensus that we'd better avoid updating RFC3315 if possible. Why is it so important not to update RFC3315? And what changes would be r= equired to DHCP servers?= From Ted.Lemon@nominum.com Wed Sep 26 05:57:46 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF7D21F86CB for ; Wed, 26 Sep 2012 05:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.737 X-Spam-Level: X-Spam-Status: No, score=-105.737 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYQe7NMk54I4 for ; Wed, 26 Sep 2012 05:57:45 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3912D21F860D for ; Wed, 26 Sep 2012 05:57:45 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUGL7yc3cfG/OaUqTkKx7G+ISAV/pK+XT@postini.com; Wed, 26 Sep 2012 05:57:45 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 890A81B82E5 for ; Wed, 26 Sep 2012 05:57:44 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7C74619005C; Wed, 26 Sep 2012 05:57:44 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Wed, 26 Sep 2012 05:57:44 -0700 From: Ted Lemon To: =?Windows-1252?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Thread-Index: AQHNeWDyHUsxdHhkUUml/eENyUzBb5dt5P4AgCx5BwCAASw+gIAASXKAgAE2VICAAEWWgA== Date: Wed, 26 Sep 2012 12:57:43 +0000 Message-ID: <8275EA44-3606-4C82-A656-653B56009D09@nominum.com> References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EA3B4@xmb-rcd-x04.cisco.com> <8AC1BB64-BA6D-4395-ABA7-1F317C3550D0@nominum.com> <39714EDD-C5DA-4DDF-AD10-E06A934EEDAE@employees.org> In-Reply-To: <39714EDD-C5DA-4DDF-AD10-E06A934EEDAE@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 12:57:46 -0000 On Sep 26, 2012, at 4:48 AM, Ole Tr=F8an wrote: > I think we should do this too. let us make sure we get that into the RFC3= 315bis that I clearly remember you volunteered to write. ;-) > this draft proposes a solution that only affects the client implementatio= n though (that is changing anyway), so I think we need this for a deployabl= e solution. The changes required to RFC3315 to do what you want are minor and don't req= uire a spin of the full document=97you can just issue a short document, abo= ut the length of your current one, that updates RFC3315. This will get yo= u what you want in the short term, and then we can fold your work into the = RFC3315 update when the time comes. What you are doing here is proposing something completely different, that i= s unnecessarily complicated, and makes things worse, and that will not be c= ompatible with the subsequent update to RFC3315. IOW, two solutions, wher= e one would have done better. From otroan@employees.org Wed Sep 26 06:12:06 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D434521F884F for ; Wed, 26 Sep 2012 06:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.679 X-Spam-Level: X-Spam-Status: No, score=-9.679 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXfJ7lKWCGeO for ; Wed, 26 Sep 2012 06:12:06 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1C70021F86F4 for ; Wed, 26 Sep 2012 06:12:04 -0700 (PDT) X-Files: smime.p7s : 4351 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAN/+YlCQ/khM/2dsb2JhbABFvlmBCIIgAQEBAwESAWYFCwtGAlUGLgeHXQaaF6ApkEFgA45ulT2BaYJp X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="p7s'?scan'208";a="76988701" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 26 Sep 2012 13:12:01 +0000 Received: from dhcp-lys01-vla250-10-147-112-179.cisco.com (dhcp-lys01-vla250-10-147-112-179.cisco.com [10.147.112.179]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8QDC010011463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Sep 2012 13:12:00 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_41452E10-80C1-4F61-B814-8848AF58BE01"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <8275EA44-3606-4C82-A656-653B56009D09@nominum.com> Date: Wed, 26 Sep 2012 15:11:59 +0200 Message-Id: <2144A493-A8A0-46C3-9281-1F2D58867685@employees.org> References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EA3B4@xmb-rcd-x04.cisco.com> <8AC1BB64-BA6D-4395-ABA7-1F317C3550D0@nominum.com> <39714EDD-C5DA-4DDF-AD10-E06A934EEDAE@employees.org> <8275EA44-3606-4C82-A656-653B56009D09@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1498) Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 13:12:07 -0000 --Apple-Mail=_41452E10-80C1-4F61-B814-8848AF58BE01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ted, >> I think we should do this too. let us make sure we get that into the = RFC3315bis that I clearly remember you volunteered to write. ;-) >> this draft proposes a solution that only affects the client = implementation though (that is changing anyway), so I think we need this = for a deployable solution. >=20 > The changes required to RFC3315 to do what you want are minor and = don't require a spin of the full document=97you can just issue a short = document, about the length of your current one, that updates RFC3315. = This will get you what you want in the short term, and then we can fold = your work into the RFC3315 update when the time comes. there would be two client/server changes: - allow global unicast addresses as source address - allow a unicast address as destination address to reach the DHCPv6 = server there are a few MUSTs that must be changed. equally there might be = security implications, and new text for how the server should deal with = on or offlink clients. > What you are doing here is proposing something completely different, = that is unnecessarily complicated, and makes things worse, and that will = not be compatible with the subsequent update to RFC3315. IOW, two = solutions, where one would have done better. this isn't completely different. the draft describes how this can be = achieved with existing DHCPv6 servers and within current RFC3315. what is complicated and what is not compatible? cheers, Ole= --Apple-Mail=_41452E10-80C1-4F61-B814-8848AF58BE01 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwOTI2MTMxMTYwWjAjBgkqhkiG9w0BCQQxFgQUEzaJA3OeiZUulFFJ xYtdTD6LHvUwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAsRFzJIMZc//hcf044tZQ XUGDUY06G3EDVgcAJh/ozieNi5sJ0ClkzyfbA1uuR+lsUSYkcchmZwlWOICSxoWlxNw75kTg/vNf oUydr+Ss+z7twEB4Xzp1Pvi8YgNzSijbEyZw02DdMIEPBABLEHWzsCbI8CC/6j+wMYVdMsT22SlC 12UffRKuozDp0EsFe+7ulyfpTZGZ9QB3TJIm1jXb3t72OP6ovTAoczUjcDtV1vxdlcOL/JPuTKar ZhaGGX0Cygzkbu5R2pSL8/jO9XFmhxUR58Uei9zXy8Bh1EFD2rB3XWup/9WOs1jp4wtttxMNKXkk JcP5tZSVDRrQTXYQNQAAAAAAAA== --Apple-Mail=_41452E10-80C1-4F61-B814-8848AF58BE01-- From tomasz.mrugalski@gmail.com Wed Sep 26 06:33:40 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA5521F86D8 for ; Wed, 26 Sep 2012 06:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OG3cYdRZ1eUV for ; Wed, 26 Sep 2012 06:33:33 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 85AA021F86D4 for ; Wed, 26 Sep 2012 06:33:33 -0700 (PDT) Received: by bkcjc3 with SMTP id jc3so324004bkc.31 for ; Wed, 26 Sep 2012 06:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=0yuu8iFJ2QESu9lQJERh1L5Wkfc5vYEDCOasJfRbrrk=; b=ENr1O+RiZiU3KJTbjbqTkpWG3U8Fv/AL7tp+DfXUVmknmWWKtfQvzjO8XLkuB9OJCY wZDJHUuZtQu3vDa4vSvLoFDL0UV3P+Ih+3SJZHa2DrFAlMWcnzodvvnC9JF6Iwe79Vog o4UbvP7NBd2Qq6oSWmWeH5blg4y1kgUL73N21AJrMYg5ie6ze3daKXmADMQMoJPRDe5G EY+Cfp3NgG6GHkHK057G7bckTVp2dcnKcPrGBCZjtLhtXl6ZQ25MyrP3OCV7LT75mGGC OcvclPjqcWneH5z3iZ4doc/y9w496xcNWwhp41gU8+RXHVi8tGit1swO16qFV10B7Wt0 +5EQ== Received: by 10.204.157.6 with SMTP id z6mr514024bkw.25.1348666412415; Wed, 26 Sep 2012 06:33:32 -0700 (PDT) Received: from ?IPv6:2001:470:6061:1:31aa:f7e:fa88:4ff9? ([2001:470:6061:1:31aa:f7e:fa88:4ff9]) by mx.google.com with ESMTPS id c18sm2484030bkv.8.2012.09.26.06.33.30 (version=SSLv3 cipher=OTHER); Wed, 26 Sep 2012 06:33:31 -0700 (PDT) Message-ID: <50630427.2020100@gmail.com> Date: Wed, 26 Sep 2012 15:33:27 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: dhcwg References: <504A1D13.8090003@gmail.com> In-Reply-To: <504A1D13.8090003@gmail.com> X-TagToolbar-Keys: D20120926153327609 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ted Lemon Subject: [dhcwg] WGLC request on draft-ietf-dhc-dhcpv6-failover-requirements-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 13:33:40 -0000 Hi, Authors of DHCPv6 Failover Requirements draft believe that it is ready for a last call. Therefore I would like to ask chairs to announce WGLC on draft-ietf-dhc-dhcpv6-failover-requirements-02. Thanks, Tomek On 07.09.2012 18:13, Tomek Mrugalski wrote: > Hi, > You may have noticed some recent movements in the failover area. It may > be a bit confusing, so I wanted to explain what has happened recently. > > Step 0: DHCPv6 Redundancy Considerations > draft-ietf-dhc-dhcpv6-redundancy-consider-03 > This draft is in IESG review now. A kind of soft discuss was raised, so > authors worked on an updated version that hopefully addresses all > concerns. It already completed WGLC, so no extra actions are requested > at this time. Of course, you are welcome to (re)read and review it, but > if your time is limited, there are better things to do to help with > failover (see steps 1 and 2 below). > > Step 1: DHCPv6 Failover Requirements > draft-ietf-dhc-dhcpv6-failover-requirements-02 > This is a first in a series of 3 drafts planned. It lays out > requirements for DHCPv6 failover. Authors believe that work on this > document is more or less done and would like to ask for WGLC. If you > have only short time for failover related things, please review this. > > Step 2: DHCPv6 Failover Design > draft-ietf-dhc-dhcpv6-failover-design-01 > This is the actual design. There is a significant progress from the -00 > version, but this work is not complete yet. Although failover endpoints > state machine and lease lifecycle descriptions are more or less > complete, there are still missing bits and pieces. See several TODO tags > in the txt version or issues marked in XML version. It would be great to > hear your comments and suggestions about this draft, or even better, > contributed text for missing pieces. > > There is a step 3 planned - the actual on-wire spec for the design laid > out in failover-design draft. This work hasn't started yet. > > If you are interested in the failover work, you are more then welcome to > join the effort. We have a public GIT repo for intermediate versions, > with a simple list of issues, historical v4 failover drafts etc. It is > available here: https://github.com/tomaszmrugalski/ietf-dhcpv6-fo > > Cheers, > Tomek > From Ted.Lemon@nominum.com Wed Sep 26 07:29:52 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A85421F8815 for ; Wed, 26 Sep 2012 07:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.342 X-Spam-Level: X-Spam-Status: No, score=-106.342 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lW86Cj0Cn2bt for ; Wed, 26 Sep 2012 07:29:51 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7AD21F86E5 for ; Wed, 26 Sep 2012 07:29:51 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUGMRXzsFU+yxBbEovm4VjxwR8ThRYsUV@postini.com; Wed, 26 Sep 2012 07:29:51 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A1B021B829F for ; Wed, 26 Sep 2012 07:29:50 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 98E3E19005C; Wed, 26 Sep 2012 07:29:50 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 26 Sep 2012 07:29:50 -0700 From: Ted Lemon To: =?Windows-1252?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Thread-Index: AQHNeWDyHUsxdHhkUUml/eENyUzBb5dt5P4AgCx5BwCAASw+gIAASXKAgAE2VICAAEWWgIAAA/2AgAAVvQA= Date: Wed, 26 Sep 2012 14:29:50 +0000 Message-ID: <7329B869-8093-4EDA-8490-1491D97D22D8@nominum.com> References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EA3B4@xmb-rcd-x04.cisco.com> <8AC1BB64-BA6D-4395-ABA7-1F317C3550D0@nominum.com> <39714EDD-C5DA-4DDF-AD10-E06A934EEDAE@employees.org> <8275EA44-3606-4C82-A656-653B56009D09@nominum.com> <2144A493-A8A0-46C3-9281-1F2D58867685@employees.org> In-Reply-To: <2144A493-A8A0-46C3-9281-1F2D58867685@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2DFF8810A5E78445A1C2DD4E45468E60@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 14:29:52 -0000 On Sep 26, 2012, at 9:11 AM, Ole Tr=F8an wrote: > - allow a unicast address as destination address to reach the DHCPv6 serv= er Huh. How does the client know that address? Why aren't you advertising = a route to the All_DHCP_Servers multicast address down the tunnel? > there are a few MUSTs that must be changed. equally there might be securi= ty implications, and new text for how the server should deal with on or off= link clients. Wouldn't the security implications be the same in both cases? You realize= that RFC3315 does allow unicast to the server if it's been negotiated with= the server, right? How are the security implications different in that c= ase than in this one? How does putting in a fake relay agent change thing= s? Can't any client put in a fake relay agent, whether they are at a tunn= el endpoint or not? I can help you to work through the security considera= tions section if that's your only concern. > this isn't completely different. the draft describes how this can be achi= eved with existing DHCPv6 servers and within current RFC3315. > what is complicated and what is not compatible? You have to hack the client to pretend it's a relay agent. If this happen= s, you're going to wind up with clients like that all over the place, and y= our DHCP deployment is going to have to handle them correctly. And then i= f we change RFC3315 to solve the problem the right way, then your DHCP depl= oyment is going to have to handle both mechanisms, one of which delivers a = packet with an extra relay package. From tomasz.mrugalski@gmail.com Wed Sep 26 09:51:08 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E15B21F852A for ; Wed, 26 Sep 2012 09:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRNZWVmrcuOB for ; Wed, 26 Sep 2012 09:51:07 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6091A21F84CF for ; Wed, 26 Sep 2012 09:51:07 -0700 (PDT) Received: by bkcjc3 with SMTP id jc3so462965bkc.31 for ; Wed, 26 Sep 2012 09:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-tagtoolbar-keys:x-forwarded-message-id:content-type :content-transfer-encoding; bh=0tbsq21GyQQu928Y60334w+DGoLhwnRBP+W6hOquWpg=; b=Q9ad7PJ9QREUKvCTSFuipZ1BEGSr9LC3+5V3Y0irobZY2my/RDYzARxySYYWLUSkF2 uvdWkp708eQWBKIttITrsTKk0lPctCZXxImFagqkgwbHkrhFutgtbaTWN6sXqfKgXqrh FFuo0ZYLiQkqX3Eawr/+XwcRW2s6+l9t+c6jMFAEulWpoOMFYL/FELS6qgEpPrWbD5sP tJB1tEZIePBCXoEeqsjVGr7FCHsgcB1+oRFk9CBuKXuOxta1A0AIldgiv9NwT4z3xEh8 3U0aduOQbNRaqioCT9gHg0aT7VmdaHu6J65hw2x/ojS3LLB8ewqzWkrwfyDhO7u/7iBt oLBA== Received: by 10.204.130.10 with SMTP id q10mr882366bks.90.1348678266259; Wed, 26 Sep 2012 09:51:06 -0700 (PDT) Received: from ?IPv6:2001:470:6061:1:31aa:f7e:fa88:4ff9? ([2001:470:6061:1:31aa:f7e:fa88:4ff9]) by mx.google.com with ESMTPS id 25sm2936934bkx.9.2012.09.26.09.51.04 (version=SSLv3 cipher=OTHER); Wed, 26 Sep 2012 09:51:05 -0700 (PDT) Message-ID: <50633275.3060002@gmail.com> Date: Wed, 26 Sep 2012 18:51:01 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: dhcwg References: <20120926162112.30703.49776.idtracker@ietfa.amsl.com> In-Reply-To: <20120926162112.30703.49776.idtracker@ietfa.amsl.com> X-TagToolbar-Keys: D20120926185101142 X-Forwarded-Message-Id: <20120926162112.30703.49776.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Adoption call request for draft-mrugalski-softwire-dhcpv4-over-v6-option-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 16:51:08 -0000 Hi, This document has been presented in Vancouver. We have received several comments during and after the meeting and this updated -01 version reflects those changes. This work was initially planned to be adopted in Softwires, but since it is a companion document for ietf-dhc-dhcpv4-over-ipv6, which is a DHC document, it makes more sense to adopt it in DHC. Also, that's what chairs have suggested. If this draft is adopted, we plan to rename it to draft-ietf-dhc-dhcpv4-over-ipv6-endpoint-option. On behalf of both authors, I would like to ask chairs to announce adoption call on this work. Thanks, Tomek -------- Original Message -------- Subject: New Version Notification for draft-mrugalski-softwire-dhcpv4-over-v6-option-01.txt Date: Wed, 26 Sep 2012 09:21:12 -0700 From: internet-drafts@ietf.org To: tomasz.mrugalski@gmail.com CC: pengwu.thu@gmail.com A new version of I-D, draft-mrugalski-softwire-dhcpv4-over-v6-option-01.txt has been successfully submitted by Tomasz Mrugalski and posted to the IETF repository. Filename: draft-mrugalski-softwire-dhcpv4-over-v6-option Revision: 01 Title: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for DHCPv4 over IPv6 Endpoint Creation date: 2012-09-26 WG ID: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-mrugalski-softwire-dhcpv4-over-v6-option-01.txt Status: http://datatracker.ietf.org/doc/draft-mrugalski-softwire-dhcpv4-over-v6-option Htmlized: http://tools.ietf.org/html/draft-mrugalski-softwire-dhcpv4-over-v6-option-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-mrugalski-softwire-dhcpv4-over-v6-option-01 Abstract: [I-D.ietf-dhc-dhcpv4-over-ipv6] defines a way for communication between legacy DHCPv4 clients with DHCPv4 servers over IPv6-only transport. It requires deployment of Client Relay Agent (CRA) that transmits messages to IPv6-Transport Server (TSV) or IPv6-Transport Relay Agent (TRA). Deployed CRA must know an address of TSV or TRA to forward incoming client's messages. This document defines a DHCPv6 option that may be used to provision TSV or TRA location to CRAs. The IETF Secretariat From Ted.Lemon@nominum.com Wed Sep 26 10:25:12 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3282E21F8569 for ; Wed, 26 Sep 2012 10:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.493 X-Spam-Level: X-Spam-Status: No, score=-106.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVGOi7DSgbmD for ; Wed, 26 Sep 2012 10:25:11 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC2A21F84BF for ; Wed, 26 Sep 2012 10:25:11 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUGM6d60KVcBrQWv6HqVhHs87oEnZULJn@postini.com; Wed, 26 Sep 2012 10:25:11 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B50341B829B for ; Wed, 26 Sep 2012 10:25:10 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id AAA5319005C; Wed, 26 Sep 2012 10:25:10 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 26 Sep 2012 10:25:10 -0700 From: Ted Lemon To: Tomek Mrugalski Thread-Topic: Authors, please do not send CFA or WGLC requests to the WG mailing list. Thread-Index: AQHNnAvhOuifjSgi00a5bdu5xLZ3EQ== Date: Wed, 26 Sep 2012 17:25:09 +0000 Message-ID: <44C607F7-A712-41B6-B439-17F950938A8B@nominum.com> References: <20120926162112.30703.49776.idtracker@ietfa.amsl.com> <50633275.3060002@gmail.com> In-Reply-To: <50633275.3060002@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <2FB9CB6DDE27B04196E5B69BB5878A8C@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhcwg Subject: [dhcwg] Authors, please do not send CFA or WGLC requests to the WG mailing list. X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 17:25:12 -0000 On Sep 26, 2012, at 12:51 PM, Tomek Mrugalski = wrote: > On behalf of both authors, I would like to ask chairs to announce > adoption call on this work. Authors, please don't cc requests like to the mailing list. If you do, th= en people start replying to them before the formal CFA goes out, and it's h= arder to track. This goes for WGLC requests as well. This has been happ= ening a lot recently, and I wonder if people are starting to think that it'= s the right thing to do. It's not. From Ted.Lemon@nominum.com Wed Sep 26 10:27:10 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD5D21F84BF for ; Wed, 26 Sep 2012 10:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.496 X-Spam-Level: X-Spam-Status: No, score=-106.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sE6041j9DMHp for ; Wed, 26 Sep 2012 10:27:10 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id E8CE121F84D3 for ; Wed, 26 Sep 2012 10:27:09 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUGM67bpaMAb8M23x1OYbbCwiJpWz2fqD@postini.com; Wed, 26 Sep 2012 10:27:10 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 53B331B829B for ; Wed, 26 Sep 2012 10:27:09 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 4DB4919005C for ; Wed, 26 Sep 2012 10:27:09 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Wed, 26 Sep 2012 10:27:09 -0700 From: Ted Lemon To: dhcwg WG Thread-Topic: Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-01 Thread-Index: AQHNnAwoksIIq5rbSkG4M+kw2Zj+pQ== Date: Wed, 26 Sep 2012 17:27:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <7E39A9427A8B3B43926D320C2834F3E5@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 17:27:10 -0000 The authors have requested that the working group adopt draft-mrugalski-sof= twire-dhcpv4-over-v6-option as a working group work item. The document is= within the scope of the current charter. It describes a DHCPv6 option th= at is used to configure client relay agents (draft-ietf-dhc-dhcpv4-over-ipv= 6). If you think the working group should be working on such an option, please = respond to this message by saying so. If you think we should not, please = say that. We will evaluate consensus on or after October 10. From Mathias.Samuelson@nominum.com Wed Sep 26 19:29:18 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB2B21F8624 for ; Wed, 26 Sep 2012 19:29:18 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lf6LMX5bkau for ; Wed, 26 Sep 2012 19:29:17 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 36A0621F861C for ; Wed, 26 Sep 2012 19:29:17 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUGO5/Pxh8DTqcp18Y0B0SV1tvGrwFwDR@postini.com; Wed, 26 Sep 2012 19:29:17 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4BC111B82B3 for ; Wed, 26 Sep 2012 19:29:16 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 4333A19005C for ; Wed, 26 Sep 2012 19:29:16 -0700 (PDT) (envelope-from Mathias.Samuelson@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Wed, 26 Sep 2012 19:29:13 -0700 From: Mathias Samuelson To: Ted Lemon Thread-Topic: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-01 Thread-Index: AQHNnAwoksIIq5rbSkG4M+kw2Zj+pZed7QAA Date: Thu, 27 Sep 2012 02:29:12 +0000 Message-ID: <83AC8034-9D2A-46D8-AAF8-EAD29DD790F7@nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <44DE7D8BAF90E5448109F46336B7D098@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhcwg WG Subject: Re: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 02:29:18 -0000 I've read this draft and support adopting it as WG work. Mathias Ps Btw, since this is my first post here I figured I'd introduce myself - I= 'm in product management at Nominum and is working on DHCP stuff! Hi all! On Sep 26, 2012, at 10:27 AM, Ted Lemon wrote: > The authors have requested that the working group adopt draft-mrugalski-s= oftwire-dhcpv4-over-v6-option as a working group work item. The document = is within the scope of the current charter. It describes a DHCPv6 option = that is used to configure client relay agents (draft-ietf-dhc-dhcpv4-over-i= pv6). >=20 > If you think the working group should be working on such an option, pleas= e respond to this message by saying so. If you think we should not, pleas= e say that. >=20 > We will evaluate consensus on or after October 10. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From leaf.y.yeh@huawei.com Wed Sep 26 20:12:43 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0875121F864D for ; Wed, 26 Sep 2012 20:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qrlK41YrkRf for ; Wed, 26 Sep 2012 20:12:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 20BBD21F8643 for ; Wed, 26 Sep 2012 20:12:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKB26452; Thu, 27 Sep 2012 03:12:39 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 27 Sep 2012 04:11:44 +0100 Received: from SZXEML439-HUB.china.huawei.com (10.72.61.74) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 27 Sep 2012 04:12:36 +0100 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.119]) by szxeml439-hub.china.huawei.com ([10.72.61.74]) with mapi id 14.01.0323.003; Thu, 27 Sep 2012 11:12:28 +0800 From: Leaf yeh To: =?iso-8859-1?Q?Ole_Tr=F8an?= , Ted Lemon Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Thread-Index: AQHNdvWqSDMOAnuzpUmlatl1eCUEGJdX0gXAgBWNlcCALAfOgIABLD2AgABJcoCAATZTgIABq0+A Date: Thu, 27 Sep 2012 03:12:27 +0000 Message-ID: References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EA3B4@xmb-rcd-x04.cisco.com> <8AC1BB64-BA6D-4395-ABA7-1F317C3550D0@nominum.com> <39714EDD-C5DA-4DDF-AD10-E06A934EEDAE@employees.org> In-Reply-To: <39714EDD-C5DA-4DDF-AD10-E06A934EEDAE@employees.org> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 03:12:43 -0000 Section 11 of RFC3315 - If the server receives the message directly = from the client and the source address in the IP datagram in which the mess= age was received is not a link-local address, then the client is on the lin= k identified by the source address in the IP datagram (note that this situa= tion can occur only if the server has enabled the use of unicast message de= livery by the client and the client has sent a message for which unicast de= livery is allowed). The above sounds the client could use the GUA for sending its message inste= ad of LLA in some case. Supposed the client also knows the GUA of the serve= r like the case of the relay. Then the technical question turns to be: if t= he assumption sounds the client already has its GUA of IPv6 (at its WAN int= erface?), why not use it directly for the stateless configuration. Best Regards, Leaf -----Original Message----- From: Ole Tr=F8an [mailto:otroan@employees.org]=20 Sent: Wednesday, September 26, 2012 4:49 PM To: Ted Lemon Cc: Leaf yeh; dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Ted, >> the use of a relay message is purely to get around the 3315 restriction = of using a link-local address. >> the client is local to the node. assume for arguments sake that in the i= mplementation the client is acting also as the relay. >=20 > I suspected as much. IMHO, this is the wrong thing to do. Just use th= e tunnel endpoint address instead of the link-local address in the case whe= re there is no link-local address. You'd have to make this standards-trac= k and update RFC3315, but I think that's okay. There's no magic to using = the link-local address on broadcast interfaces-it's just the one address we= can always count on the client having. Of course, in this case we can't = count on that, and if you look at section 1.1 of RFC3315 and section 11, yo= u can see that the standard already accounts for cases where the link-local= address is not used. Actually, it looks like the spec may have a bug wit= h respect to unicast that needs to be fixed. I think we should do this too. let us make sure we get that into the RFC331= 5bis that I clearly remember you volunteered to write. ;-) this draft proposes a solution that only affects the client implementation = though (that is changing anyway), so I think we need this for a deployable = solution. cheers, Ole From otroan@employees.org Thu Sep 27 00:59:45 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5392821F86D9 for ; Thu, 27 Sep 2012 00:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.989 X-Spam-Level: X-Spam-Status: No, score=-9.989 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWXRH58-7fW2 for ; Thu, 27 Sep 2012 00:59:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2B84921F86D5 for ; Thu, 27 Sep 2012 00:59:44 -0700 (PDT) X-Files: smime.p7s : 4351 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIkGZFCQ/khM/2dsb2JhbABFvg+BCIIgAQEBAwESAWYQC0YCVQY1h10Gl3Cff5BVYAOObpU9gWmCaQ X-IronPort-AV: E=Sophos;i="4.80,494,1344211200"; d="p7s'?scan'208";a="144437196" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 27 Sep 2012 07:59:42 +0000 Received: from dhcp-lys01-vla250-10-147-112-179.cisco.com (dhcp-lys01-vla250-10-147-112-179.cisco.com [10.147.112.179]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8R7xfMi028306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Sep 2012 07:59:42 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_53F11B0F-3B7B-43BF-A407-053D56E597E7"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <7329B869-8093-4EDA-8490-1491D97D22D8@nominum.com> Date: Thu, 27 Sep 2012 09:59:40 +0200 Message-Id: <2918F4E4-DD2D-4705-ACBC-5D6E5E0F2357@employees.org> References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EA3B4@xmb-rcd-x04.cisco.com> <8AC1BB64-BA6D-4395-ABA7-1F317C3550D0@nominum.com> <39714EDD-C5DA-4DDF-AD10-E06A934EEDAE@employees.org> <8275EA44-3606-4C82-A656-653B56009D09@nominum.com> <2144A493-A8A0-46C3-9281-1F2D58867685@employees.org> <7329B869-8093-4EDA-8490-1491D97D22D8@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1498) Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 07:59:45 -0000 --Apple-Mail=_53F11B0F-3B7B-43BF-A407-053D56E597E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ted, >> - allow a unicast address as destination address to reach the DHCPv6 = server >=20 > Huh. How does the client know that address? Why aren't you = advertising a route to the All_DHCP_Servers multicast address down the = tunnel? draft: "The 6rd CE DHCPv6 relay agent SHOULD use the 6rd BR IPv6 anycast = address as the destination address,=20 section 20 of [RFC3315]. If the 6rd link supports multicast = [I-D.ietf-mboned-auto-multicast] the 6rd CE DHCPv6 relay MAY use the All_DHCP_Servers [RFC3315] as the = destination address of Relay-forward messages." some links (e.g. 6rd) do not support IPv6 multicast. >> there are a few MUSTs that must be changed. equally there might be = security implications, and new text for how the server should deal with = on or offlink clients. >=20 > Wouldn't the security implications be the same in both cases? You = realize that RFC3315 does allow unicast to the server if it's been = negotiated with the server, right? How are the security implications = different in that case than in this one? How does putting in a fake = relay agent change things? Can't any client put in a fake relay agent, = whether they are at a tunnel endpoint or not? I can help you to work = through the security considerations section if that's your only concern. >=20 >> this isn't completely different. the draft describes how this can be = achieved with existing DHCPv6 servers and within current RFC3315. >> what is complicated and what is not compatible? >=20 > You have to hack the client to pretend it's a relay agent. If this = happens, you're going to wind up with clients like that all over the = place, and your DHCP deployment is going to have to handle them = correctly. And then if we change RFC3315 to solve the problem the = right way, then your DHCP deployment is going to have to handle both = mechanisms, one of which delivers a packet with an extra relay package. I don't quite understand this concern. this draft describes how one can = put together existing DHCP protocol modules to achieve support for links = that do not support link-local addresses and multicast. if we instead were to change 3315 how would a new client speak to an old = server? cheers, Ole= --Apple-Mail=_53F11B0F-3B7B-43BF-A407-053D56E597E7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwOTI3MDc1OTQxWjAjBgkqhkiG9w0BCQQxFgQUdeKvjBu4yGNnfVMD bz6+C0PRxPAwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAZJUAvjI3NW4bhCKGw7Uf eovrN4H0okiV5UfpFNOjYbL6xl4pnjS2xg0+nTwSGRE9oJh2UTvX/w0Bd2Clut74qAKIdrxCWF8u cZTRweHZ4f/+z/pZz8RAUR+uU/pGWLhgSDSqFBKgYH3LKFPVf80W3BrgjIvLq07+pdn+cSJv3+ZD XUtcNeb/fIgADC7j85Do4AY3ZAl+nCiSAzFJ9kOxPp3JTHtxqmdjS0fPQVw2TPRZRcc7W+L7ggQo fVps7l/6g8uMW5ffdF4Hqx7JjQjEp6gQ7VzuADqZZM1Pw4A7NwsNoACaIO8l4wIoiBirP6Rjf8oY vbLT1UvDIx78WdBTnAAAAAAAAA== --Apple-Mail=_53F11B0F-3B7B-43BF-A407-053D56E597E7-- From Ted.Lemon@nominum.com Thu Sep 27 05:58:14 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F1B21F8425 for ; Thu, 27 Sep 2012 05:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.348 X-Spam-Level: X-Spam-Status: No, score=-106.348 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClDUbdK01qDm for ; Thu, 27 Sep 2012 05:58:13 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2A61C21F841E for ; Thu, 27 Sep 2012 05:58:13 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUGRNZCQjs+GJqd6ilbEXT8jEQnnUj2Sj@postini.com; Thu, 27 Sep 2012 05:58:13 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 49C3E1B8075 for ; Thu, 27 Sep 2012 05:58:12 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3EA5519005C; Thu, 27 Sep 2012 05:58:12 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 27 Sep 2012 05:58:12 -0700 From: Ted Lemon To: =?Windows-1252?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Thread-Index: AQHNeWDyHUsxdHhkUUml/eENyUzBb5dt5P4AgCx5BwCAASw+gIAASXKAgAE2VICAAEWWgIAAA/2AgAAVvQCAASVVAIAAU2eA Date: Thu, 27 Sep 2012 12:58:12 +0000 Message-ID: References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EA3B4@xmb-rcd-x04.cisco.com> <8AC1BB64-BA6D-4395-ABA7-1F317C3550D0@nominum.com> <39714EDD-C5DA-4DDF-AD10-E06A934EEDAE@employees.org> <8275EA44-3606-4C82-A656-653B56009D09@nominum.com> <2144A493-A8A0-46C3-9281-1F2D58867685@employees.org> <7329B869-8093-4EDA-8490-1491D97D22D8@nominum.com> <2918F4E4-DD2D-4705-ACBC-5D6E5E0F2357@employees.org> In-Reply-To: <2918F4E4-DD2D-4705-ACBC-5D6E5E0F2357@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 12:58:14 -0000 On Sep 27, 2012, at 3:59 AM, Ole Tr=F8an wrote: > I don't quite understand this concern. this draft describes how one can p= ut together existing DHCP protocol modules to achieve support for links tha= t do not support link-local addresses and multicast. This is really a two-bad-choices situation. If you add a relay header jus= t to hack around the restriction in the DHCP server, that's weird. But if= you hack the DHCP server to allow unicast, that's bad too, because then we= 'll start to see clients doing this because the implementor just tested aga= inst the server without carefully following the spec. In practice, the ISC server currently will drop packets that are unicast. = The Nominum server, as far as I can tell, doesn't, and the return path in = the Nominum server at least looks like it works for unicast packets; I susp= ect that's true of the ISC server as well, since unicast is an option for s= ome packets. Dunno what Cisco does. I know the authors discussed this issue; quite a few people also responded = saying that they were in favor of advancing this draft. Can any of those = people tell me what they think about this issue? Can any of the usual sus= pects weigh in? From tomasz.mrugalski@gmail.com Thu Sep 27 14:15:07 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7FE21F851A for ; Thu, 27 Sep 2012 14:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGzy15hDf+Lr for ; Thu, 27 Sep 2012 14:15:06 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D748121F84FE for ; Thu, 27 Sep 2012 14:15:05 -0700 (PDT) Received: by bkcjc3 with SMTP id jc3so2593800bkc.31 for ; Thu, 27 Sep 2012 14:15:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=0rsiAOemqHNZ7bNQ3oqdWyRHQ/dWARdurwE1n9OzZn8=; b=Xm4Tkh8ZMzqy6QMwe6eJZBKcjvIcKkdIBLFOjjTYglclKZaH1KXWsXXlFM0lyKA3++ 0xBqgzn95Mxf2Fzjja5kCq5QAcdS2MgRzHLUEFVBME80CkOJMDoIMtBHVE+9000MilYZ yUFFOvvor42rg3gKaF8JpzwaaH488DP+owrBqGHFKcKcqJlVkFvQKQGadUWGzcUghyPz qx/SNGc11FUN2i0LUfj7eIunyKOldS9RYPsQRZt57F6zPO4UeihRt9V/1OcD2C3KxVYz QEx+1At5f8GKqQmrNHLmMven+YSjY6y+GCY9rv5sSzcBNNs4LZ6U/79s3nQZkSkn31Pq gGpw== Received: by 10.204.151.81 with SMTP id b17mr2867814bkw.95.1348780504725; Thu, 27 Sep 2012 14:15:04 -0700 (PDT) Received: from tomek.local (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id z22sm5580797bkw.2.2012.09.27.14.15.03 (version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 14:15:04 -0700 (PDT) Message-ID: <5064C1D6.6070201@gmail.com> Date: Thu, 27 Sep 2012 23:15:02 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: dhcwg@ietf.org References: <4D779082-B182-4728-9534-39456573682E@nominum.com> In-Reply-To: <4D779082-B182-4728-9534-39456573682E@nominum.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 21:15:07 -0000 On 12-08-10 14:42, Ted Lemon wrote: > The authors of this draft have requested a working group last call. > The draft explains how DHCP clients operate in an environment where > the interface being configured doesn't support multicast (e.g., 6RD). > If this is a matter of interest to you, please review the draft and > send comments to the list. > > If you are in favor of advancing the draft, please say so on the > list; if nobody supports it, it won't advance. If you oppose > advancing it, please also say so. We will determine consensus on > August 24. Hi, I'm terribly sorry for not joining the discussion earlier. I'm in favor of advancing the draft, but not in its current form. In my opinion allowing the client to send every message encapsulated in relay-forw will not give you much, but will just bring more problems. In particular: - What would you put in the peer-addr and link-addr fields of the relay-forw message? Bernie's suggestion for putting 0s in peer-addr makes sense, but what about link-addr? Would you put CE's global unicast address there? That would work, but in many cases it would scale up poorly. If you have 1000 CEs in your network, you would potentially need to configure 1000 subnets as the server is supposed to use link-addr to find out those links. Some servers require explicit network topology information (i.e. listing all links that the server is supposed to support). On the other hand, you can define one large subnet that covers all your 6rd CE's global addresses, but that would not work in certain implementations. This leads to a question if the server is supposed to treat all CEs as being the same or different links. - This draft mentions DNS, SIP and NTP options. Are we talking stateless or stateful (or both) here? That should be clarified. - The argument for not having to update 3315 is weak. There are couple inconsistencies in it and there's 3315 bis planned anyway. To be more specific, This statement "client MUST use link-local address..." from 3315 is in direct contradiction with a another sentence from section 18.1 of 3315: "If the client has a source address of sufficient scope that can be used by the server as a return address, and the client has received a Server Unicast option (section 22.12) from the server, the client SHOULD unicast any Request, Renew, Release and Decline messages to the server." Have you considered a different approach? Something like this: 1. Say that any DHCPv6 solution working over tunnels (or non-multicast, no link-local interfaces in general) MUST support server unicast. 2. Make the 6rd CE send normal messages (not relayed) from its global address to 6rd BR anycast address. 3. Extend the server unicast to work on solicit, confirm, rebind and inf-request. (update 3315, section 15, second paragraph). 4. Optionally update 3315 to point out inconsistencies regarding source address ("MUST use link-local address..." in section 16 vs. 18.1 "If the client has a source address of sufficient scope..."). That is really optional, as any server that implements server unicast already disobeys that rule. This will work on all servers that adhere to sections 17.2.2 (advertise) and 18.2.8 (reply): " If the Solicit message was received directly by the server, the server unicasts the Advertise message directly to the client using the address in the source address field from the IP datagram in which the Solicit message was received.". I understand that you want to have it deployed as soon as possible, but we have 3315bis work planned anyway, so there will be changes and that is unavoidable. And with the server-unicast approach, it really isn't that big change. Step 4 will happen anyway. So it's a matter of updating section 15: "A server MUST discard any Solicit, Confirm, Rebind or Information-request messages it receives with a unicast destination address." to "A server MUST discard any Solicit, Confirm, Rebind or Information-request messages it receives with a unicast destination address, unless explicitly configured to use server unicast option with that address.". If we are concerned of any possible side effects in normal deployment scenarios, we may work out some extra safety checks (add "... and the receiving interface does not support multicast nor link-local addresses"). Sure, expecting the client to magically know server address when sending the first solicit is odd, but if we want to make DHCPv6 work on non-multicast, no link-local interfaces, we need to make some compromises. I very much prefer that approach, compared to the server reporting that there are 1000s of new relays or server starting to blindly accepting unicast messages. On the other hand, there's RFC6276 that talks about co-locating relay and PD client, so the effort to avoid it is already lost. Editorial comment: "The 6rd CE DHCPv6 relay agent SHOULD use the 6rd BR IPv6 anycast address as the destination address, section 20 of [RFC3315]". That reference to section 20 of RFC3315 is strange. Section 20 describes relay operation. What exactly authors want to point to in this context? Hope that helps, Tomek p.s. Where are we with the 3315bis plans? I know that it is a major work, so it is not easy to commit to it, but there are more and more things that require update. I'm already overburdened with the failover work and other stuff, but for such a grand purpose I will find some time. From xuxiaohu@huawei.com Thu Sep 27 19:19:16 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89AC21F853F for ; Thu, 27 Sep 2012 19:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7zmc0-+T2sE for ; Thu, 27 Sep 2012 19:19:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8451B21F8444 for ; Thu, 27 Sep 2012 19:19:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKC15595; Fri, 28 Sep 2012 02:19:14 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 28 Sep 2012 03:18:28 +0100 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 28 Sep 2012 03:19:13 +0100 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.168]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 28 Sep 2012 10:19:08 +0800 From: Xuxiaohu To: Tomek Mrugalski , "dhcwg@ietf.org" Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Thread-Index: AQHNnPUoSDMOAnuzpUmlatl1eCUEGJee/Tdw Date: Fri, 28 Sep 2012 02:19:08 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0755D36B@szxeml525-mbx.china.huawei.com> References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <5064C1D6.6070201@gmail.com> In-Reply-To: <5064C1D6.6070201@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.24] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 02:19:17 -0000 PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gtPqx7Q0KPiBUb21layBNcnVnYWxza2kNCj4g t6LLzcqxvOQ6IDIwMTLE6jnUwjI4yNUgNToxNQ0KPiDK1bz+yMs6IGRoY3dnQGlldGYub3JnDQo+ INb3zOI6IFJlOiBbZGhjd2ddIFdHTEM6IGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni10dW5uZWwtMDEu dHh0DQo+IA0KPiBPbiAxMi0wOC0xMCAxNDo0MiwgVGVkIExlbW9uIHdyb3RlOg0KPiA+IFRoZSBh dXRob3JzIG9mIHRoaXMgZHJhZnQgaGF2ZSByZXF1ZXN0ZWQgYSB3b3JraW5nIGdyb3VwIGxhc3Qg Y2FsbC4NCj4gPiBUaGUgZHJhZnQgZXhwbGFpbnMgaG93IERIQ1AgY2xpZW50cyBvcGVyYXRlIGlu IGFuIGVudmlyb25tZW50IHdoZXJlDQo+ID4gdGhlIGludGVyZmFjZSBiZWluZyBjb25maWd1cmVk IGRvZXNuJ3Qgc3VwcG9ydCBtdWx0aWNhc3QgKGUuZy4sIDZSRCkuDQo+ID4gSWYgdGhpcyBpcyBh IG1hdHRlciBvZiBpbnRlcmVzdCB0byB5b3UsIHBsZWFzZSByZXZpZXcgdGhlIGRyYWZ0IGFuZA0K PiA+IHNlbmQgY29tbWVudHMgdG8gdGhlIGxpc3QuDQo+ID4NCj4gPiBJZiB5b3UgYXJlIGluIGZh dm9yIG9mIGFkdmFuY2luZyB0aGUgZHJhZnQsIHBsZWFzZSBzYXkgc28gb24gdGhlDQo+ID4gbGlz dDsgaWYgbm9ib2R5IHN1cHBvcnRzIGl0LCBpdCB3b24ndCBhZHZhbmNlLiAgIElmIHlvdSBvcHBv c2UNCj4gPiBhZHZhbmNpbmcgaXQsIHBsZWFzZSBhbHNvIHNheSBzby4gICBXZSB3aWxsIGRldGVy bWluZSBjb25zZW5zdXMgb24NCj4gPiBBdWd1c3QgMjQuDQo+IEhpLA0KPiANCj4gSSdtIHRlcnJp Ymx5IHNvcnJ5IGZvciBub3Qgam9pbmluZyB0aGUgZGlzY3Vzc2lvbiBlYXJsaWVyLiBJJ20gaW4g ZmF2b3INCj4gb2YgYWR2YW5jaW5nIHRoZSBkcmFmdCwgYnV0IG5vdCBpbiBpdHMgY3VycmVudCBm b3JtLg0KDQpIaSBUb21laywNCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLiBBcyBP bGUgaGFzIHNhaWQgZWFybGllciwgd2Ugc2hvdWxkIGRvIGJvdGguIEkgZnVsbHkgYWdyZWUgdGhh dCB1cGRhdGluZyBSRkMzMzE1IHRvIHJlbGF4IHRoZSB1c2FnZSBvZiBsaW5rLWxvY2FsIGFkZHJl c3NlcyBpcyBncmVhdC4gSG93ZXZlciwgd2Ugc3RpbGwgbmVlZCBhIG1lY2hhbmlzbSBhcyBkZXNj cmliZWQgaW4gdGhlIGN1cnJlbnQgZHJhZnQgc28gZmFyIHRvIGRlYWwgd2l0aCBleGlzdGluZyBE SENQdjYgc2VydmVycyB3aGljaCBoYXZlIGJlZW4gaW1wbGVtZW50ZWQgYWNjb3JkaW5nIHRvIHRo ZSBjdXJyZW50IFJGQzMzMTUgc3BlY2lmaWNhdGlvbnMsIHJhdGhlciB0aGFuIHRoZSBSRkMzMzE1 YmlzLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiBJbiBteSBvcGluaW9uIGFsbG93aW5n IHRoZSBjbGllbnQgdG8gc2VuZCBldmVyeSBtZXNzYWdlIGVuY2Fwc3VsYXRlZCBpbg0KPiByZWxh eS1mb3J3IHdpbGwgbm90IGdpdmUgeW91IG11Y2gsIGJ1dCB3aWxsIGp1c3QgYnJpbmcgbW9yZSBw cm9ibGVtcy4gSW4NCj4gcGFydGljdWxhcjoNCj4gDQo+IC0gV2hhdCB3b3VsZCB5b3UgcHV0IGlu IHRoZSBwZWVyLWFkZHIgYW5kIGxpbmstYWRkciBmaWVsZHMgb2YgdGhlDQo+IHJlbGF5LWZvcncg bWVzc2FnZT8gQmVybmllJ3Mgc3VnZ2VzdGlvbiBmb3IgcHV0dGluZyAwcyBpbiBwZWVyLWFkZHIN Cj4gbWFrZXMgc2Vuc2UsIGJ1dCB3aGF0IGFib3V0IGxpbmstYWRkcj8gV291bGQgeW91IHB1dCBD RSdzIGdsb2JhbCB1bmljYXN0DQo+IGFkZHJlc3MgdGhlcmU/IFRoYXQgd291bGQgd29yaywgYnV0 IGluIG1hbnkgY2FzZXMgaXQgd291bGQgc2NhbGUgdXANCj4gcG9vcmx5LiBJZiB5b3UgaGF2ZSAx MDAwIENFcyBpbiB5b3VyIG5ldHdvcmssIHlvdSB3b3VsZCBwb3RlbnRpYWxseSBuZWVkDQo+IHRv IGNvbmZpZ3VyZSAxMDAwIHN1Ym5ldHMgYXMgdGhlIHNlcnZlciBpcyBzdXBwb3NlZCB0byB1c2Ug bGluay1hZGRyIHRvDQo+IGZpbmQgb3V0IHRob3NlIGxpbmtzLiBTb21lIHNlcnZlcnMgcmVxdWly ZSBleHBsaWNpdCBuZXR3b3JrIHRvcG9sb2d5DQo+IGluZm9ybWF0aW9uIChpLmUuIGxpc3Rpbmcg YWxsIGxpbmtzIHRoYXQgdGhlIHNlcnZlciBpcyBzdXBwb3NlZCB0bw0KPiBzdXBwb3J0KS4gT24g dGhlIG90aGVyIGhhbmQsIHlvdSBjYW4gZGVmaW5lIG9uZSBsYXJnZSBzdWJuZXQgdGhhdCBjb3Zl cnMNCj4gYWxsIHlvdXIgNnJkIENFJ3MgZ2xvYmFsIGFkZHJlc3NlcywgYnV0IHRoYXQgd291bGQg bm90IHdvcmsgaW4gY2VydGFpbg0KPiBpbXBsZW1lbnRhdGlvbnMuIFRoaXMgbGVhZHMgdG8gYSBx dWVzdGlvbiBpZiB0aGUgc2VydmVyIGlzIHN1cHBvc2VkIHRvDQo+IHRyZWF0IGFsbCBDRXMgYXMg YmVpbmcgdGhlIHNhbWUgb3IgZGlmZmVyZW50IGxpbmtzLg0KPiANCj4gLSBUaGlzIGRyYWZ0IG1l bnRpb25zIEROUywgU0lQIGFuZCBOVFAgb3B0aW9ucy4gQXJlIHdlIHRhbGtpbmcgc3RhdGVsZXNz DQo+IG9yIHN0YXRlZnVsIChvciBib3RoKSBoZXJlPyBUaGF0IHNob3VsZCBiZSBjbGFyaWZpZWQu DQo+IA0KPiAtIFRoZSBhcmd1bWVudCBmb3Igbm90IGhhdmluZyB0byB1cGRhdGUgMzMxNSBpcyB3 ZWFrLiBUaGVyZSBhcmUgY291cGxlDQo+IGluY29uc2lzdGVuY2llcyBpbiBpdCBhbmQgdGhlcmUn cyAzMzE1IGJpcyBwbGFubmVkIGFueXdheS4gVG8gYmUgbW9yZQ0KPiBzcGVjaWZpYywgVGhpcyBz dGF0ZW1lbnQgImNsaWVudCBNVVNUIHVzZSBsaW5rLWxvY2FsIGFkZHJlc3MuLi4iIGZyb20NCj4g MzMxNSBpcyBpbiBkaXJlY3QgY29udHJhZGljdGlvbiB3aXRoIGEgYW5vdGhlciBzZW50ZW5jZSBm cm9tIHNlY3Rpb24NCj4gMTguMSBvZiAzMzE1OiAiSWYgdGhlIGNsaWVudCBoYXMgYSBzb3VyY2Ug YWRkcmVzcyBvZiBzdWZmaWNpZW50IHNjb3BlDQo+IHRoYXQgY2FuIGJlIHVzZWQgYnkgdGhlIHNl cnZlciBhcyBhIHJldHVybiBhZGRyZXNzLCBhbmQgdGhlIGNsaWVudCBoYXMNCj4gcmVjZWl2ZWQg YSBTZXJ2ZXIgVW5pY2FzdCBvcHRpb24gKHNlY3Rpb24gMjIuMTIpIGZyb20gdGhlIHNlcnZlciwg dGhlDQo+IGNsaWVudCBTSE9VTEQgdW5pY2FzdCBhbnkgUmVxdWVzdCwgUmVuZXcsIFJlbGVhc2Ug YW5kIERlY2xpbmUgbWVzc2FnZXMNCj4gdG8gdGhlIHNlcnZlci4iDQo+IA0KPiBIYXZlIHlvdSBj b25zaWRlcmVkIGEgZGlmZmVyZW50IGFwcHJvYWNoPyBTb21ldGhpbmcgbGlrZSB0aGlzOg0KPiAN Cj4gMS4gU2F5IHRoYXQgYW55IERIQ1B2NiBzb2x1dGlvbiB3b3JraW5nIG92ZXIgdHVubmVscyAo b3Igbm9uLW11bHRpY2FzdCwNCj4gbm8gbGluay1sb2NhbCBpbnRlcmZhY2VzIGluIGdlbmVyYWwp IE1VU1Qgc3VwcG9ydCBzZXJ2ZXIgdW5pY2FzdC4NCj4gMi4gTWFrZSB0aGUgNnJkIENFIHNlbmQg bm9ybWFsIG1lc3NhZ2VzIChub3QgcmVsYXllZCkgZnJvbSBpdHMgZ2xvYmFsDQo+IGFkZHJlc3Mg dG8gNnJkIEJSIGFueWNhc3QgYWRkcmVzcy4NCj4gMy4gRXh0ZW5kIHRoZSBzZXJ2ZXIgdW5pY2Fz dCB0byB3b3JrIG9uIHNvbGljaXQsIGNvbmZpcm0sIHJlYmluZCBhbmQNCj4gaW5mLXJlcXVlc3Qu ICh1cGRhdGUgMzMxNSwgc2VjdGlvbiAxNSwgc2Vjb25kIHBhcmFncmFwaCkuDQo+IDQuIE9wdGlv bmFsbHkgdXBkYXRlIDMzMTUgdG8gcG9pbnQgb3V0IGluY29uc2lzdGVuY2llcyByZWdhcmRpbmcg c291cmNlDQo+IGFkZHJlc3MgKCJNVVNUIHVzZSBsaW5rLWxvY2FsIGFkZHJlc3MuLi4iIGluIHNl Y3Rpb24gMTYgdnMuIDE4LjEgIklmIHRoZQ0KPiBjbGllbnQgaGFzIGEgc291cmNlIGFkZHJlc3Mg b2Ygc3VmZmljaWVudCBzY29wZS4uLiIpLiBUaGF0IGlzIHJlYWxseQ0KPiBvcHRpb25hbCwgYXMg YW55IHNlcnZlciB0aGF0IGltcGxlbWVudHMgc2VydmVyIHVuaWNhc3QgYWxyZWFkeSBkaXNvYmV5 cw0KPiB0aGF0IHJ1bGUuDQo+IA0KPiBUaGlzIHdpbGwgd29yayBvbiBhbGwgc2VydmVycyB0aGF0 IGFkaGVyZSB0byBzZWN0aW9ucyAxNy4yLjIgKGFkdmVydGlzZSkNCj4gYW5kIDE4LjIuOCAocmVw bHkpOiAiIElmIHRoZSBTb2xpY2l0IG1lc3NhZ2Ugd2FzIHJlY2VpdmVkIGRpcmVjdGx5IGJ5DQo+ IHRoZSBzZXJ2ZXIsIHRoZSBzZXJ2ZXIgdW5pY2FzdHMgdGhlIEFkdmVydGlzZSBtZXNzYWdlIGRp cmVjdGx5IHRvIHRoZQ0KPiBjbGllbnQgdXNpbmcgdGhlIGFkZHJlc3MgaW4gdGhlIHNvdXJjZSBh ZGRyZXNzIGZpZWxkIGZyb20gdGhlIElQDQo+IGRhdGFncmFtIGluIHdoaWNoIHRoZSBTb2xpY2l0 IG1lc3NhZ2Ugd2FzIHJlY2VpdmVkLiIuDQo+IA0KPiBJIHVuZGVyc3RhbmQgdGhhdCB5b3Ugd2Fu dCB0byBoYXZlIGl0IGRlcGxveWVkIGFzIHNvb24gYXMgcG9zc2libGUsIGJ1dA0KPiB3ZSBoYXZl IDMzMTViaXMgd29yayBwbGFubmVkIGFueXdheSwgc28gdGhlcmUgd2lsbCBiZSBjaGFuZ2VzIGFu ZCB0aGF0DQo+IGlzIHVuYXZvaWRhYmxlLiBBbmQgd2l0aCB0aGUgc2VydmVyLXVuaWNhc3QgYXBw cm9hY2gsIGl0IHJlYWxseSBpc24ndA0KPiB0aGF0IGJpZyBjaGFuZ2UuDQo+IA0KPiBTdGVwIDQg d2lsbCBoYXBwZW4gYW55d2F5LiBTbyBpdCdzIGEgbWF0dGVyIG9mIHVwZGF0aW5nIHNlY3Rpb24g MTU6DQo+IA0KPiAiQSBzZXJ2ZXIgTVVTVCBkaXNjYXJkIGFueSBTb2xpY2l0LCBDb25maXJtLCBS ZWJpbmQgb3INCj4gSW5mb3JtYXRpb24tcmVxdWVzdCBtZXNzYWdlcyBpdCByZWNlaXZlcyB3aXRo IGEgdW5pY2FzdCBkZXN0aW5hdGlvbg0KPiBhZGRyZXNzLiINCj4gDQo+IHRvDQo+IA0KPiAiQSBz ZXJ2ZXIgTVVTVCBkaXNjYXJkIGFueSBTb2xpY2l0LCBDb25maXJtLCBSZWJpbmQgb3INCj4gSW5m b3JtYXRpb24tcmVxdWVzdCBtZXNzYWdlcyBpdCByZWNlaXZlcyB3aXRoIGEgdW5pY2FzdCBkZXN0 aW5hdGlvbg0KPiBhZGRyZXNzLCB1bmxlc3MgZXhwbGljaXRseSBjb25maWd1cmVkIHRvIHVzZSBz ZXJ2ZXIgdW5pY2FzdCBvcHRpb24gd2l0aA0KPiB0aGF0IGFkZHJlc3MuIi4NCj4gDQo+IElmIHdl IGFyZSBjb25jZXJuZWQgb2YgYW55IHBvc3NpYmxlIHNpZGUgZWZmZWN0cyBpbiBub3JtYWwgZGVw bG95bWVudA0KPiBzY2VuYXJpb3MsIHdlIG1heSB3b3JrIG91dCBzb21lIGV4dHJhIHNhZmV0eSBj aGVja3MgKGFkZCAiLi4uIGFuZCB0aGUNCj4gcmVjZWl2aW5nIGludGVyZmFjZSBkb2VzIG5vdCBz dXBwb3J0IG11bHRpY2FzdCBub3IgbGluay1sb2NhbCBhZGRyZXNzZXMiKS4NCj4gDQo+IFN1cmUs IGV4cGVjdGluZyB0aGUgY2xpZW50IHRvIG1hZ2ljYWxseSBrbm93IHNlcnZlciBhZGRyZXNzIHdo ZW4gc2VuZGluZw0KPiB0aGUgZmlyc3Qgc29saWNpdCBpcyBvZGQsIGJ1dCBpZiB3ZSB3YW50IHRv IG1ha2UgREhDUHY2IHdvcmsgb24NCj4gbm9uLW11bHRpY2FzdCwgbm8gbGluay1sb2NhbCBpbnRl cmZhY2VzLCB3ZSBuZWVkIHRvIG1ha2Ugc29tZQ0KPiBjb21wcm9taXNlcy4gSSB2ZXJ5IG11Y2gg cHJlZmVyIHRoYXQgYXBwcm9hY2gsIGNvbXBhcmVkIHRvIHRoZSBzZXJ2ZXINCj4gcmVwb3J0aW5n IHRoYXQgdGhlcmUgYXJlIDEwMDBzIG9mIG5ldyByZWxheXMgb3Igc2VydmVyIHN0YXJ0aW5nIHRv DQo+IGJsaW5kbHkgYWNjZXB0aW5nIHVuaWNhc3QgbWVzc2FnZXMuDQo+IA0KPiBPbiB0aGUgb3Ro ZXIgaGFuZCwgdGhlcmUncyBSRkM2Mjc2IHRoYXQgdGFsa3MgYWJvdXQgY28tbG9jYXRpbmcgcmVs YXkNCj4gYW5kIFBEIGNsaWVudCwgc28gdGhlIGVmZm9ydCB0byBhdm9pZCBpdCBpcyBhbHJlYWR5 IGxvc3QuDQo+IA0KPiBFZGl0b3JpYWwgY29tbWVudDoNCj4gIlRoZSA2cmQgQ0UgREhDUHY2IHJl bGF5IGFnZW50IFNIT1VMRCB1c2UgdGhlIDZyZCBCUiBJUHY2IGFueWNhc3QNCj4gYWRkcmVzcyBh cyB0aGUgZGVzdGluYXRpb24gYWRkcmVzcywgc2VjdGlvbiAyMCBvZiBbUkZDMzMxNV0iLiBUaGF0 DQo+IHJlZmVyZW5jZSB0byBzZWN0aW9uIDIwIG9mIFJGQzMzMTUgaXMgc3RyYW5nZS4gU2VjdGlv biAyMCBkZXNjcmliZXMNCj4gcmVsYXkgb3BlcmF0aW9uLiBXaGF0IGV4YWN0bHkgYXV0aG9ycyB3 YW50IHRvIHBvaW50IHRvIGluIHRoaXMgY29udGV4dD8NCj4gDQo+IEhvcGUgdGhhdCBoZWxwcywN Cj4gVG9tZWsNCj4gDQo+IHAucy4NCj4gV2hlcmUgYXJlIHdlIHdpdGggdGhlIDMzMTViaXMgcGxh bnM/IEkga25vdyB0aGF0IGl0IGlzIGEgbWFqb3Igd29yaywgc28NCj4gaXQgaXMgbm90IGVhc3kg dG8gY29tbWl0IHRvIGl0LCBidXQgdGhlcmUgYXJlIG1vcmUgYW5kIG1vcmUgdGhpbmdzIHRoYXQN Cj4gcmVxdWlyZSB1cGRhdGUuIEknbSBhbHJlYWR5IG92ZXJidXJkZW5lZCB3aXRoIHRoZSBmYWls b3ZlciB3b3JrIGFuZA0KPiBvdGhlciBzdHVmZiwgYnV0IGZvciBzdWNoIGEgZ3JhbmQgcHVycG9z ZSBJIHdpbGwgZmluZCBzb21lIHRpbWUuDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRoY3dnIG1haWxpbmcgbGlzdA0KPiBk aGN3Z0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ro Y3dnDQo= From leaf.y.yeh@huawei.com Thu Sep 27 20:47:45 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD1721F84CE for ; Thu, 27 Sep 2012 20:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiWjBnWzZrsi for ; Thu, 27 Sep 2012 20:47:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B7BC321F8471 for ; Thu, 27 Sep 2012 20:47:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALC85499; Fri, 28 Sep 2012 03:47:42 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 28 Sep 2012 04:46:55 +0100 Received: from SZXEML439-HUB.china.huawei.com (10.72.61.74) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 28 Sep 2012 04:47:40 +0100 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.192]) by szxeml439-hub.china.huawei.com ([10.72.61.74]) with mapi id 14.01.0323.003; Fri, 28 Sep 2012 11:47:20 +0800 From: Leaf yeh To: Tomek Mrugalski , "dhcwg@ietf.org" Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Thread-Index: AQHNnPUoSDMOAnuzpUmlatl1eCUEGJefHSeA Date: Fri, 28 Sep 2012 03:47:19 +0000 Message-ID: References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <5064C1D6.6070201@gmail.com> In-Reply-To: <5064C1D6.6070201@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 03:47:45 -0000 Tomek - Where are we with the 3315bis plans? I know that it is a major work= , ..., but for such a grand purpose I will find some time. I'd also like to join the plan if I could provide any help. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= omek Mrugalski Sent: Friday, September 28, 2012 5:15 AM To: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt On 12-08-10 14:42, Ted Lemon wrote: > The authors of this draft have requested a working group last call. > The draft explains how DHCP clients operate in an environment where > the interface being configured doesn't support multicast (e.g., 6RD). > If this is a matter of interest to you, please review the draft and > send comments to the list. >=20 > If you are in favor of advancing the draft, please say so on the > list; if nobody supports it, it won't advance. If you oppose > advancing it, please also say so. We will determine consensus on > August 24. Hi, I'm terribly sorry for not joining the discussion earlier. I'm in favor of advancing the draft, but not in its current form. In my opinion allowing the client to send every message encapsulated in relay-forw will not give you much, but will just bring more problems. In particular: - What would you put in the peer-addr and link-addr fields of the relay-forw message? Bernie's suggestion for putting 0s in peer-addr makes sense, but what about link-addr? Would you put CE's global unicast address there? That would work, but in many cases it would scale up poorly. If you have 1000 CEs in your network, you would potentially need to configure 1000 subnets as the server is supposed to use link-addr to find out those links. Some servers require explicit network topology information (i.e. listing all links that the server is supposed to support). On the other hand, you can define one large subnet that covers all your 6rd CE's global addresses, but that would not work in certain implementations. This leads to a question if the server is supposed to treat all CEs as being the same or different links. - This draft mentions DNS, SIP and NTP options. Are we talking stateless or stateful (or both) here? That should be clarified. - The argument for not having to update 3315 is weak. There are couple inconsistencies in it and there's 3315 bis planned anyway. To be more specific, This statement "client MUST use link-local address..." from 3315 is in direct contradiction with a another sentence from section 18.1 of 3315: "If the client has a source address of sufficient scope that can be used by the server as a return address, and the client has received a Server Unicast option (section 22.12) from the server, the client SHOULD unicast any Request, Renew, Release and Decline messages to the server." Have you considered a different approach? Something like this: 1. Say that any DHCPv6 solution working over tunnels (or non-multicast, no link-local interfaces in general) MUST support server unicast. 2. Make the 6rd CE send normal messages (not relayed) from its global address to 6rd BR anycast address. 3. Extend the server unicast to work on solicit, confirm, rebind and inf-request. (update 3315, section 15, second paragraph). 4. Optionally update 3315 to point out inconsistencies regarding source address ("MUST use link-local address..." in section 16 vs. 18.1 "If the client has a source address of sufficient scope..."). That is really optional, as any server that implements server unicast already disobeys that rule. This will work on all servers that adhere to sections 17.2.2 (advertise) and 18.2.8 (reply): " If the Solicit message was received directly by the server, the server unicasts the Advertise message directly to the client using the address in the source address field from the IP datagram in which the Solicit message was received.". I understand that you want to have it deployed as soon as possible, but we have 3315bis work planned anyway, so there will be changes and that is unavoidable. And with the server-unicast approach, it really isn't that big change. Step 4 will happen anyway. So it's a matter of updating section 15: "A server MUST discard any Solicit, Confirm, Rebind or Information-request messages it receives with a unicast destination address." to "A server MUST discard any Solicit, Confirm, Rebind or Information-request messages it receives with a unicast destination address, unless explicitly configured to use server unicast option with that address.". If we are concerned of any possible side effects in normal deployment scenarios, we may work out some extra safety checks (add "... and the receiving interface does not support multicast nor link-local addresses"). Sure, expecting the client to magically know server address when sending the first solicit is odd, but if we want to make DHCPv6 work on non-multicast, no link-local interfaces, we need to make some compromises. I very much prefer that approach, compared to the server reporting that there are 1000s of new relays or server starting to blindly accepting unicast messages. On the other hand, there's RFC6276 that talks about co-locating relay and PD client, so the effort to avoid it is already lost. Editorial comment: "The 6rd CE DHCPv6 relay agent SHOULD use the 6rd BR IPv6 anycast address as the destination address, section 20 of [RFC3315]". That reference to section 20 of RFC3315 is strange. Section 20 describes relay operation. What exactly authors want to point to in this context? Hope that helps, Tomek p.s. Where are we with the 3315bis plans? I know that it is a major work, so it is not easy to commit to it, but there are more and more things that require update. I'm already overburdened with the failover work and other stuff, but for such a grand purpose I will find some time. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From internet-drafts@ietf.org Fri Sep 28 04:19:10 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3FB21F85F9; Fri, 28 Sep 2012 04:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTXYzirp12zg; Fri, 28 Sep 2012 04:19:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF02F21F85C0; Fri, 28 Sep 2012 04:19:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120928111909.8155.40436.idtracker@ietfa.amsl.com> Date: Fri, 28 Sep 2012 04:19:09 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-triggered-reconfigure-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 11:19:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : RECONFIGURE Triggered by DHCPv6 Relay Agents Author(s) : Mohamed Boucadair Xavier Pougnard Filename : draft-ietf-dhc-triggered-reconfigure-01.txt Pages : 8 Date : 2012-09-28 Abstract: This document defines a new DHCPv6 message type: RECONFIGURE-REQUEST. This message is sent by a DHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a RECONFIGURE message accordingly. This document updates RFC3315 and RFC6422. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-triggered-reconfigure There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-triggered-reconfigure-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-triggered-reconfigure-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Fri Sep 28 04:25:06 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEB721F8513 for ; Fri, 28 Sep 2012 04:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5N7CPAsAD2NU for ; Fri, 28 Sep 2012 04:25:06 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB9B21F8512 for ; Fri, 28 Sep 2012 04:25:05 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id C323022C801 for ; Fri, 28 Sep 2012 13:25:04 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id AC2C427C046 for ; Fri, 28 Sep 2012 13:25:04 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Fri, 28 Sep 2012 13:25:04 +0200 From: To: "dhcwg@ietf.org" Date: Fri, 28 Sep 2012 13:25:02 +0200 Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-triggered-reconfigure-01.txt Thread-Index: Ac2daxeALn79YPCJQLekuRJDsx93QAAAA9aA Message-ID: <94C682931C08B048B7A8645303FDC9F36E5E44E594@PUEXCB1B.nanterre.francetelecom.fr> References: <20120928111909.8155.40436.idtracker@ietfa.amsl.com> In-Reply-To: <20120928111909.8155.40436.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.28.100315 Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-triggered-reconfigure-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 11:25:07 -0000 Dear all,=20 As no preference was received for the two discussion points raised here: ht= tp://www.ietf.org/mail-archive/web/dhcwg/current/msg13122.html, we updated = the document as follows: * add new text to specify the behaviour of a relay agent receiving RECONFIG= URE-REQUEST message. * The second discussion note is removed: no text is added to cover the case= where all clients bound to the same relay-agents are concerned with a chan= ge. A diff is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc= -triggered-reconfigure-01.txt. Cheers, Med >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De=20 >la part de internet-drafts@ietf.org >Envoy=E9 : vendredi 28 septembre 2012 13:19 >=C0 : i-d-announce@ietf.org >Cc : dhcwg@ietf.org >Objet : [dhcwg] I-D Action: draft-ietf-dhc-triggered-reconfigure-01.txt > > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. > This draft is a work item of the Dynamic Host Configuration=20 >Working Group of the IETF. > > Title : RECONFIGURE Triggered by DHCPv6 Relay Agents > Author(s) : Mohamed Boucadair > Xavier Pougnard > Filename : draft-ietf-dhc-triggered-reconfigure-01.txt > Pages : 8 > Date : 2012-09-28 > >Abstract: > This document defines a new DHCPv6 message type:=20 >RECONFIGURE-REQUEST. > This message is sent by a DHCPv6 relay agent to notify a DHCPv6 > server about a configuration information change, so that the DHCPv6 > server can send a RECONFIGURE message accordingly. > > This document updates RFC3315 and RFC6422. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-dhc-triggered-reconfigure > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-dhc-triggered-reconfigure-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-triggered-recon >figure-01 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg >= From volz@cisco.com Fri Sep 28 06:36:10 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B662821F85ED for ; Fri, 28 Sep 2012 06:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.148 X-Spam-Level: X-Spam-Status: No, score=-8.148 tagged_above=-999 required=5 tests=[AWL=-2.091, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4O+wuB2XBIW for ; Fri, 28 Sep 2012 06:36:09 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5845321F85A8 for ; Fri, 28 Sep 2012 06:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15354; q=dns/txt; s=iport; t=1348839369; x=1350048969; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6iSJAkyoGXw8VjTv7coL8udg0wfmFIydmjrzgfrnnJU=; b=k5EV6Uz0n56vcVyjp2q6hdHLisjEta4t61JXIi5Plnb1P35uFEFoLSF6 q+iEqsfnCcu4O7ew83XuVp/uTo2/ciLhl7jojA09BgIWgZGy5LcngDZLF A75E9yEGTJlzSwYE5ErtyoOIVe5wsjQh+bZav3sOjq3nnsYpJ1/qIXcTY s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFACWnZVCtJXG+/2dsb2JhbAA7CoYLtn6BBoEIgiABAQEDAQEBAQ8BFA06EAcEAgEGAhEEAQEBBAYdBQICJQsUCQgCBAESCBMHh10GC5djjRUIkwkEgR2JexAEhH02YAOkK4FpgmeBWj0 X-IronPort-AV: E=Sophos;i="4.80,502,1344211200"; d="scan'208";a="126360458" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 28 Sep 2012 13:36:08 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8SDa8cp005302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Sep 2012 13:36:08 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0298.004; Fri, 28 Sep 2012 08:36:08 -0500 From: "Bernie Volz (volz)" To: Xuxiaohu , Tomek Mrugalski , "dhcwg@ietf.org" Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Thread-Index: AQHNnPUoSDMOAnuzpUmlatl1eCUEGJee/TdwgAC6FeA= Date: Fri, 28 Sep 2012 13:36:08 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F50792C@xmb-rcd-x04.cisco.com> References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <5064C1D6.6070201@gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0755D36B@szxeml525-mbx.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0755D36B@szxeml525-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.159] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19216.004 x-tm-as-result: No--64.360300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 13:36:10 -0000 SSBhbHNvIHRoaW5rIHRoZSBkcmFmdCdzIHByb3Bvc2VkIHNvbHV0aW9uIGlzIGEgYmFkIG9uZS4g SXQgZG9lcyBtYWtlIGxvY2F0aW5nIHRoZSAnY29ycmVjdCcgcmVsYXkgYWdlbnQgaW5mb3JtYXRp b24gKHNpbmNlIGluIHNvbWUgY2FzZXMgdGhlcmUgbWF5IGJlIG11bHRpcGxlKSBkaWZmaWN1bHQg Zm9yIHRoZSBzZXJ2ZXIgLS0gc3VyZSBsYWNrIG9mIGEgbGluay1hZGRyZXNzIHZhbHVlIChhbGwg MCdzKSBtaWdodCB0cmlnZ2VyIGNvcnJlY3QgcHJvY2Vzc2luZyAoYWR2YW5jZSB0byBuZXh0IHJl bGF5KSwgYnV0IHRoZXJlIGFyZSBtYW55IG90aGVyIGNhc2VzIHdoZXJlIHRoZSBzZXJ2ZXIgbmVl ZHMgdG8gdXNlIHRoZSAnY29ycmVjdCcgcmVsYXkgaW5mb3JtYXRpb24uDQoNCkkgdGhpbmsgc2Vj dGlvbiAxMyBvZiBSRkMgMzMxNSAoVHJhbnNtaXNzaW9uIG9mIE1lc3NhZ2VzIGJ5IGEgQ2xpZW50 KSB3YXMgbWVhbnQgdG8gY292ZXIgYWxsIGFzcGVjdHMgb2Ygc2VuZGluZyBwYWNrZXRzIC0gbm90 IGp1c3QgdGhlICdkZXN0aW5hdGlvbicgYWRkcmVzcyBvZiB0aGUgcGFja2V0Lg0KDQpXaGlsZSBJ IGRvbid0IGtub3cgZW5vdWdoIGFib3V0IHRoZSA2cmQgLyB0dW5uZWwgZW52aXJvbm1lbnQsIEkn bSBub3Qgc3VyZSB3aGF0IG90aGVyIGdlbmVyYWwgSVB2NiBpc3N1ZXMgbGFjayBvZiBhIGxpbmst bG9jYWwgYWRkcmVzcyBjYXVzZXMuIEJ1dCwgbGV0J3MgcHV0IHRoYXQgYXNpZGUgYXMgSSBkb24n dCB0aGluayB0aGUgY2xpZW50J3MgcGFja2V0IHNvdXJjZSBhZGRyZXNzIGlzIHRoYXQgY3JpdGlj YWwgLS0gaXQganVzdCBuZWVkcyB0byBiZSBzb21ldGhpbmcgdGhhdCB0aGUgJ2ZpcnN0JyBob3Ag ZGV2aWNlIGNhbiB1c2UgdG8gc2VuZCBhIHJlc3BvbnNlIHBhY2tldCBiYWNrIHRvIHRoZSBjbGll bnQuDQoNClRoZSBpbnRlbnQgb2YgdXNpbmcgbXVsdGljYXN0IGFkZHJlc3NlcyBhbmQgbGluay1s b2NhbCB3YXMgdG8gJ2ZvcmNlJyB0aGUgY2xpZW50IHRvIGFsd2F5cyBjb21tdW5pY2F0ZSB2aWEg dGhlIHJlbGF5IGFnZW50IHNpbmNlIGxhY2sgb2YgcmVsYXkgYWdlbnQgaW5mb3JtYXRpb24gaW4g c29tZSBvZiB0aGUgREhDUHY0IGludGVyYWN0aW9ucyBjYXVzZWQgaXNzdWVzIGFuZCBoYWQgdG8g aGF2ZSBzcGVjaWFsIHdvcmthcm91bmRzIHRvIGFkZHJlc3MuIEkgdGhpbmsgdGhpcyBpcyBzb21l dGhpbmcgQ1JJVElDQUwgdG8ga2VlcC4gVGhlIHNlcnZlciBjYW4gdGVsbCBhIGNsaWVudCBpdCBp cyBPSyB0byB1c2UgYSB1bmljYXN0IGFkZHJlc3MsIGJ1dCB0aGF0IGlzIG5vdCBwb3NzaWJsZSBp biB0aGUgU29saWNpdCBzbyBJJ20gbm90IHN1cmUgaG93IFRvbWVrJ3MgcHJvcG9zYWwgdG8gZXh0 ZW5kIHRoaXMgd291bGQgd29yayAtLSB0aGUgY2xpZW50IGhhcyB0byBrbm93IHdoYXQgdG8gdXNl IEJFRk9SRSBpdCBzdGFydHMgYW55IGludGVyYWN0aW9ucyB3aXRoIHRoZSBzZXJ2ZXIuDQoNCkFu ZCwgaW4gInRyYWRpdGlvbmFsIiBSRkMgMzMxNSBlbnZpcm9ubWVudHMgdGhlIG9ubHkgY29tbXVu aWNhdGlvbiB0aGF0IHdhcyBrbm93biB0byBiZSBwb3NzaWJsZSB3YXMgbGluay1sb2NhbCAoc2lu Y2UgdGhhdCB3YXMgdGhlIG9ubHkgYWRkcmVzcyB0aGUgY2xpZW50IHdhcyBrbm93biB0byBhbHdh eXMgaGF2ZSBhdmFpbGFibGUpLg0KDQpBdCB0aGUgdGltZSBSRkMgMzMxNSB3YXMgd3JpdHRlbiwg aWYgSSByZWNhbGwsIGFueWNhc3QgYWRkcmVzc2VzIHdlcmUgc3RpbGwgYSBiaXQgbmV3IGFuZCBu b3QgY29tcGxldGVseSBiYWtlZCAoYW5kIGl0IHdhc24ndCBwb3NzaWJsZSB0byBpZGVudGlmeSBh biBhbnljYXN0IGFkZHJlc3MsIGl0IHdhcyBtZWFudCBtb3JlIGZvciBuZXR3b3JrIGxvY2FsaXR5 IGlzc3VlcyAod2hpY2ggZG9lc24ndCByZWFsbHkgY29tZSBpbnRvIHBsYXkgd2l0aCBjb21tdW5p Y2F0aW9uIG9uIGEgc2luZ2xlIGxpbmssIGFuZCB0aGVyZSB3YXNuJ3QgYW55IHdheSB0byAidGVs bCIgdGhlIGNsaWVudCB3aGF0IGFueWNhc3QgYWRkcmVzcyB0byB1c2UgYW55d2F5KS4gSG93ZXZl ciwgSSBkb24ndCByZWFsbHkgc2VlIHRoYXQgYW4gYW55Y2FzdCBhZGRyZXNzIHZpb2xhdGVzIHRo ZSBzcGlyaXQgb2YgUkZDIDMzMTUgd2l0aCByZXNwZWN0IHRvIG11bHRpY2FzdCAtLSBpbiBzb21l IHdheXMsIGFueWNhc3QgaXMgYSBkaWZmZXJlbnQgZm9ybSBvZiBtdWx0aWNhc3QuDQoNCkkgZG9u J3Qga25vdyBmb3Igc3VyZSwgYnV0IHdpdGggdGhlIGludGVudCBvZiB1c2luZyB0aGUgIjZyZCBC UiBJUHY2IGFueWNhc3QgYWRkcmVzcyIsIHRoZXJlIHdvdWxkIGJlIGEgcmVsYXkgYWdlbnQgb24g dGhpcyBlbmQtcG9pbnQgKG9yIHRoZSBESENQdjYgc2VydmVyIHdvdWxkIGJlIHRoZXJlKS4gSWYg YSByZWxheSBhZ2VudCBpcyBwcmVzZW50LCB0aGVuIHRoZXJlJ3Mgbm8gaXNzdWUgYXMgdGhlIERI Q1B2NiBzZXJ2ZXIgZG9lc24ndCByZWFsbHkgY2FyZSBob3cgdGhlIGNsaWVudCA8LT4gcmVsYXkg Y29tbXVuaWNhdGlvbiBvY2N1cnMgYW5kIGhhcyBub3RoaW5nIHRvIGNoZWNrIHRvIGRldGVybWlu ZSBob3cgdGhlIHBhY2tldCB3YXMgZXhjaGFuZ2VkLg0KDQpJZiB0aGUgREhDUHY2IHNlcnZlciBp cyBwcmVzZW50IG9uIHRoYXQgQlIsIHRoZW4gaXQgY2FuIGhhdmUgcnVsZXMgZm9yIHRoYXQgZW52 aXJvbm1lbnQuDQoNClNvIEkgdGhpbmsgZm9yIHRoaXMgZW52aXJvbm1lbnQsIEkgd291bGQgcHJl ZmVyIHRvIHNlZSB0aGUgdHJhbnNtaXNzaW9uIHJ1bGVzIGZvciBjbGllbnRzIGNoYW5nZWQgdG86 DQoNCjEuIEFsbG93IHVuaWNhc3QgcGFja2V0cyB0byBhbiBhbnljYXN0IGFkZHJlc3MgZnJvbSBj bGllbnRzIChub3RlIHRoYXQgdGhlcmUgaXMgbm8gd2F5IHRvIHRlbGwgYW4gYW55Y2FzdCBhZGRy ZXNzIGZyb20gYSB1bmljYXN0IGFkZHJlc3MpLiBTcGVjaWZpY2FsbHkgdGhlIDZyZCBCUiBJUHY2 IGFueWNhc3QgYWRkcmVzcy4gKFRoZXJlIG1pZ2h0IGJlIHRleHQgaGVyZSB0byByZWNvbW1lbmQg dXNlIG9mIHRoZSBzdGFuZGFyZCBESENQdjYgbXVsdGljYXN0IGFkZHJlc3MgKGZmMDI6OjE6Mikg aWYgbXVsdGljYXN0IGF2YWlsYWJsZS4pDQoNCjIuIEFsbG93IHRoZSBjbGllbnQncyBzb3VyY2Ut YWRkcmVzcyB0byBiZSBpbiB3aGF0ZXZlciBzY29wZSBpcyBhcHByb3ByaWF0ZSBmb3IgdGhhdCBk ZXN0aW5hdGlvbiBhZGRyZXNzIChpLmUuLCB3aGF0ZXZlciBpcyBhcHByb3ByaWF0ZSBmb3IgdGhh dCBmaXJzdCBob3AgY29tbXVuaWNhdGlvbiBldmVuIGlmIHRoaXMgaXMgbWF5IGJlIGEgZ2xvYmFs bHkgcm91dGFibGUgYWRkcmVzcykuIFRoZXJlIG1pZ2h0IGJlIHRleHQgaGVyZSB0byByZWNvbW1l bmQgdXNlIG9mIHRoZSBsaW5rLWxvY2FsIGFkZHJlc3MgaWYgb25lIGlzIGF2YWlsYWJsZSBhcyB0 aGF0IGxpbWl0cyB0aGUgbWVzc2FnZSBleGNoYW5nZSB0byB3aGVyZSBpdCBzaG91bGQgYmUuDQoN CkFuZCBzaW1pbGFyIGNoYW5nZXMgdG8gYWNjb21tb2RhdGUgYW55IGNoZWNraW5nIGluIHJlbGF5 cyBvciBzZXJ2ZXJzIHdpdGggcmVzcGVjdCB0byBob3cgdGhlIGNsaWVudCBwYWNrZXQgd2FzIHRy YW5zbWl0dGVkIHRvIHRoYXQgZmlyc3QgaG9wIGRldmljZXMuDQoNCk5vdGUgdGhhdCB0aGVzZSBj aGFuZ2VzIGRvIGFsbG93IGZvciBESENQdjYgY2xpZW50IHRyYWZmaWMgdG8gbm90IGJlIGxpbWl0 ZWQgdG8gYSBzaW5nbGUgJ2xpbmsnLg0KDQpUaGlzIGRvZXMgb2YgY291cnNlIHJlcXVpcmUgdGhl IGNsaWVudCB0byBrbm93IHRoYXQgaXQgaXMgaW4gdGhpcyBlbnZpcm9ubWVudCwgYnV0IEkgdGhp bmsgdGhhdCBpcyBhIGdpdmVuIGluIHRoZSBkcmFmdCdzIHNvbHV0aW9uIHRvby4NCg0KUGVyc29u YWxseSwgSSB0aGluayB0aGVzZSBjaGFuZ2VzIGFyZSBmYXIgYmV0dGVyIHRoYW4gaGF2aW5nIHRv IGluY2x1ZGUgcmVsYXkgZnVuY3Rpb25hbGl0eSBpbnRvIHRoZSBjbGllbnQgYW5kIGRlYWxpbmcg d2l0aCB0aGUgZmFsbG91dC4NCg0KUGVyaGFwcyB5b3UndmUgY29uc2lkZXJlZCB0aGlzIGJ1dCBk ZWNpZGVkIGFnYWluc3QgaXQ/IEkgaGF2ZW4ndCBiZWVuIGZvbGxvd2luZyB0aGlzIHdvcmsgY2xv c2VseSBzbyBpZiB0aGlzIGhhZCBiZWVuIHN1Z2dlc3RlZCBidXQgc2hvdCBkb3duIHByZXZpb3Vz bHksIHNvcnJ5IGZvciByYWlzaW5nIGl0IGFnYWluLiANCg0KLSBCZXJuaWUNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpk aGN3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWHV4aWFvaHUNClNlbnQ6IFRodXJz ZGF5LCBTZXB0ZW1iZXIgMjcsIDIwMTIgMTA6MTkgUE0NClRvOiBUb21layBNcnVnYWxza2k7IGRo Y3dnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2RoY3dnXSBXR0xDOiBkcmFmdC1pZXRmLWRoYy1k aGNwdjYtdHVubmVsLTAxLnR4dA0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IGRo Y3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSC0+rHt DQo+IFRvbWVrIE1ydWdhbHNraQ0KPiC3osvNyrG85DogMjAxMsTqOdTCMjjI1SA1OjE1DQo+IMrV vP7IyzogZGhjd2dAaWV0Zi5vcmcNCj4g1vfM4jogUmU6IFtkaGN3Z10gV0dMQzogZHJhZnQtaWV0 Zi1kaGMtZGhjcHY2LXR1bm5lbC0wMS50eHQNCj4gDQo+IE9uIDEyLTA4LTEwIDE0OjQyLCBUZWQg TGVtb24gd3JvdGU6DQo+ID4gVGhlIGF1dGhvcnMgb2YgdGhpcyBkcmFmdCBoYXZlIHJlcXVlc3Rl ZCBhIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsLg0KPiA+IFRoZSBkcmFmdCBleHBsYWlucyBob3cg REhDUCBjbGllbnRzIG9wZXJhdGUgaW4gYW4gZW52aXJvbm1lbnQgd2hlcmUgDQo+ID4gdGhlIGlu dGVyZmFjZSBiZWluZyBjb25maWd1cmVkIGRvZXNuJ3Qgc3VwcG9ydCBtdWx0aWNhc3QgKGUuZy4s IDZSRCkuDQo+ID4gSWYgdGhpcyBpcyBhIG1hdHRlciBvZiBpbnRlcmVzdCB0byB5b3UsIHBsZWFz ZSByZXZpZXcgdGhlIGRyYWZ0IGFuZCANCj4gPiBzZW5kIGNvbW1lbnRzIHRvIHRoZSBsaXN0Lg0K PiA+DQo+ID4gSWYgeW91IGFyZSBpbiBmYXZvciBvZiBhZHZhbmNpbmcgdGhlIGRyYWZ0LCBwbGVh c2Ugc2F5IHNvIG9uIHRoZQ0KPiA+IGxpc3Q7IGlmIG5vYm9keSBzdXBwb3J0cyBpdCwgaXQgd29u J3QgYWR2YW5jZS4gICBJZiB5b3Ugb3Bwb3NlDQo+ID4gYWR2YW5jaW5nIGl0LCBwbGVhc2UgYWxz byBzYXkgc28uICAgV2Ugd2lsbCBkZXRlcm1pbmUgY29uc2Vuc3VzIG9uDQo+ID4gQXVndXN0IDI0 Lg0KPiBIaSwNCj4gDQo+IEknbSB0ZXJyaWJseSBzb3JyeSBmb3Igbm90IGpvaW5pbmcgdGhlIGRp c2N1c3Npb24gZWFybGllci4gSSdtIGluIA0KPiBmYXZvciBvZiBhZHZhbmNpbmcgdGhlIGRyYWZ0 LCBidXQgbm90IGluIGl0cyBjdXJyZW50IGZvcm0uDQoNCkhpIFRvbWVrLA0KDQpUaGFua3MgYSBs b3QgZm9yIHlvdXIgY29tbWVudHMuIEFzIE9sZSBoYXMgc2FpZCBlYXJsaWVyLCB3ZSBzaG91bGQg ZG8gYm90aC4gSSBmdWxseSBhZ3JlZSB0aGF0IHVwZGF0aW5nIFJGQzMzMTUgdG8gcmVsYXggdGhl IHVzYWdlIG9mIGxpbmstbG9jYWwgYWRkcmVzc2VzIGlzIGdyZWF0LiBIb3dldmVyLCB3ZSBzdGls bCBuZWVkIGEgbWVjaGFuaXNtIGFzIGRlc2NyaWJlZCBpbiB0aGUgY3VycmVudCBkcmFmdCBzbyBm YXIgdG8gZGVhbCB3aXRoIGV4aXN0aW5nIERIQ1B2NiBzZXJ2ZXJzIHdoaWNoIGhhdmUgYmVlbiBp bXBsZW1lbnRlZCBhY2NvcmRpbmcgdG8gdGhlIGN1cnJlbnQgUkZDMzMxNSBzcGVjaWZpY2F0aW9u cywgcmF0aGVyIHRoYW4gdGhlIFJGQzMzMTViaXMuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0K DQo+IEluIG15IG9waW5pb24gYWxsb3dpbmcgdGhlIGNsaWVudCB0byBzZW5kIGV2ZXJ5IG1lc3Nh Z2UgZW5jYXBzdWxhdGVkIA0KPiBpbiByZWxheS1mb3J3IHdpbGwgbm90IGdpdmUgeW91IG11Y2gs IGJ1dCB3aWxsIGp1c3QgYnJpbmcgbW9yZSANCj4gcHJvYmxlbXMuIEluDQo+IHBhcnRpY3VsYXI6 DQo+IA0KPiAtIFdoYXQgd291bGQgeW91IHB1dCBpbiB0aGUgcGVlci1hZGRyIGFuZCBsaW5rLWFk ZHIgZmllbGRzIG9mIHRoZSANCj4gcmVsYXktZm9ydyBtZXNzYWdlPyBCZXJuaWUncyBzdWdnZXN0 aW9uIGZvciBwdXR0aW5nIDBzIGluIHBlZXItYWRkciANCj4gbWFrZXMgc2Vuc2UsIGJ1dCB3aGF0 IGFib3V0IGxpbmstYWRkcj8gV291bGQgeW91IHB1dCBDRSdzIGdsb2JhbCANCj4gdW5pY2FzdCBh ZGRyZXNzIHRoZXJlPyBUaGF0IHdvdWxkIHdvcmssIGJ1dCBpbiBtYW55IGNhc2VzIGl0IHdvdWxk IA0KPiBzY2FsZSB1cCBwb29ybHkuIElmIHlvdSBoYXZlIDEwMDAgQ0VzIGluIHlvdXIgbmV0d29y aywgeW91IHdvdWxkIA0KPiBwb3RlbnRpYWxseSBuZWVkIHRvIGNvbmZpZ3VyZSAxMDAwIHN1Ym5l dHMgYXMgdGhlIHNlcnZlciBpcyBzdXBwb3NlZCANCj4gdG8gdXNlIGxpbmstYWRkciB0byBmaW5k IG91dCB0aG9zZSBsaW5rcy4gU29tZSBzZXJ2ZXJzIHJlcXVpcmUgDQo+IGV4cGxpY2l0IG5ldHdv cmsgdG9wb2xvZ3kgaW5mb3JtYXRpb24gKGkuZS4gbGlzdGluZyBhbGwgbGlua3MgdGhhdCB0aGUg DQo+IHNlcnZlciBpcyBzdXBwb3NlZCB0byBzdXBwb3J0KS4gT24gdGhlIG90aGVyIGhhbmQsIHlv dSBjYW4gZGVmaW5lIG9uZSANCj4gbGFyZ2Ugc3VibmV0IHRoYXQgY292ZXJzIGFsbCB5b3VyIDZy ZCBDRSdzIGdsb2JhbCBhZGRyZXNzZXMsIGJ1dCB0aGF0IA0KPiB3b3VsZCBub3Qgd29yayBpbiBj ZXJ0YWluIGltcGxlbWVudGF0aW9ucy4gVGhpcyBsZWFkcyB0byBhIHF1ZXN0aW9uIGlmIA0KPiB0 aGUgc2VydmVyIGlzIHN1cHBvc2VkIHRvIHRyZWF0IGFsbCBDRXMgYXMgYmVpbmcgdGhlIHNhbWUg b3IgZGlmZmVyZW50IGxpbmtzLg0KPiANCj4gLSBUaGlzIGRyYWZ0IG1lbnRpb25zIEROUywgU0lQ IGFuZCBOVFAgb3B0aW9ucy4gQXJlIHdlIHRhbGtpbmcgDQo+IHN0YXRlbGVzcyBvciBzdGF0ZWZ1 bCAob3IgYm90aCkgaGVyZT8gVGhhdCBzaG91bGQgYmUgY2xhcmlmaWVkLg0KPiANCj4gLSBUaGUg YXJndW1lbnQgZm9yIG5vdCBoYXZpbmcgdG8gdXBkYXRlIDMzMTUgaXMgd2Vhay4gVGhlcmUgYXJl IGNvdXBsZSANCj4gaW5jb25zaXN0ZW5jaWVzIGluIGl0IGFuZCB0aGVyZSdzIDMzMTUgYmlzIHBs YW5uZWQgYW55d2F5LiBUbyBiZSBtb3JlIA0KPiBzcGVjaWZpYywgVGhpcyBzdGF0ZW1lbnQgImNs aWVudCBNVVNUIHVzZSBsaW5rLWxvY2FsIGFkZHJlc3MuLi4iIGZyb20NCj4gMzMxNSBpcyBpbiBk aXJlY3QgY29udHJhZGljdGlvbiB3aXRoIGEgYW5vdGhlciBzZW50ZW5jZSBmcm9tIHNlY3Rpb24N Cj4gMTguMSBvZiAzMzE1OiAiSWYgdGhlIGNsaWVudCBoYXMgYSBzb3VyY2UgYWRkcmVzcyBvZiBz dWZmaWNpZW50IHNjb3BlIA0KPiB0aGF0IGNhbiBiZSB1c2VkIGJ5IHRoZSBzZXJ2ZXIgYXMgYSBy ZXR1cm4gYWRkcmVzcywgYW5kIHRoZSBjbGllbnQgaGFzIA0KPiByZWNlaXZlZCBhIFNlcnZlciBV bmljYXN0IG9wdGlvbiAoc2VjdGlvbiAyMi4xMikgZnJvbSB0aGUgc2VydmVyLCB0aGUgDQo+IGNs aWVudCBTSE9VTEQgdW5pY2FzdCBhbnkgUmVxdWVzdCwgUmVuZXcsIFJlbGVhc2UgYW5kIERlY2xp bmUgbWVzc2FnZXMgDQo+IHRvIHRoZSBzZXJ2ZXIuIg0KPiANCj4gSGF2ZSB5b3UgY29uc2lkZXJl ZCBhIGRpZmZlcmVudCBhcHByb2FjaD8gU29tZXRoaW5nIGxpa2UgdGhpczoNCj4gDQo+IDEuIFNh eSB0aGF0IGFueSBESENQdjYgc29sdXRpb24gd29ya2luZyBvdmVyIHR1bm5lbHMgKG9yIA0KPiBu b24tbXVsdGljYXN0LCBubyBsaW5rLWxvY2FsIGludGVyZmFjZXMgaW4gZ2VuZXJhbCkgTVVTVCBz dXBwb3J0IHNlcnZlciB1bmljYXN0Lg0KPiAyLiBNYWtlIHRoZSA2cmQgQ0Ugc2VuZCBub3JtYWwg bWVzc2FnZXMgKG5vdCByZWxheWVkKSBmcm9tIGl0cyBnbG9iYWwgDQo+IGFkZHJlc3MgdG8gNnJk IEJSIGFueWNhc3QgYWRkcmVzcy4NCj4gMy4gRXh0ZW5kIHRoZSBzZXJ2ZXIgdW5pY2FzdCB0byB3 b3JrIG9uIHNvbGljaXQsIGNvbmZpcm0sIHJlYmluZCBhbmQgDQo+IGluZi1yZXF1ZXN0LiAodXBk YXRlIDMzMTUsIHNlY3Rpb24gMTUsIHNlY29uZCBwYXJhZ3JhcGgpLg0KPiA0LiBPcHRpb25hbGx5 IHVwZGF0ZSAzMzE1IHRvIHBvaW50IG91dCBpbmNvbnNpc3RlbmNpZXMgcmVnYXJkaW5nIA0KPiBz b3VyY2UgYWRkcmVzcyAoIk1VU1QgdXNlIGxpbmstbG9jYWwgYWRkcmVzcy4uLiIgaW4gc2VjdGlv biAxNiB2cy4gDQo+IDE4LjEgIklmIHRoZSBjbGllbnQgaGFzIGEgc291cmNlIGFkZHJlc3Mgb2Yg c3VmZmljaWVudCBzY29wZS4uLiIpLiANCj4gVGhhdCBpcyByZWFsbHkgb3B0aW9uYWwsIGFzIGFu eSBzZXJ2ZXIgdGhhdCBpbXBsZW1lbnRzIHNlcnZlciB1bmljYXN0IA0KPiBhbHJlYWR5IGRpc29i ZXlzIHRoYXQgcnVsZS4NCj4gDQo+IFRoaXMgd2lsbCB3b3JrIG9uIGFsbCBzZXJ2ZXJzIHRoYXQg YWRoZXJlIHRvIHNlY3Rpb25zIDE3LjIuMiANCj4gKGFkdmVydGlzZSkgYW5kIDE4LjIuOCAocmVw bHkpOiAiIElmIHRoZSBTb2xpY2l0IG1lc3NhZ2Ugd2FzIHJlY2VpdmVkIA0KPiBkaXJlY3RseSBi eSB0aGUgc2VydmVyLCB0aGUgc2VydmVyIHVuaWNhc3RzIHRoZSBBZHZlcnRpc2UgbWVzc2FnZSAN Cj4gZGlyZWN0bHkgdG8gdGhlIGNsaWVudCB1c2luZyB0aGUgYWRkcmVzcyBpbiB0aGUgc291cmNl IGFkZHJlc3MgZmllbGQgDQo+IGZyb20gdGhlIElQIGRhdGFncmFtIGluIHdoaWNoIHRoZSBTb2xp Y2l0IG1lc3NhZ2Ugd2FzIHJlY2VpdmVkLiIuDQo+IA0KPiBJIHVuZGVyc3RhbmQgdGhhdCB5b3Ug d2FudCB0byBoYXZlIGl0IGRlcGxveWVkIGFzIHNvb24gYXMgcG9zc2libGUsIA0KPiBidXQgd2Ug aGF2ZSAzMzE1YmlzIHdvcmsgcGxhbm5lZCBhbnl3YXksIHNvIHRoZXJlIHdpbGwgYmUgY2hhbmdl cyBhbmQgDQo+IHRoYXQgaXMgdW5hdm9pZGFibGUuIEFuZCB3aXRoIHRoZSBzZXJ2ZXItdW5pY2Fz dCBhcHByb2FjaCwgaXQgcmVhbGx5IA0KPiBpc24ndCB0aGF0IGJpZyBjaGFuZ2UuDQo+IA0KPiBT dGVwIDQgd2lsbCBoYXBwZW4gYW55d2F5LiBTbyBpdCdzIGEgbWF0dGVyIG9mIHVwZGF0aW5nIHNl Y3Rpb24gMTU6DQo+IA0KPiAiQSBzZXJ2ZXIgTVVTVCBkaXNjYXJkIGFueSBTb2xpY2l0LCBDb25m aXJtLCBSZWJpbmQgb3IgDQo+IEluZm9ybWF0aW9uLXJlcXVlc3QgbWVzc2FnZXMgaXQgcmVjZWl2 ZXMgd2l0aCBhIHVuaWNhc3QgZGVzdGluYXRpb24gDQo+IGFkZHJlc3MuIg0KPiANCj4gdG8NCj4g DQo+ICJBIHNlcnZlciBNVVNUIGRpc2NhcmQgYW55IFNvbGljaXQsIENvbmZpcm0sIFJlYmluZCBv ciANCj4gSW5mb3JtYXRpb24tcmVxdWVzdCBtZXNzYWdlcyBpdCByZWNlaXZlcyB3aXRoIGEgdW5p Y2FzdCBkZXN0aW5hdGlvbiANCj4gYWRkcmVzcywgdW5sZXNzIGV4cGxpY2l0bHkgY29uZmlndXJl ZCB0byB1c2Ugc2VydmVyIHVuaWNhc3Qgb3B0aW9uIA0KPiB3aXRoIHRoYXQgYWRkcmVzcy4iLg0K PiANCj4gSWYgd2UgYXJlIGNvbmNlcm5lZCBvZiBhbnkgcG9zc2libGUgc2lkZSBlZmZlY3RzIGlu IG5vcm1hbCBkZXBsb3ltZW50IA0KPiBzY2VuYXJpb3MsIHdlIG1heSB3b3JrIG91dCBzb21lIGV4 dHJhIHNhZmV0eSBjaGVja3MgKGFkZCAiLi4uIGFuZCB0aGUgDQo+IHJlY2VpdmluZyBpbnRlcmZh Y2UgZG9lcyBub3Qgc3VwcG9ydCBtdWx0aWNhc3Qgbm9yIGxpbmstbG9jYWwgYWRkcmVzc2VzIiku DQo+IA0KPiBTdXJlLCBleHBlY3RpbmcgdGhlIGNsaWVudCB0byBtYWdpY2FsbHkga25vdyBzZXJ2 ZXIgYWRkcmVzcyB3aGVuIA0KPiBzZW5kaW5nIHRoZSBmaXJzdCBzb2xpY2l0IGlzIG9kZCwgYnV0 IGlmIHdlIHdhbnQgdG8gbWFrZSBESENQdjYgd29yayANCj4gb24gbm9uLW11bHRpY2FzdCwgbm8g bGluay1sb2NhbCBpbnRlcmZhY2VzLCB3ZSBuZWVkIHRvIG1ha2Ugc29tZSANCj4gY29tcHJvbWlz ZXMuIEkgdmVyeSBtdWNoIHByZWZlciB0aGF0IGFwcHJvYWNoLCBjb21wYXJlZCB0byB0aGUgc2Vy dmVyIA0KPiByZXBvcnRpbmcgdGhhdCB0aGVyZSBhcmUgMTAwMHMgb2YgbmV3IHJlbGF5cyBvciBz ZXJ2ZXIgc3RhcnRpbmcgdG8gDQo+IGJsaW5kbHkgYWNjZXB0aW5nIHVuaWNhc3QgbWVzc2FnZXMu DQo+IA0KPiBPbiB0aGUgb3RoZXIgaGFuZCwgdGhlcmUncyBSRkM2Mjc2IHRoYXQgdGFsa3MgYWJv dXQgY28tbG9jYXRpbmcgcmVsYXkgDQo+IGFuZCBQRCBjbGllbnQsIHNvIHRoZSBlZmZvcnQgdG8g YXZvaWQgaXQgaXMgYWxyZWFkeSBsb3N0Lg0KPiANCj4gRWRpdG9yaWFsIGNvbW1lbnQ6DQo+ICJU aGUgNnJkIENFIERIQ1B2NiByZWxheSBhZ2VudCBTSE9VTEQgdXNlIHRoZSA2cmQgQlIgSVB2NiBh bnljYXN0IA0KPiBhZGRyZXNzIGFzIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzLCBzZWN0aW9uIDIw IG9mIFtSRkMzMzE1XSIuIFRoYXQgDQo+IHJlZmVyZW5jZSB0byBzZWN0aW9uIDIwIG9mIFJGQzMz MTUgaXMgc3RyYW5nZS4gU2VjdGlvbiAyMCBkZXNjcmliZXMgDQo+IHJlbGF5IG9wZXJhdGlvbi4g V2hhdCBleGFjdGx5IGF1dGhvcnMgd2FudCB0byBwb2ludCB0byBpbiB0aGlzIGNvbnRleHQ/DQo+ IA0KPiBIb3BlIHRoYXQgaGVscHMsDQo+IFRvbWVrDQo+IA0KPiBwLnMuDQo+IFdoZXJlIGFyZSB3 ZSB3aXRoIHRoZSAzMzE1YmlzIHBsYW5zPyBJIGtub3cgdGhhdCBpdCBpcyBhIG1ham9yIHdvcmss IA0KPiBzbyBpdCBpcyBub3QgZWFzeSB0byBjb21taXQgdG8gaXQsIGJ1dCB0aGVyZSBhcmUgbW9y ZSBhbmQgbW9yZSB0aGluZ3MgDQo+IHRoYXQgcmVxdWlyZSB1cGRhdGUuIEknbSBhbHJlYWR5IG92 ZXJidXJkZW5lZCB3aXRoIHRoZSBmYWlsb3ZlciB3b3JrIA0KPiBhbmQgb3RoZXIgc3R1ZmYsIGJ1 dCBmb3Igc3VjaCBhIGdyYW5kIHB1cnBvc2UgSSB3aWxsIGZpbmQgc29tZSB0aW1lLg0KPiANCj4g DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBkaGN3ZyBtYWlsaW5nIGxpc3QNCj4gZGhjd2dAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCmRoY3dnIG1haWxpbmcgbGlzdA0KZGhjd2dAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCg== From volz@cisco.com Fri Sep 28 11:05:42 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6602621F8523 for ; Fri, 28 Sep 2012 11:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.463 X-Spam-Level: X-Spam-Status: No, score=-10.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2zRudQzEhDK for ; Fri, 28 Sep 2012 11:05:41 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3584021F84F3 for ; Fri, 28 Sep 2012 11:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4653; q=dns/txt; s=iport; t=1348855541; x=1350065141; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=DtP3XWw9r0ldPvQgnZS/LPXGuiYYtsQ47UAH5Hu2WWg=; b=O462fHrT8A6xOTdmHCFAIre8YXXjLv+o8qlNa6ylBk9eOCMjY79X6MFW sFtUUIiKmMVytQra2OKgxfGn6Wj3+YueUP3c3IHD21GW0qw7x7cxh0aRg Ki4QlReAj2tNf/NlohDR01dmnh7Szqrgbg4jw0u+tLezEyzCiNMTYt0Rd g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIjlZVCtJXHA/2dsb2JhbABFvhSBCIIgAQEBBAEBAQ8BJzQDFAQCAQgOAwQBAQsUCQcnCxQJCAIEARIIARmHYwuYEqAuixgVBoUsYAOkK4FpgmeBWzw X-IronPort-AV: E=Sophos;i="4.80,503,1344211200"; d="scan'208";a="126499624" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 28 Sep 2012 18:05:33 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8SI5WE6013932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Sep 2012 18:05:32 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Fri, 28 Sep 2012 13:05:32 -0500 From: "Bernie Volz (volz)" To: Andre Kostur , "dhcwg@ietf.org" Thread-Topic: [dhcwg] Load Balancing for DHCPv6 -01 Thread-Index: AQHNmoZtPen9880S70SjX8m6Kq3NjJegCoKw Date: Fri, 28 Sep 2012 18:05:31 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F507AC4@xmb-rcd-x04.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.159] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19216.004 x-tm-as-result: No--36.936500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Load Balancing for DHCPv6 -01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 18:05:42 -0000 >There is still outstanding discussion around whether section 3.1 may apply= to all messages, vs. whether a server should always answer a Release and/o= r Decline. See discussion between myself and Bernie. I can't see why this is an open issue for Release/Decline? The other server= can't respond as it isn't the server being addressed by the server-id and = there is no 'fallback' (i.e., like Rebind for Renew)? And ignoring the pack= et means leaving the address or prefix leased until it expires. I think section 3.1 should be clear that it applies to Renew messages.=20 There may be more to discuss regarding Request and Information-Request, but= ... The Request is an edge case (as that would be from the Solicit/Advertise/Re= quest/Reply sequence where the partner returned between Advertise and Reque= st). Whether to include Request here is up in the air - it would delay the = client getting an address (or prefix) as the client would need to timeout a= nd return to Solicit; whereas having the server continue with the Request w= ould allow the client to complete DHCP immediately and then transition at R= enew/Rebind time (though at that time it is still able to use the address o= r prefix). So I could see this as an implementation choice. In my opinion, = I think it better to get the client online quickly (think of MTAs after a p= ower failure and someone needing to place a call!). It also avoids the time= -out processing that likely has to occur for the provisionally assigned add= ress or prefix - if the server does that. Note that the Request parameters are: REQ_TIMEOUT 1 sec Initial Request timeout REQ_MAX_RT 30 secs Max Request timeout value REQ_MAX_RC 10 Max Request retry attempts So, likely this would be 1 + 2 + 4 + 8 + 16 + 30 + 30 + 30 + 30 + 30 =3D 20= 9 seconds (3.5 minutes) which is a long time to wait before returning to So= licit - especially if it is an emergency call!. So, that is why I think it = is a bad idea. Information-Request, which may have a server-identifier(at least based on s= ection 15 text, though the section 18.1.5 is silent on this matter) is also= less clear if it has one as I am not sure what, if any, fallback occurs fo= r that case? And, this is usually a fairly low cost operation so not sure t= here is a significant benefit in not responding. And, there is no limit to = the number of times an Information-Request is transmitted; though that seem= s like a problem if the server-identifier option is present. Perhaps this i= s something to clean up in RFC 3315bis -- either don't allow the server-ide= ntifier option or if one is included, a retry limit (MRC) should be imposed= (with the fallback to remove the option?). I don't mind if we just explained these options and their implications and = leave it to the server implementer to decide what their choice is (or to pr= ovide knobs). I can't see that either choice cause a 'severe' failure or in= teroperability issue - since the server being specified in a server-identif= ier may not always be available anyway (or could be replaced by another ser= ver). And, even if two servers that were participating in load balancing behaved = differently, there would be no issue (in one case, the clients transition; = in the others they don't). -- A minor nit in section 3 you say "... with the following two differences." = But 3 sections follow (3.1, 3.2, 3.3). Perhaps best to just drop "two"? - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of A= ndre Kostur Sent: Monday, September 24, 2012 2:57 PM To: dhcwg@ietf.org Subject: [dhcwg] Load Balancing for DHCPv6 -01 Dear all: I have submitted an updated I-D updating RFC 3074 to apply to DHCPv6. The text is available at: http://www.ietf.org/internet-drafts/draft-kostur-dhc-loadbv6-01.txt Major changes: Added a new Section 3.1 to discuss the requests with a Server ID specified. Modified the specification of the STID to remove the restriction to 16 byte= s. Remaining currently outstanding item: There is still outstanding discussion around whether section 3.1 may apply = to all messages, vs. whether a server should always answer a Release and/or= Decline. See discussion between myself and Bernie. Comments and suggestions welcome. I am looking to have the WG take this on as a work item. -- Andre Kostur _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From xuxiaohu@huawei.com Fri Sep 28 19:55:24 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB7721F861A for ; Fri, 28 Sep 2012 19:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pv33b44H0Ofd for ; Fri, 28 Sep 2012 19:55:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7702921F8610 for ; Fri, 28 Sep 2012 19:55:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALD65939; Sat, 29 Sep 2012 02:55:19 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 03:51:29 +0100 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 03:52:26 +0100 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.168]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Sat, 29 Sep 2012 10:52:20 +0800 From: Xuxiaohu To: "Bernie Volz (volz)" , Tomek Mrugalski , "dhcwg@ietf.org" Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Thread-Index: AQHNnPUoSDMOAnuzpUmlatl1eCUEGJee/TdwgAC6FeCAANr4AA== Date: Sat, 29 Sep 2012 02:52:20 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0755D57E@szxeml525-mbx.china.huawei.com> References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <5064C1D6.6070201@gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0755D36B@szxeml525-mbx.china.huawei.com> <489D13FBFA9B3E41812EA89F188F018E0F50792C@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F50792C@xmb-rcd-x04.cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.24] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 02:55:25 -0000 SGkgQmVybmllLA0KDQpUaGFua3MgYSBsb3QgZm9yIHlvdXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rp b25zLiBQbGVhc2Ugc2VlIG15IHJlc3BvbnNlIGluIGxpbmUuDQoNCj4gLS0tLS3Tyrz+1K28/i0t LS0tDQo+ILeivP7IyzogZGhjd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRoY3dnLWJvdW5j ZXNAaWV0Zi5vcmddILT6se0NCj4gQmVybmllIFZvbHogKHZvbHopDQo+ILeiy83KsbzkOiAyMDEy xOo51MIyOMjVIDIxOjM2DQo+IMrVvP7IyzogWHV4aWFvaHU7IFRvbWVrIE1ydWdhbHNraTsgZGhj d2dAaWV0Zi5vcmcNCj4g1vfM4jogUmU6IFtkaGN3Z10gV0dMQzogZHJhZnQtaWV0Zi1kaGMtZGhj cHY2LXR1bm5lbC0wMS50eHQNCj4gDQo+IEkgYWxzbyB0aGluayB0aGUgZHJhZnQncyBwcm9wb3Nl ZCBzb2x1dGlvbiBpcyBhIGJhZCBvbmUuIEl0IGRvZXMgbWFrZSBsb2NhdGluZyB0aGUNCj4gJ2Nv cnJlY3QnIHJlbGF5IGFnZW50IGluZm9ybWF0aW9uIChzaW5jZSBpbiBzb21lIGNhc2VzIHRoZXJl IG1heSBiZSBtdWx0aXBsZSkNCj4gZGlmZmljdWx0IGZvciB0aGUgc2VydmVyIC0tIHN1cmUgbGFj ayBvZiBhIGxpbmstYWRkcmVzcyB2YWx1ZSAoYWxsIDAncykgbWlnaHQgdHJpZ2dlcg0KPiBjb3Jy ZWN0IHByb2Nlc3NpbmcgKGFkdmFuY2UgdG8gbmV4dCByZWxheSksIGJ1dCB0aGVyZSBhcmUgbWFu eSBvdGhlciBjYXNlcw0KPiB3aGVyZSB0aGUgc2VydmVyIG5lZWRzIHRvIHVzZSB0aGUgJ2NvcnJl Y3QnIHJlbGF5IGluZm9ybWF0aW9uLg0KDQpBcyBzYWlkIGluIHNlY3Rpb24gMjAuMS4yLiBSZWxh eWluZyBhIE1lc3NhZ2UgZnJvbSBhIFJlbGF5IEFnZW50LA0KIiBJZiB0aGUgc291cmNlIGFkZHJl c3MgZnJvbSB0aGUgSVAgZGF0YWdyYW0gaGVhZGVyIG9mIHRoZSByZWNlaXZlZA0KICAgbWVzc2Fn ZSBpcyBhIGdsb2JhbCBvciBzaXRlLWxvY2FsIGFkZHJlc3MgKGFuZCB0aGUgZGV2aWNlIG9uIHdo aWNoDQogICB0aGUgcmVsYXkgYWdlbnQgaXMgcnVubmluZyBiZWxvbmdzIHRvIG9ubHkgb25lIHNp dGUpLCB0aGUgcmVsYXkgYWdlbnQNCiAgIHNldHMgdGhlIGxpbmstYWRkcmVzcyBmaWVsZCB0byAw ICIgIFRoaXMgaXMgdGhlIGNhc2UgdGhhdCB5b3UgcG9pbnRlZCBvdXQgd2hlcmUgdGhlIHNlcnZl ciBjb3VsZCBjb3JyZWN0bHkgcHJvY2VzcyB0aGUgcmVjZWl2ZWQgREhDUCBtZXNzYWdlcy4NCg0K SW4gYWRkaXRpb24sIHNpbmNlIHRoaXMgZHJhZnQgaXMganVzdCBpbnRlbmRlZCB0byB1c2Ugc3Rh dGVsZXNzIERIQ1B2Niwgd291bGQgeW91IHBsZWFzZSBsaXN0IGFueSBjb25jcmV0ZSBjYXNlcyB3 aGVyZSB0aGUgc2VydmVyIG5lZWRzIHRvIHVzZSB0aGUgY29ycmVjdCByZWxheSBpbmZvcm1hdGlv bj8NCiANCj4gSSB0aGluayBzZWN0aW9uIDEzIG9mIFJGQyAzMzE1IChUcmFuc21pc3Npb24gb2Yg TWVzc2FnZXMgYnkgYSBDbGllbnQpIHdhcw0KPiBtZWFudCB0byBjb3ZlciBhbGwgYXNwZWN0cyBv ZiBzZW5kaW5nIHBhY2tldHMgLSBub3QganVzdCB0aGUgJ2Rlc3RpbmF0aW9uJw0KPiBhZGRyZXNz IG9mIHRoZSBwYWNrZXQuDQo+IA0KPiBXaGlsZSBJIGRvbid0IGtub3cgZW5vdWdoIGFib3V0IHRo ZSA2cmQgLyB0dW5uZWwgZW52aXJvbm1lbnQsIEknbSBub3Qgc3VyZQ0KPiB3aGF0IG90aGVyIGdl bmVyYWwgSVB2NiBpc3N1ZXMgbGFjayBvZiBhIGxpbmstbG9jYWwgYWRkcmVzcyBjYXVzZXMuIEJ1 dCwgbGV0J3MgcHV0DQo+IHRoYXQgYXNpZGUgYXMgSSBkb24ndCB0aGluayB0aGUgY2xpZW50J3Mg cGFja2V0IHNvdXJjZSBhZGRyZXNzIGlzIHRoYXQgY3JpdGljYWwgLS0gaXQNCj4ganVzdCBuZWVk cyB0byBiZSBzb21ldGhpbmcgdGhhdCB0aGUgJ2ZpcnN0JyBob3AgZGV2aWNlIGNhbiB1c2UgdG8g c2VuZCBhDQo+IHJlc3BvbnNlIHBhY2tldCBiYWNrIHRvIHRoZSBjbGllbnQuDQo+IA0KPiBUaGUg aW50ZW50IG9mIHVzaW5nIG11bHRpY2FzdCBhZGRyZXNzZXMgYW5kIGxpbmstbG9jYWwgd2FzIHRv ICdmb3JjZScgdGhlIGNsaWVudCB0bw0KPiBhbHdheXMgY29tbXVuaWNhdGUgdmlhIHRoZSByZWxh eSBhZ2VudCBzaW5jZSBsYWNrIG9mIHJlbGF5IGFnZW50IGluZm9ybWF0aW9uIGluDQo+IHNvbWUg b2YgdGhlIERIQ1B2NCBpbnRlcmFjdGlvbnMgY2F1c2VkIGlzc3VlcyBhbmQgaGFkIHRvIGhhdmUg c3BlY2lhbA0KPiB3b3JrYXJvdW5kcyB0byBhZGRyZXNzLiBJIHRoaW5rIHRoaXMgaXMgc29tZXRo aW5nIENSSVRJQ0FMIHRvIGtlZXAuIFRoZSBzZXJ2ZXINCj4gY2FuIHRlbGwgYSBjbGllbnQgaXQg aXMgT0sgdG8gdXNlIGEgdW5pY2FzdCBhZGRyZXNzLCBidXQgdGhhdCBpcyBub3QgcG9zc2libGUg aW4gdGhlDQo+IFNvbGljaXQgc28gSSdtIG5vdCBzdXJlIGhvdyBUb21laydzIHByb3Bvc2FsIHRv IGV4dGVuZCB0aGlzIHdvdWxkIHdvcmsgLS0gdGhlDQo+IGNsaWVudCBoYXMgdG8ga25vdyB3aGF0 IHRvIHVzZSBCRUZPUkUgaXQgc3RhcnRzIGFueSBpbnRlcmFjdGlvbnMgd2l0aCB0aGUNCj4gc2Vy dmVyLg0KPiANCj4gQW5kLCBpbiAidHJhZGl0aW9uYWwiIFJGQyAzMzE1IGVudmlyb25tZW50cyB0 aGUgb25seSBjb21tdW5pY2F0aW9uIHRoYXQgd2FzDQo+IGtub3duIHRvIGJlIHBvc3NpYmxlIHdh cyBsaW5rLWxvY2FsIChzaW5jZSB0aGF0IHdhcyB0aGUgb25seSBhZGRyZXNzIHRoZSBjbGllbnQN Cj4gd2FzIGtub3duIHRvIGFsd2F5cyBoYXZlIGF2YWlsYWJsZSkuDQo+IA0KPiBBdCB0aGUgdGlt ZSBSRkMgMzMxNSB3YXMgd3JpdHRlbiwgaWYgSSByZWNhbGwsIGFueWNhc3QgYWRkcmVzc2VzIHdl cmUgc3RpbGwgYSBiaXQNCj4gbmV3IGFuZCBub3QgY29tcGxldGVseSBiYWtlZCAoYW5kIGl0IHdh c24ndCBwb3NzaWJsZSB0byBpZGVudGlmeSBhbiBhbnljYXN0DQo+IGFkZHJlc3MsIGl0IHdhcyBt ZWFudCBtb3JlIGZvciBuZXR3b3JrIGxvY2FsaXR5IGlzc3VlcyAod2hpY2ggZG9lc24ndCByZWFs bHkNCj4gY29tZSBpbnRvIHBsYXkgd2l0aCBjb21tdW5pY2F0aW9uIG9uIGEgc2luZ2xlIGxpbmss IGFuZCB0aGVyZSB3YXNuJ3QgYW55IHdheQ0KPiB0byAidGVsbCIgdGhlIGNsaWVudCB3aGF0IGFu eWNhc3QgYWRkcmVzcyB0byB1c2UgYW55d2F5KS4gSG93ZXZlciwgSSBkb24ndA0KPiByZWFsbHkg c2VlIHRoYXQgYW4gYW55Y2FzdCBhZGRyZXNzIHZpb2xhdGVzIHRoZSBzcGlyaXQgb2YgUkZDIDMz MTUgd2l0aCByZXNwZWN0DQo+IHRvIG11bHRpY2FzdCAtLSBpbiBzb21lIHdheXMsIGFueWNhc3Qg aXMgYSBkaWZmZXJlbnQgZm9ybSBvZiBtdWx0aWNhc3QuDQo+IA0KPiBJIGRvbid0IGtub3cgZm9y IHN1cmUsIGJ1dCB3aXRoIHRoZSBpbnRlbnQgb2YgdXNpbmcgdGhlICI2cmQgQlIgSVB2NiBhbnlj YXN0DQo+IGFkZHJlc3MiLCB0aGVyZSB3b3VsZCBiZSBhIHJlbGF5IGFnZW50IG9uIHRoaXMgZW5k LXBvaW50IChvciB0aGUgREhDUHY2IHNlcnZlcg0KPiB3b3VsZCBiZSB0aGVyZSkuIElmIGEgcmVs YXkgYWdlbnQgaXMgcHJlc2VudCwgdGhlbiB0aGVyZSdzIG5vIGlzc3VlIGFzIHRoZQ0KPiBESENQ djYgc2VydmVyIGRvZXNuJ3QgcmVhbGx5IGNhcmUgaG93IHRoZSBjbGllbnQgPC0+IHJlbGF5IGNv bW11bmljYXRpb24NCj4gb2NjdXJzIGFuZCBoYXMgbm90aGluZyB0byBjaGVjayB0byBkZXRlcm1p bmUgaG93IHRoZSBwYWNrZXQgd2FzIGV4Y2hhbmdlZC4NCg0KU3VyZSwgaWYgYSByZWxheSBhZ2Vu dCBpcyBwcmVzZW50IG9uIHRoYXQgQlIsIHRoZXJlIGlzIG5vIGlzc3VlIGZvciB0aGUgREhDUHY2 IHNlcnZlcnMuIEhvd2V2ZXIsIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiByZWxheSBhZ2VudCBvbiB0 aGF0IEJSIGlzIG5vdCBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIGV4aXN0aW5nIFJGQzMzMTUgc3Bl Y2lmaWNhdGlvbnMgYW55bW9yZS4gDQoNCj4gSWYgdGhlIERIQ1B2NiBzZXJ2ZXIgaXMgcHJlc2Vu dCBvbiB0aGF0IEJSLCB0aGVuIGl0IGNhbiBoYXZlIHJ1bGVzIGZvciB0aGF0DQo+IGVudmlyb25t ZW50Lg0KDQpTaW1pbGFybHksIGlmIGEgREhDUCBzZXJ2ZXIgaXMgcHJlc2VudCBvbiB0aGF0IEJS LCB0aGUgaW1wbGVtZW50YXRpb24gb2YgREhDUCBzZXJ2ZXIgb24gdGhhdCBCUiBpcyBub3QgaW4g YWNjb3JkYW5jZSB3aXRoIHRoZSBleGlzdGluZyBSRkMzMzE1IHNwZWNpZmljYXRpb25zIGFueW1v cmUuIA0KDQo+IFNvIEkgdGhpbmsgZm9yIHRoaXMgZW52aXJvbm1lbnQsIEkgd291bGQgcHJlZmVy IHRvIHNlZSB0aGUgdHJhbnNtaXNzaW9uIHJ1bGVzIGZvcg0KPiBjbGllbnRzIGNoYW5nZWQgdG86 DQo+IA0KPiAxLiBBbGxvdyB1bmljYXN0IHBhY2tldHMgdG8gYW4gYW55Y2FzdCBhZGRyZXNzIGZy b20gY2xpZW50cyAobm90ZSB0aGF0IHRoZXJlIGlzDQo+IG5vIHdheSB0byB0ZWxsIGFuIGFueWNh c3QgYWRkcmVzcyBmcm9tIGEgdW5pY2FzdCBhZGRyZXNzKS4gU3BlY2lmaWNhbGx5IHRoZSA2cmQN Cj4gQlIgSVB2NiBhbnljYXN0IGFkZHJlc3MuIChUaGVyZSBtaWdodCBiZSB0ZXh0IGhlcmUgdG8g cmVjb21tZW5kIHVzZSBvZiB0aGUNCj4gc3RhbmRhcmQgREhDUHY2IG11bHRpY2FzdCBhZGRyZXNz IChmZjAyOjoxOjIpIGlmIG11bHRpY2FzdCBhdmFpbGFibGUuKQ0KPiANCj4gMi4gQWxsb3cgdGhl IGNsaWVudCdzIHNvdXJjZS1hZGRyZXNzIHRvIGJlIGluIHdoYXRldmVyIHNjb3BlIGlzIGFwcHJv cHJpYXRlIGZvcg0KPiB0aGF0IGRlc3RpbmF0aW9uIGFkZHJlc3MgKGkuZS4sIHdoYXRldmVyIGlz IGFwcHJvcHJpYXRlIGZvciB0aGF0IGZpcnN0IGhvcA0KPiBjb21tdW5pY2F0aW9uIGV2ZW4gaWYg dGhpcyBpcyBtYXkgYmUgYSBnbG9iYWxseSByb3V0YWJsZSBhZGRyZXNzKS4gVGhlcmUgbWlnaHQN Cj4gYmUgdGV4dCBoZXJlIHRvIHJlY29tbWVuZCB1c2Ugb2YgdGhlIGxpbmstbG9jYWwgYWRkcmVz cyBpZiBvbmUgaXMgYXZhaWxhYmxlIGFzDQo+IHRoYXQgbGltaXRzIHRoZSBtZXNzYWdlIGV4Y2hh bmdlIHRvIHdoZXJlIGl0IHNob3VsZCBiZS4NCj4gDQo+IEFuZCBzaW1pbGFyIGNoYW5nZXMgdG8g YWNjb21tb2RhdGUgYW55IGNoZWNraW5nIGluIHJlbGF5cyBvciBzZXJ2ZXJzIHdpdGgNCj4gcmVz cGVjdCB0byBob3cgdGhlIGNsaWVudCBwYWNrZXQgd2FzIHRyYW5zbWl0dGVkIHRvIHRoYXQgZmly c3QgaG9wIGRldmljZXMuDQoNCkFzIHN1Y2gsIG5vIG1hdHRlciBhIERIQ1Agc2VydmVyIG9yIGEg REhDUCByZWxheSBhZ2VudCBpcyBwcmVzZW50IG9uIHRoYXQgQlIsIHRoZSBpbXBsZW1lbnRhdGlv bnMgb2YgREhDUCBvbiBib3RoIHRoZSBCUiAoZWl0aGVyIGFzIGEgc2VydmVyIG9yIGEgcmVsYXkg YWdlbnQpIGFuZCB0aGUgQ0UgKGFzIGEgY2xpZW50KSBzaG91bGQgYmUgY2hhbmdlZCBhbmQgdGhl cmVmb3JlIGFyZSBub3QgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBleGlzdGluZyBSRkMzMzE1IHNw ZWNpZmljYXRpb25zIGFueW1vcmUuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IE5vdGUg dGhhdCB0aGVzZSBjaGFuZ2VzIGRvIGFsbG93IGZvciBESENQdjYgY2xpZW50IHRyYWZmaWMgdG8g bm90IGJlIGxpbWl0ZWQgdG8NCj4gYSBzaW5nbGUgJ2xpbmsnLg0KPiANCj4gVGhpcyBkb2VzIG9m IGNvdXJzZSByZXF1aXJlIHRoZSBjbGllbnQgdG8ga25vdyB0aGF0IGl0IGlzIGluIHRoaXMgZW52 aXJvbm1lbnQsIGJ1dA0KPiBJIHRoaW5rIHRoYXQgaXMgYSBnaXZlbiBpbiB0aGUgZHJhZnQncyBz b2x1dGlvbiB0b28uDQo+IA0KPiBQZXJzb25hbGx5LCBJIHRoaW5rIHRoZXNlIGNoYW5nZXMgYXJl IGZhciBiZXR0ZXIgdGhhbiBoYXZpbmcgdG8gaW5jbHVkZSByZWxheQ0KPiBmdW5jdGlvbmFsaXR5 IGludG8gdGhlIGNsaWVudCBhbmQgZGVhbGluZyB3aXRoIHRoZSBmYWxsb3V0Lg0KPiANCj4gUGVy aGFwcyB5b3UndmUgY29uc2lkZXJlZCB0aGlzIGJ1dCBkZWNpZGVkIGFnYWluc3QgaXQ/IEkgaGF2 ZW4ndCBiZWVuIGZvbGxvd2luZw0KPiB0aGlzIHdvcmsgY2xvc2VseSBzbyBpZiB0aGlzIGhhZCBi ZWVuIHN1Z2dlc3RlZCBidXQgc2hvdCBkb3duIHByZXZpb3VzbHksIHNvcnJ5DQo+IGZvciByYWlz aW5nIGl0IGFnYWluLg0KPiANCj4gLSBCZXJuaWUNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gWHV4aWFvaHUNCj4gU2VudDogVGh1cnNkYXks IFNlcHRlbWJlciAyNywgMjAxMiAxMDoxOSBQTQ0KPiBUbzogVG9tZWsgTXJ1Z2Fsc2tpOyBkaGN3 Z0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2RoY3dnXSBXR0xDOiBkcmFmdC1pZXRmLWRoYy1k aGNwdjYtdHVubmVsLTAxLnR4dA0KPiANCj4gPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPiC3orz+ yMs6IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3Jn XSC0+rHtDQo+ID4gVG9tZWsgTXJ1Z2Fsc2tpDQo+ID4gt6LLzcqxvOQ6IDIwMTLE6jnUwjI4yNUg NToxNQ0KPiA+IMrVvP7IyzogZGhjd2dAaWV0Zi5vcmcNCj4gPiDW98ziOiBSZTogW2RoY3dnXSBX R0xDOiBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtdHVubmVsLTAxLnR4dA0KPiA+DQo+ID4gT24gMTIt MDgtMTAgMTQ6NDIsIFRlZCBMZW1vbiB3cm90ZToNCj4gPiA+IFRoZSBhdXRob3JzIG9mIHRoaXMg ZHJhZnQgaGF2ZSByZXF1ZXN0ZWQgYSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC4NCj4gPiA+IFRo ZSBkcmFmdCBleHBsYWlucyBob3cgREhDUCBjbGllbnRzIG9wZXJhdGUgaW4gYW4gZW52aXJvbm1l bnQgd2hlcmUNCj4gPiA+IHRoZSBpbnRlcmZhY2UgYmVpbmcgY29uZmlndXJlZCBkb2Vzbid0IHN1 cHBvcnQgbXVsdGljYXN0IChlLmcuLCA2UkQpLg0KPiA+ID4gSWYgdGhpcyBpcyBhIG1hdHRlciBv ZiBpbnRlcmVzdCB0byB5b3UsIHBsZWFzZSByZXZpZXcgdGhlIGRyYWZ0IGFuZA0KPiA+ID4gc2Vu ZCBjb21tZW50cyB0byB0aGUgbGlzdC4NCj4gPiA+DQo+ID4gPiBJZiB5b3UgYXJlIGluIGZhdm9y IG9mIGFkdmFuY2luZyB0aGUgZHJhZnQsIHBsZWFzZSBzYXkgc28gb24gdGhlDQo+ID4gPiBsaXN0 OyBpZiBub2JvZHkgc3VwcG9ydHMgaXQsIGl0IHdvbid0IGFkdmFuY2UuICAgSWYgeW91IG9wcG9z ZQ0KPiA+ID4gYWR2YW5jaW5nIGl0LCBwbGVhc2UgYWxzbyBzYXkgc28uICAgV2Ugd2lsbCBkZXRl cm1pbmUgY29uc2Vuc3VzIG9uDQo+ID4gPiBBdWd1c3QgMjQuDQo+ID4gSGksDQo+ID4NCj4gPiBJ J20gdGVycmlibHkgc29ycnkgZm9yIG5vdCBqb2luaW5nIHRoZSBkaXNjdXNzaW9uIGVhcmxpZXIu IEknbSBpbg0KPiA+IGZhdm9yIG9mIGFkdmFuY2luZyB0aGUgZHJhZnQsIGJ1dCBub3QgaW4gaXRz IGN1cnJlbnQgZm9ybS4NCj4gDQo+IEhpIFRvbWVrLA0KPiANCj4gVGhhbmtzIGEgbG90IGZvciB5 b3VyIGNvbW1lbnRzLiBBcyBPbGUgaGFzIHNhaWQgZWFybGllciwgd2Ugc2hvdWxkIGRvIGJvdGgu IEkNCj4gZnVsbHkgYWdyZWUgdGhhdCB1cGRhdGluZyBSRkMzMzE1IHRvIHJlbGF4IHRoZSB1c2Fn ZSBvZiBsaW5rLWxvY2FsIGFkZHJlc3NlcyBpcw0KPiBncmVhdC4gSG93ZXZlciwgd2Ugc3RpbGwg bmVlZCBhIG1lY2hhbmlzbSBhcyBkZXNjcmliZWQgaW4gdGhlIGN1cnJlbnQgZHJhZnQgc28NCj4g ZmFyIHRvIGRlYWwgd2l0aCBleGlzdGluZyBESENQdjYgc2VydmVycyB3aGljaCBoYXZlIGJlZW4g aW1wbGVtZW50ZWQNCj4gYWNjb3JkaW5nIHRvIHRoZSBjdXJyZW50IFJGQzMzMTUgc3BlY2lmaWNh dGlvbnMsIHJhdGhlciB0aGFuIHRoZSBSRkMzMzE1YmlzLg0KPiANCj4gQmVzdCByZWdhcmRzLA0K PiBYaWFvaHUNCj4gDQo+ID4gSW4gbXkgb3BpbmlvbiBhbGxvd2luZyB0aGUgY2xpZW50IHRvIHNl bmQgZXZlcnkgbWVzc2FnZSBlbmNhcHN1bGF0ZWQNCj4gPiBpbiByZWxheS1mb3J3IHdpbGwgbm90 IGdpdmUgeW91IG11Y2gsIGJ1dCB3aWxsIGp1c3QgYnJpbmcgbW9yZQ0KPiA+IHByb2JsZW1zLiBJ bg0KPiA+IHBhcnRpY3VsYXI6DQo+ID4NCj4gPiAtIFdoYXQgd291bGQgeW91IHB1dCBpbiB0aGUg cGVlci1hZGRyIGFuZCBsaW5rLWFkZHIgZmllbGRzIG9mIHRoZQ0KPiA+IHJlbGF5LWZvcncgbWVz c2FnZT8gQmVybmllJ3Mgc3VnZ2VzdGlvbiBmb3IgcHV0dGluZyAwcyBpbiBwZWVyLWFkZHINCj4g PiBtYWtlcyBzZW5zZSwgYnV0IHdoYXQgYWJvdXQgbGluay1hZGRyPyBXb3VsZCB5b3UgcHV0IENF J3MgZ2xvYmFsDQo+ID4gdW5pY2FzdCBhZGRyZXNzIHRoZXJlPyBUaGF0IHdvdWxkIHdvcmssIGJ1 dCBpbiBtYW55IGNhc2VzIGl0IHdvdWxkDQo+ID4gc2NhbGUgdXAgcG9vcmx5LiBJZiB5b3UgaGF2 ZSAxMDAwIENFcyBpbiB5b3VyIG5ldHdvcmssIHlvdSB3b3VsZA0KPiA+IHBvdGVudGlhbGx5IG5l ZWQgdG8gY29uZmlndXJlIDEwMDAgc3VibmV0cyBhcyB0aGUgc2VydmVyIGlzIHN1cHBvc2VkDQo+ ID4gdG8gdXNlIGxpbmstYWRkciB0byBmaW5kIG91dCB0aG9zZSBsaW5rcy4gU29tZSBzZXJ2ZXJz IHJlcXVpcmUNCj4gPiBleHBsaWNpdCBuZXR3b3JrIHRvcG9sb2d5IGluZm9ybWF0aW9uIChpLmUu IGxpc3RpbmcgYWxsIGxpbmtzIHRoYXQgdGhlDQo+ID4gc2VydmVyIGlzIHN1cHBvc2VkIHRvIHN1 cHBvcnQpLiBPbiB0aGUgb3RoZXIgaGFuZCwgeW91IGNhbiBkZWZpbmUgb25lDQo+ID4gbGFyZ2Ug c3VibmV0IHRoYXQgY292ZXJzIGFsbCB5b3VyIDZyZCBDRSdzIGdsb2JhbCBhZGRyZXNzZXMsIGJ1 dCB0aGF0DQo+ID4gd291bGQgbm90IHdvcmsgaW4gY2VydGFpbiBpbXBsZW1lbnRhdGlvbnMuIFRo aXMgbGVhZHMgdG8gYSBxdWVzdGlvbiBpZg0KPiA+IHRoZSBzZXJ2ZXIgaXMgc3VwcG9zZWQgdG8g dHJlYXQgYWxsIENFcyBhcyBiZWluZyB0aGUgc2FtZSBvciBkaWZmZXJlbnQgbGlua3MuDQo+ID4N Cj4gPiAtIFRoaXMgZHJhZnQgbWVudGlvbnMgRE5TLCBTSVAgYW5kIE5UUCBvcHRpb25zLiBBcmUg d2UgdGFsa2luZw0KPiA+IHN0YXRlbGVzcyBvciBzdGF0ZWZ1bCAob3IgYm90aCkgaGVyZT8gVGhh dCBzaG91bGQgYmUgY2xhcmlmaWVkLg0KPiA+DQo+ID4gLSBUaGUgYXJndW1lbnQgZm9yIG5vdCBo YXZpbmcgdG8gdXBkYXRlIDMzMTUgaXMgd2Vhay4gVGhlcmUgYXJlIGNvdXBsZQ0KPiA+IGluY29u c2lzdGVuY2llcyBpbiBpdCBhbmQgdGhlcmUncyAzMzE1IGJpcyBwbGFubmVkIGFueXdheS4gVG8g YmUgbW9yZQ0KPiA+IHNwZWNpZmljLCBUaGlzIHN0YXRlbWVudCAiY2xpZW50IE1VU1QgdXNlIGxp bmstbG9jYWwgYWRkcmVzcy4uLiIgZnJvbQ0KPiA+IDMzMTUgaXMgaW4gZGlyZWN0IGNvbnRyYWRp Y3Rpb24gd2l0aCBhIGFub3RoZXIgc2VudGVuY2UgZnJvbSBzZWN0aW9uDQo+ID4gMTguMSBvZiAz MzE1OiAiSWYgdGhlIGNsaWVudCBoYXMgYSBzb3VyY2UgYWRkcmVzcyBvZiBzdWZmaWNpZW50IHNj b3BlDQo+ID4gdGhhdCBjYW4gYmUgdXNlZCBieSB0aGUgc2VydmVyIGFzIGEgcmV0dXJuIGFkZHJl c3MsIGFuZCB0aGUgY2xpZW50IGhhcw0KPiA+IHJlY2VpdmVkIGEgU2VydmVyIFVuaWNhc3Qgb3B0 aW9uIChzZWN0aW9uIDIyLjEyKSBmcm9tIHRoZSBzZXJ2ZXIsIHRoZQ0KPiA+IGNsaWVudCBTSE9V TEQgdW5pY2FzdCBhbnkgUmVxdWVzdCwgUmVuZXcsIFJlbGVhc2UgYW5kIERlY2xpbmUgbWVzc2Fn ZXMNCj4gPiB0byB0aGUgc2VydmVyLiINCj4gPg0KPiA+IEhhdmUgeW91IGNvbnNpZGVyZWQgYSBk aWZmZXJlbnQgYXBwcm9hY2g/IFNvbWV0aGluZyBsaWtlIHRoaXM6DQo+ID4NCj4gPiAxLiBTYXkg dGhhdCBhbnkgREhDUHY2IHNvbHV0aW9uIHdvcmtpbmcgb3ZlciB0dW5uZWxzIChvcg0KPiA+IG5v bi1tdWx0aWNhc3QsIG5vIGxpbmstbG9jYWwgaW50ZXJmYWNlcyBpbiBnZW5lcmFsKSBNVVNUIHN1 cHBvcnQgc2VydmVyDQo+IHVuaWNhc3QuDQo+ID4gMi4gTWFrZSB0aGUgNnJkIENFIHNlbmQgbm9y bWFsIG1lc3NhZ2VzIChub3QgcmVsYXllZCkgZnJvbSBpdHMgZ2xvYmFsDQo+ID4gYWRkcmVzcyB0 byA2cmQgQlIgYW55Y2FzdCBhZGRyZXNzLg0KPiA+IDMuIEV4dGVuZCB0aGUgc2VydmVyIHVuaWNh c3QgdG8gd29yayBvbiBzb2xpY2l0LCBjb25maXJtLCByZWJpbmQgYW5kDQo+ID4gaW5mLXJlcXVl c3QuICh1cGRhdGUgMzMxNSwgc2VjdGlvbiAxNSwgc2Vjb25kIHBhcmFncmFwaCkuDQo+ID4gNC4g T3B0aW9uYWxseSB1cGRhdGUgMzMxNSB0byBwb2ludCBvdXQgaW5jb25zaXN0ZW5jaWVzIHJlZ2Fy ZGluZw0KPiA+IHNvdXJjZSBhZGRyZXNzICgiTVVTVCB1c2UgbGluay1sb2NhbCBhZGRyZXNzLi4u IiBpbiBzZWN0aW9uIDE2IHZzLg0KPiA+IDE4LjEgIklmIHRoZSBjbGllbnQgaGFzIGEgc291cmNl IGFkZHJlc3Mgb2Ygc3VmZmljaWVudCBzY29wZS4uLiIpLg0KPiA+IFRoYXQgaXMgcmVhbGx5IG9w dGlvbmFsLCBhcyBhbnkgc2VydmVyIHRoYXQgaW1wbGVtZW50cyBzZXJ2ZXIgdW5pY2FzdA0KPiA+ IGFscmVhZHkgZGlzb2JleXMgdGhhdCBydWxlLg0KPiA+DQo+ID4gVGhpcyB3aWxsIHdvcmsgb24g YWxsIHNlcnZlcnMgdGhhdCBhZGhlcmUgdG8gc2VjdGlvbnMgMTcuMi4yDQo+ID4gKGFkdmVydGlz ZSkgYW5kIDE4LjIuOCAocmVwbHkpOiAiIElmIHRoZSBTb2xpY2l0IG1lc3NhZ2Ugd2FzIHJlY2Vp dmVkDQo+ID4gZGlyZWN0bHkgYnkgdGhlIHNlcnZlciwgdGhlIHNlcnZlciB1bmljYXN0cyB0aGUg QWR2ZXJ0aXNlIG1lc3NhZ2UNCj4gPiBkaXJlY3RseSB0byB0aGUgY2xpZW50IHVzaW5nIHRoZSBh ZGRyZXNzIGluIHRoZSBzb3VyY2UgYWRkcmVzcyBmaWVsZA0KPiA+IGZyb20gdGhlIElQIGRhdGFn cmFtIGluIHdoaWNoIHRoZSBTb2xpY2l0IG1lc3NhZ2Ugd2FzIHJlY2VpdmVkLiIuDQo+ID4NCj4g PiBJIHVuZGVyc3RhbmQgdGhhdCB5b3Ugd2FudCB0byBoYXZlIGl0IGRlcGxveWVkIGFzIHNvb24g YXMgcG9zc2libGUsDQo+ID4gYnV0IHdlIGhhdmUgMzMxNWJpcyB3b3JrIHBsYW5uZWQgYW55d2F5 LCBzbyB0aGVyZSB3aWxsIGJlIGNoYW5nZXMgYW5kDQo+ID4gdGhhdCBpcyB1bmF2b2lkYWJsZS4g QW5kIHdpdGggdGhlIHNlcnZlci11bmljYXN0IGFwcHJvYWNoLCBpdCByZWFsbHkNCj4gPiBpc24n dCB0aGF0IGJpZyBjaGFuZ2UuDQo+ID4NCj4gPiBTdGVwIDQgd2lsbCBoYXBwZW4gYW55d2F5LiBT byBpdCdzIGEgbWF0dGVyIG9mIHVwZGF0aW5nIHNlY3Rpb24gMTU6DQo+ID4NCj4gPiAiQSBzZXJ2 ZXIgTVVTVCBkaXNjYXJkIGFueSBTb2xpY2l0LCBDb25maXJtLCBSZWJpbmQgb3INCj4gPiBJbmZv cm1hdGlvbi1yZXF1ZXN0IG1lc3NhZ2VzIGl0IHJlY2VpdmVzIHdpdGggYSB1bmljYXN0IGRlc3Rp bmF0aW9uDQo+ID4gYWRkcmVzcy4iDQo+ID4NCj4gPiB0bw0KPiA+DQo+ID4gIkEgc2VydmVyIE1V U1QgZGlzY2FyZCBhbnkgU29saWNpdCwgQ29uZmlybSwgUmViaW5kIG9yDQo+ID4gSW5mb3JtYXRp b24tcmVxdWVzdCBtZXNzYWdlcyBpdCByZWNlaXZlcyB3aXRoIGEgdW5pY2FzdCBkZXN0aW5hdGlv bg0KPiA+IGFkZHJlc3MsIHVubGVzcyBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgdG8gdXNlIHNlcnZl ciB1bmljYXN0IG9wdGlvbg0KPiA+IHdpdGggdGhhdCBhZGRyZXNzLiIuDQo+ID4NCj4gPiBJZiB3 ZSBhcmUgY29uY2VybmVkIG9mIGFueSBwb3NzaWJsZSBzaWRlIGVmZmVjdHMgaW4gbm9ybWFsIGRl cGxveW1lbnQNCj4gPiBzY2VuYXJpb3MsIHdlIG1heSB3b3JrIG91dCBzb21lIGV4dHJhIHNhZmV0 eSBjaGVja3MgKGFkZCAiLi4uIGFuZCB0aGUNCj4gPiByZWNlaXZpbmcgaW50ZXJmYWNlIGRvZXMg bm90IHN1cHBvcnQgbXVsdGljYXN0IG5vciBsaW5rLWxvY2FsIGFkZHJlc3NlcyIpLg0KPiA+DQo+ ID4gU3VyZSwgZXhwZWN0aW5nIHRoZSBjbGllbnQgdG8gbWFnaWNhbGx5IGtub3cgc2VydmVyIGFk ZHJlc3Mgd2hlbg0KPiA+IHNlbmRpbmcgdGhlIGZpcnN0IHNvbGljaXQgaXMgb2RkLCBidXQgaWYg d2Ugd2FudCB0byBtYWtlIERIQ1B2NiB3b3JrDQo+ID4gb24gbm9uLW11bHRpY2FzdCwgbm8gbGlu ay1sb2NhbCBpbnRlcmZhY2VzLCB3ZSBuZWVkIHRvIG1ha2Ugc29tZQ0KPiA+IGNvbXByb21pc2Vz LiBJIHZlcnkgbXVjaCBwcmVmZXIgdGhhdCBhcHByb2FjaCwgY29tcGFyZWQgdG8gdGhlIHNlcnZl cg0KPiA+IHJlcG9ydGluZyB0aGF0IHRoZXJlIGFyZSAxMDAwcyBvZiBuZXcgcmVsYXlzIG9yIHNl cnZlciBzdGFydGluZyB0bw0KPiA+IGJsaW5kbHkgYWNjZXB0aW5nIHVuaWNhc3QgbWVzc2FnZXMu DQo+ID4NCj4gPiBPbiB0aGUgb3RoZXIgaGFuZCwgdGhlcmUncyBSRkM2Mjc2IHRoYXQgdGFsa3Mg YWJvdXQgY28tbG9jYXRpbmcgcmVsYXkNCj4gPiBhbmQgUEQgY2xpZW50LCBzbyB0aGUgZWZmb3J0 IHRvIGF2b2lkIGl0IGlzIGFscmVhZHkgbG9zdC4NCj4gPg0KPiA+IEVkaXRvcmlhbCBjb21tZW50 Og0KPiA+ICJUaGUgNnJkIENFIERIQ1B2NiByZWxheSBhZ2VudCBTSE9VTEQgdXNlIHRoZSA2cmQg QlIgSVB2NiBhbnljYXN0DQo+ID4gYWRkcmVzcyBhcyB0aGUgZGVzdGluYXRpb24gYWRkcmVzcywg c2VjdGlvbiAyMCBvZiBbUkZDMzMxNV0iLiBUaGF0DQo+ID4gcmVmZXJlbmNlIHRvIHNlY3Rpb24g MjAgb2YgUkZDMzMxNSBpcyBzdHJhbmdlLiBTZWN0aW9uIDIwIGRlc2NyaWJlcw0KPiA+IHJlbGF5 IG9wZXJhdGlvbi4gV2hhdCBleGFjdGx5IGF1dGhvcnMgd2FudCB0byBwb2ludCB0byBpbiB0aGlz IGNvbnRleHQ/DQo+ID4NCj4gPiBIb3BlIHRoYXQgaGVscHMsDQo+ID4gVG9tZWsNCj4gPg0KPiA+ IHAucy4NCj4gPiBXaGVyZSBhcmUgd2Ugd2l0aCB0aGUgMzMxNWJpcyBwbGFucz8gSSBrbm93IHRo YXQgaXQgaXMgYSBtYWpvciB3b3JrLA0KPiA+IHNvIGl0IGlzIG5vdCBlYXN5IHRvIGNvbW1pdCB0 byBpdCwgYnV0IHRoZXJlIGFyZSBtb3JlIGFuZCBtb3JlIHRoaW5ncw0KPiA+IHRoYXQgcmVxdWly ZSB1cGRhdGUuIEknbSBhbHJlYWR5IG92ZXJidXJkZW5lZCB3aXRoIHRoZSBmYWlsb3ZlciB3b3Jr DQo+ID4gYW5kIG90aGVyIHN0dWZmLCBidXQgZm9yIHN1Y2ggYSBncmFuZCBwdXJwb3NlIEkgd2ls bCBmaW5kIHNvbWUgdGltZS4NCj4gPg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGRoY3dnIG1haWxpbmcgbGlzdA0KPiA+ IGRoY3dnQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kaGN3Zw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBkaGN3ZyBtYWlsaW5nIGxpc3QNCj4gZGhjd2dAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBkaGN3ZyBtYWlsaW5nIGxpc3QNCj4gZGhjd2dA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0K From Ted.Lemon@nominum.com Fri Sep 28 19:59:23 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4463B21F8643 for ; Fri, 28 Sep 2012 19:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.626 X-Spam-Level: X-Spam-Status: No, score=-105.626 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkIaYiKUrByE for ; Fri, 28 Sep 2012 19:59:22 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8B60821F863F for ; Fri, 28 Sep 2012 19:59:22 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUGZkChQaz2zaNGFy9IZeilS6QXAUXqvV@postini.com; Fri, 28 Sep 2012 19:59:22 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id BC03C108007 for ; Fri, 28 Sep 2012 19:59:21 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id AE65E19005C; Fri, 28 Sep 2012 19:59:21 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 28 Sep 2012 19:59:16 -0700 From: Ted Lemon To: Xuxiaohu Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Thread-Index: AQHNnPUuXMpQailO5E2MrdROm+zFG5eferUAgAC9JwCAAN51AIAAAe+A Date: Sat, 29 Sep 2012 02:59:16 +0000 Message-ID: <96AEEED6-F7E2-4C0D-84B8-B4ED0CF5E054@nominum.com> References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <5064C1D6.6070201@gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0755D36B@szxeml525-mbx.china.huawei.com> <489D13FBFA9B3E41812EA89F188F018E0F50792C@xmb-rcd-x04.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0755D57E@szxeml525-mbx.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0755D57E@szxeml525-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="gb2312" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 02:59:23 -0000 T24gU2VwIDI4LCAyMDEyLCBhdCAxMDo1MiBQTSwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5j b20+IHdyb3RlOg0KPiBJbiBhZGRpdGlvbiwgc2luY2UgdGhpcyBkcmFmdCBpcyBqdXN0IGludGVu ZGVkIHRvIHVzZSBzdGF0ZWxlc3MgREhDUHY2LCB3b3VsZCB5b3UgcGxlYXNlIGxpc3QgYW55IGNv bmNyZXRlIGNhc2VzIHdoZXJlIHRoZSBzZXJ2ZXIgbmVlZHMgdG8gdXNlIHRoZSBjb3JyZWN0IHJl bGF5IGluZm9ybWF0aW9uPw0KDQpUaGUgcmVhc29uIHRoYXQgZXZlbiBpbmZvcm1hdGlvbiByZXF1 ZXN0IG1lc3NhZ2VzIGFyZSByZXF1aXJlZCB0byBiZSBicm9hZGNhc3QgaXMgdGhhdCBhIGRldmlj ZSB0aGF0IGRvZXMgc3RhdGVmdWwgYW5kIHRoZW4gc3RhdGVsZXNzIHNob3VsZCBnZXQgdGhlIHNh bWUgYW5zd2VycywgYW5kIHRoaXMgY2FuJ3QgaGFwcGVuIGlmIHRoZSByZWxheXMgYXJlbid0IGlu IHRoZSBwYXRoIGFuZCBhcmVuJ3QgYWJsZSB0byBhZGQgdGhlaXIgb3B0aW9ucy4NCg0KQWxzbywg aXQgc2VlbXMgdG8gbWUgdGhhdCB5b3VyIHR1bm5lbCBkcmFmdCBpcyBhcHBsaWNhYmxlIHRvIHBy ZWZpeCBkZWxlZ2F0aW9uOyBJIHJlYWxpemUgdGhpcyBpc24ndCBhbiBpbnRlbmRlZCB1c2UgdGhh dCB5b3UgaGF2ZSBpbiBtaW5kLCBidXQgaXQncyBjZXJ0YWlubHkgYSBwZXJmZWN0bHkgdmFsaWQg b25lLCBhbmQgc29tZW9uZSB3aWxsIG5vIGRvdWJ0IHdhbnQgaXQgYXQgc29tZSBsYXRlciBkYXRl LiAgIFNvIHdlIHNob3VsZG4ndCBkZXNpZ24gYSBzb2x1dGlvbiB0aGF0IHdlJ3JlIG5vdCBjb21m b3J0YWJsZSB3aXRoIGluIHRoYXQgY2FzZS4NCg0KPiBBcyBzdWNoLCBubyBtYXR0ZXIgYSBESENQ IHNlcnZlciBvciBhIERIQ1AgcmVsYXkgYWdlbnQgaXMgcHJlc2VudCBvbiB0aGF0IEJSLCB0aGUg aW1wbGVtZW50YXRpb25zIG9mIERIQ1Agb24gYm90aCB0aGUgQlIgKGVpdGhlciBhcyBhIHNlcnZl ciBvciBhIHJlbGF5IGFnZW50KSBhbmQgdGhlIENFIChhcyBhIGNsaWVudCkgc2hvdWxkIGJlIGNo YW5nZWQgYW5kIHRoZXJlZm9yZSBhcmUgbm90IGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgZXhpc3Rp bmcgUkZDMzMxNSBzcGVjaWZpY2F0aW9ucyBhbnltb3JlLg0KDQpUaGlzIGlzIHdoeSB3ZSBhcmUg dGFsa2luZyBhYm91dCB1cGRhdGluZyBSRkMzMzE1Lg0KDQo= From volz@cisco.com Fri Sep 28 20:38:00 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0BE21F8613 for ; Fri, 28 Sep 2012 20:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.474 X-Spam-Level: X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPsJXir4pb61 for ; Fri, 28 Sep 2012 20:37:59 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA6C21F8496 for ; Fri, 28 Sep 2012 20:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2305; q=dns/txt; s=iport; t=1348889867; x=1350099467; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Rp+TrvnndHQbC4G5OVXiRQiK0Lf3y3PNT24TvCW+5F0=; b=Qs1YeweJpx30UX9Rtc8nZJdtVgFd05vvzwcoU4NLiyQCuWkYDxC71Ww9 IIVyL2Q1ttBGElD7zLCdwUKKVSJrEABIKOcNmk74AZNwaWKYI0502TRey AaymFP8+8rKX9OwMfErqaIBnAMURcGvnvRzy9BIEqwjakitj5Li7cSBbz g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOZrZlCtJXHA/2dsb2JhbABFvjCBCIIgAQEBAwESASc/BQcEAgEIEQQBAQEKFAkHMhQJCAIEAQ0FCBMHh10GmG+gGYsfFIVXYAOkK4FpgmeBWj0 X-IronPort-AV: E=Sophos;i="4.80,505,1344211200"; d="scan'208";a="126595926" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 29 Sep 2012 03:37:46 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8T3bkUl007358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 29 Sep 2012 03:37:46 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Fri, 28 Sep 2012 22:37:46 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , Xuxiaohu Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Thread-Index: AQHNnPUoSDMOAnuzpUmlatl1eCUEGJee/TdwgAC6FeCAANr4AIAAZHYA//+0lMA= Date: Sat, 29 Sep 2012 03:37:45 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F507C50@xmb-rcd-x04.cisco.com> References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <5064C1D6.6070201@gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0755D36B@szxeml525-mbx.china.huawei.com> <489D13FBFA9B3E41812EA89F188F018E0F50792C@xmb-rcd-x04.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0755D57E@szxeml525-mbx.china.huawei.com> <96AEEED6-F7E2-4C0D-84B8-B4ED0CF5E054@nominum.com> In-Reply-To: <96AEEED6-F7E2-4C0D-84B8-B4ED0CF5E054@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.159] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19216.004 x-tm-as-result: No--35.764700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 03:38:00 -0000 > This is why we are talking about updating RFC3315. Yup ... my point exactly. As stated in RFC3315 section 13, a separate document may detail how to appl= y DHCPv6 to other link types. I think it is rather natural to have to relax= some of the unicast restrictions if multicast isn't used (how else would t= his work). I think this is perfectly in line with what was intended by such= a document. I would also like to make sure we design something that can support all of = DHCPv6 and not something limited to Information-Request/Reply. Also, perhap= s I missed it but I see nothing in your document that states it is limited = to Information-Request/Reply? But again, even if it did say that, I would s= till want us to specify something that could accommodate the full DHCPv6 ra= nge of messages. - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Friday, September 28, 2012 10:59 PM To: Xuxiaohu Cc: Bernie Volz (volz); Tomek Mrugalski; dhcwg@ietf.org Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt On Sep 28, 2012, at 10:52 PM, Xuxiaohu wrote: > In addition, since this draft is just intended to use stateless DHCPv6, w= ould you please list any concrete cases where the server needs to use the c= orrect relay information? The reason that even information request messages are required to be broadc= ast is that a device that does stateful and then stateless should get the s= ame answers, and this can't happen if the relays aren't in the path and are= n't able to add their options. Also, it seems to me that your tunnel draft is applicable to prefix delegat= ion; I realize this isn't an intended use that you have in mind, but it's c= ertainly a perfectly valid one, and someone will no doubt want it at some l= ater date. So we shouldn't design a solution that we're not comfortable w= ith in that case. > As such, no matter a DHCP server or a DHCP relay agent is present on that= BR, the implementations of DHCP on both the BR (either as a server or a re= lay agent) and the CE (as a client) should be changed and therefore are not= in accordance with the existing RFC3315 specifications anymore. This is why we are talking about updating RFC3315. From ghalwasi@cisco.com Sun Sep 30 19:49:10 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D5D21F8555 for ; Sun, 30 Sep 2012 19:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.347 X-Spam-Level: X-Spam-Status: No, score=-10.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXjYt3foaoNJ for ; Sun, 30 Sep 2012 19:48:52 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8F521F8554 for ; Sun, 30 Sep 2012 19:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1210; q=dns/txt; s=iport; t=1349059732; x=1350269332; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=nKMGoYZQZs3i510pkrIZwgSLMLnsoYGvz13B+UoedNE=; b=csSxr7Hkp2qVqXbP/TtDRUBfm/w8FU1yBi58ldvWWRWqSU7CPiOBfdHM NDUkTj5e+tdGpMYVdZv5WVYQDY4LA+tUEa1qMcW6nPv2RyKg00V0AXjZE edmc8K+ONQwKWtkJ/Z2OU6Ej9zJDpB9deqKWHBdmL62hdFehSOwmfjsUH w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEkEaVCtJXG+/2dsb2JhbABFvjmBCIIgAQEBBAEBAQ8BCh00FwQCAQgRBAEBCxQJBycLFAkIAgQBEggah2MLmjafFgSLH4VrYAOkK4FpgmeCFw X-IronPort-AV: E=Sophos;i="4.80,514,1344211200"; d="scan'208";a="126964891" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 01 Oct 2012 02:48:51 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q912mpnr032022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Oct 2012 02:48:51 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.235]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Sun, 30 Sep 2012 21:48:51 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Ted Lemon , dhc WG Thread-Topic: Call for adoption: draft-lemon-dhc-pd-01 Thread-Index: AQHNlrARAq1IuhHT2UasbuE4rMIyj5ej0M6g Date: Mon, 1 Oct 2012 02:48:51 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB1BD3A001@xmb-aln-x06.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.82.82] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19222.004 x-tm-as-result: No--43.641700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Call for adoption: draft-lemon-dhc-pd-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 02:49:10 -0000 I read this I.D and I think it's a useful work to do. I am in favor of adop= ting this document as WG document. Thanks, Gaurav=20 -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Thursday, September 20, 2012 3:15 AM To: dhc WG Subject: [dhcwg] Call for adoption: draft-lemon-dhc-pd-01 I'd like the working group to work on this document. The point of the doc= ument is to provide a mechanism whereby DHCP requesting routers can indicat= e their preference to the DHCP delegating router as to how the reverse zone= for a delegated prefix should be handled, and to provide a mechanism where= by the delegating router can communicate back to the requesting router the = mechanism that was chosen. John will be evaluating consensus, since I'm the author of the draft. He = will evaluate consensus some time after October 2. If you are in favor of= adopting this draft, please say so on the mailing list. If you think it'= s a bad idea, please say so on the list. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg