From pjhingra@cisco.com Tue Jul 3 03:09: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 DAC9D21F87DE for ; Tue, 3 Jul 2012 03:09:37 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lx1O3GUCZvbr for ; Tue, 3 Jul 2012 03:09:37 -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 8EC7C21F87DD for ; Tue, 3 Jul 2012 03:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pjhingra@cisco.com; l=962; q=dns/txt; s=iport; t=1341310184; x=1342519784; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=zNsQtxfX+AtKNrWyMMyk61u0dwW477/2v1DCy5iVMeo=; b=Qd0m+CbUPzxfhV2yV0rCRGdbFviUF1WziJKJU03sGYjMLXnRAvxj16du Z0XKF5owonpb/3oJDNa69GXeBqcrw/jVlTfZXDDshcnzeq+QCe220nmQH iPQclZ+2GPohVjA//JawTzUeqFhxYbBjHs1xtI9VLMPEpBh9v6Xidl3ri g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALHD8k+tJXG9/2dsb2JhbABFtmiBB4IYAQEBBAEBAQ8BCh00FwQCAQgRBAEBCxQJBycLFAkIAgQBEggah2kLmnOgSgSLOIU6YAOjUoFmgl8 X-IronPort-AV: E=Sophos;i="4.77,514,1336348800"; d="scan'208";a="98322246" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 03 Jul 2012 10:09:36 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q63A9YT1009940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jul 2012 10:09:34 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.68]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Tue, 3 Jul 2012 05:09:33 -0500 From: "Prashant Jhingran (pjhingra)" To: Ted Lemon , "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] Call for adoption: draft-halwasia-dhc-dhcpv6-hardware-addr-opt Thread-Index: AQHNU5KEDrOys2eyz0i2Aoad2FFKDpcXYIbA Date: Tue, 3 Jul 2012 10:09:32 +0000 Message-ID: References: <45496742-3C07-491A-BCCA-43DC706639AA@nominum.com> In-Reply-To: <45496742-3C07-491A-BCCA-43DC706639AA@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.64.97] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19014.005 x-tm-as-result: No--39.659500-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-halwasia-dhc-dhcpv6-hardware-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: Tue, 03 Jul 2012 10:09:38 -0000 +1, 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: Tuesday, June 26, 2012 5:25 PM To: dhcwg@ietf.org WG Subject: [dhcwg] Call for adoption: draft-halwasia-dhc-dhcpv6-hardware-addr= -opt Folks, there was a call for adoption on the list in April, and a few people= spoke out in favor. Nobody spoke against. The call was somewhat inform= al, so I'm making it formal. If you object to adopting this as a working = group work item, please say so by Tuesday, July 3. There are already a nu= mber of voices in favor, so if I don't hear any objections the consensus wi= ll be in favor, but if you are in favor please say so anyway just in case t= here is opposition. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Tue Jul 3 07:02: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 148E311E80D5 for ; Tue, 3 Jul 2012 07:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.536 X-Spam-Level: X-Spam-Status: No, score=-106.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEQGoio9x3vh for ; Tue, 3 Jul 2012 07:02:22 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 0D52811E807F for ; Tue, 3 Jul 2012 07:02:21 -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 DSNKT/L7dbw9BKhRrGki+c25hhqqcJZdE+pn@postini.com; Tue, 03 Jul 2012 07:02: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 8C9FE1B82FF for ; Tue, 3 Jul 2012 07:02: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 82357190043 for ; Tue, 3 Jul 2012 07:02: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; Tue, 3 Jul 2012 07:02:28 -0700 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] Call for adoption: draft-halwasia-dhc-dhcpv6-hardware-addr-opt Thread-Index: AQHNWSR68tHlWH6xFUGW+HWnShc4nw== Date: Tue, 3 Jul 2012 14:02:27 +0000 Message-ID: <9B258916-24C9-462D-AA12-0D578C2E8BC8@nominum.com> References: <45496742-3C07-491A-BCCA-43DC706639AA@nominum.com> In-Reply-To: <45496742-3C07-491A-BCCA-43DC706639AA@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: multipart/alternative; boundary="_000_9B25891624C9462DAA120D578C2E8BC8nominumcom_" MIME-Version: 1.0 Subject: Re: [dhcwg] Call for adoption: draft-halwasia-dhc-dhcpv6-hardware-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: Tue, 03 Jul 2012 14:02:23 -0000 --_000_9B25891624C9462DAA120D578C2E8BC8nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jun 26, 2012, at 7:55 AM, Ted Lemon wrote: Folks, there was a call for adoption on the list in April, and a few people= spoke out in favor. Nobody spoke against. The call was somewhat inform= al, so I'm making it formal. If you object to adopting this as a working = group work item, please say so by Tuesday, July 3. There are already a nu= mber of voices in favor, so if I don't hear any objections the consensus wi= ll be in favor, but if you are in favor please say so anyway just in case t= here is opposition. This draft had significant support and no opposition, so it's adopted as a = working group draft. Would the authors please submit a -00 version of dra= ft-ietf-dhc-dhcpv6-hardware-addr-opt ASAP? We're past a soft deadline for= the coming IETF, and approaching a hard deadline, so sooner is better if y= ou can manage it. :) Thanks! --_000_9B25891624C9462DAA120D578C2E8BC8nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0EC692E17573FA4AB5B30FECC021EABA@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jun 26, 2012, at 7:55 AM, Ted Lemon wrote:
Folks, there was a call for adoption on the list in April, and a few people spoke= out in favor.   Nobody spoke against.   The call was s= omewhat informal, so I'm making it formal.   If you object to ado= pting this as a working group work item, please say so by Tuesday, July 3.   There are already a number of voices in favor, so if I= don't hear any objections the consensus will be in favor, but if you are i= n favor please say so anyway just in case there is opposition.

This draft had significant support and no opposition, so it's adopted = as a working group draft.   Would the authors please submit a -00 vers= ion of draft-ietf-dhc-dhcpv6-hardware-addr-opt ASAP?   We're past a so= ft deadline for the coming IETF, and approaching a hard deadline, so sooner is better if you can manage it.   :)

Thanks!

--_000_9B25891624C9462DAA120D578C2E8BC8nominumcom_-- From volz@cisco.com Tue Jul 3 07:02: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 578C611E8111 for ; Tue, 3 Jul 2012 07:02:35 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3P3QoPWQDS75 for ; Tue, 3 Jul 2012 07:02:34 -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 9700211E8089 for ; Tue, 3 Jul 2012 07:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=921; q=dns/txt; s=iport; t=1341324162; x=1342533762; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=clXhUtM7ylOo25iX6vg/BEZYFD5cl2OkBeV4wst9qZk=; b=hd0mxLZ8aZgpRgMHUwdFo717Us0z7Fd6nnfXdM9Ms66zPHmzg1kSRq6h VJZv7IjrS3wh/vqocsa6sGbkKAgQFQmdDcMkCQncFGpCY2sAEf+IeW4Ke lylTQExJ2kW1WsiaSyKpZk3s5IjvNm4U4Hwoy5EyMKL7RZx2hd50Dv4op 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHz68k+tJXG9/2dsb2JhbABFtmSBB4IYAQEBBAEBAQ8BCh00FwYBCBEEAQELFAkuCxQJCgQBEggah2kLmkigRQSLN4U6YAOjUoFmgl8 X-IronPort-AV: E=Sophos;i="4.77,515,1336348800"; d="scan'208";a="98150993" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 03 Jul 2012 14:02:42 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q63E2gZj013300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jul 2012 14:02:42 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.57]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Tue, 3 Jul 2012 09:02:41 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] Call for adoption:draft-halwasia-dhc-dhcpv6-hardware-addr-opt Thread-Index: AQHNU5KEDrOys2eyz0i2Aoad2FFKDpcXodKQ Date: Tue, 3 Jul 2012 14:02:38 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018EFBB5@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.242.218] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19014.005 x-tm-as-result: No--39.659500-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-halwasia-dhc-dhcpv6-hardware-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: Tue, 03 Jul 2012 14:02:35 -0000 In favor of adopting. -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Tuesday, June 26, 2012 7:55 AM To: dhcwg@ietf.org WG Subject: [dhcwg] Call for adoption:draft-halwasia-dhc-dhcpv6-hardware-addr-= opt Folks, there was a call for adoption on the list in April, and a few people= spoke out in favor. Nobody spoke against. The call was somewhat inform= al, so I'm making it formal. If you object to adopting this as a working = group work item, please say so by Tuesday, July 3. There are already a nu= mber of voices in favor, so if I don't hear any objections the consensus wi= ll be in favor, but if you are in favor please say so anyway just in case t= here is opposition. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From ghalwasi@cisco.com Tue Jul 3 07:04: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 6826921F857F for ; Tue, 3 Jul 2012 07:04:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+Ib74Iu86Oe for ; Tue, 3 Jul 2012 07:04:17 -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 C8E0C21F8818 for ; Tue, 3 Jul 2012 07:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=6683; q=dns/txt; s=iport; t=1341324265; x=1342533865; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=/PCih9qB/jaH1aZTz+Ekpu8TYwBwDDUmUilv3adnJyI=; b=PSV/+4CzjpE/LtAhvca/2fK9DM9xkQxrJ2+QT2nahzfVShpjK0anA+Or ppCC6t2sHMqrzmhrnA9Ice/1LyrT4cEv2PzLp/xtmR3sjBPXXv5q9RDB2 aqAxnBzQZ56n7zm3nnpSs6XXBplu8LE51OIOrk57EgdEDuciUrCyI4oer I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALr78k+tJV2Z/2dsb2JhbABEgkW0H4EHghgBAQEEEgEKEFwCAQgRBAEBCx0HMhQJCAIEARIIGodpmj6gR4s3hTpgA6NSgWaCXw X-IronPort-AV: E=Sophos;i="4.77,515,1336348800"; d="scan'208,217";a="98151691" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 03 Jul 2012 14:04:24 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q63E4OQo028473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jul 2012 14:04:24 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.14]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Tue, 3 Jul 2012 09:04:24 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Ted Lemon , "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] Call for adoption: draft-halwasia-dhc-dhcpv6-hardware-addr-opt Thread-Index: AQHNWSSJiRzWVzi8OEmSsn/QpGsj2ZcXlvBQ Date: Tue, 3 Jul 2012 14:04:22 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB0554F5@xmb-aln-x06.cisco.com> References: <45496742-3C07-491A-BCCA-43DC706639AA@nominum.com> <9B258916-24C9-462D-AA12-0D578C2E8BC8@nominum.com> In-Reply-To: <9B258916-24C9-462D-AA12-0D578C2E8BC8@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.64.32] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19014.003 x-tm-as-result: No--43.796900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_90903C21C73202418A48BFBE80AEE5EB0554F5xmbalnx06ciscocom_" MIME-Version: 1.0 Subject: Re: [dhcwg] Call for adoption: draft-halwasia-dhc-dhcpv6-hardware-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: Tue, 03 Jul 2012 14:04:18 -0000 --_000_90903C21C73202418A48BFBE80AEE5EB0554F5xmbalnx06ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure, Ted, I will post -00 version soon. Thanks, Gaurav From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Tuesday, July 03, 2012 7:32 PM To: dhcwg@ietf.org WG Subject: Re: [dhcwg] Call for adoption: draft-halwasia-dhc-dhcpv6-hardware-= addr-opt On Jun 26, 2012, at 7:55 AM, Ted Lemon wrote: Folks, there was a call for adoption on the list in April, and a few people= spoke out in favor. Nobody spoke against. The call was somewhat inform= al, so I'm making it formal. If you object to adopting this as a working = group work item, please say so by Tuesday, July 3. There are already a nu= mber of voices in favor, so if I don't hear any objections the consensus wi= ll be in favor, but if you are in favor please say so anyway just in case t= here is opposition. This draft had significant support and no opposition, so it's adopted as a = working group draft. Would the authors please submit a -00 version of dra= ft-ietf-dhc-dhcpv6-hardware-addr-opt ASAP? We're past a soft deadline for= the coming IETF, and approaching a hard deadline, so sooner is better if y= ou can manage it. :) Thanks! --_000_90903C21C73202418A48BFBE80AEE5EB0554F5xmbalnx06ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sure, Ted, I will post -00 version soon.

 

Thanks,

Gaurav

 <= /p>

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon
Sent: Tuesday, July 03, 2012 7:32 PM
To: dhcwg@ietf.org WG
Subject: Re: [dhcwg] Call for adoption: draft-halwasia-dhc-dhcpv6-ha= rdware-addr-opt

 

On Jun 26, 2012, at 7:55 AM, Ted Lemon wrote:

Folk= s, there was a call for adoption on the list in April, and a few people spo= ke out in favor.   Nobody spoke against.   The call was= somewhat informal, so I'm making it formal.   If you object to adopting t= his as a working group work item, please say so by Tuesday, July 3.  &= nbsp;There are already a number of voices in favor, so if I don't hear any = objections the consensus will be in favor, but if you are in favor please say so anyway just in case there is opposition.=

 

This draft had significant support and no opposition= , so it's adopted as a working group draft.   Would the authors please= submit a -00 version of draft-ietf-dhc-dhcpv6-hardware-addr-opt ASAP? &nbs= p; We're past a soft deadline for the coming IETF, and approaching a hard deadline, so sooner is better if you can mana= ge it.   :)

 

Thanks!

 

--_000_90903C21C73202418A48BFBE80AEE5EB0554F5xmbalnx06ciscocom_-- From internet-drafts@ietf.org Tue Jul 3 09:09: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 4B09F11E81A1; Tue, 3 Jul 2012 09:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AGp2ad0HMKU; Tue, 3 Jul 2012 09:09:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BB211E819C; Tue, 3 Jul 2012 09:09: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.21p1 Message-ID: <20120703160901.14518.93555.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2012 09:09:01 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Tue, 03 Jul 2012 16:09:03 -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-00.txt Pages : 6 Date : 2012-07-03 Abstract: This document specifies the format and mechanism that is to be used for encoding client link-layer address in DHCPv6 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= -00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From akostur@incognito.com Tue Jul 3 12: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 E475C11E80F2 for ; Tue, 3 Jul 2012 12:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHW0ACPRgUXI for ; Tue, 3 Jul 2012 12:52:58 -0700 (PDT) Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) by ietfa.amsl.com (Postfix) with SMTP id 703D611E80CA for ; Tue, 3 Jul 2012 12:52:57 -0700 (PDT) Received: from mail-lb0-f175.google.com ([209.85.217.175]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKT/NNoU50C6wU73de1VV2AwYTh0if49L7@postini.com; Tue, 03 Jul 2012 12:53:06 PDT Received: by lbol5 with SMTP id l5so10341185lbo.34 for ; Tue, 03 Jul 2012 12:53:04 -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 :content-type:x-gm-message-state; bh=5nnwy6g1AriyK7Zjj6pvOSr8W+J2EbfvgOs1piMUXm0=; b=Ksa+2WZJnfOqc5okz7Dm8ahQx/TVI19XBuPrgcDN2qLn06E8ujsVQFeGPuGtIaf7Ef 3nW0x41qRjucQP1XA3TUNOIeZN1kbY09pj4bcvdW4PHGKL+0gyBZdHUwCXj5xwP9FnvT 2MZqrwHxnZt9H0/4FS1lTDY+3XHBjQuFLhal16QTQ0kz7rhM7W/At0pi7j/PNjz6PT9i 3qC66r37Cxw2Qu8d3ztM+gWkoy0TGdrfORvNdOWw6q9Y3kPr7Mg8eApe69GhhQfPfQ7G kR54UGaKV2Gtzb0Hy/a7NMKP0nbqBQig+L7Vo653ef8mJGK12CSl2OpSaR1VUsVKWxWn rhKw== MIME-Version: 1.0 Received: by 10.152.144.138 with SMTP id sm10mr14912011lab.22.1341345183710; Tue, 03 Jul 2012 12:53:03 -0700 (PDT) Received: by 10.112.40.228 with HTTP; Tue, 3 Jul 2012 12:53:03 -0700 (PDT) In-Reply-To: <20120703160901.14518.93555.idtracker@ietfa.amsl.com> References: <20120703160901.14518.93555.idtracker@ietfa.amsl.com> Date: Tue, 3 Jul 2012 12:53:03 -0700 Message-ID: From: Andre Kostur To: dhcwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnAf05I2b+/4+39vLCJkULLupYHzSyhLYhxl+J3+4HuhBaufDv4tkpedmQ5xxsikLwDEIhy Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Tue, 03 Jul 2012 19:52:59 -0000 I think section 4 needs a little more to it. As it stands, the section talks about putting in the link-layer address, but does not specify which one. Perhaps that should be changed to specify that this is the link-address of the interface that the host is attempting to configure. The use-case I'm thinking of is perhaps a laptop with both a wired and wireless interface. We'd like to communicate the link-address of the wired interface when configuring the wired interface, and the link-address of the wifi interface when configuring that interface. As written (since it's unspecified), a host could conceivably use the wired link-address for both transactions. I think the phrasing "All hosts or clients MAY include.." is inconsistent with other RFCs. I think it is sufficient to say "A client MAY include this option ..." to be consistent with RFC 3315, section 22.14, 22.9, and others. On Tue, Jul 3, 2012 at 9:09 AM, 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-00.txt > Pages : 6 > Date : 2012-07-03 > > Abstract: > This document specifies the format and mechanism that is to be used > for encoding client link-layer address in DHCPv6 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-00 > > > 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 -- Andre Kostur From Ted.Lemon@nominum.com Tue Jul 3 13:30: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 4B5DE11E80A2 for ; Tue, 3 Jul 2012 13:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 801Dw+w6zSwP for ; Tue, 3 Jul 2012 13:30:35 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 8946511E80EF for ; Tue, 3 Jul 2012 13:30:35 -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 DSNKT/NWc1VkRk2Q4IN3UcePl7Mlv8LKICJr@postini.com; Tue, 03 Jul 2012 13:30: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 B12E11B8300 for ; Tue, 3 Jul 2012 13:30:41 -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 A8B40190043; Tue, 3 Jul 2012 13:30:41 -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, 3 Jul 2012 13:30:41 -0700 From: Ted Lemon To: Andre Kostur Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNWTYzEnSkOV9kXEK+vS82ZmpDh5cYbdWAgAAKgwA= Date: Tue, 3 Jul 2012 20:30:41 +0000 Message-ID: <6A888CF2-7AB0-4913-A3A6-BA430531E3E7@nominum.com> References: <20120703160901.14518.93555.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: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0DC7ED210D393240BEF9918EA88CD462@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Tue, 03 Jul 2012 20:30:36 -0000 I think the section about clients including link-layer addresses should jus= t be removed. This option ought to be for relay agents only, because that= 's the only way it will be ubiquitous. We shouldn't confuse the issue by = proposing that it apply to clients as well=97if we do, it will see really s= potty adoption, and probably not be of much use. From akostur@incognito.com Tue Jul 3 13:43: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 72DC711E816F for ; Tue, 3 Jul 2012 13:43:58 -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=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfLbXPQg0I8i for ; Tue, 3 Jul 2012 13:43:57 -0700 (PDT) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by ietfa.amsl.com (Postfix) with SMTP id D0FE511E80A2 for ; Tue, 3 Jul 2012 13:43:56 -0700 (PDT) Received: from mail-lb0-f176.google.com ([209.85.217.176]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKT/NZjzy9nnPBgJyHBWgAsSj5loz0wbt6@postini.com; Tue, 03 Jul 2012 13:44:06 PDT Received: by lboj14 with SMTP id j14so8542279lbo.7 for ; Tue, 03 Jul 2012 13:43:58 -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=KZdgCUwh/YjyDD/w3cVkxyS2vQv8Q1jCwYAWkN/tuD8=; b=IzP4uCSgJs/UKSgZmhLOHb47CGdjWOFL2yq/n2i9eBCgLufHw9bJObQXhHz+1CJNlG GfYovNsTF755PwQ0A3aWoQ8Q+XL/waCYjrD6z21ui5Qtbrnf+sKWjourk+pVUH/WvjaP epNljBypheYFuhjWCARj1VPZfUtKAbYCBvcFjSk3MFYkIPYXJP4p7oW5FrVZvWhkc84Z EZgXYFo/aH4CgEe3RpVEjvgwdDom+bFB6/ovfAAChkXgzaxugKg8845d2a+sxFHdHu1K kADJiazMThEEAl1JPXaLrq8jPDpjjg3LIiBqC0Kpxz7c9sphigqtJrkknhq6BoHv/Sbk noIQ== MIME-Version: 1.0 Received: by 10.112.83.228 with SMTP id t4mr9036491lby.74.1341348238151; Tue, 03 Jul 2012 13:43:58 -0700 (PDT) Received: by 10.112.40.228 with HTTP; Tue, 3 Jul 2012 13:43:58 -0700 (PDT) In-Reply-To: <6A888CF2-7AB0-4913-A3A6-BA430531E3E7@nominum.com> References: <20120703160901.14518.93555.idtracker@ietfa.amsl.com> <6A888CF2-7AB0-4913-A3A6-BA430531E3E7@nominum.com> Date: Tue, 3 Jul 2012 13:43:58 -0700 Message-ID: From: Andre Kostur To: Ted Lemon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnyln/8D39Vgzs+T/5SfBg1itY7dP2Z0UhDRqZvCabYLsWwcrO/xcp1hWPBJVnDBYinaiaP Cc: "" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Tue, 03 Jul 2012 20:43:58 -0000 Do we want to exclude environments where there is no relay agent from ever being able to talk about client link-addresses? On Tue, Jul 3, 2012 at 1:30 PM, Ted Lemon wrote: > I think the section about clients including link-layer addresses should j= ust be removed. This option ought to be for relay agents only, because th= at's the only way it will be ubiquitous. We shouldn't confuse the issue b= y proposing that it apply to clients as well=97if we do, it will see really= spotty adoption, and probably not be of much use. > From Ted.Lemon@nominum.com Tue Jul 3 14:09: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 DBD0E11E80C4 for ; Tue, 3 Jul 2012 14:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.545 X-Spam-Level: X-Spam-Status: No, score=-106.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmMPX+pOH3B0 for ; Tue, 3 Jul 2012 14:09:39 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2870E11E80A3 for ; Tue, 3 Jul 2012 14:09:31 -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 DSNKT/NflJpbNtX2TBui6Imw//svhGOhWBIu@postini.com; Tue, 03 Jul 2012 14:09: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 080031B8300 for ; Tue, 3 Jul 2012 14:09:40 -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 ED50F190043; Tue, 3 Jul 2012 14:09:39 -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, 3 Jul 2012 14:09:39 -0700 From: Ted Lemon To: Andre Kostur Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNWVyUOeCvBeo/hEmj3Ky74/h/DZcYgu4A Date: Tue, 3 Jul 2012 21:09:39 +0000 Message-ID: <32847D7B-63BD-4E92-B1BB-F6F55ADFE0D6@nominum.com> References: <20120703160901.14518.93555.idtracker@ietfa.amsl.com> <6A888CF2-7AB0-4913-A3A6-BA430531E3E7@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_32847D7B63BD4E92B1BBF6F55ADFE0D6nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Tue, 03 Jul 2012 21:09:40 -0000 --_000_32847D7B63BD4E92B1BBF6F55ADFE0D6nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jul 3, 2012, at 4:43 PM, Andre Kostur wrote: Do we want to exclude environments where there is no relay agent from ever being able to talk about client link-addresses? No. Of course not. In those environments, the link-layer address is ava= ilable to the server from the layer 2 header. That's how the relay is get= ting it too. --_000_32847D7B63BD4E92B1BBF6F55ADFE0D6nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <34C2D2F024CDF740AF46BAAF119E1CDD@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jul 3, 2012, at 4:43 PM, Andre Kostur wrote:
Do we want to exclude environments where there is no relay agent from
ever being able to talk about client link-addresses?

No.   Of course not.   In those environments, the link-layer= address is available to the server from the layer 2 header.   That's = how the relay is getting it too.

--_000_32847D7B63BD4E92B1BBF6F55ADFE0D6nominumcom_-- From internet-drafts@ietf.org Wed Jul 4 05:32: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 724D621F871D; Wed, 4 Jul 2012 05:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zwx-wQuJIXtg; Wed, 4 Jul 2012 05:32:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EF421F86CA; Wed, 4 Jul 2012 05:32:52 -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.30 Message-ID: <20120704123252.19874.94025.idtracker@ietfa.amsl.com> Date: Wed, 04 Jul 2012 05:32:52 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-failover-requirements-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, 04 Jul 2012 12:32:53 -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-01.txt Pages : 19 Date : 2012-07-04 Abstract: The DHCPv6 protocol, defined in [RFC3315] allows for multiple servers to operate on a single network, however it does not define any way to decide which server responds to which client queries. 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-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-failover-require= ments-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Jul 4 06:56: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 0445C21F87EE; Wed, 4 Jul 2012 06:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf195GSWCrg2; Wed, 4 Jul 2012 06:56:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C1A21F879F; Wed, 4 Jul 2012 06:56:44 -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.30 Message-ID: <20120704135644.1143.51831.idtracker@ietfa.amsl.com> Date: Wed, 04 Jul 2012 06:56:44 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-failover-design-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: Wed, 04 Jul 2012 13:56:45 -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-00.txt Pages : 42 Date : 2012-07-04 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-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From volz@cisco.com Thu Jul 5 20:23: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 D22E411E809A for ; Thu, 5 Jul 2012 20:23:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVNUhVPLYtuN for ; Thu, 5 Jul 2012 20:23: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 6965111E8095 for ; Thu, 5 Jul 2012 20:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=657; q=dns/txt; s=iport; t=1341545015; x=1342754615; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MPxl5GFTOJ6gNt1nkkpHPyvwkgM6/RCjQmqhT6YPiGE=; b=MCSTaOekTQzV9enNVAXXrg4ltd3cJ76UAgpYfU7NT6KrRGjROnoOpyr6 H9tCcG0vuW8UUaDTcOo95QucUE1hn78JqpN0+Vtn5dbpR5XrwJIsLb6jm v9pbBJD5dWTa5UIjKoUfIszTMC6hNeVeEoRd9xjl7RmPZW/90JecYhYa4 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHtZ9k+tJV2a/2dsb2JhbABFtzaBB4IZAQEEEgEnNAsQAgEIIhQQMiUBAQQODRqHaZl3oBuQf2ADo1SBZoJf X-IronPort-AV: E=Sophos;i="4.77,535,1336348800"; d="scan'208";a="99252486" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 06 Jul 2012 03:23:35 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q663NZGi013431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Jul 2012 03:23:35 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Thu, 5 Jul 2012 22:23:35 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 Thread-Index: Ac06QOfpB+YCOuC4SFifU+LuLN2whwAIIOBACDEp/UA= Date: Fri, 6 Jul 2012 03:23:34 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E01C91F@xmb-rcd-x04.cisco.com> References: <20120525063747.GD20816@shell-too.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.247.219] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19022.000 x-tm-as-result: No--33.374300-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] Comments on draft-troan-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, 06 Jul 2012 03:23:24 -0000 Hi: I was reviewing the comments related to this draft on the mailing list to s= ee about updating the draft and re-submitting it. However, after a review of the comments and draft, I don't see anything tha= t I feel needs to change. For those that commented on the draft, do you agree or is there something I= missed that needs to be updated/clarified in the draft? For those have not (yet) commented, comments are appreciated. Ole and I would like to advance this draft (to DHC working group last call)= , so please comment as to whether you feel edits are necessary or whether y= ou feel it is OK as is. Thanks much! - Bernie From shwethab@cisco.com Mon Jul 9 11:16: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 866C011E80D9 for ; Mon, 9 Jul 2012 11:16:10 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-FhDQRWi5V8 for ; Mon, 9 Jul 2012 11:16:09 -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 46A0C11E80D5 for ; Mon, 9 Jul 2012 11:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shwethab@cisco.com; l=4369; q=dns/txt; s=iport; t=1341857795; x=1343067395; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=bY7PGvbcUicOlob5IzGsQbdTqY097omyI5hbQDw85Ms=; b=OhiXybGA16lf0/0F9hdXLUG9iqJP408aC87y2c433yTR3Zbz1M6rcrim Duj3vOgOsURprhGs9Fe3XL6ZleKPncFCATxKnWuCNgAmQWokpzq7JDcaN rHLjXDRNcMj+0T6tUhr9NB+AmNjGYNhlYO0/w+iTu7OmQZsdNlQEnZ7lq w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGgf+0+tJV2c/2dsb2JhbABFt3aBB4IgAQEBAwEBAQEPAVoBHQEIDgpVCyUCBAESIodlBgubaaAUi0CGDAOVNoESjQ2BZoJf X-IronPort-AV: E=Sophos;i="4.77,553,1336348800"; d="scan'208";a="100136604" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 09 Jul 2012 18:16:34 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q69IGY3n002130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Jul 2012 18:16:34 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0298.004; Mon, 9 Jul 2012 13:16:34 -0500 From: "Shwetha Bhandari (shwethab)" To: Andre Kostur , "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNXf743EeIYAlOUEydhG/O9JiELg== Date: Mon, 9 Jul 2012 18:16:33 +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.0.0.100825 x-originating-ip: [10.65.81.164] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19028.005 x-tm-as-result: No--42.708600-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: <138EF94AA6D71347BF43E81163AE493D@cisco.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-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, 09 Jul 2012 18:16:10 -0000 Thanks for the review. Earlier discussion on the alias inclined towards setting the link-address to the hardware address of the interface facing the relay (Approach 1). Your comments regarding link-address set as the hardware address of the interface that is being configured (approach 2) are also valid. As per Ted's comments: I think the section about clients including link-layer addresses should just be removed. This option ought to be for relay agents only, because that's the only way it will be ubiquitous. We shouldn't confuse the issue by proposing that it apply to clients as well=8Bif we do, it will see really spotty adoption, and probably not be of much use. If we modify the draft so that the hardware address is inserted by the first hop relay only, then it will be of the interface facing the relay/network(approach 1). Since one of the uses of learning link layer address was to correlate DHCPv4 and DHCPv6 messages from the same client interface ( as described in Section 2 Problem Background and Scenario of the draft), the link layer address should match 'chaddr' field of DHCPv4 messages sent for configuring the same interface. RFC 2131 text about content of chaddr does not clearly state which interface's link layer address is to be used. However the 'chaddr' field in DHCPv4 is the hardware address that is used by the first hop relay/server to send DHCP Reply message to the client, and hence would be hardware address of the interface that is facing the relay/server. With this reasoning will it be fair to go with Approach 1 i.e link layer address will be that of the relay/network facing interface of the client and allow this option to be inserted by the first hop relay only? Thanks, Shwetha On 7/4/12 1:23 AM, "Andre Kostur" wrote: >I think section 4 needs a little more to it. As it stands, the >section talks about putting in the link-layer address, but does not >specify which one. Perhaps that should be changed to specify that >this is the link-address of the interface that the host is attempting >to configure. The use-case I'm thinking of is perhaps a laptop with >both a wired and wireless interface. We'd like to communicate the >link-address of the wired interface when configuring the wired >interface, and the link-address of the wifi interface when configuring >that interface. As written (since it's unspecified), a host could >conceivably use the wired link-address for both transactions. > >I think the phrasing "All hosts or clients MAY include.." is >inconsistent with other RFCs. I think it is sufficient to say "A >client MAY include this option ..." to be consistent with RFC 3315, >section 22.14, 22.9, and others. > >On Tue, Jul 3, 2012 at 9:09 AM, 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-00.txt >> Pages : 6 >> Date : 2012-07-03 >> >> Abstract: >> This document specifies the format and mechanism that is to be used >> for encoding client link-layer address in DHCPv6 messages by defining >> a new DHCPv6 Client Link-layer Address option. >> >> >> >> The IETF datatracker status page for this draft is: >>=20 >>https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer- >>addr-opt >> >> There's also a htmlized version available at: >>=20 >>http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-addr-o >>pt-00 >> >> >> 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 > > >-- >Andre Kostur >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Mon Jul 9 11:29: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 4D85A11E80D0 for ; Mon, 9 Jul 2012 11:29:56 -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.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4oPk2xdnw8h for ; Mon, 9 Jul 2012 11:29:55 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 485EB11E81AD for ; Mon, 9 Jul 2012 11:29:55 -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 DSNKT/sjPB7SdakMZxekuRgB33OHmN7SkkUU@postini.com; Mon, 09 Jul 2012 11:30: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 E88281B82CD for ; Mon, 9 Jul 2012 11:30: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 D301F19005C; Mon, 9 Jul 2012 11:30: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; Mon, 9 Jul 2012 11:30:19 -0700 From: Ted Lemon To: "Shwetha Bhandari (shwethab)" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNXf7+ZrBEJQCsAkSClbxFr7Ij65chuyaA Date: Mon, 9 Jul 2012 18:30:19 +0000 Message-ID: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@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: multipart/alternative; boundary="_000_4B2C9E20D9254D9AB9B8AAE396379AB7nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Andre Kostur Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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, 09 Jul 2012 18:29:56 -0000 --_000_4B2C9E20D9254D9AB9B8AAE396379AB7nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jul 9, 2012, at 2:16 PM, Shwetha Bhandari (shwethab) wrote: With this reasoning will it be fair to go with Approach 1 i.e link layer address will be that of the relay/network facing interface of the client and allow this option to be inserted by the first hop relay only? That's certainly what I'd advocate! --_000_4B2C9E20D9254D9AB9B8AAE396379AB7nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <22680EAAA731544A9C79796B3637E859@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jul 9, 2012, at 2:16 PM, Shwetha Bhandari (shwethab) wrote:
With this reasoning will it be fair to go with Approach 1
i.e link layer address will be that of the relay/network facing interface of the client and allow this option to be inserted by the first hop relay only?

That's certainly what I'd advocate!

--_000_4B2C9E20D9254D9AB9B8AAE396379AB7nominumcom_-- From internet-drafts@ietf.org Mon Jul 9 12:25: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 986AD11E81DC; Mon, 9 Jul 2012 12:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veYssZqemZkG; Mon, 9 Jul 2012 12:25:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F2411E81C7; Mon, 9 Jul 2012 12:25:46 -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.30p3 Message-ID: <20120709192546.30874.32808.idtracker@ietfa.amsl.com> Date: Mon, 09 Jul 2012 12:25:46 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-11.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, 09 Jul 2012 19:25:46 -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 : The DHCPv4 Relay Agent Identifier Suboption Author(s) : Bharat Joshi D.T.V Ramakrishna Rao Mark Stapp Filename : draft-ietf-dhc-relay-id-suboption-11.txt Pages : 7 Date : 2012-07-09 Abstract: This draft defines a new Relay Agent Identifier suboption for the Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information option. The suboption carries a value that uniquely identifies the relay agent device within the administrative domain. The value is normally administratively-configured in the relay agent. The suboption allows a DHCP relay agent to include the identifier in the DHCP messages it sends. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-id-suboption There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-relay-id-suboption-11 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-relay-id-suboption-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From greg.rabil@jagornet.com Mon Jul 9 16:04: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 3090611E80F1 for ; Mon, 9 Jul 2012 16:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHY54lA5oJqe for ; Mon, 9 Jul 2012 16:04: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 7EB4611E80C1 for ; Mon, 9 Jul 2012 16:04:06 -0700 (PDT) Received: by bkty7 with SMTP id y7so3171891bkt.31 for ; Mon, 09 Jul 2012 16:04:31 -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=9HD5e9voz8M32N6IbMTPJf9SGQeM60p6i6Gh/O64uMw=; b=aXAc/+BuwzIa2XiRlePIE8OqUzYSs1xrXI815Oxabr7m8+GmM57zLION87t+kwk6Av SUfuw1oRujidJDfmq9xvWgdEmMhTIrv9cyfRmfn9Fxo+jePZkVh5gl7s59d0Zxpzt/KU IIHx/pei1X7ihHoMiy8QC3/RCj+7YwLgJcSGaRC1zohav2B3nBpK3/xEJCvWdyFKR1+R COOXkmBvchqBJb3kzTK/KLKjuSJ2tgcuHeEWPRCIkyOIKUjEy3fdVXe7wmjNQlYclia2 J7z+jdFtzL/4/6x/geH3JYqhJ7NXdz6idu+a5Ix6gtTMr3DJLc2k/uV909Ab5gJGvYYr oWgg== MIME-Version: 1.0 Received: by 10.204.153.15 with SMTP id i15mr20570656bkw.74.1341875071620; Mon, 09 Jul 2012 16:04:31 -0700 (PDT) Received: by 10.204.156.133 with HTTP; Mon, 9 Jul 2012 16:04:31 -0700 (PDT) In-Reply-To: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> Date: Mon, 9 Jul 2012 19:04:31 -0400 Message-ID: From: "A. Gregory Rabil" To: Ted Lemon Content-Type: multipart/alternative; boundary=0015175cd5cefa195d04c46da23d X-Gm-Message-State: ALoCoQlRUexNGzCrLuY/XETmvZbQgFezkBghU4Kz6bb3DfZyKo0AXd2l4D5cqb00OCkGdaXiB15M Cc: "dhcwg@ietf.org" , Andre Kostur Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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, 09 Jul 2012 23:04:08 -0000 --0015175cd5cefa195d04c46da23d Content-Type: text/plain; charset=ISO-8859-1 I think this would severely limit the usefulness of this option. I would much prefer Andre's suggestion that this option be filled with the link layer address of the interface being configured. This would mean that the client would be responsible for adding this option, not the relay. I understand the motivation for the option is to help correlate the client to the IPv4 chaddr field. > Since one of the uses of learning link layer address was to correlate DHCPv4 and DHCPv6 messages from the same client interface ( as described in Section 2 Problem Background and Scenario of the draft), the link layer address should match 'chaddr' field of DHCPv4 messages sent for configuring the same interface. RFC 2131 text about content of chaddr does not clearly state which interface's link layer address is to be used. However the 'chaddr' field in DHCPv4 is the hardware address that is used by the first hop relay/server to send DHCP Reply message to the client, and hence would be hardware address of the interface that is facing the relay/server. With all DHCPv4 client implementations that I am familiar with, the chaddr is always the address of the interface which is being configured. Also, DHCPv4 does not support the ability to request multiple addresses in one request. With DHCPv6, the protocol supports configuration of multiple interfaces and multiple addresses in one request. If the proposed option does not contain the link layer address of the interface being configured, then it may not be correlated back to the DHCPv4 chaddr. Therefore, I would suggest that the option must be within the IA_NA/IA_TA/IA_PD option "bucket" so as to properly support the multiple interface request case. Greg On Mon, Jul 9, 2012 at 2:30 PM, Ted Lemon wrote: > On Jul 9, 2012, at 2:16 PM, Shwetha Bhandari (shwethab) wrote: > > With this reasoning will it be fair to go with Approach 1 > i.e link layer address will be that of the relay/network facing interface > of the client and allow this option to be inserted by the first hop relay > only? > > > That's certainly what I'd advocate! > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > --0015175cd5cefa195d04c46da23d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think this would severely limit the usefulness of this option. =A0I would= much prefer Andre's suggestion that this option be filled with the lin= k layer address of the interface being configured. =A0This would mean that = the client would be responsible for adding this option, not the relay. =A0I= understand the motivation for the option is to help correlate the client t= o the IPv4 chaddr field.

> Since one of the= uses of learning link layer address was to correlate
DHCPv4 and DHCPv6 messages from the = same client interface ( as described
in Section 2 Problem Background and = Scenario of the draft), the link layer
address should match 'chaddr'= ; field of DHCPv4 messages sent for
configuring the same interface. RFC = 2131 text about content of chaddr does
not clearly state which interface= 9;s link layer address is to be used.
However the 'chaddr' field i= n DHCPv4 is the hardware address that is used
by the first hop relay/server to sen= d DHCP Reply message to the client,
and hence would be hardware address = of the interface that is facing the
relay/server.

With all DHCPv4 client implementations that I am familiar with, the cha= ddr is always the address of the interface which is being configured. =A0Al= so, DHCPv4 does not support the ability to request multiple addresses in on= e request. =A0With DHCPv6, the protocol supports configuration of multiple = interfaces and multiple addresses in one request. =A0If the proposed option= does not contain the link layer address of the interface being configured,= then it may not be correlated back to the DHCPv4 chaddr. =A0Therefore, I w= ould suggest that the option must be within the IA_NA/IA_TA/IA_PD option &q= uot;bucket" so as to properly support the multiple interface request c= ase.

Greg

On Mon, J= ul 9, 2012 at 2:30 PM, Ted Lemon <Ted.Lemon@nominum.com>= wrote:
On Jul 9, 2012, at 2:16 PM, Shwetha Bhandari (shwethab) wrote:
= With this reasoning will it be fair to go with Approach 1
i.e link layer address will be that of the relay/network facing interface of the client and allow this option to be inserted by the first hop relay only?

That's certainly what I'd advocate!


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg


--0015175cd5cefa195d04c46da23d-- From Ted.Lemon@nominum.com Mon Jul 9 16:19: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 213F121F863C for ; Mon, 9 Jul 2012 16:19:55 -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.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N91srZIH4i5R for ; Mon, 9 Jul 2012 16:19:54 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id A1AD421F8636 for ; Mon, 9 Jul 2012 16:19:52 -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 DSNKT/tnMpgRnuc+voPNXbz6MF/Z6woMVil0@postini.com; Mon, 09 Jul 2012 16:20:18 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 C74691B830F for ; Mon, 9 Jul 2012 16:20:17 -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 BC5DF19005C; Mon, 9 Jul 2012 16:20:17 -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, 9 Jul 2012 16:20:17 -0700 From: Ted Lemon To: "A. Gregory Rabil" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNXf7+ZrBEJQCsAkSClbxFr7Ij65chuyaAgABMmoCAAARngA== Date: Mon, 9 Jul 2012 23:20:17 +0000 Message-ID: <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@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_2411883C9E45454EA3B73D366D47FC81nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Andre Kostur Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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, 09 Jul 2012 23:19:55 -0000 --_000_2411883C9E45454EA3B73D366D47FC81nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jul 9, 2012, at 7:04 PM, A. Gregory Rabil wrote: I think this would severely limit the usefulness of this option. I would m= uch prefer Andre's suggestion that this option be filled with the link laye= r address of the interface being configured. This would mean that the clie= nt would be responsible for adding this option, not the relay. I understan= d the motivation for the option is to help correlate the client to the IPv4= chaddr field. Why would having the relay add the option limit its usefulness? The infor= mation is the same in either case. The difference is that you don't have = to update all your DHCPv6 clients, and you don't have to worry that some DH= CPv6 client vendors won't ever implement this option. --_000_2411883C9E45454EA3B73D366D47FC81nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jul 9, 2012, at 7:04 PM, A. Gregory Rabil wrote:
I think this would severely limit the usefulness of this option.  I wou= ld much prefer Andre's suggestion that this option be filled with the link = layer address of the interface being configured.  This would mean that= the client would be responsible for adding this option, not the relay.  I understand the motivation for the opti= on is to help correlate the client to the IPv4 chaddr field.

Why would having the relay add the option limit its usefulness?  = The information is the same in either case.   The difference is that = you don't have to update all your DHCPv6 clients, and you don't have to wor= ry that some DHCPv6 client vendors won't ever implement this option.

--_000_2411883C9E45454EA3B73D366D47FC81nominumcom_-- From greg.rabil@jagornet.com Mon Jul 9 16:40: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 9CD3F21F875E for ; Mon, 9 Jul 2012 16:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dojuz38Yb11U for ; Mon, 9 Jul 2012 16:40:53 -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 B814121F875D for ; Mon, 9 Jul 2012 16:40:52 -0700 (PDT) Received: by bkty7 with SMTP id y7so3183087bkt.31 for ; Mon, 09 Jul 2012 16:41:18 -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=ZDst47ZEUDsDVGXYV+Z6IVkOZKUisiK7qOCO8gJRQoA=; b=pQtwqhyeTryN8jlw/8aH1sug1QJHIldaVLS+rOsziR/rnBbaUhTeKLZ2F7CfK94GYZ k9pbkpDXmk/3BUmmmMjJNnQjnEC+jY8cH/yVngU+4LEQKp38LEYh+DUdQq4mMq3r0x4O cOv+VLmC/Wa4t3D1fFtMfFW6Y6EnxISLM2l435MSlf9LqDQ0/0+eJNy2+xNG3F3dIG0+ GNIbYCZg3EvhxdQ1K6fGVsJn69atPN1ld3ePanch9pICU4OnAf7NBT0+ntJeRH8xX+ve YeYBf/U8UnKCDg68nfUXIg8SZIOX8TW9hI+g/Yshv4KCqhrtbps8BurphFSCKuBvoiYe jLDQ== MIME-Version: 1.0 Received: by 10.204.152.19 with SMTP id e19mr20744736bkw.8.1341877277889; Mon, 09 Jul 2012 16:41:17 -0700 (PDT) Received: by 10.204.156.133 with HTTP; Mon, 9 Jul 2012 16:41:17 -0700 (PDT) In-Reply-To: <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> Date: Mon, 9 Jul 2012 19:41:17 -0400 Message-ID: From: "A. Gregory Rabil" To: Ted Lemon Content-Type: multipart/alternative; boundary=0015175d04067b170f04c46e2628 X-Gm-Message-State: ALoCoQmDDFkfjMowz2OGIgZ2I4fs0qGa90shNYlTXizu8ztrMsETkVw8k3OZJfrFby1QvsW8F8dW Cc: "dhcwg@ietf.org" , Andre Kostur Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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, 09 Jul 2012 23:40:53 -0000 --0015175d04067b170f04c46e2628 Content-Type: text/plain; charset=ISO-8859-1 I don't believe the information would be the same in the case where the client is requesting an address for a different interface (which is possible in DHCPv6, but not in DHCPv4). That's what I was trying to explain with the rest of my post. Greg On Mon, Jul 9, 2012 at 7:20 PM, Ted Lemon wrote: > On Jul 9, 2012, at 7:04 PM, A. Gregory Rabil wrote: > > I think this would severely limit the usefulness of this option. I would > much prefer Andre's suggestion that this option be filled with the link > layer address of the interface being configured. This would mean that the > client would be responsible for adding this option, not the relay. I > understand the motivation for the option is to help correlate the client to > the IPv4 chaddr field. > > > Why would having the relay add the option limit its usefulness? The > information is the same in either case. The difference is that you don't > have to update all your DHCPv6 clients, and you don't have to worry that > some DHCPv6 client vendors won't ever implement this option. > > --0015175d04067b170f04c46e2628 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't believe the information would be the same in the case where the= client is requesting an address for a different interface (which is possib= le in DHCPv6, but not in DHCPv4). =A0That's what I was trying to explai= n with the rest of my post.

Greg

On Mon, Jul 9, 2012 a= t 7:20 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
On Jul 9, 2012, at 7:04 PM, A. Gregory Rabil wrote:
= I think this would severely limit the usefulness of this option. =A0I would = much prefer Andre's suggestion that this option be filled with the link= layer address of the interface being configured. =A0This would mean that t= he client would be responsible for adding this option, not the relay. =A0I understand the motivation for the option = is to help correlate the client to the IPv4 chaddr field.

Why would having the relay add the option limit its usefulness? = =A0 The information is the same in either case. =A0 The difference is that = you don't have to update all your DHCPv6 clients, and you don't hav= e to worry that some DHCPv6 client vendors won't ever implement this option.


--0015175d04067b170f04c46e2628-- From akostur@incognito.com Mon Jul 9 17:55:25 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 D2BC421F86D0 for ; Mon, 9 Jul 2012 17:55:24 -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=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fQLt+63a4W7 for ; Mon, 9 Jul 2012 17:55:23 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with SMTP id 0EE1421F86CF for ; Mon, 9 Jul 2012 17:55:22 -0700 (PDT) Received: from mail-lb0-f171.google.com ([209.85.217.171]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKT/t9lNal3KQ5BG72PEPefbZt9EGsAkYu@postini.com; Mon, 09 Jul 2012 17:55:49 PDT Received: by lbom4 with SMTP id m4so1239261lbo.30 for ; Mon, 09 Jul 2012 17:55:47 -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=LXTwnfwO3liYWc3qp/TrdrI52ZO1iIgfpfoxCkBZcOg=; b=Ye1cTbpeFVoCioA5nvA5v4HF852+0ePW1yMe7b2hmKNi8qmuh5CwfzAVFe/6NQNUZi hG+4wI7KuEA+D/sAK4UM/u9T/UGG7+QtVWYUZcXqvKWBpGanFWPy+pn0d0+3fVbIeXc5 gn4OQCFxIEs6mIPFKgEudq8dY2X21vRBWWpM3QAkfZqubsWifKwGOPX11wzCrb12Mlrk +rhg4lJfvsrxZ18O3ZCEpqzYCictbWhklmd0LpghYWitJQApzheAYYGFww0yQTfIR6dl q1rGTdFPGcMqOn61x5YtYFOXmCM1oTEL7JgXZ36R9EIeMkv3rtIe2SOwP3X+9ab1wf3/ 7DOA== MIME-Version: 1.0 Received: by 10.112.36.163 with SMTP id r3mr19182788lbj.87.1341881746992; Mon, 09 Jul 2012 17:55:46 -0700 (PDT) Received: by 10.112.40.228 with HTTP; Mon, 9 Jul 2012 17:55:46 -0700 (PDT) In-Reply-To: References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> Date: Mon, 9 Jul 2012 17:55:46 -0700 Message-ID: From: Andre Kostur To: "A. Gregory Rabil" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkbpBOQ7zQrYIg3RLpUWvFEdjVLqqjGvf1kv2NyP6QKwDFmXVvBxN3xCVmkdm9rKN7LMCZj Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Tue, 10 Jul 2012 00:55:25 -0000 Note that my suggestion is that clients MAY add this field as well as relays, not one or the other. I do see the argument that the option should probably go into an IA options field instead of the top-level options field as each IA may have different link addresses to talk about. The client may add the option as it may be operating in an environment where there are no relays, and the relay may add the option as it may be operating in an environment where the dhcp server may not be entirely trusting the client device, but trusts the relay more. As an example, in the cable world, the CMTS (playing the DHCPv6 relay) adds on the MAC address of the cable modem into its relayed options (currently a sub-option of option 17). On Mon, Jul 9, 2012 at 4:41 PM, A. Gregory Rabil wrote: > I don't believe the information would be the same in the case where the > client is requesting an address for a different interface (which is possible > in DHCPv6, but not in DHCPv4). That's what I was trying to explain with the > rest of my post. > > Greg > > > On Mon, Jul 9, 2012 at 7:20 PM, Ted Lemon wrote: >> >> On Jul 9, 2012, at 7:04 PM, A. Gregory Rabil wrote: >> >> I think this would severely limit the usefulness of this option. I would >> much prefer Andre's suggestion that this option be filled with the link >> layer address of the interface being configured. This would mean that the >> client would be responsible for adding this option, not the relay. I >> understand the motivation for the option is to help correlate the client to >> the IPv4 chaddr field. >> >> >> Why would having the relay add the option limit its usefulness? The >> information is the same in either case. The difference is that you don't >> have to update all your DHCPv6 clients, and you don't have to worry that >> some DHCPv6 client vendors won't ever implement this option. >> > -- Andre Kostur Senior Product Design 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 greg.rabil@jagornet.com Mon Jul 9 18:03: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 4D84311E80B8 for ; Mon, 9 Jul 2012 18:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TctZ7R1BqO05 for ; Mon, 9 Jul 2012 18:03:53 -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 0FCF411E8072 for ; Mon, 9 Jul 2012 18:03:52 -0700 (PDT) Received: by bkty7 with SMTP id y7so3207384bkt.31 for ; Mon, 09 Jul 2012 18:04:18 -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=hPrOg38XCU0cMto72T66hzPeWHEZSA2hDmxsM/CGR3I=; b=YFMX1KzmsWb0Sko375DfpiWjLYXJ12FwjWQ4h3qwAbgAVpjg5SAXI4+LDMm19NEaME Z9XEIhsjpUlxtv1F8+uAHFikokEuGKIj6tHRk4MP2C59YY5W7eyvAHQkBWpKHEELshAA egCyMxni28teKaU7gFOzNtCc49QEajo6Mw4BAqFxI/zFZpQwIPO2BrlUgrJ8SyOIAldL 9KFvwBHUueoO0JaQ3o1kSadCnOAkAztWb/HXoacEKE+RQ+701kjvWnc242tv++ZT5CU2 VEklFxYqdFcFYn/qFhcnNkirjdcVRcZCfDwO71tYOJjKQDSwi7FKvkWIQipoqwIE5n31 UYgQ== MIME-Version: 1.0 Received: by 10.204.156.11 with SMTP id u11mr1245073bkw.69.1341882258226; Mon, 09 Jul 2012 18:04:18 -0700 (PDT) Received: by 10.204.156.133 with HTTP; Mon, 9 Jul 2012 18:04:18 -0700 (PDT) In-Reply-To: References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> Date: Mon, 9 Jul 2012 21:04:18 -0400 Message-ID: From: "A. Gregory Rabil" To: Andre Kostur Content-Type: multipart/alternative; boundary=0015175d02d254ff1d04c46f4f68 X-Gm-Message-State: ALoCoQnym2rxFE+DiiiQoRxpUhefwcHMQk9uQheifJhwY/5mr835aNAqT6UclzbmYEbGkvHKnE4a Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Tue, 10 Jul 2012 01:03:54 -0000 --0015175d02d254ff1d04c46f4f68 Content-Type: text/plain; charset=ISO-8859-1 I believe the argument for having the the option in the IA options field instead of top-level options suggests that the option should/must be done by the client, because I'm not sure how the relay could glean that information. Greg On Mon, Jul 9, 2012 at 8:55 PM, Andre Kostur wrote: > Note that my suggestion is that clients MAY add this field as well as > relays, not one or the other. I do see the argument that the option > should probably go into an IA options field instead of the top-level > options field as each IA may have different link addresses to talk > about. The client may add the option as it may be operating in an > environment where there are no relays, and the relay may add the > option as it may be operating in an environment where the dhcp server > may not be entirely trusting the client device, but trusts the relay > more. As an example, in the cable world, the CMTS (playing the > DHCPv6 relay) adds on the MAC address of the cable modem into its > relayed options (currently a sub-option of option 17). > > > > On Mon, Jul 9, 2012 at 4:41 PM, A. Gregory Rabil > wrote: > > I don't believe the information would be the same in the case where the > > client is requesting an address for a different interface (which is > possible > > in DHCPv6, but not in DHCPv4). That's what I was trying to explain with > the > > rest of my post. > > > > Greg > > > > > > On Mon, Jul 9, 2012 at 7:20 PM, Ted Lemon wrote: > >> > >> On Jul 9, 2012, at 7:04 PM, A. Gregory Rabil wrote: > >> > >> I think this would severely limit the usefulness of this option. I > would > >> much prefer Andre's suggestion that this option be filled with the link > >> layer address of the interface being configured. This would mean that > the > >> client would be responsible for adding this option, not the relay. I > >> understand the motivation for the option is to help correlate the > client to > >> the IPv4 chaddr field. > >> > >> > >> Why would having the relay add the option limit its usefulness? The > >> information is the same in either case. The difference is that you > don't > >> have to update all your DHCPv6 clients, and you don't have to worry that > >> some DHCPv6 client vendors won't ever implement this option. > >> > > > > > > -- > Andre Kostur > Senior Product Design 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 > --0015175d02d254ff1d04c46f4f68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I believe the argument for having the the option in the IA options field in= stead of top-level options suggests that the option should/must be done by = the client, because I'm not sure how the relay could glean that informa= tion.

Greg

On Mon, Jul 9, 2012 a= t 8:55 PM, Andre Kostur <akostur@incognito.com> wrote:
Note that my suggestion is that clients MAY add this field as well as
relays, not one or the other. =A0I do see the argument that the option
should probably go into an IA options field instead of the top-level
options field as each IA may have different link addresses to talk
about. =A0 The client may add the option as it may be operating in an
environment where there are no relays, and the relay may add the
option as it may be operating in an environment where the dhcp server
may not be entirely trusting the client device, but trusts the relay
more. =A0 As an example, in the cable world, the CMTS (playing the
DHCPv6 relay) adds on the MAC address of the cable modem into its
relayed options (currently a sub-option of option 17).



On Mon, Jul 9, 2012 at 4:41 PM, A. Gregory Rabil
<greg.rabil@jagornet.com&= gt; wrote:
> I don't believe the information would be the same in the case wher= e the
> client is requesting an address for a different interface (which is po= ssible
> in DHCPv6, but not in DHCPv4). =A0That's what I was trying to expl= ain with the
> rest of my post.
>
> Greg
>
>
> On Mon, Jul 9, 2012 at 7:20 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
>>
>> On Jul 9, 2012, at 7:04 PM, A. Gregory Rabil wrote:
>>
>> I think this would severely limit the usefulness of this option. = =A0I would
>> much prefer Andre's suggestion that this option be filled with= the link
>> layer address of the interface being configured. =A0This would mea= n that the
>> client would be responsible for adding this option, not the relay.= =A0I
>> understand the motivation for the option is to help correlate the = client to
>> the IPv4 chaddr field.
>>
>>
>> Why would having the relay add the option limit its usefulness? = =A0 The
>> information is the same in either case. =A0 The difference is that= you don't
>> have to update all your DHCPv6 clients, and you don't have to = worry that
>> some DHCPv6 client vendors won't ever implement this option. >>
>



--
Andre Kostur
Senior Product Design 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

--0015175d02d254ff1d04c46f4f68-- From zehn.cao@gmail.com Mon Jul 9 19:34: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 EC1F311E80C1 for ; Mon, 9 Jul 2012 19:34:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2VBVLq04O2G for ; Mon, 9 Jul 2012 19:34: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 68CF911E80A1 for ; Mon, 9 Jul 2012 19:34:54 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so20794495pbc.31 for ; Mon, 09 Jul 2012 19:35:20 -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=tVTjY6+ICxEZjfhFPIOOwSkIx9t44iiUHCoVZpzXlxE=; b=hYm1T8fexG+M9puKLDqP3ly0DVxBh+kCP8yCREbWMt+v1GDSzyMDwVMR3CaKaPE4hS k7534ncz2l5li6G7LpxDnXb75z5ZGrxdpH6GUEu/PGZ9QeC+PbSLtXiJ0QCUVaOBkJLK 1UVKiUFaeL53b/q+ghRGqUZsvMQwlTH0gH7f/b+D3K40Ue/FMr7Ah8fBE2+E1H0ia0VW /tbfXSrmiYudysVBrAjzAaJc5Ro2h4xJkg0ZrvKNLKHkKamurPP9kDgurEmEKpRwxrOd qEJoRGomnVX0WhJ3UM7zZmWVCjdHvc2Lmwl6/9BrRzrWxjcZ7tYHY0AlOdzMzLCBnyL+ 74nQ== MIME-Version: 1.0 Received: by 10.68.197.198 with SMTP id iw6mr64386606pbc.36.1341887707195; Mon, 09 Jul 2012 19:35:07 -0700 (PDT) Received: by 10.68.60.8 with HTTP; Mon, 9 Jul 2012 19:35:07 -0700 (PDT) In-Reply-To: <20120709100258.10493.24990.idtracker@ietfa.amsl.com> References: <20120709100258.10493.24990.idtracker@ietfa.amsl.com> Date: Tue, 10 Jul 2012 10:35:07 +0800 Message-ID: From: Zhen Cao To: DHC WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [dhcwg] Fwd: New Version Notification for draft-cao-dhc-anqp-option-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, 10 Jul 2012 02:34:55 -0000 Hi All, FYI. ---------- Forwarded message ---------- From: Date: Mon, Jul 9, 2012 at 6:02 PM Subject: New Version Notification for draft-cao-dhc-anqp-option-00.txt To: zehn.cao@gmail.com Cc: suntao@chinamobile.com, smccann@rim.com A new version of I-D, draft-cao-dhc-anqp-option-00.txt has been successfully submitted by Zhen Cao and posted to the IETF repository. Filename: draft-cao-dhc-anqp-option Revision: 00 Title: DHCPv4 and DHCPv6 Options for Access Network Query Protocol Servers Creation date: 2012-07-09 WG ID: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-cao-dhc-anqp-option-00.txt Status: http://datatracker.ietf.org/doc/draft-cao-dhc-anqp-option Htmlized: http://tools.ietf.org/html/draft-cao-dhc-anqp-option-00 Abstract: This document defines a DHCPv4 option and DHCPv6 option of the Access Network Query Protocol (ANQP) server address. These options are used to configure the ANQP server addresses on the Access Point of WLAN system. The IETF Secretariat -- Best regards, Zhen From internet-drafts@ietf.org Tue Jul 10 02:52: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 C520821F854B; Tue, 10 Jul 2012 02:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVgIuzcDcjgs; Tue, 10 Jul 2012 02:52:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387B921F870A; Tue, 10 Jul 2012 02:52:30 -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.30p3 Message-ID: <20120710095230.32546.60348.idtracker@ietfa.amsl.com> Date: Tue, 10 Jul 2012 02:52:30 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-client-id-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: Tue, 10 Jul 2012 09:52:31 -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-03.txt Pages : 6 Date : 2012-07-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-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-client-id-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Ted.Lemon@nominum.com Tue Jul 10 06:53: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 5999621F85C9 for ; Tue, 10 Jul 2012 06:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.555 X-Spam-Level: X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYYuvXfIiKIZ for ; Tue, 10 Jul 2012 06:53:13 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id B456321F85D3 for ; Tue, 10 Jul 2012 06:53:12 -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 DSNKT/wz5AG8eKYfqFWoKfXHGAW2Qknkkh4/@postini.com; Tue, 10 Jul 2012 06:53:40 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 B3D361B831E for ; Tue, 10 Jul 2012 06:53:39 -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 A6DE419005C for ; Tue, 10 Jul 2012 06:53:39 -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, 10 Jul 2012 06:53:33 -0700 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: Comments on draft-ietf-dhc-client-id-03 Thread-Index: AQHNXqNkRZpW/pCYikuN07C/VAzylA== Date: Tue, 10 Jul 2012 13:53:32 +0000 Message-ID: References: <3CF88B99A9ED504197498BC6F6F04B81069F0381@XMB-BGL-41E.cisco.com> <41E29081-C36C-44DE-B56B-0F6086F3A173@nominum.com> <3CF88B99A9ED504197498BC6F6F04B81069F0385@XMB-BGL-41E.cisco.com> <90903C21C73202418A48BFBE80AEE5EB06A82F@xmb-aln-x06.cisco.com> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB06A82F@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 Subject: [dhcwg] Comments on draft-ietf-dhc-client-id-03 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, 10 Jul 2012 13:53:14 -0000 On Jul 10, 2012, at 5:57 AM, Gaurav Halwasia (ghalwasi) wrote: > We have taken care of comments which came in the last WGLC and posted a n= ew revision today. Appreciate if you can let us know the next steps in this= to proceed. This text: > Client MAY use 'client identifier' or 'chaddr' received from server along= with 'xid' to map the response to request. This will guarantee that a par= ticular response from the server is meant for the particular client. Should say this instead: > When a client receives a DHCP message containing a 'client identifier' op= tion, the client MUST compare that client identifier to the one it is confi= gured to send. If the two client identifiers do not match, the client MUS= T silently discard the message. The reason for this is that if you say "MAY," nobody will implement it. A= lso, if you say "MAY," then you are implying some unspecified heuristic in = the client which the client implementor must guess at, and will probably ge= t wrong. I think the motivation to say "MAY" is predicated on the assumption that no= t all clients will implement this spec, and we don't want clients that don'= t implement it to violate it. But that's not true; only clients that impl= ement this spec are responsible to follow it, and we need not worry about c= lients that don't implement it. This spec addresses a very special use ca= se, and it's perfectly understandable if it is not implemented by all clien= ts. Another concern might be that a client would drop a message it otherwise wo= uld have accepted, resulting in a failure for that client to be configured.= This too is not a concern: non-conforming DHCP servers will never send a= 'client identifier' option. Conforming DHCP servers will always send the= correct option. So the only case in which we will see a problem is when = a broken implementation does the wrong thing, and we can't prevent that by = making the standard overly lax. From ghalwasi@cisco.com Tue Jul 10 07:03: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 0AB7421F85C6 for ; Tue, 10 Jul 2012 07:03:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxcSnf0WBWgd for ; Tue, 10 Jul 2012 07:03:08 -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 3654021F859A for ; Tue, 10 Jul 2012 07:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=3178; q=dns/txt; s=iport; t=1341929016; x=1343138616; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Nl+1ctq46d+rLWbd7IDV5o9RKXv55Y8XLDSLQgc9rJA=; b=HW/0NGNAX8EFVZeCM2wWMUvOzeTR7VFhRWKnXvbrs8tod+vMlD1Lgcu1 Clp2JHjPQxPd4kOxFTSS/ASRBisIoJK7bzJ/fEsy3mUJRna5VIP/eCeh0 qo4h/PHfYD6yFdEbaYWIA8J6qaTiviXrKcajc2Fy+IyPIhIVfqHuVvMcX 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJE1/E+tJV2Y/2dsb2JhbABFt3+BB4IgAQEBAwEBAQEPAScNJxAHBAIBCBEEAQEBChQJBycLFAkIAgQBEggah2UGC5xRkQWPMgSLQIVCYAOjVYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,559,1336348800"; d="scan'208";a="100438250" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 10 Jul 2012 14:03:35 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6AE3Z3v027131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jul 2012 14:03:35 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.153]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Tue, 10 Jul 2012 09:03:35 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Ted Lemon , "dhcwg@ietf.org WG" Thread-Topic: Comments on draft-ietf-dhc-client-id-03 Thread-Index: AQHNXqNudj/Hf9gKa0yk3WEfIG7Rj5cii2JA Date: Tue, 10 Jul 2012 14:03:35 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB06AF05@xmb-aln-x06.cisco.com> References: <3CF88B99A9ED504197498BC6F6F04B81069F0381@XMB-BGL-41E.cisco.com> <41E29081-C36C-44DE-B56B-0F6086F3A173@nominum.com> <3CF88B99A9ED504197498BC6F6F04B81069F0385@XMB-BGL-41E.cisco.com> <90903C21C73202418A48BFBE80AEE5EB06A82F@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.84.209] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19030.006 x-tm-as-result: No--38.917600-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] Comments on draft-ietf-dhc-client-id-03 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, 10 Jul 2012 14:03:09 -0000 Thanks Ted for your comments. I absolutely agree with your comments. > I think the motivation to say "MAY" is predicated on the assumption that = not all clients will implement this spec, and we don't want clients that do= n't implement it to violate it. But that's not true; only clients that im= plement this spec are responsible to follow it, and we need not worry about= clients that don't implement it. This spec addresses a very special use = case, and it's perfectly understandable if it is not implemented by all cli= ents. That's precisely the reason why I used 'MAY'. But as you clarified only cli= ents that implement this spec are responsible to follow it. I will wait for a day and then will repost the draft after taking care of y= our comments. Thanks again. Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Tuesday, July 10, 2012 7:24 PM To: dhcwg@ietf.org WG Subject: [dhcwg] Comments on draft-ietf-dhc-client-id-03 On Jul 10, 2012, at 5:57 AM, Gaurav Halwasia (ghalwasi) wrote: > We have taken care of comments which came in the last WGLC and posted a n= ew revision today. Appreciate if you can let us know the next steps in this= to proceed. This text: > Client MAY use 'client identifier' or 'chaddr' received from server along= with 'xid' to map the response to request. This will guarantee that a par= ticular response from the server is meant for the particular client. Should say this instead: > When a client receives a DHCP message containing a 'client identifier' op= tion, the client MUST compare that client identifier to the one it is confi= gured to send. If the two client identifiers do not match, the client MUS= T silently discard the message. The reason for this is that if you say "MAY," nobody will implement it. A= lso, if you say "MAY," then you are implying some unspecified heuristic in = the client which the client implementor must guess at, and will probably ge= t wrong. I think the motivation to say "MAY" is predicated on the assumption that no= t all clients will implement this spec, and we don't want clients that don'= t implement it to violate it. But that's not true; only clients that impl= ement this spec are responsible to follow it, and we need not worry about c= lients that don't implement it. This spec addresses a very special use ca= se, and it's perfectly understandable if it is not implemented by all clien= ts. Another concern might be that a client would drop a message it otherwise wo= uld have accepted, resulting in a failure for that client to be configured.= This too is not a concern: non-conforming DHCP servers will never send a= 'client identifier' option. Conforming DHCP servers will always send the= correct option. So the only case in which we will see a problem is when = a broken implementation does the wrong thing, and we can't prevent that by = making the standard overly lax. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Tue Jul 10 07:11: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 9D6E921F8762 for ; Tue, 10 Jul 2012 07:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0jeKTZzbUdI for ; Tue, 10 Jul 2012 07:11:13 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9389621F8707 for ; Tue, 10 Jul 2012 07:11:12 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT/w4HJYew1RRIzX51iLgaHrclia+PvNP@postini.com; Tue, 10 Jul 2012 07:11:40 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 A91A41B8320 for ; Tue, 10 Jul 2012 07:11:39 -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 A172C19005C; Tue, 10 Jul 2012 07:11:39 -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, 10 Jul 2012 07:11:26 -0700 From: Ted Lemon To: "A. Gregory Rabil" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNXf7+ZrBEJQCsAkSClbxFr7Ij65chuyaAgABMmoCAAARngIAABd6AgADzHYA= Date: Tue, 10 Jul 2012 14:11:26 +0000 Message-ID: <12EEF4CE-B85C-4542-AFF5-085CDE2ACFE5@nominum.com> References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@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_12EEF4CEB85C4542AFF5085CDE2ACFE5nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Andre Kostur Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Tue, 10 Jul 2012 14:11:13 -0000 --_000_12EEF4CEB85C4542AFF5085CDE2ACFE5nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jul 9, 2012, at 7:41 PM, A. Gregory Rabil wrote: I don't believe the information would be the same in the case where the cli= ent is requesting an address for a different interface (which is possible i= n DHCPv6, but not in DHCPv4). That's what I was trying to explain with the= rest of my post. Why do we care? The link layer address is not an interface identifier=97i= t's a hint to be used by your corporate back-office inventory tracking syst= em so that it can tell that an IPv4 address belongs to the same machine as = an IPv6 address. As long as your inventory tracking system has a list of = all the interfaces on a machine, or as long as the DHCPv4 server has receiv= ed a request from the same interface, the connection is made. We are hint= ing at the machine's identity, not the interface's identity. --_000_12EEF4CEB85C4542AFF5085CDE2ACFE5nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <971B3B5C2287674FB7898AF7498DB1AC@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jul 9, 2012, at 7:41 PM, A. Gregory Rabil wrote:
I don't believe the information would be the same in the case where the clie= nt is requesting an address for a different interface (which is possible in= DHCPv6, but not in DHCPv4).  That's what I was trying to explain with= the rest of my post.

Why do we care?   The link layer address is not an interface iden= tifier=97it's a hint to be used by your corporate back-office inventory tra= cking system so that it can tell that an IPv4 address belongs to the same m= achine as an IPv6 address.   As long as your inventory tracking system has a list of all the interfaces on a machi= ne, or as long as the DHCPv4 server has received a request from the same in= terface, the connection is made.   We are hinting at the machine's ide= ntity, not the interface's identity.

--_000_12EEF4CEB85C4542AFF5085CDE2ACFE5nominumcom_-- From Ted.Lemon@nominum.com Tue Jul 10 07:16: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 7A2C221F875E for ; Tue, 10 Jul 2012 07:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3lv02jK9bUD for ; Tue, 10 Jul 2012 07:16:45 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2B18F21F871C for ; Tue, 10 Jul 2012 07:16:45 -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 DSNKT/w5aAaAdVNkHfY/mwso7LVVC2nQWPh6@postini.com; Tue, 10 Jul 2012 07:17: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 CB9831B8322 for ; Tue, 10 Jul 2012 07:17:11 -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 C2F8919005C; Tue, 10 Jul 2012 07:17:11 -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, 10 Jul 2012 07:17:11 -0700 From: Ted Lemon To: Andre Kostur Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNXf7+ZrBEJQCsAkSClbxFr7Ij65chuyaAgABMmoCAAARngIAABd6AgAAU0ACAAN/oAA== Date: Tue, 10 Jul 2012 14:17:11 +0000 Message-ID: <396DEDBA-E0DB-42FD-9076-787D50FCEE3E@nominum.com> References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@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_396DEDBAE0DB42FD9076787D50FCEE3Enominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Tue, 10 Jul 2012 14:16:46 -0000 --_000_396DEDBAE0DB42FD9076787D50FCEE3Enominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jul 9, 2012, at 8:55 PM, Andre Kostur wrote: Note that my suggestion is that clients MAY add this field as well as relays, not one or the other. I do see the argument that the option should probably go into an IA options field instead of the top-level options field as each IA may have different link addresses to talk about. All of this discussion makes a huge amount of sense if your intention is to= deprecate IAIDs, but makes no sense at all if you are intending this optio= n to be a hint. This option was adopted by the working group on the basis= that we would be using it as a hint. This draft is important work. If we turn it into a referendum on IAIDs, i= t will be very contentious and won't get done anytime soon. I would reall= y appreciate it if we could keep a laser-like focus on the purpose that thi= s draft was adopted to serve, and stop trying to rewrite history. --_000_396DEDBAE0DB42FD9076787D50FCEE3Enominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jul 9, 2012, at 8:55 PM, Andre Kostur wrote:
Note that my suggestion is that clients MAY add this field as well as
relays, not one or the other.  I do see the argument that the option should probably go into an IA options field instead of the top-level
options field as each IA may have different link addresses to talk
about.

All of this discussion makes a huge amount of sense if your intention = is to deprecate IAIDs, but makes no sense at all if you are intending this = option to be a hint.   This option was adopted by the working group on= the basis that we would be using it as a hint.

This draft is important work.   If we turn it into a referendum o= n IAIDs, it will be very contentious and won't get done anytime soon.  = ; I would really appreciate it if we could keep a laser-like focus on the p= urpose that this draft was adopted to serve, and stop trying to rewrite history.

--_000_396DEDBAE0DB42FD9076787D50FCEE3Enominumcom_-- From akostur@incognito.com Tue Jul 10 07:52: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 49AA321F875C for ; Tue, 10 Jul 2012 07:52: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=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDAd7zKyX+7T for ; Tue, 10 Jul 2012 07:52:00 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with SMTP id C955221F8762 for ; Tue, 10 Jul 2012 07:51:58 -0700 (PDT) Received: from mail-lb0-f179.google.com ([209.85.217.179]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKT/xBqjzK1HMW1cceE3CJMW6VPB0nqHEy@postini.com; Tue, 10 Jul 2012 07:52:27 PDT Received: by lban1 with SMTP id n1so335986lba.38 for ; Tue, 10 Jul 2012 07:52:24 -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=3O/U4v8+hdz8MlKfRKYIiIB7E/p5ghEaRcnScKNT+1E=; b=KUU2DzdHlqqXx0jwJDEsd0HFijrXhNl2cV6IKYrhoulY1jB4TkuE/R8sVo5RlgtJr+ LsWy0bxQM44TtQy2kvYzcVHcChv8t6Z3iE2H9gTwAWfhu9i7YVkRdkt09hHfkHEnLEk3 Z+3X/WJ+SZ4NPezIbMMcsT4mn3Q7BelOUNkYwvOT7iSymHIedFFa42q77Xf328Vnu4x7 uF7QPNSB5zJ+HZ2Pj+fOBKJjnUmIzjp7cqWvqNsEu9Umc3aR/AWs4GIBR6ggqwRiPwwA EmJUq+M98H1TF8cMnXXAdAItTQ0BEJFfK/606iI9Yem/ENwM0b7Z7VJ/qm9QACe7Mi+W HORw== MIME-Version: 1.0 Received: by 10.112.99.98 with SMTP id ep2mr20960497lbb.45.1341931944626; Tue, 10 Jul 2012 07:52:24 -0700 (PDT) Received: by 10.112.40.228 with HTTP; Tue, 10 Jul 2012 07:52:24 -0700 (PDT) In-Reply-To: <396DEDBA-E0DB-42FD-9076-787D50FCEE3E@nominum.com> References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> <396DEDBA-E0DB-42FD-9076-787D50FCEE3E@nominum.com> Date: Tue, 10 Jul 2012 07:52:24 -0700 Message-ID: From: Andre Kostur To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk18YBtnsPtP1MkHOz/F5nT/gtfV0fo4KmgMDBz6qaqw4Uv9+ssGZ8XgRywKc45KYeXVIKn Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Tue, 10 Jul 2012 14:52:02 -0000 On Tue, Jul 10, 2012 at 7:17 AM, Ted Lemon wrote: > On Jul 9, 2012, at 8:55 PM, Andre Kostur wrote: > > Note that my suggestion is that clients MAY add this field as well as > relays, not one or the other. I do see the argument that the option > should probably go into an IA options field instead of the top-level > options field as each IA may have different link addresses to talk > about. > > > All of this discussion makes a huge amount of sense if your intention is to > deprecate IAIDs, but makes no sense at all if you are intending this option > to be a hint. This option was adopted by the working group on the basis > that we would be using it as a hint. > > This draft is important work. If we turn it into a referendum on IAIDs, it > will be very contentious and won't get done anytime soon. I would really > appreciate it if we could keep a laser-like focus on the purpose that this > draft was adopted to serve, and stop trying to rewrite history. Looking at the background of this draft, one of the justifications for the draft is "based on an identifier that is already used by that operator." None of the operators are currently using the IAID as an identifier, so that's not a good choice. If we were simply trying to select a mechanism to tie a v4 allocation to a v6 allocation one could just use RFC 4361 on the v4 side and you have that information. But back to the problem that the DUID isn't an identifier that is already used by operators. The hardware address doesn't necessarily have a one-to-one mapping to IAIDs. A MAC address may be associated with multiple IAIDs (perhaps interface aliasing? eth0:0, eth0:1, etc.), so it won't be replacing IAIDs. -- Andre Kostur Senior Product Design Engineer From Ted.Lemon@nominum.com Tue Jul 10 08:16: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 2BFB711E8085 for ; Tue, 10 Jul 2012 08:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCpMBXibk-Gc for ; Tue, 10 Jul 2012 08:16:57 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF9811E807F for ; Tue, 10 Jul 2012 08:16:57 -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 DSNKT/xHhDgcRZaR2H47pMFSb+uFDfaACty5@postini.com; Tue, 10 Jul 2012 08:17:25 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 213EE1B8321 for ; Tue, 10 Jul 2012 08:17: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 920E219005C; Tue, 10 Jul 2012 08:17:21 -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, 10 Jul 2012 08:17:21 -0700 From: Ted Lemon To: Andre Kostur Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNXf7+ZrBEJQCsAkSClbxFr7Ij65chuyaAgABMmoCAAARngIAABd6AgAAU0ACAAN/oAIAACdgAgAAG+AA= Date: Tue, 10 Jul 2012 15:17:21 +0000 Message-ID: <07DA37D4-670E-407E-8610-4B0118541627@nominum.com> References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> <396DEDBA-E0DB-42FD-9076-787D50FCEE3E@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: <4A6EEBEE148064468CACD180506557FA@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Tue, 10 Jul 2012 15:16:58 -0000 On Jul 10, 2012, at 10:52 AM, Andre Kostur wrote: > Looking at the background of this draft, one of the justifications for > the draft is "based on an identifier that is already used by that > operator." How so? I don't recall this justification coming up in the working group = meeting in Paris. What I recall was an agreement that it would be nice if= there were a way for a DHCPv6 server to get the hardware address of the cl= ient so that it could be correlated with the DHCPv4 client identifier. > None of the operators are currently using the IAID as an > identifier, so that's not a good choice. By "identifier" here I assume you mean "machine inventory identifier," not = "database key associated with assigned IP address." If you mean the latt= er, then you are saying that operators are using DHCPv6-like servers that d= on't follow the protocol, which would be news to me, although I suppose it'= s possible. > If we were simply trying to > select a mechanism to tie a v4 allocation to a v6 allocation one could > just use RFC 4361 on the v4 side and you have that information. We discussed this in the meeting. We can't use RFC4361 because the timing= was wrong=97it would have had to come out about ten years earlier in order= to have been useful. Uptake thus far has been zero. Hence, it cannot b= e used. > But back to the problem that the DUID isn't an identifier that is already > used by operators. Again, please be clear on what you mean by "identifier." Otherwise we're = going to wind up in a useless debate about stuff we can't change. > The hardware address doesn't necessarily have a one-to-one mapping to > IAIDs. A MAC address may be associated with multiple IAIDs (perhaps > interface aliasing? eth0:0, eth0:1, etc.), so it won't be replacing > IAIDs. Correct. So unless you really are saying that the link-layer address ought to replac= e DUID/IAID, there is no reason for the client to send it=97it's easier and= more deployable if the relay agent does it, because you have to buy a lot = fewer of them, and the party interested in the identifier is the one writin= g the RFP for the device that has the relay agent running on it. From wwwrun@rfc-editor.org Tue Jul 10 11:24: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 506EC21F8698; Tue, 10 Jul 2012 11:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.879 X-Spam-Level: X-Spam-Status: No, score=-101.879 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyDrXWkbAsjQ; Tue, 10 Jul 2012 11:24:14 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id DE49C21F8694; Tue, 10 Jul 2012 11:24:14 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id ECA55621A1; Tue, 10 Jul 2012 11:24:36 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120710182436.ECA55621A1@rfc-editor.org> Date: Tue, 10 Jul 2012 11:24:36 -0700 (PDT) Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] RFC 6644 on Rebind Capability in DHCPv6 Reconfigure Messages 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, 10 Jul 2012 18:24:15 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6644 Title: Rebind Capability in DHCPv6 Reconfigure Messages Author: D. Evans, R. Droms, S. Jiang Status: Standards Track Stream: IETF Date: July 2012 Mailbox: N7DR@ipfonix.com, rdroms@cisco.com, jiangsheng@huawei.com Pages: 10 Characters: 19176 Updates: RFC3315 I-D Tag: draft-ietf-dhc-dhcpv6-reconfigure-rebind-10.txt URL: http://www.rfc-editor.org/rfc/rfc6644.txt This document updates RFC 3315 (DHCPv6) to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message. It extends the Reconfigure message to allow a DHCPv6 server to cause a DHCPv6 client to send a Rebind message. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. [STANDARDS-TRACK] This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From jhutz@cmu.edu Tue Jul 10 14:44: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 1678211E80F8 for ; Tue, 10 Jul 2012 14:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dB-qCrp7wN-L for ; Tue, 10 Jul 2012 14:44:34 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id 328B311E80C4 for ; Tue, 10 Jul 2012 14:44:26 -0700 (PDT) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q6ALipTQ025531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2012 17:44:52 -0400 (EDT) From: Jeffrey Hutzelman To: Ted Lemon In-Reply-To: <14182_1341929504_q6AEBh92024157_12EEF4CE-B85C-4542-AFF5-085CDE2ACFE5@nominum.com> References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> <14182_1341929504_q6AEBh92024157_12EEF4CE-B85C-4542-AFF5-085CDE2ACFE5@nominum.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 10 Jul 2012 17:44:51 -0400 Message-ID: <1341956691.7190.24.camel@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: "dhcwg@ietf.org" , Andre Kostur , jhutz@cmu.edu Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Tue, 10 Jul 2012 21:44:35 -0000 On Tue, 2012-07-10 at 14:11 +0000, Ted Lemon wrote: > On Jul 9, 2012, at 7:41 PM, A. Gregory Rabil wrote: > > I don't believe the information would be the same in the case where > > the client is requesting an address for a different interface (which > > is possible in DHCPv6, but not in DHCPv4). That's what I was trying > > to explain with the rest of my post. > > Why do we care? The link layer address is not an interface > identifierβ€”it's a hint to be used by your corporate back-office > inventory tracking system so that it can tell that an IPv4 address > belongs to the same machine as an IPv6 address. No. Not only is it an interface identifier; for this purpose, it is _the_ interface identifier. We use client hardware addresses not just for after-the-fact tracking, but for making decisions about what addresses to assign, what options to send, and what DDNS updates to do, among other things. It seems to me there are two use cases here, which argue for different uses of the option: The first use case is to allow the DHCP server to identify the client by its hardware address, the same as it could under DHCPv4, even when there is a relay involved. The option takes the place of the DHCPv4 chaddr field or the layer 2 source address, and is needed when and only when there is a relay involved. The second use case is to allow a client which is configuring addresses for multiple interfaces, or for interfaces other than the one which it is using to reach the server, to identify those interfaces. As I note above, we _do_ use hardware addresses for interface identification, and to me this is definitely a valid use case. Here, the option performs a function not available in DHCPv4, and is needed only when the client is using a feature of DHCPv6 that is also not available in DHCPv4. The need exists whether or not there is a relay involved, and a relay does not have enough information to help anyway. I would suggest that for the first use case, the option be added at the top-level by the relay agent. Relays which support this option should, in the normal case, unconditionally add or replace this option at the top level. Clients SHOULD NOT use this option at the top level. For the second use case, a client wishing to identify a particular interface may do so by using this option in the IA options field for that interface. Relays SHOULD NOT add, modify, or remove this option at the IA level. -- Jeff From jhutz@cmu.edu Tue Jul 10 14:51: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 D6EDC11E80E6 for ; Tue, 10 Jul 2012 14:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BV2sKv2tRWkk for ; Tue, 10 Jul 2012 14:51:33 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id BB7A811E80B6 for ; Tue, 10 Jul 2012 14:51:32 -0700 (PDT) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q6ALq0SC025645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2012 17:52:00 -0400 (EDT) From: Jeffrey Hutzelman To: Ted Lemon In-Reply-To: <30780_1341933448_q6AFHR0X005120_07DA37D4-670E-407E-8610-4B0118541627@nominum.com> References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> <396DEDBA-E0DB-42FD-9076-787D50FCEE3E@nominum.com> <30780_1341933448_q6AFHR0X005120_07DA37D4-670E-407E-8610-4B0118541627@nominum.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 10 Jul 2012 17:51:59 -0400 Message-ID: <1341957119.7190.30.camel@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: "dhcwg@ietf.org" , Andre Kostur , jhutz@cmu.edu Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Tue, 10 Jul 2012 21:51:34 -0000 On Tue, 2012-07-10 at 15:17 +0000, Ted Lemon wrote: > > None of the operators are currently using the IAID as an > > identifier, so that's not a good choice. > > By "identifier" here I assume you mean "machine inventory identifier," > not "database key associated with assigned IP address." If you mean > the latter, then you are saying that operators are using DHCPv6-like > servers that don't follow the protocol, which would be news to me, > although I suppose it's possible. The server may use IAIDs as keys in the lease database, but I promise you that my registration database, which contains the registration information used to decide which clients get which fixed addresses (or are given leases at all), contains hardware addresses. -- Jeff From Ted.Lemon@nominum.com Tue Jul 10 16:11: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 1890C11E8159 for ; Tue, 10 Jul 2012 16:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2e9RExHxA3kT for ; Tue, 10 Jul 2012 16:11:20 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 3D06D11E8143 for ; Tue, 10 Jul 2012 16:11:20 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKT/y2tD33GTj5MlvVPog9+2x9URR6ZLQD@postini.com; Tue, 10 Jul 2012 16:11:49 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 24E771B831E for ; Tue, 10 Jul 2012 16:11: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 182D519005C; Tue, 10 Jul 2012 16:11: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; Tue, 10 Jul 2012 16:11:48 -0700 From: Ted Lemon To: Jeffrey Hutzelman Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNXuU7ZrBEJQCsAkSClbxFr7Ij65cjmlCA Date: Tue, 10 Jul 2012 23:11:47 +0000 Message-ID: References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> <14182_1341929504_q6AEBh92024157_12EEF4CE-B85C-4542-AFF5-085CDE2ACFE5@nominum.com> <1341956691.7190.24.camel@minbar.fac.cs.cmu.edu> In-Reply-To: <1341956691.7190.24.camel@minbar.fac.cs.cmu.edu> 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_A579B8931F76436AA33908B63403811Dnominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Andre Kostur Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Tue, 10 Jul 2012 23:11:21 -0000 --_000_A579B8931F76436AA33908B63403811Dnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jul 10, 2012, at 5:44 PM, Jeffrey Hutzelman wrote: No. Not only is it an interface identifier; for this purpose, it is _the_ interface identifier. Jeffrey, you may have your own personal beliefs about how you want to opera= te your own DHCPv6 server, but these beliefs are out of scope for this disc= ussion. This discussion is about how to extend the DHCPv6 protocol to pro= vide functionality that will interoperate in a general way, but provide inf= ormation that sites like yours need in order to associate entries in the DH= CPv4 lease database and DHCPv6 allocation database with each other. If you are interested in pursuing this latter goal, that's great. If you = just want to keep having the same old stupid argument about how RFC3315 oug= ht to have been written, please take it somewhere else. --_000_A579B8931F76436AA33908B63403811Dnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <89FA27A76A54F54B8E479F1E9F48A0AA@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jul 10, 2012, at 5:44 PM, Jeffrey Hutzelman wrote:
No.  Not only is it an interface identifier; for this purpose, it is
_the_ interface identifier.

Jeffrey, you may have your own personal beliefs about how you want to = operate your own DHCPv6 server, but these beliefs are out of scope for this= discussion.   This discussion is about how to extend the DHCPv6 proto= col to provide functionality that will interoperate in a general way, but provide information that sites like you= rs need in order to associate entries in the DHCPv4 lease database and DHCP= v6 allocation database with each other.

If you are interested in pursuing this latter goal, that's great. &nbs= p; If you just want to keep having the same old stupid argument about how R= FC3315 ought to have been written, please take it somewhere else.

--_000_A579B8931F76436AA33908B63403811Dnominumcom_-- From volz@cisco.com Tue Jul 10 20:07: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 71AC711E80C5 for ; Tue, 10 Jul 2012 20:07:47 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PABAPohxvagx for ; Tue, 10 Jul 2012 20:07:44 -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 1C8BA11E8099 for ; Tue, 10 Jul 2012 20:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=16317; q=dns/txt; s=iport; t=1341976093; x=1343185693; h=from:to:cc:subject:date:message-id:mime-version; bh=3owE5dht2aMzFH5oz/kgk4i9PKoQRaEYloYWZzhOnh8=; b=lxDdO2O4lyj9xK+BtgAaHISXZggxITNFXxtXtuRQfT9fZaiFOhPzrHA2 8J+LC66O2av+DcK/um0y/MQrci7xyly6uQEYuv8sTAYganSeKjHoJP+PH ig7aCQcNeyTu1yl5AqPzw2xi34jVJm3uH0nt8ohJez4aQ5Ao8cMsftLgT U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHnt/E+tJV2Z/2dsb2JhbABCA4JKtTWBB4IgAQEBBBIBGkwSAQgRBAEBAQoKEzkUCQcCAQEDAQ0FCBqHa50coBCLQBUQgiiCQWADo1WBZoIVSoFX X-IronPort-AV: E=Sophos;i="4.77,564,1336348800"; d="scan'208,217";a="100444709" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 11 Jul 2012 03:08:12 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6B38C4r025005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jul 2012 03:08:12 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0298.004; Tue, 10 Jul 2012 22:08:12 -0500 From: "Bernie Volz (volz)" To: "A. Gregory Rabil" , Andre Kostur Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00 Thread-Index: Ac1fEYlVw3Lx4+b9RQaZa4eQW9vv9w== Date: Wed, 11 Jul 2012 03:08:12 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E02130B@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.255.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19032.001 x-tm-as-result: No--54.508400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E02130Bxmbrcdx04ciscocom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-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: Wed, 11 Jul 2012 03:07:47 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E02130Bxmbrcdx04ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >I do see the argument that the option >should probably go into an IA options field instead of the top-level >options field as each IA may have different link addresses to talk >about. No. Each DHCPv6 exchange by a client is for ONE interface and can have many= IAs associated with that interface (an IA must be associated with a single= interface, an interface can have many IAs). If a client has multiple interfaces, it MUST use separate transactions for = each of the interfaces. (Sadly there is no direct text in RFC 3315 that probably says this; there's= a lot of reading between the lines and some text in Section 16.) This option should be a 'top' level option (as it is currently defined) - o= ne for a message (note that if relayed, there are multiple messages so mult= iple options are possible in the 'overall' message). While the reference to the DOCSIS CableLabs Vendor Specific Options is an i= nteresting one, it is a bit different. They relay is adding the CM's mac ad= dress to all messages; not the actual mac address of the device doing DHCPv= 6. And, the CM does add its own mac address to the client portion of the me= ssage (in the CableLabs Vendor Specific Options) - which is what this optio= n could replace. For DOCSIS, the relay version of this option would not do = what is needed and therefore would not be used. - Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of A= . Gregory Rabil Sent: Monday, July 09, 2012 9:04 PM To: Andre Kostur Cc: dhcwg@ietf.org; Ted Lemon Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-ad= dr-opt-00.txt I believe the argument for having the the option in the IA options field in= stead of top-level options suggests that the option should/must be done by = the client, because I'm not sure how the relay could glean that information= . Greg On Mon, Jul 9, 2012 at 8:55 PM, Andre Kostur > wrote: Note that my suggestion is that clients MAY add this field as well as relays, not one or the other. I do see the argument that the option should probably go into an IA options field instead of the top-level options field as each IA may have different link addresses to talk about. The client may add the option as it may be operating in an environment where there are no relays, and the relay may add the option as it may be operating in an environment where the dhcp server may not be entirely trusting the client device, but trusts the relay more. As an example, in the cable world, the CMTS (playing the DHCPv6 relay) adds on the MAC address of the cable modem into its relayed options (currently a sub-option of option 17). On Mon, Jul 9, 2012 at 4:41 PM, A. Gregory Rabil > wrote: > I don't believe the information would be the same in the case where the > client is requesting an address for a different interface (which is possi= ble > in DHCPv6, but not in DHCPv4). That's what I was trying to explain with = the > rest of my post. > > Greg > > > On Mon, Jul 9, 2012 at 7:20 PM, Ted Lemon > wrote: >> >> On Jul 9, 2012, at 7:04 PM, A. Gregory Rabil wrote: >> >> I think this would severely limit the usefulness of this option. I woul= d >> much prefer Andre's suggestion that this option be filled with the link >> layer address of the interface being configured. This would mean that t= he >> client would be responsible for adding this option, not the relay. I >> understand the motivation for the option is to help correlate the client= to >> the IPv4 chaddr field. >> >> >> Why would having the relay add the option limit its usefulness? The >> information is the same in either case. The difference is that you don= 't >> have to update all your DHCPv6 clients, and you don't have to worry that >> some DHCPv6 client vendors won't ever implement this option. >> > -- Andre Kostur Senior Product Design 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 --_000_489D13FBFA9B3E41812EA89F188F018E02130Bxmbrcdx04ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>I do see the argument that the option
>should probably go into an IA options field instead of the top-level >options field as each IA may have different link addresses to talk
>about.  

 

No. Each DHCPv6 exchange by a client is for ONE inte= rface and can have many IAs associated with that interface (an IA must be a= ssociated with a single interface, an interface can have many IAs).

 

If a client has multiple interfaces, it MUST use sep= arate transactions for each of the interfaces.

 

(Sadly there is no direct text in RFC 3315 that prob= ably says this; there’s a lot of reading between the lines and some t= ext in Section 16.)

 

This option should be a ‘top’ level opti= on (as it is currently defined) – one for a message (note that if rel= ayed, there are multiple messages so multiple options are possible in the &= #8216;overall’ message).

 <= /p>

 

While the reference to the DOCSIS CableLabs Vendor S= pecific Options is an interesting one, it is a bit different. They relay is= adding the CM’s mac address to all messages; not the actual mac addr= ess of the device doing DHCPv6. And, the CM does add its own mac address to the client portion of the message (in t= he CableLabs Vendor Specific Options) – which is what this option cou= ld replace. For DOCSIS, the relay version of this option would not do what = is needed and therefore would not be used.

 

-          Bernie=

 <= /p>

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of A. Gregory Rabil
Sent: Monday, July 09, 2012 9:04 PM
To: Andre Kostur
Cc: dhcwg@ietf.org; Ted Lemon
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-l= ayer-addr-opt-00.txt

 

I believe the argument for having the the option in = the IA options field instead of top-level options suggests that the option = should/must be done by the client, because I'm not sure how the relay could= glean that information.

 

Greg

On Mon, Jul 9, 2012 at 8:55 PM, Andre Kostur <akostur@incognito.c= om> wrote:

Note that my suggestion is that clients MAY add this= field as well as
relays, not one or the other.  I do see the argument that the option should probably go into an IA options field instead of the top-level
options field as each IA may have different link addresses to talk
about.   The client may add the option as it may be operating in an environment where there are no relays, and the relay may add the
option as it may be operating in an environment where the dhcp server
may not be entirely trusting the client device, but trusts the relay
more.   As an example, in the cable world, the CMTS (playing the
DHCPv6 relay) adds on the MAC address of the cable modem into its
relayed options (currently a sub-option of option 17).




On Mon, Jul 9, 2012 at 4:41 PM, A. Gregory Rabil
<greg.rabil@jagornet.com&= gt; wrote:
> I don't believe the information would be the same in the case where th= e
> client is requesting an address for a different interface (which is po= ssible
> in DHCPv6, but not in DHCPv4).  That's what I was trying to expla= in with the
> rest of my post.
>
> Greg
>
>
> On Mon, Jul 9, 2012 at 7:20 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
>>
>> On Jul 9, 2012, at 7:04 PM, A. Gregory Rabil wrote:
>>
>> I think this would severely limit the usefulness of this option. &= nbsp;I would
>> much prefer Andre's suggestion that this option be filled with the= link
>> layer address of the interface being configured.  This would = mean that the
>> client would be responsible for adding this option, not the relay.=  I
>> understand the motivation for the option is to help correlate the = client to
>> the IPv4 chaddr field.
>>
>>
>> Why would having the relay add the option limit its usefulness? &n= bsp; The
>> information is the same in either case.   The difference is t= hat you don't
>> have to update all your DHCPv6 clients, and you don't have to worr= y that
>> some DHCPv6 client vendors won't ever implement this option.
>>
>


--
Andre Kostur
Senior Product Design 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

 

--_000_489D13FBFA9B3E41812EA89F188F018E02130Bxmbrcdx04ciscocom_-- From greg.rabil@jagornet.com Tue Jul 10 20:30: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 D5A3A21F85B6 for ; Tue, 10 Jul 2012 20:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIkbIlY8t542 for ; Tue, 10 Jul 2012 20:30:05 -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 C5D6611E8079 for ; Tue, 10 Jul 2012 20:30:04 -0700 (PDT) Received: by bkty7 with SMTP id y7so552880bkt.31 for ; Tue, 10 Jul 2012 20:30:33 -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=5AlRZow7oXjL8uGy+4IUnQpTppV0RKSzJwvKSGwCzAs=; b=kPtmz86x/Ji2ZEbk/D4DqlBZovC+tWTVsdafCUtgY5b3etnERW3bP7PtLqycr74wux 3RI4sJXBNvYoQl91/9918kprIpSiIE9TN5bce4OrYxFvzLqEUmA8URjQKXoVhmvPHgf6 JIjkUqOQ3nvVCtkpHZysh5LbNJAn+OdPwmFUsz3rRD076Y6/IR3B/fCtGo/c5kDG2w76 sFpwTwCAgLj4rEYGGizfaneK6E/6pL/ioq3n3JoXQaI20I2NC7OPmGPvslgRXXP3uPN2 QdRhuagXZ3LM90GWgc9Lei/N9Vt+8GTc5LGtEacQsK4SuYGJOtSAfGISLk6Ei6lTrBbE roVg== MIME-Version: 1.0 Received: by 10.204.129.208 with SMTP id p16mr5162331bks.129.1341977433213; Tue, 10 Jul 2012 20:30:33 -0700 (PDT) Received: by 10.204.156.133 with HTTP; Tue, 10 Jul 2012 20:30:33 -0700 (PDT) In-Reply-To: <12EEF4CE-B85C-4542-AFF5-085CDE2ACFE5@nominum.com> References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> <12EEF4CE-B85C-4542-AFF5-085CDE2ACFE5@nominum.com> Date: Tue, 10 Jul 2012 23:30:33 -0400 Message-ID: From: "A. Gregory Rabil" To: Ted Lemon Content-Type: multipart/alternative; boundary=00151747ba06340aaa04c48578aa X-Gm-Message-State: ALoCoQlIWtzijQc1dUizyEg8hPOOOr9LE5NvgQ2aHzMf3eAR4/iLttN1vxHoUFdNZFRhpXU3N8Ol Cc: "dhcwg@ietf.org" , Andre Kostur Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Wed, 11 Jul 2012 03:30:05 -0000 --00151747ba06340aaa04c48578aa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > We are hinting at the machine's identity, not the interface's identity. I believe this is exactly what limits the usefulness of this option. Why not identify the machine AND the interface? I understand the argument that it is easier to update relay agents versus clients, but it just seems like this is incomplete solution. I also understand the DUID/IAID and am not out to change that at all. I would simply like add this link-layer option to identify the interface actually being configured in order to provide as much information as possible for administrative control, because experience has shown that such controls are inevitably needed. Greg On Tue, Jul 10, 2012 at 10:11 AM, Ted Lemon wrote: > On Jul 9, 2012, at 7:41 PM, A. Gregory Rabil wrote: > > I don't believe the information would be the same in the case where the > client is requesting an address for a different interface (which is > possible in DHCPv6, but not in DHCPv4). That's what I was trying to > explain with the rest of my post. > > > Why do we care? The link layer address is not an interface > identifier=97it's a hint to be used by your corporate back-office invento= ry > tracking system so that it can tell that an IPv4 address belongs to the > same machine as an IPv6 address. As long as your inventory tracking > system has a list of all the interfaces on a machine, or as long as the > DHCPv4 server has received a request from the same interface, the > connection is made. We are hinting at the machine's identity, not the > interface's identity. > > --00151747ba06340aaa04c48578aa Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >=A0We are hinting at the machine's identity, not the interface'= s identity.

I believe this is exactly what limits the us= efulness of this option. =A0Why not identify the machine AND the interface?= =A0I understand the argument that it is easier to update relay agents vers= us clients, but it just seems like this is incomplete solution. =A0I also u= nderstand the DUID/IAID and am not out to change that at all. =A0I would si= mply like add this link-layer option to identify the interface actually bei= ng configured in order to provide as much information as possible for admin= istrative control, because experience has shown that such controls are inev= itably needed.

Greg

On Tue, Jul 10, = 2012 at 10:11 AM, Ted Lemon <Ted.Lemon@nominum.com> wrot= e:
On Jul 9, 2012, at 7:41 PM, A. Gregory Rabil wrote:
= I don't believe the information would be the same in the case where the = client is requesting an address for a different interface (which is possibl= e in DHCPv6, but not in DHCPv4). =A0That's what I was trying to explain= with the rest of my post.

Why do we care? =A0 The link layer address is not an interface i= dentifier=97it's a hint to be used by your corporate back-office invent= ory tracking system so that it can tell that an IPv4 address belongs to the= same machine as an IPv6 address. =A0 As long as your inventory tracking system has a list of all the interfaces on a machi= ne, or as long as the DHCPv4 server has received a request from the same in= terface, the connection is made. =A0 We are hinting at the machine's id= entity, not the interface's identity.


--00151747ba06340aaa04c48578aa-- From Ted.Lemon@nominum.com Tue Jul 10 20:53: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 B798721F85AA for ; Tue, 10 Jul 2012 20:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNPIajBsBIRQ for ; Tue, 10 Jul 2012 20:53:01 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 948F121F85B6 for ; Tue, 10 Jul 2012 20:53:01 -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 DSNKT/z4uiNnPw21Sh2GgI9quiWZeAxqBt/t@postini.com; Tue, 10 Jul 2012 20:53:31 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 3ED131B831F for ; Tue, 10 Jul 2012 20:53:30 -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 3512C19005C; Tue, 10 Jul 2012 20:53:30 -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, 10 Jul 2012 20:53:23 -0700 From: Ted Lemon To: "A. Gregory Rabil" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNXf7+ZrBEJQCsAkSClbxFr7Ij65chuyaAgABMmoCAAARngIAABd6AgADzHYCAAN9HgIAABl6A Date: Wed, 11 Jul 2012 03:53:21 +0000 Message-ID: <545EC59B-EEB6-44A1-9663-AC0BF6F0A412@nominum.com> References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> <12EEF4CE-B85C-4542-AFF5-085CDE2ACFE5@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_545EC59BEEB644A19663AC0BF6F0A412nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Andre Kostur Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Wed, 11 Jul 2012 03:53:02 -0000 --_000_545EC59BEEB644A19663AC0BF6F0A412nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jul 10, 2012, at 11:30 PM, A. Gregory Rabil wrote: I believe this is exactly what limits the usefulness of this option. Why n= ot identify the machine AND the interface? I understand the argument that = it is easier to update relay agents versus clients, but it just seems like = this is incomplete solution. I also understand the DUID/IAID and am not ou= t to change that at all. I would simply like add this link-layer option to= identify the interface actually being configured in order to provide as mu= ch information as possible for administrative control, because experience h= as shown that such controls are inevitably needed. The purpose of the draft was very simply and exclusively to tag each DHCPv6= packet with the link-layer address of the interface on which the packet wa= s originally sent. This is a very simple, very restricted scope. It's s= omething that I think everyone in the working group can agree on. It's al= so very easy to implement, because it can be done in the relay agent. What you've said is very difficult for me to parse=97you seem to be imputin= g a ton of additional protocol and semantic detail on top of something very= simple. Can you state in simple, clear terms why the first sentence in t= he paragraph above does not satisfy you? --_000_545EC59BEEB644A19663AC0BF6F0A412nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <934F9D72184D204BB8E47A4DE853CE36@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jul 10, 2012, at 11:30 PM, A. Gregory Rabil wrote:
I believe this is exactly what limits the usefulness of this option.  W= hy not identify the machine AND the interface?  I understand the argum= ent that it is easier to update relay agents versus clients, but it just se= ems like this is incomplete solution.  I also understand the DUID/IAID and am not out to change that at all.  I wou= ld simply like add this link-layer option to identify the interface actuall= y being configured in order to provide as much information as possible for = administrative control, because experience has shown that such controls are inevitably needed.

The purpose of the draft was very simply and exclusively to tag each D= HCPv6 packet with the link-layer address of the interface on which the pack= et was originally sent.   This is a very simple, very restricted scope= .   It's something that I think everyone in the working group can agree on.   It's also very easy to implement= , because it can be done in the relay agent.

What you've said is very difficult for me to parse=97you seem to be im= puting a ton of additional protocol and semantic detail on top of something= very simple.   Can you state in simple, clear terms why the first sen= tence in the paragraph above does not satisfy you?

--_000_545EC59BEEB644A19663AC0BF6F0A412nominumcom_-- From internet-drafts@ietf.org Wed Jul 11 02:04: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 20BEF21F8683; Wed, 11 Jul 2012 02:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igdEOYIzqqS9; Wed, 11 Jul 2012 02:04:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DE221F864A; Wed, 11 Jul 2012 02:04:34 -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.30p3 Message-ID: <20120711090434.10485.95917.idtracker@ietfa.amsl.com> Date: Wed, 11 Jul 2012 02:04:34 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-client-id-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: Wed, 11 Jul 2012 09:04:35 -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-04.txt Pages : 6 Date : 2012-07-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-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-client-id-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From marccp@srttel.com Wed Jul 11 08: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 D521321F8649 for ; Wed, 11 Jul 2012 08:20:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mV+uqXLfaFs for ; Wed, 11 Jul 2012 08:20:30 -0700 (PDT) Received: from mail.srttel.com (mail.srttel.com [216.221.96.218]) by ietfa.amsl.com (Postfix) with ESMTP id CEF8F21F8679 for ; Wed, 11 Jul 2012 08:20:29 -0700 (PDT) Received: from srtdom-MTA by mail.srttel.com with Novell_GroupWise; Wed, 11 Jul 2012 10:20:59 -0500 Message-Id: <4FFD5373.39E4.004A.0@srttel.com> X-Mailer: Novell GroupWise Internet Agent 7.0.3 Date: Wed, 11 Jul 2012 10:20:47 -0500 From: "Marc Perea" To: References: In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part9CB223DF.0__=" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Wed, 11 Jul 2012 15:20:32 -0000 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part9CB223DF.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I'm new to posting on this list, but have followed closely this particular = problem space for quite a while. =20 >It seems to me there are two use cases here, which argue for different >uses of the option: I think the WG would argue that there are many use cases for DHCP, two of = which you indicate here. >The first use case is to allow the DHCP server to identify the client by >its hardware address, the same as it could under DHCPv4, even when there >is a relay involved. The option takes the place of the DHCPv4 chaddr >field or the layer 2 source address, and is needed when and only when >there is a relay involved. =20 There's been quite a lot of misconception (including myself) about what = the chaddr represents. It is both a primary key for spec following DHCP = servers in the absence of client id in dhcpv4, and a (semi) unique = identifier that many of us used in our daily activities and workflow = processes. I believe that from the WG perspective, with the scope of = identifying what a protocol should support, Ted in particular often = specifies the importance of unique identifiers from the protocol perspectiv= e. We should appreciate that, because that's important to the stability of = the protocol. On the other hand, many of us have currently broken workflow = and tracking because the mac address isn't readily available today on v6, = and sometimes that's the best (or only) way to reasonably match identificat= ion of an endpoint capable of v4 + v6. Some of us are choosing not to = implement v6 for this specific feature lack. That's the problem that this = draft was written specifically to address. I like what's happening so far. >The second use case is to allow a client which is configuring addresses >for multiple interfaces, or for interfaces other than the one which it >is using to reach the server, to identify those interfaces. As I note >above, we _do_ use hardware addresses for interface identification, and >to me this is definitely a valid use case. Here, the option performs a >function not available in DHCPv4, and is needed only when the client is >using a feature of DHCPv6 that is also not available in DHCPv4. The >need exists whether or not there is a relay involved, and a relay does >not have enough information to help anyway. IMO, this is out of scope for this work. This is a different problem space = and should likely have a different mechanism to fix it. Whereas the former = problem statement is (pretty) clearly defined and understood, and can be = fairly easily implemented since many operators/admins have a good amount = of control over their relays and servers, very few operators/admins have a = functional relationship with DHCP client implementors enough to make the = changes being discussed here in the latter use case a reality. I'm not = saying it's not a valid use case - I'm saying I don't think it fits the = problem this draft was intended to solve, which is a way for operators to = tie v4 and v6 endpoints together. Perhaps I'm mistaken, but it seems like = this should be pursued as a separate draft. --Marc --=__Part9CB223DF.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML
I'm new to posting on this list, but have followed closely this = particular problem space for quite a while.
 
>It seems to me there are two use cases here, which argue for = different
>uses of the option:

I  think the WG would = argue that there are many use cases for DHCP, two of which you indicat= e here.

>The first use case is to allow the DHCP server to identify = the client by
>its hardware address, the same as it could under = DHCPv4, even when there
>is a relay involved.  The option takes = the place of the DHCPv4 chaddr
>field or the layer 2 source address, = and is needed when and only when
>there is a relay involved.
 
There's been quite a lot of misconception (including myself) about = what the chaddr represents. It is both a primary key for spec following = DHCP servers in the absence of client id in dhcpv4, and a (semi) unique = identifier that many of us used in our daily activities and workflow = processes. I believe that from the WG perspective, with the scope of = identifying what a protocol should support, Ted in particular often = specifies the importance of unique identifiers from the protocol perspectiv= e. We should appreciate that, because that's important to the stability of = the protocol. On the other hand, many of us have currently broken workflow = and tracking because the mac address isn't readily available today on v6, = and sometimes that's the best (or only) way to reasonably match identificat= ion of an endpoint capable of v4 + v6. Some of us are choosing not to = implement v6 for this specific feature lack. That's the problem that this = draft was written specifically to address. I like what's happening so = far.

>The second use case is to allow a client which is = configuring addresses
>for multiple interfaces, or for interfaces = other than the one which it
>is using to reach the server, to = identify those interfaces.  As I note
>above, we _do_ use = hardware addresses for interface identification, and
>to me this is = definitely a valid use case.  Here, the option performs a
>funct= ion not available in DHCPv4, and is needed only when the client is
>u= sing a feature of DHCPv6 that is also not available in DHCPv4.  = The
>need exists whether or not there is a relay involved, and a = relay does
>not have enough information to help anyway.

IMO, = this is out of scope for this work. This is a different problem space and = should likely have a different mechanism to fix it. Whereas the former = problem statement is (pretty) clearly defined and understood, and can be = fairly easily implemented since many operators/admins have a good amount = of control over their relays and servers, very few operators/admins have a = functional relationship with DHCP client implementors enough to make the = changes being discussed here in the latter use case a reality. I'm not = saying it's not a valid use case - I'm saying I don't think it fits the = problem this draft was intended to solve, which is a way for operators to = tie v4 and v6 endpoints together. Perhaps I'm mistaken, but it seems like = this should be pursued as a separate draft.

--Marc
--=__Part9CB223DF.0__=-- From greg.rabil@jagornet.com Wed Jul 11 11:49: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 86ACF21F85A8 for ; Wed, 11 Jul 2012 11:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aYhEijeLjMz for ; Wed, 11 Jul 2012 11:49:31 -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 1F85621F8554 for ; Wed, 11 Jul 2012 11:49:30 -0700 (PDT) Received: by bkty7 with SMTP id y7so1281551bkt.31 for ; Wed, 11 Jul 2012 11:50:01 -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=iDb1x2T9c4rSl9JlPsyWlO42rbTT1BR3/2auJvJAiBw=; b=Am4gsvU5owTl++rCfy1MBJ4p5VvomvVqG8Zzlmes/PGzcWDEoWKV6dmlvwSPJ/dI5z 89sckE5N1vmAFCjeY4iAwEVUmeH+FMu3HsEUu8xgvrioo8vf3zuTEY58ysfbZs2ogYVm FtDvaSd0EN1vSY+cW8KFQwdWm3wpZLsTj6s7g5J6I97NHpSSazLH1chgqFyEVoBFQxGd rH6i2tX9xeZHCePa/en11+vZnI99rg5l5lTAV5Pv0Ds6mgdt9qf7fDP2niDdHjUTvVC5 NTFBCW86Wd7MAG+dykubh57YeEBPH5HyleSza8VwFJGbQ8RVSXFMFGYLcVoJpzCH/UGT 9f5g== MIME-Version: 1.0 Received: by 10.204.152.199 with SMTP id h7mr25282113bkw.39.1342032601397; Wed, 11 Jul 2012 11:50:01 -0700 (PDT) Received: by 10.204.156.133 with HTTP; Wed, 11 Jul 2012 11:50:01 -0700 (PDT) In-Reply-To: <545EC59B-EEB6-44A1-9663-AC0BF6F0A412@nominum.com> References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> <12EEF4CE-B85C-4542-AFF5-085CDE2ACFE5@nominum.com> <545EC59B-EEB6-44A1-9663-AC0BF6F0A412@nominum.com> Date: Wed, 11 Jul 2012 14:50:01 -0400 Message-ID: From: "A. Gregory Rabil" To: Ted Lemon Content-Type: multipart/alternative; boundary=0015175cd9e87bb86904c4925038 X-Gm-Message-State: ALoCoQliBRslLJwu5Zmu1WOkTwOPVu4y092QK0dhSmFbQrfmH+Gh+PLJWjHktXizWyBat6n0VQKc Cc: "dhcwg@ietf.org" , Andre Kostur Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Wed, 11 Jul 2012 18:49:32 -0000 --0015175cd9e87bb86904c4925038 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable What does not satisfy about that first sentence is that it limits the usefulness of this option because of the part that says "the interface on which the packet was originally sent". My argument is that although this may be useful, it it not a complete solution because I would like it to identify the interface which is being configured. This text is from the section 2 of the draft: In dual stack scenarios it is desirable for the operator to associate DHCPv4 and DHCPv6 messages as belonging to the same client interface based on an identifier that is already used by that operator such as the client hardware address. This refers to the client interface, not just the client. This statement is reiterated by the author earlier in this email thread: > Since one of the uses of learning link layer address was to correlate DHCPv4 and DHCPv6 messages from the same client interface ( as described in Section 2 Problem Background and Scenario of the draft), the link layer address should match 'chaddr' field of DHCPv4 messages sent for configuring the same interface. I believe I have explained how this may not always be the case if the relay is responsible for inserting the option, whereas it can be ensured if the client does it. As an example, consider a client which is dual-stacked on two interfaces. In DHCPv4, each request MUST be sent with a chaddr of the interface being configured, which is, by definition, the interface on which the request is sent. In this situation, an administrator could provide different options, etc. for each interface based upon what the back-office database says. In DHCPv6, the text in RFC 3315 section 16 suggests that it is possible for the client to send a request out an interface other than the one being configured. In this scenario, it may not be possible to correlate this as being "messages from the same client interface" as the DHCPv4 client. Earlier you referenced and "inventory tracking system has a list of all the interfaces on a machine". What if that inventory tracking system is trying to "discover" the interfaces by reading the DHCP server's lease database? DHCPv4 cannot correlate the two interfaces to being on the same client, so even if it is the same server serving all four requests (v4 and v6 address for each interface), it is possible that both v6 requests look to be coming from one interface. So, an inventory system would learn that one interface has an IPv4 address and two IPv6 addresses, and the other interface has one IPv4 address, which would be incorrect. In the end, I think it comes down to the fact that DHCPv4/v6 configure interfaces, not machines. Administrators are accustomed to being able to configure interfaces (not machines) by their link-layer address in DHCPv4. I believe that in order to provide this same capability in DHCPv6, we need to ensure that the option identifies the interface being configured, not just the machine. Another aspect of the option not being inserted by the client is that it forces implementations (relays and servers) to read layer 2 information from the incoming packets. If the client provides this information as an option, it works for all implementations without such a requirement. Greg On Tue, Jul 10, 2012 at 11:53 PM, Ted Lemon wrote: > On Jul 10, 2012, at 11:30 PM, A. Gregory Rabil wrote: > > I believe this is exactly what limits the usefulness of this option. Why > not identify the machine AND the interface? I understand the argument th= at > it is easier to update relay agents versus clients, but it just seems lik= e > this is incomplete solution. I also understand the DUID/IAID and am not > out to change that at all. I would simply like add this link-layer optio= n > to identify the interface actually being configured in order to provide a= s > much information as possible for administrative control, because experien= ce > has shown that such controls are inevitably needed. > > > The purpose of the draft was very simply and exclusively to tag each > DHCPv6 packet with the link-layer address of the interface on which the > packet was originally sent. This is a very simple, very restricted scop= e. > It's something that I think everyone in the working group can agree on. > It's also very easy to implement, because it can be done in the relay age= nt. > > What you've said is very difficult for me to parse=97you seem to be > imputing a ton of additional protocol and semantic detail on top of > something very simple. Can you state in simple, clear terms why the fir= st > sentence in the paragraph above does not satisfy you? > > --0015175cd9e87bb86904c4925038 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable What does not satisfy about that first sentence is that it limits the usefu= lness of this option because of the part that says "the interface on w= hich the packet was originally sent". =A0My argument is that although = this may be useful, it it not a complete solution because I would like it t= o identify the interface which is being configured.

This text is from the section 2 of the draft:

= 
   In d=
ual stack scenarios it is desirable for the operator
   to associate DHCPv4 and DHCPv6 messages as belonging to the same
   client interface based on an identifier that is already used by that
   operator such as the client hardware address.

=
This refers to the client interface, not just the client. =A0This stat= ement is reiterated by the author earlier in this email thread:

> Since one of the uses of learning link layer = address was to correlate
DHCPv4 and DHCPv6 messages from the same client interface ( as describ= ed
in Section 2 Problem Background and Scenario of the draft), the link l= ayer
address should match 'chaddr' field of DHCPv4 messages sent fo= r
configuring the same interface.=A0

I b= elieve I have explained how this may not always be the case if the relay is= responsible for inserting the option, whereas it can be ensured if the cli= ent does it. =A0

As an example, consider a client which is dual-stacked = on two interfaces. =A0In DHCPv4, each request MUST be sent with a chaddr of= the interface being configured, which is, by definition, the interface on = which the request is sent. =A0In this situation, an administrator could pro= vide different options, etc. for each interface based upon what the back-of= fice database says. =A0In DHCPv6, the text in RFC 3315 section 16 suggests = that it is possible for the client to send a request out an interface other= than the one being configured. =A0In this scenario, it may not be possible= to correlate this as being "messages from the same client interf= ace" as the DHCPv4 client. =A0Earlier you referenced and "= inventory tracking system has a list= of all the interfaces on a machine". =A0What if that inventory tracki= ng system is trying to "discover" the interfaces by reading the D= HCP server's lease database? =A0DHCPv4 cannot correlate the two interfa= ces to being on the same client, so even if it is the same server serving a= ll four requests (v4 and v6 address for each interface), it is possible tha= t both v6 requests look to be coming from one interface. =A0So, an inventor= y system would learn that one interface has an IPv4 address and two IPv6 ad= dresses, and the other interface has one IPv4 address, which would be incor= rect.

In the end, I think it comes down to the fact= that DHCPv4/v6 configure interfaces, not machines. =A0Administrators are a= ccustomed to being able to configure interfaces (not machines) by their lin= k-layer address in DHCPv4. =A0I believe that in order to provide this same = capability in DHCPv6, we need to ensure that the option identifies the inte= rface being configured, not just the machine.

Another aspect of the option not being inserted by the = client is that it forces implementations (relays and servers) to read layer= 2 information from the incoming packets. =A0If the client provides this in= formation as an option, it works for all implementations without such a req= uirement.

Greg



On Tue, Jul 10, 2012 at 11:53 PM, Ted Lemon <= ;Ted.Lemon@nomin= um.com> wrote:
On Jul 10, 2012, at 11:30 PM, A. Gregory Rabil wrote:
= I believe this is exactly what limits the usefulness of this option. =A0Why = not identify the machine AND the interface? =A0I understand the argument th= at it is easier to update relay agents versus clients, but it just seems li= ke this is incomplete solution. =A0I also understand the DUID/IAID and am not out to change that at all. =A0I would = simply like add this link-layer option to identify the interface actually b= eing configured in order to provide as much information as possible for adm= inistrative control, because experience has shown that such controls are inevitably needed.

The purpose of the draft was very simply and exclusively to tag = each DHCPv6 packet with the link-layer address of the interface on which th= e packet was originally sent. =A0 This is a very simple, very restricted sc= ope. =A0 It's something that I think everyone in the working group can agree on. =A0 It's also very easy to implemen= t, because it can be done in the relay agent.

What you've said is very difficult for me to parse=97you seem to b= e imputing a ton of additional protocol and semantic detail on top of somet= hing very simple. =A0 Can you state in simple, clear terms why the first se= ntence in the paragraph above does not satisfy you?


--0015175cd9e87bb86904c4925038-- From linux@thehobsons.co.uk Wed Jul 11 13:03: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 2DDA621F84A0 for ; Wed, 11 Jul 2012 13:03:10 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtO3sfukyoIX for ; Wed, 11 Jul 2012 13:03:09 -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 DC7D121F8498 for ; Wed, 11 Jul 2012 13:03:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 1D37910401B for ; Wed, 11 Jul 2012 21:03:39 +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 PO2F3cm+Ksc4 for ; Wed, 11 Jul 2012 21:03:39 +0100 (BST) Received: from simon.thehobsons.co.uk (simons-macbookpro.thehobsons.co.uk [192.168.0.202]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id A8A4E10401A for ; Wed, 11 Jul 2012 21:03:38 +0100 (BST) Mime-Version: 1.0 Message-Id: Date: Wed, 11 Jul 2012 21:03:34 +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-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: Wed, 11 Jul 2012 20:03:10 -0000 A. Gregory Rabil wrote: >Another aspect of the option not being inserted by the client is >that it forces implementations (relays and servers) to read layer 2 >information from the incoming packets. If the client provides this >information as an option, it works for all implementations without >such a requirement. This has also been discussed before. In an ideal world, we could just change the required client behaviour and all the vendors would update their clients and their users would update their software/firmware. Meanwhile, back in the real world, the opportunity to change clients has (largely) past - but there are fewer vendors of servers and relay agents which makes it a better bet to do this in the server or relay agent. If ISC, Dibbler?, Cisco, and a handful of others update their server/relay agents, then that's probably the majority of situations covered where this is an issue. Plus, you can run a relay agent on something other than your routers - so even if your router vendor doesn't update, you can just fire up some small Linux/BSD/whatever box (can be a virtual machine) on the remote network and you're sorted. In a way it's a parallel argument to using LL (MAC) addresses anyway. Again, in an ideal world the specs would have been updated to mandate a globally unique client ID, printed on the outside of the box (probably with a barcode as well), and sent by both the IPv4 and IPv6 DHCP clients. Short of inventing a time machine and going back a decade or two, that's not going to happen. So back in the real world again, at least in the IPv4 world we are stuck using LL addresses since they are the nearest thing we have to a universally present, globally unique, and immutable identifier. -- 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 Ted.Lemon@nominum.com Wed Jul 11 13:09: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 981D011E80A2 for ; Wed, 11 Jul 2012 13:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37l8VIYvBuOx for ; Wed, 11 Jul 2012 13:09:34 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id AE1D721F852C for ; Wed, 11 Jul 2012 13:09:33 -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 DSNKT/3dnEd9E8wZlua1UXb12yccB1BR0UVH@postini.com; Wed, 11 Jul 2012 13:10: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 57ED11B8313 for ; Wed, 11 Jul 2012 13:10:04 -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 4BDAC19005C; Wed, 11 Jul 2012 13:10:04 -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, 11 Jul 2012 13:10:04 -0700 From: Ted Lemon To: "A. Gregory Rabil" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNXf7+ZrBEJQCsAkSClbxFr7Ij65chuyaAgABMmoCAAARngIAABd6AgADzHYCAAN9HgIAABl6AgAD6h4CAABZcgA== Date: Wed, 11 Jul 2012 20:10:03 +0000 Message-ID: <49A52050-7FCA-44E8-9130-EFE3979D7FC3@nominum.com> References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> <12EEF4CE-B85C-4542-AFF5-085CDE2ACFE5@nominum.com> <545EC59B-EEB6-44A1-9663-AC0BF6F0A412@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_49A520507FCA44E89130EFE3979D7FC3nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Andre Kostur Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Wed, 11 Jul 2012 20:09:34 -0000 --_000_49A520507FCA44E89130EFE3979D7FC3nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jul 11, 2012, at 2:50 PM, A. Gregory Rabil wrote: What does not satisfy about that first sentence is that it limits the usefu= lness of this option because of the part that says "the interface on which = the packet was originally sent". My argument is that although this may be = useful, it it not a complete solution because I would like it to identify t= he interface which is being configured. Okay, great. So, the link-layer address for the interface being configure= d is being attached to the packet that was sent on that interface, but some= how this doesn't satisfy your need. Can you describe (please, one or two = sentences, not several paragraphs) under what real-world circumstances this= would occur? --_000_49A520507FCA44E89130EFE3979D7FC3nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <579ABF97F7317A4397CF7F9A3A9E604E@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jul 11, 2012, at 2:50 PM, A. Gregory Rabil wrote:
What does not satisfy about that first sentence is that it limits the usefulnes= s of this option because of the part that says "the interface on which= the packet was originally sent".  My argument is that although t= his may be useful, it it not a complete solution because I would like it to identify the interface which is being configure= d.

Okay, great.   So, the link-layer address for the interface being= configured is being attached to the packet that was sent on that interface= , but somehow this doesn't satisfy your need.   Can you describe (plea= se, one or two sentences, not several paragraphs) under what real-world circumstances this would occur?

--_000_49A520507FCA44E89130EFE3979D7FC3nominumcom_-- From greg.rabil@jagornet.com Wed Jul 11 14:10: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 A567111E80EA for ; Wed, 11 Jul 2012 14:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLTgZ6BtRQrQ for ; Wed, 11 Jul 2012 14:10:00 -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 9C69711E80D2 for ; Wed, 11 Jul 2012 14:09:59 -0700 (PDT) Received: by bkty7 with SMTP id y7so1394501bkt.31 for ; Wed, 11 Jul 2012 14:10:30 -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=mX3wKjNpdJRMVgqPlmNzL1Ppc3F/UDORdi8K6aKWf+0=; b=MBJ/r4UlzD4ndoP1QYk3qSyHdaX7f3kzc6WpVQAamJBcA+0H8G4h173b9ILW1HNbG8 1JHyxUK7aKu6x9ramI/gm5lQ+G0K5+ojW3pGEHcegx1kqi5Xx5NluMRWOU7oF6Fvy4N1 ZgsuQuHGu2hKp7InqOPFoO+e7LqWbQZGst/zfZDlPVwgxtKL0tenf0ttfyT5us3Kdtnn L47x+fD3zsF86bvb/iKmJWiMzohBzgW9U/EkJn96dZ04NG29HPLDXzcwohnscVDipCHx ivqRBFhmlzDZCl5nBwTPEt6rtqhXfl0JA9EWIHNp9OlMos5fso2eDN+yoCjiKprqayyc qSxg== MIME-Version: 1.0 Received: by 10.204.152.19 with SMTP id e19mr24815420bkw.8.1342041030235; Wed, 11 Jul 2012 14:10:30 -0700 (PDT) Received: by 10.204.156.133 with HTTP; Wed, 11 Jul 2012 14:10:29 -0700 (PDT) In-Reply-To: <49A52050-7FCA-44E8-9130-EFE3979D7FC3@nominum.com> References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> <12EEF4CE-B85C-4542-AFF5-085CDE2ACFE5@nominum.com> <545EC59B-EEB6-44A1-9663-AC0BF6F0A412@nominum.com> <49A52050-7FCA-44E8-9130-EFE3979D7FC3@nominum.com> Date: Wed, 11 Jul 2012 17:10:29 -0400 Message-ID: From: "A. Gregory Rabil" To: Ted Lemon Content-Type: multipart/alternative; boundary=0015175d0406e1970f04c4944677 X-Gm-Message-State: ALoCoQkzHEHasMnIoXNhvmzEz8REhsfvEwQ3ht0OYtRuMHQxba+NzhlxxmgTWBClB/3XaM17AcVX Cc: "dhcwg@ietf.org" , Andre Kostur Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Wed, 11 Jul 2012 21:10:00 -0000 --0015175d0406e1970f04c4944677 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 11, 2012 at 4:10 PM, Ted Lemon wrote: > Okay, great. So, the link-layer address for the interface being > configured is being attached to the packet that was sent on that interface, > but somehow this doesn't satisfy your need. Can you describe (please, one > or two sentences, not several paragraphs) under what real-world > circumstances this would occur? > > Okay, consider prefix-delegation, for example. The requesting router will send an IA_PD request out the WAN interface to get a prefix which is then allocated to the downstream/LAN interface. Since the packet is sent via the WAN interface, I believe that the relay would insert the link-layer address of the WAN interface in the request, and thus the prefix would then be "associated" with the WAN interface, whereas it is really associated with the LAN interface. So, this is how the interface being configured is NOT the interface on which the packet is sent. Further, consider a requesting router with two distinct downstream/LAN interfaces. The PD requests for both LAN interfaces would be sent via the WAN interface, and thus the WAN's link-layer address will be inserted into the option by the relay (or learnt by the server from layer 2). An administrator may wish to configure different prefixes and/or options for each LAN interface, but has no way to do identify them individually via the proposed mechanism. Sorry, that was more than two sentences. I hope it is a bit clearer now. Greg --0015175d0406e1970f04c4944677 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 11, 2012 at 4:10 PM, Ted Lemon=A0<Ted.Lemon@nominum.c= om>=A0wrote:
Okay, great. =A0 So, = the link-layer address for the interface being configured is being attached= to the packet that was sent on that interface, but somehow this doesn'= t satisfy your need. =A0 Can you describe (please, one or two sentences, no= t several paragraphs) under what real-world circumstances this would occur?=


<= /div>Okay, consider prefix-delegation, for example. =A0The requesting route= r will send an IA_PD request out the WAN interface to get a prefix which is= then allocated to the downstream/LAN interface. =A0Since the packet is sen= t via the WAN interface, I believe that the relay would insert the link-lay= er address of the WAN interface in the request, and thus the prefix would t= hen be "associated" with the WAN interface, whereas it is really = associated with the LAN interface. =A0So, this is how the interface being c= onfigured is NOT the interface on which the packet is sent. =A0Further, con= sider a requesting router with two distinct downstream/LAN interfaces. =A0T= he PD requests for both LAN interfaces would be sent via the WAN interface,= and thus the WAN's link-layer address will be inserted into the option= by the relay (or learnt by the server from layer 2). =A0An administrator m= ay wish to configure different prefixes and/or options for each LAN interfa= ce, but has no way to do identify them individually via the proposed mechan= ism.

Sorry, that was more than two sentences. =A0I hope it is a b= it clearer now.

Greg



=

--0015175d0406e1970f04c4944677-- From Ted.Lemon@nominum.com Wed Jul 11 14:26: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 D0A0811E80EE for ; Wed, 11 Jul 2012 14:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3WljVo9YKlO for ; Wed, 11 Jul 2012 14:26:09 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 01C7011E80EA for ; Wed, 11 Jul 2012 14:26:08 -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 DSNKT/3vkK8NmFJmlI58Jl/3ksPy7xk7JSRT@postini.com; Wed, 11 Jul 2012 14:26:40 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 AF5BC1B8313 for ; Wed, 11 Jul 2012 14:26:39 -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 A676D19005C; Wed, 11 Jul 2012 14:26:39 -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, 11 Jul 2012 14:26:39 -0700 From: Ted Lemon To: "A. Gregory Rabil" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNXf7+ZrBEJQCsAkSClbxFr7Ij65chuyaAgABMmoCAAARngIAABd6AgADzHYCAAN9HgIAABl6AgAD6h4CAABZcgIAAEOOAgAAEgoA= Date: Wed, 11 Jul 2012 21:26:38 +0000 Message-ID: <8EFF556D-7D3D-4594-B335-08DF3DA8EB9F@nominum.com> References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> <12EEF4CE-B85C-4542-AFF5-085CDE2ACFE5@nominum.com> <545EC59B-EEB6-44A1-9663-AC0BF6F0A412@nominum.com> <49A52050-7FCA-44E8-9130-EFE3979D7FC3@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: <34E08AB81D6E9A41B2DD11CED037086D@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Andre Kostur Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Wed, 11 Jul 2012 21:26:09 -0000 On Jul 11, 2012, at 5:10 PM, A. Gregory Rabil wrote: > Okay, consider prefix-delegation, for example. The requesting router wil= l send an IA_PD request out the WAN interface to get a prefix which is then= allocated to the downstream/LAN interface. Since the packet is sent via t= he WAN interface, I believe that the relay would insert the link-layer addr= ess of the WAN interface in the request, and thus the prefix would then be = "associated" with the WAN interface, whereas it is really associated with t= he LAN interface. So, this is how the interface being configured is NOT th= e interface on which the packet is sent. Further, consider a requesting ro= uter with two distinct downstream/LAN interfaces. The PD requests for both= LAN interfaces would be sent via the WAN interface, and thus the WAN's lin= k-layer address will be inserted into the option by the relay (or learnt by= the server from layer 2). An administrator may wish to configure differen= t prefixes and/or options for each LAN interface, but has no way to do iden= tify them individually via the proposed mechanism. So you're saying that we need the functionality because of a protocol featu= re that doesn't exist. Got it. From greg.rabil@jagornet.com Wed Jul 11 16:13: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 BB84821F853D for ; Wed, 11 Jul 2012 16:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WO3wa7M12gZO for ; Wed, 11 Jul 2012 16:13:36 -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 8289321F853B for ; Wed, 11 Jul 2012 16:13:35 -0700 (PDT) Received: by bkty7 with SMTP id y7so1448307bkt.31 for ; Wed, 11 Jul 2012 16:14: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=+AZ8qvEsMJSYPWbcCZGSxht333RMPBqtk3o7iEvUQpA=; b=DNXIJXTp+Cd+UAMpBDqq+7iEo3KHtJDPkyirV0gazJ2K17gMArzH6vWPiqg9UqX1QI aF7UzhUjMlR1gEySE9yIY1o5gaf6pADibenGiE3hzcfbRkT4SzznQ+U7bRmPY7B17azN IsYd/IIiUIBS0j3nrYwpUB9mtKO4bFmBc3xQ62mjfOEgb5sD/L6cOXsU3TFLl22qD6/k dDEO6SJZdxXAch56hW+hUV3hF4rJKIGjL34NdwNSw0RT+vrTkJ4HDmLcH7IAuA7Zdfpk 9dnsVWA0SkohjwmYxlUuSbaKvVMQy6jUwtBqsaamh4LZs1iiqCn31XPtucxFaWQbdJjV 93iQ== MIME-Version: 1.0 Received: by 10.204.157.22 with SMTP id z22mr24196764bkw.4.1342048446354; Wed, 11 Jul 2012 16:14:06 -0700 (PDT) Received: by 10.204.156.133 with HTTP; Wed, 11 Jul 2012 16:14:06 -0700 (PDT) In-Reply-To: <8EFF556D-7D3D-4594-B335-08DF3DA8EB9F@nominum.com> References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> <12EEF4CE-B85C-4542-AFF5-085CDE2ACFE5@nominum.com> <545EC59B-EEB6-44A1-9663-AC0BF6F0A412@nominum.com> <49A52050-7FCA-44E8-9130-EFE3979D7FC3@nominum.com> <8EFF556D-7D3D-4594-B335-08DF3DA8EB9F@nominum.com> Date: Wed, 11 Jul 2012 19:14:06 -0400 Message-ID: From: "A. Gregory Rabil" To: Ted Lemon Content-Type: multipart/alternative; boundary=0015175cd00eea970904c49600d8 X-Gm-Message-State: ALoCoQkNCSG61iqSq+gb/JoEqOd4vriKAs0SiN1049uZIrjczY2h13viuz+AXLx/fUUnwcyIwJvg Cc: "dhcwg@ietf.org" , Andre Kostur Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Wed, 11 Jul 2012 23:13:36 -0000 --0015175cd00eea970904c49600d8 Content-Type: text/plain; charset=ISO-8859-1 No. You asked for me to provide a scenario where the interface being configured is not the interface on which the packet is sent. I believe I have done that. The example was extended simply to demonstrate that we may also consider other uses for this option beyond the box you wish to put it in. But you are clearly not interested in a larger box. Got it. On Wed, Jul 11, 2012 at 5:26 PM, Ted Lemon wrote: > On Jul 11, 2012, at 5:10 PM, A. Gregory Rabil wrote: > > Okay, consider prefix-delegation, for example. The requesting router > will send an IA_PD request out the WAN interface to get a prefix which is > then allocated to the downstream/LAN interface. Since the packet is sent > via the WAN interface, I believe that the relay would insert the link-layer > address of the WAN interface in the request, and thus the prefix would then > be "associated" with the WAN interface, whereas it is really associated > with the LAN interface. So, this is how the interface being configured is > NOT the interface on which the packet is sent. Further, consider a > requesting router with two distinct downstream/LAN interfaces. The PD > requests for both LAN interfaces would be sent via the WAN interface, and > thus the WAN's link-layer address will be inserted into the option by the > relay (or learnt by the server from layer 2). An administrator may wish to > configure different prefixes and/or options for each LAN interface, but has > no way to do identify them individually via the proposed mechanism. > > So you're saying that we need the functionality because of a protocol > feature that doesn't exist. Got it. > > --0015175cd00eea970904c49600d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
No. =A0You asked for me to provide a scenario where the interface bein= g configured is not the interface on which the packet is sent. =A0I believe= I have done that. =A0The example was extended simply to demonstrate that w= e may also consider other uses for this option beyond the box you wish to p= ut it in. =A0But you are clearly not interested in a larger box. =A0Got it.=

On Wed, Jul 11, 2012 at 5:26 PM, Ted Le= mon <Ted.Lemon@nominum.com> wrote:
On Jul 11, 2012, at 5:10 PM, A. Gregory= Rabil wrote:
> Okay, consider prefix-delegation, for example. =A0The requesting route= r will send an IA_PD request out the WAN interface to get a prefix which is= then allocated to the downstream/LAN interface. =A0Since the packet is sen= t via the WAN interface, I believe that the relay would insert the link-lay= er address of the WAN interface in the request, and thus the prefix would t= hen be "associated" with the WAN interface, whereas it is really = associated with the LAN interface. =A0So, this is how the interface being c= onfigured is NOT the interface on which the packet is sent. =A0Further, con= sider a requesting router with two distinct downstream/LAN interfaces. =A0T= he PD requests for both LAN interfaces would be sent via the WAN interface,= and thus the WAN's link-layer address will be inserted into the option= by the relay (or learnt by the server from layer 2). =A0An administrator m= ay wish to configure different prefixes and/or options for each LAN interfa= ce, but has no way to do identify them individually via the proposed mechan= ism.

So you're saying that we need the functionality because of a prot= ocol feature that doesn't exist. =A0 Got it.


--0015175cd00eea970904c49600d8-- From akostur@incognito.com Wed Jul 11 16:25: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 AF24E11E80E6 for ; Wed, 11 Jul 2012 16:25:58 -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=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRXy4fdzqAd8 for ; Wed, 11 Jul 2012 16:25:57 -0700 (PDT) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by ietfa.amsl.com (Postfix) with SMTP id 59DFB11E80BE for ; Wed, 11 Jul 2012 16:25:57 -0700 (PDT) Received: from mail-lb0-f175.google.com ([209.85.217.175]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKT/4LpKId08iQKlaY+4PPzN191tR1Iojs@postini.com; Wed, 11 Jul 2012 16:26:29 PDT Received: by lbol5 with SMTP id l5so2647360lbo.20 for ; Wed, 11 Jul 2012 16:26:27 -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=/zcc9fKlW0xcSfpeQYY35WCvc5gHPZQ0+SR1O9O2TtY=; b=O1NmuUVA8fg1QRae+yS+tCl1sM/qAenn2uxCKqZ87o2WlOhwK6FSB19Jss7KNuDECB iAYONEsKgpOYEuwKwBNKkTjjdgZXXdasj9VV6IuOwds400+Lzad3UwIAEJobqb/jH701 5DUOB+6FAkOR40KUxi5uN798l2SsWhSv6LlRF+vDMPSdxS7OSCUuFGAfkRjN50129K2c WDWBCFmsKLn2gq3NGmrKG9/KgI1Z1n+6FDESyUakh4EZ5RMmsbqTg1CISF9CFuDX6WRY /RHguXqdikBzi9O3tHh2OYVb4jd0Yy04Mt1pYVFclokLGtGnv/1LidXpull0gQROfqcS ZBSg== MIME-Version: 1.0 Received: by 10.112.99.98 with SMTP id ep2mr45990lbb.45.1342049186931; Wed, 11 Jul 2012 16:26:26 -0700 (PDT) Received: by 10.112.40.228 with HTTP; Wed, 11 Jul 2012 16:26:26 -0700 (PDT) In-Reply-To: <07DA37D4-670E-407E-8610-4B0118541627@nominum.com> References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> <396DEDBA-E0DB-42FD-9076-787D50FCEE3E@nominum.com> <07DA37D4-670E-407E-8610-4B0118541627@nominum.com> Date: Wed, 11 Jul 2012 16:26:26 -0700 Message-ID: From: Andre Kostur To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlZOkQ8eZQEz44CRW2xNSNnN4sLKPA7VfLe4dJJNMUtPJvav1YogCwQp6e14wiNKTA6+Px7 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Wed, 11 Jul 2012 23:25:58 -0000 On Tue, Jul 10, 2012 at 8:17 AM, Ted Lemon wrote: > On Jul 10, 2012, at 10:52 AM, Andre Kostur wrote: >> Looking at the background of this draft, one of the justifications for >> the draft is "based on an identifier that is already used by that >> operator." > > How so? I don't recall this justification coming up in the working grou= p meeting in Paris. What I recall was an agreement that it would be nice = if there were a way for a DHCPv6 server to get the hardware address of the = client so that it could be correlated with the DHCPv4 client identifier. Whups... hadn't replied to this. How so?: Section 2, paragraph 2, third sentence. That was a quote from the draft. --=20 Andre Kostur From Ted.Lemon@nominum.com Wed Jul 11 16:50: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 3439711E80C9 for ; Wed, 11 Jul 2012 16:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqyTb00kJAkf for ; Wed, 11 Jul 2012 16:50:40 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 51CA711E80F8 for ; Wed, 11 Jul 2012 16:50:40 -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 DSNKT/4Rb5xT9r8iNCCTEwiMWmcUfo1EwuOF@postini.com; Wed, 11 Jul 2012 16:51:12 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 4125B1B831E for ; Wed, 11 Jul 2012 16:51: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 38F2919005C; Wed, 11 Jul 2012 16:51: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; Wed, 11 Jul 2012 16:51:11 -0700 From: Ted Lemon To: Andre Kostur Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNXf7+ZrBEJQCsAkSClbxFr7Ij65chuyaAgABMmoCAAARngIAABd6AgAAU0ACAAN/oAIAACdgAgAAG+ACAAhr8AIAABukA Date: Wed, 11 Jul 2012 23:51:10 +0000 Message-ID: <3FEB5BAA-FBD4-4223-B654-922720803271@nominum.com> References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> <396DEDBA-E0DB-42FD-9076-787D50FCEE3E@nominum.com> <07DA37D4-670E-407E-8610-4B0118541627@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_3FEB5BAAFBD44223B654922720803271nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Wed, 11 Jul 2012 23:50:42 -0000 --_000_3FEB5BAAFBD44223B654922720803271nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jul 11, 2012, at 7:26 PM, Andre Kostur wrote: Whups... hadn't replied to this. How so?: Section 2, paragraph 2, third sentence. That was a quote from the draft. The draft was in fact originally written with the intention of doing someth= ing like what you and Greg are talking about, but the consensus to adopt in= Paris was on the basis of a much more limited scope. We all understood (= I thought!) that trying to change the DUID, or provide something like a DHC= Pv4 chaddr that has the same semantics, was out of scope. Now it seems th= at a few participants are trying to pull that back in-scope. The problem = with this is twofold: one, I think it will create massive interoperability = problems. And two, I don't think it will ever make it to the IESG as a fi= nished draft. This is why I'm pushing back on the people who have been advocating re-expa= nding the scope of the draft to what the authors originally intended. I t= hought the authors had agreed to the more limited scope, since it achieves = their purpose. --_000_3FEB5BAAFBD44223B654922720803271nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <006E429FEBE061438F5C6F9C530D8DBF@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jul 11, 2012, at 7:26 PM, Andre Kostur wrote:
Whups... hadn't replied to this.   How so?:  Section 2, paragraph 2,=
third sentence.  That was a quote from the draft.

The draft was in fact originally written with the intention of doing s= omething like what you and Greg are talking about, but the consensus to ado= pt in Paris was on the basis of a much more limited scope.   We all un= derstood (I thought!) that trying to change the DUID, or provide something like a DHCPv4 chaddr that has the sa= me semantics, was out of scope.   Now it seems that a few participants= are trying to pull that back in-scope.   The problem with this is two= fold: one, I think it will create massive interoperability problems.   And two, I don't think it will ever make= it to the IESG as a finished draft.

This is why I'm pushing back on the people who have been advocating re= -expanding the scope of the draft to what the authors originally intended. =   I thought the authors had agreed to the more limited scope, since it= achieves their purpose.

--_000_3FEB5BAAFBD44223B654922720803271nominumcom_-- From akostur@incognito.com Wed Jul 11 17:34: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 AA37211E8176 for ; Wed, 11 Jul 2012 17:34:33 -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=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMu7AVJE9Kp6 for ; Wed, 11 Jul 2012 17:34:33 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with SMTP id A97E311E816D for ; Wed, 11 Jul 2012 17:34:32 -0700 (PDT) Received: from mail-lb0-f177.google.com ([209.85.217.177]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKT/4btwx6EnaMMW7rrcd+ptt66zQfblIz@postini.com; Wed, 11 Jul 2012 17:35:04 PDT Received: by lbbgg6 with SMTP id gg6so3170965lbb.22 for ; Wed, 11 Jul 2012 17:35:02 -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=TUd4yEM7tsH0BcFdhKRCF+N8P00lk0/Ey3FsNIlaZp0=; b=NyItcCPIadfnoSx3obR4kDJYG8+wYJgfBflCDfvOTMaV3LfoKkZ7wxWi3MZGFbnGzX XJzJ3scElRKib3iJ/Y5gVFu9tp5vIOwbiDCHOz+B7VllVD8NToUAcUYqIYk1SZeiXTDq lUP8ii7lh0FXju3khOGVmFKvxKd3JqotntQm9INF4d6K/cIpkTUuQgd8AWn6kbGj3+uS haGbIVspFdOZqxQfSSGYOphzR0d639wp+aFyF8p/MM4/CXIC2cuXjI3D45eMFLA1+P00 XL177Mnwvf6jj/bb999J1hWx3NWIdONQNE+RImRGL4VuP6bfB9RLSQtKn5hPis1qCJjC iB9A== MIME-Version: 1.0 Received: by 10.152.132.233 with SMTP id ox9mr50920567lab.25.1342053302284; Wed, 11 Jul 2012 17:35:02 -0700 (PDT) Received: by 10.112.40.228 with HTTP; Wed, 11 Jul 2012 17:35:02 -0700 (PDT) In-Reply-To: <3FEB5BAA-FBD4-4223-B654-922720803271@nominum.com> References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> <396DEDBA-E0DB-42FD-9076-787D50FCEE3E@nominum.com> <07DA37D4-670E-407E-8610-4B0118541627@nominum.com> <3FEB5BAA-FBD4-4223-B654-922720803271@nominum.com> Date: Wed, 11 Jul 2012 17:35:02 -0700 Message-ID: From: Andre Kostur To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlut6WvmPQjSj5k4mSgzTYTqBmvFfFQ4plaiGk9VTpMTrLyC5aMUspYY6V5AIPP0xKYl+gy Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Thu, 12 Jul 2012 00:34:33 -0000 On Wed, Jul 11, 2012 at 4:51 PM, Ted Lemon wrote: > On Jul 11, 2012, at 7:26 PM, Andre Kostur wrote: > > Whups... hadn't replied to this. How so?: Section 2, paragraph 2, > third sentence. That was a quote from the draft. > > > The draft was in fact originally written with the intention of doing > something like what you and Greg are talking about, but the consensus to > adopt in Paris was on the basis of a much more limited scope. We all > understood (I thought!) that trying to change the DUID, or provide something > like a DHCPv4 chaddr that has the same semantics, was out of scope. Now it > seems that a few participants are trying to pull that back in-scope. The > problem with this is twofold: one, I think it will create massive > interoperability problems. And two, I don't think it will ever make it to > the IESG as a finished draft. > > This is why I'm pushing back on the people who have been advocating > re-expanding the scope of the draft to what the authors originally intended. > I thought the authors had agreed to the more limited scope, since it > achieves their purpose. I wasn't in Paris, but will be in Vancouver since you're all coming to my backyard. Paris was in March, but this draft was published in July without the Paris input? -- Andre Kostur From Ted.Lemon@nominum.com Wed Jul 11 20: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 F15A111E8111 for ; Wed, 11 Jul 2012 20:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.57 X-Spam-Level: X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvwDw56+MXiP for ; Wed, 11 Jul 2012 20:44:16 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2985B21F8474 for ; Wed, 11 Jul 2012 20:44:16 -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 DSNKT/5IMOjFi0VvtvlerN1qnPSAptvuuu9P@postini.com; Wed, 11 Jul 2012 20:44: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 A8B9A1B8315 for ; Wed, 11 Jul 2012 20:44: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 9A4CB19005C; Wed, 11 Jul 2012 20:44: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; Wed, 11 Jul 2012 20:44:41 -0700 From: Ted Lemon To: Andre Kostur Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNXf7+ZrBEJQCsAkSClbxFr7Ij65chuyaAgABMmoCAAARngIAABd6AgAAU0ACAAN/oAIAACdgAgAAG+ACAAhr8AIAABukAgAAMQQCAADT8AA== Date: Thu, 12 Jul 2012 03:44:40 +0000 Message-ID: <5EB39793-A4C1-4AA9-AF2C-27905959A757@nominum.com> References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> <396DEDBA-E0DB-42FD-9076-787D50FCEE3E@nominum.com> <07DA37D4-670E-407E-8610-4B0118541627@nominum.com> <3FEB5BAA-FBD4-4223-B654-922720803271@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_5EB39793A4C14AA9AF2C27905959A757nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Thu, 12 Jul 2012 03:44:17 -0000 --_000_5EB39793A4C14AA9AF2C27905959A757nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jul 11, 2012, at 8:35 PM, Andre Kostur wrote: I wasn't in Paris, but will be in Vancouver since you're all coming to my backyard. Paris was in March, but this draft was published in July without the Paris input? I assumed that it was just publication as a working group draft without an = update; was I mistaken? --_000_5EB39793A4C14AA9AF2C27905959A757nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jul 11, 2012, at 8:35 PM, Andre Kostur wrote:
I wasn't in Paris, but will be in Vancouver since you're all coming to
my backyard.  Paris was in March, but this draft was published in July=
without the Paris input?

I assumed that it was just publication as a working group draft withou= t an update; was I mistaken?

--_000_5EB39793A4C14AA9AF2C27905959A757nominumcom_-- From ghalwasi@cisco.com Wed Jul 11 20:45: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 0F8DE21F8526 for ; Wed, 11 Jul 2012 20:45:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DB6gjiD4Vetk for ; Wed, 11 Jul 2012 20:45: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 F186021F8474 for ; Wed, 11 Jul 2012 20:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=6253; q=dns/txt; s=iport; t=1342064782; x=1343274382; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hy6txcfkQFQ3/B6z0DNJLc8Gs/ro+UT3kE++pyFm1jg=; b=hwxVnuOeegGYsGUDacnkt0LSLS/HGYCkBt8La/BSREicc7IHVHvgd9P9 EIh3Ic4IH9wclIDO7XJE1AgPpF1OoUcXXKeFTPa0A4NHfbAWdGSSwTDlw R8pZe26HXoMuHGD7yxaSujJ83XLErM1lRzR6YGDK86Pv1NuLkHn2gt4Il M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFVH/k+tJV2Y/2dsb2JhbABFgkq1NIEHgiABAQEDARIBGkwFCwIBCBEEAQELHQcyFAkIAgQBDQUIGodlBp1poCWLQIUOYAOjWoFmgl8 X-IronPort-AV: E=Sophos;i="4.77,571,1336348800"; d="scan'208,217";a="101062280" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 12 Jul 2012 03:46:22 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6C3kLml005166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jul 2012 03:46:21 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.153]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 22:46:21 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Ted Lemon , Andre Kostur Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNX+CzqKVTYY96YEKbaruIx8bgRpclAbqA Date: Thu, 12 Jul 2012 03:46:21 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB071456@xmb-aln-x06.cisco.com> References: <4B2C9E20-D925-4D9A-B9B8-AAE396379AB7@nominum.com> <2411883C-9E45-454E-A3B7-3D366D47FC81@nominum.com> <396DEDBA-E0DB-42FD-9076-787D50FCEE3E@nominum.com> <07DA37D4-670E-407E-8610-4B0118541627@nominum.com> <3FEB5BAA-FBD4-4223-B654-922720803271@nominum.com> <5EB39793-A4C1-4AA9-AF2C-27905959A757@nominum.com> In-Reply-To: <5EB39793-A4C1-4AA9-AF2C-27905959A757@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.65.189] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19032.004 x-tm-as-result: No--42.421500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_90903C21C73202418A48BFBE80AEE5EB071456xmbalnx06ciscocom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Thu, 12 Jul 2012 03:45:51 -0000 --_000_90903C21C73202418A48BFBE80AEE5EB071456xmbalnx06ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Ted and All, > I assumed that it was just publication as a working group draft without a= n update; was I mistaken? [Gaurav] Yes, you are right. It was just a publication as WG draft without = an update. Thanks, Gaurav From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Thursday, July 12, 2012 9:15 AM To: Andre Kostur Cc: dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-ad= dr-opt-00.txt On Jul 11, 2012, at 8:35 PM, Andre Kostur wrote: I wasn't in Paris, but will be in Vancouver since you're all coming to my backyard. Paris was in March, but this draft was published in July without the Paris input? I assumed that it was just publication as a working group draft without an = update; was I mistaken? --_000_90903C21C73202418A48BFBE80AEE5EB071456xmbalnx06ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Ted and All,

 <= /p>

> I assumed tha= t it was just publication as a working group draft without an update; was I= mistaken?

[Gaurav] Yes, you are rig= ht. It was just a publication as WG draft without an update.

 <= /p>

Thanks,=

Gaurav<= /p>

 <= /p>

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon
Sent: Thursday, July 12, 2012 9:15 AM
To: Andre Kostur
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-l= ayer-addr-opt-00.txt

 

On Jul 11, 2012, at 8:35 PM, Andre Kostur wrote:

I wa= sn't in Paris, but will be in Vancouver since you're all coming to
my backyard.  Paris was in March, but= this draft was published in July
without the Paris input?

 

I assumed that it was just publication as a working = group draft without an update; was I mistaken?

 

--_000_90903C21C73202418A48BFBE80AEE5EB071456xmbalnx06ciscocom_-- From dankney@network1.net Thu Jul 12 05:56: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 5148321F87D6 for ; Thu, 12 Jul 2012 05:56:43 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iI3I6m30Rzdb for ; Thu, 12 Jul 2012 05:56:42 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7735121F87CF for ; Thu, 12 Jul 2012 05:56:42 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 923B3540E15; Thu, 12 Jul 2012 08:57:14 -0400 (EDT) Date: Thu, 12 Jul 2012 08:57:14 -0400 (EDT) From: perl-list To: "A. Gregory Rabil" Message-ID: <521202936.30106.1342097834494.JavaMail.root@network1.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_30105_376322993.1342097834493" X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC20 (Mac)/7.2.0_GA_2669) Cc: dhcwg@ietf.org, Andre Kostur , Ted Lemon Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Thu, 12 Jul 2012 12:56:43 -0000 ------=_Part_30105_376322993.1342097834493 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Greg, What you say in theory is interesting and could pose a problem. In practice, however, it seems that prefix delegation and WAN configuration happen simultaneously in the same exchange within the same packet. Also, as this draft is intended to help correlation between DHCPv4 and DHCPv6 using the (hardware / link layer / MAC - whatever we are calling it these days) address, your argument about downstream interfaces that would not be known in DHCPv4 space is irrelevant. ----- Original Message ----- > From: "A. Gregory Rabil" > To: "Ted Lemon" > Cc: dhcwg@ietf.org, "Andre Kostur" > Sent: Wednesday, July 11, 2012 5:10:29 PM > Subject: Re: [dhcwg] I-D Action: > draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt > On Wed, Jul 11, 2012 at 4:10 PM, Ted Lemon < Ted.Lemon@nominum.com > > wrote: > > Okay, great. So, the link-layer address for the interface being > > configured is being attached to the packet that was sent on that > > interface, but somehow this doesn't satisfy your need. Can you > > describe (please, one or two sentences, not several paragraphs) > > under what real-world circumstances this would occur? > > Okay, consider prefix-delegation, for example. The requesting router > will send an IA_PD request out the WAN interface to get a prefix > which is then allocated to the downstream/LAN interface. Since the > packet is sent via the WAN interface, I believe that the relay would > insert the link-layer address of the WAN interface in the request, > and thus the prefix would then be "associated" with the WAN > interface, whereas it is really associated with the LAN interface. > So, this is how the interface being configured is NOT the interface > on which the packet is sent. Further, consider a requesting router > with two distinct downstream/LAN interfaces. The PD requests for > both LAN interfaces would be sent via the WAN interface, and thus > the WAN's link-layer address will be inserted into the option by the > relay (or learnt by the server from layer 2). An administrator may > wish to configure different prefixes and/or options for each LAN > interface, but has no way to do identify them individually via the > proposed mechanism. > Sorry, that was more than two sentences. I hope it is a bit clearer > now. > Greg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg ------=_Part_30105_376322993.1342097834493 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'>

What you say in theory is inte= resting and could pose a problem.  In practice, however, it seems that= prefix delegation and WAN configuration happen simultaneously in the same = exchange within the same packet.  Also, as this draft is intended to h= elp correlation between DHCPv4 and DHCPv6 using the (hardware / l= ink layer / MAC - whatever we are calling it these days) address, your argu= ment about downstream interfaces that would not be known in DHCPv4 space is= irrelevant.  

From: = "A. Gregory Rabil" <greg.rabil@jagornet.com>
To: "Ted Lemon= " <Ted.Lemon@nominum.com>
Cc: dhcwg@ietf.org, "Andre Kostur= " <akostur@incognito.com>
Sent: Wednesday, July 11, 2012 5:= 10:29 PM
Subject: Re: [dhcwg] I-D Action:    =     draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00= .txt

On Wed, Jul 11, 2012 at 4:10 PM, Ted Lemon <Ted= .Lemon@nominum.com> wrote:
Okay, great.   S= o, the link-layer address for the interface being configured is being attac= hed to the packet that was sent on that interface, but somehow this doesn't= satisfy your need.   Can you describe (please, one or two sentences, = not several paragraphs) under what real-world circumstances this would occu= r?


<= /div>Okay, consider prefix-delegation, for example.  The requesting ro= uter will send an IA_PD request out the WAN interface to get a prefix which= is then allocated to the downstream/LAN interface.  Since the packet = is sent via the WAN interface, I believe that the relay would insert the li= nk-layer address of the WAN interface in the request, and thus the prefix w= ould then be "associated" with the WAN interface, whereas it is really asso= ciated with the LAN interface.  So, this is how the interface being co= nfigured is NOT the interface on which the packet is sent.  Further, c= onsider a requesting router with two distinct downstream/LAN interfaces. &n= bsp;The PD requests for both LAN interfaces would be sent via the WAN inter= face, and thus the WAN's link-layer address will be inserted into the optio= n by the relay (or learnt by the server from layer 2).  An administrat= or may wish to configure different prefixes and/or options for each LAN int= erface, but has no way to do identify them individually via the proposed me= chanism.

Sorry, that was more than two sentences.  I hope it is = a bit clearer now.

Greg


<= br>


_______________________________________________
dhcwg mailing listdhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

------=_Part_30105_376322993.1342097834493-- From linux@thehobsons.co.uk Thu Jul 12 07:00: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 5441C21F882B for ; Thu, 12 Jul 2012 07:00:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqU+t0vt4tdu for ; Thu, 12 Jul 2012 07:00:40 -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 33F0B21F87BC for ; Thu, 12 Jul 2012 07:00:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id C507910401C for ; Thu, 12 Jul 2012 15:01:11 +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 qJqQGsX7wj86 for ; Thu, 12 Jul 2012 15:01:11 +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 1180B10401A for ; Thu, 12 Jul 2012 15:01:10 +0100 (BST) Mime-Version: 1.0 Message-Id: In-Reply-To: <521202936.30106.1342097834494.JavaMail.root@network1.net> References: <521202936.30106.1342097834494.JavaMail.root@network1.net> Date: Thu, 12 Jul 2012 15:00:47 +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-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: Thu, 12 Jul 2012 14:00:41 -0000 perl-list wrote: >>Okay, consider prefix-delegation, for example. ... >What you say in theory is interesting and could pose a problem. In >practice, however, it seems that prefix delegation and WAN >configuration happen simultaneously in the same exchange within the >same packet. Also, as this draft is intended to >help correlation between DHCPv4 and DHCPv6 using the (hardware / >link layer / MAC - whatever we are calling it these days) address, >your argument about downstream interfaces that would not be known in >DHCPv4 space is irrelevant. I agree, and what's more I can't really see how it's an upstream server's job to configure downstream interfaces on a router. In the general case where PD is likely, it's going to be an ISP delivering a prefix to a customer's router - what the customer wants to do with that isn't really anything to do with the ISP. All the ISP needs to do is a) configure the customer's WAN, and b) provide them with a PD. While I could see some situations where going further might be useful, I could only see it working in a managed environment (eg ISP supplied routers, I'm thinking something similar to ISP supplied cable modems). I'd see that sort of situation managed by 'private' extensions/options which could be agreed between the client and server - possibly as an industry segment standard vendor option space. I'm inclined to agree with Ted - keep it simple so it can actually get passed ! -- 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 akostur@incognito.com Thu Jul 12 07:17: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 360EA21F8778 for ; Thu, 12 Jul 2012 07:17:38 -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=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b4ikvUFTm41 for ; Thu, 12 Jul 2012 07:17:37 -0700 (PDT) Received: from na3sys010aog106.obsmtp.com (na3sys010aog106.obsmtp.com [74.125.245.80]) by ietfa.amsl.com (Postfix) with SMTP id 319B021F87AD for ; Thu, 12 Jul 2012 07:17:37 -0700 (PDT) Received: from mail-lb0-f169.google.com ([209.85.217.169]) (using TLSv1) by na3sys010aob106.postini.com ([74.125.244.12]) with SMTP ID DSNKT/7colXDko8sYpvSSfEtoNdw6mlx6HY9@postini.com; Thu, 12 Jul 2012 07:18:11 PDT Received: by lbjn8 with SMTP id n8so3916700lbj.0 for ; Thu, 12 Jul 2012 07:18:08 -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=Wfetr68+aympjer5N66jSU1L4tCJtR/0fbHbUvt/K9Q=; b=awFgMU3L9xB3kpRZ7pP/yvAAHRZ6jMnWmQLyspZvHOU+80Y2m7gFsosFIBsOO6Dn/h 2ctQIb07HlK+cts8Cm+RFnRRhIJ+7DSv8BYVynQ2ajDhrXL882HBAF0vRrf8AsfDPlZF MpC09g1BC4hJm5xHWRnV9rcVTNWxm7cqGmo8FCBj1mdox7k9EXL59WuOjudlnDN7L3P2 tJRdSjUO3mg22UqdOtWbupQKaPYR3bw9nqlMMjd0YbWvHJMccjFnqYcK+aV2RsSBGw38 Xtx8ccAheWw7Bws1tLFMJd/CoBa01hBwmZKSYGOLKxgna1XWj5FNuXSQLmGCBZtA1ctN 4nyA== MIME-Version: 1.0 Received: by 10.152.144.103 with SMTP id sl7mr39051415lab.37.1342102688564; Thu, 12 Jul 2012 07:18:08 -0700 (PDT) Received: by 10.112.40.228 with HTTP; Thu, 12 Jul 2012 07:18:08 -0700 (PDT) In-Reply-To: <521202936.30106.1342097834494.JavaMail.root@network1.net> References: <521202936.30106.1342097834494.JavaMail.root@network1.net> Date: Thu, 12 Jul 2012 07:18:08 -0700 Message-ID: From: Andre Kostur To: perl-list Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkDspXz9wGa4mAqQ5Ff7jKLWzzYRd0MZAl2efoQInPE1TndiEQvGjS7xVnukaqihI+R0sLv Cc: dhcwg@ietf.org, Ted Lemon Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Thu, 12 Jul 2012 14:17:38 -0000 On Thu, Jul 12, 2012 at 5:57 AM, perl-list wrote: > Also, as > this draft is intended to help correlation between DHCPv4 and DHCPv6 using > the (hardware / link layer / MAC - whatever we are calling it these days) > address, your argument about downstream interfaces that would not be known > in DHCPv4 space is irrelevant. Changing gears for a second... if the point behind this draft is to correlate DHCPv4 and DHCPv6 leases, is the MAC address sufficient? Consider the case of any device using the DHCPv4 client identifier to distinguish between multiple leases on the same computer. (One client that I know does this is Microsoft RRAS servers.). Or any case where there is no MAC address to speak of (wasn't there something like DHCP over Infiniband which mandated the use of Client ID since there was no MAC address?). Or are we writing these cases as "we don't care about these edge problems, using the MAC address will solve the vast majority of the cases"? -- Andre Kostur From dankney@network1.net Thu Jul 12 08:11: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 4C0A221F87CC for ; Thu, 12 Jul 2012 08:11:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eVIa7wH8ZLd for ; Thu, 12 Jul 2012 08:11:22 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2D83B21F87BA for ; Thu, 12 Jul 2012 08:11:22 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 980425410E0; Thu, 12 Jul 2012 11:11:52 -0400 (EDT) Date: Thu, 12 Jul 2012 11:11:52 -0400 (EDT) From: perl-list To: Andre Kostur Message-ID: <1879457686.30777.1342105912528.JavaMail.root@network1.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_30776_366693047.1342105912527" X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC20 (Mac)/7.2.0_GA_2669) Cc: dhcwg@ietf.org, Ted Lemon Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Thu, 12 Jul 2012 15:11:28 -0000 ------=_Part_30776_366693047.1342105912527 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit This is done with ISPs in mind. ISPs typically use the mac address to maintain customer records as it is the most consistent method of identifying a device on an IPv4 / DHCPv4 network. RRAS or other router types internal interfaces are typically ignored in the IPv4 space and are privately addressed from the customer perspective. Hence, the ISP neither needs nor wants knowledge of those interfaces. In the IPv6 / DHCPv6 world, one would assume that the PD to the internal interfaces would need to be correlated with the external / WAN interface of the customer equipment. The mac address of the WAN can serve the needs here too. ----- Original Message ----- > From: "Andre Kostur" > To: "perl-list" > Cc: "A. Gregory Rabil" , dhcwg@ietf.org, > "Ted Lemon" > Sent: Thursday, July 12, 2012 10:18:08 AM > Subject: Re: [dhcwg] I-D Action: > draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt > On Thu, Jul 12, 2012 at 5:57 AM, perl-list > wrote: > > Also, as > > this draft is intended to help correlation between DHCPv4 and > > DHCPv6 using > > the (hardware / link layer / MAC - whatever we are calling it these > > days) > > address, your argument about downstream interfaces that would not > > be known > > in DHCPv4 space is irrelevant. > Changing gears for a second... if the point behind this draft is to > correlate DHCPv4 and DHCPv6 leases, is the MAC address sufficient? > Consider the case of any device using the DHCPv4 client identifier to > distinguish between multiple leases on the same computer. (One client > that I know does this is Microsoft RRAS servers.). Or any case where > there is no MAC address to speak of (wasn't there something like DHCP > over Infiniband which mandated the use of Client ID since there was > no > MAC address?). > Or are we writing these cases as "we don't care about these edge > problems, using the MAC address will solve the vast majority of the > cases"? > -- > Andre Kostur ------=_Part_30776_366693047.1342105912527 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'>
This is done with ISPs in mind.  ISPs typically use t= he mac address to maintain customer records as it is the most consistent me= thod of identifying a device on an IPv4 / DHCPv4 network.  RRAS or oth= er router types internal interfaces are typically ignored in the IPv4 space= and are privately addressed from the customer perspective.  Hence, th= e ISP neither needs nor wants knowledge of those interfaces.  In the I= Pv6 / DHCPv6 world, one would assume that the PD to the internal interfaces= would need to be correlated with the external / WAN interface of the custo= mer equipment.  The mac address of the WAN can serve the needs here to= o.  

From: "Andre Kostur" <akostur@incogn= ito.com>
To: "perl-list" <perl-list@network1.net>
= Cc: "A. Gregory Rabil" <greg.rabil@jagornet.com>, dhcwg@ietf.org,= "Ted Lemon" <Ted.Lemon@nominum.com>
Sent: Thursday, July 1= 2, 2012 10:18:08 AM
Subject: Re: [dhcwg] I-D Action: draft-ietf-d= hc-dhcpv6-client-link-layer-addr-opt-00.txt

On Thu, Jul 12, 2012 at = 5:57 AM, perl-list <perl-list@network1.net> wrote:

> Also, = as
> this draft is intended to help correlation between DHCPv4 and DH= CPv6 using
> the (hardware / link layer / MAC - whatever we are calli= ng it these days)
> address, your argument about downstream interface= s that would not be known
> in DHCPv4 space is irrelevant.

Cha= nging gears for a second... if the point behind this draft is to
correla= te DHCPv4 and DHCPv6 leases, is the MAC address sufficient?
Consider the= case of any device using the DHCPv4 client identifier to
distinguish be= tween multiple leases on the same computer.  (One client
that I kno= w does this is Microsoft RRAS servers.).  Or any case where
there i= s no MAC address to speak of (wasn't there something like DHCP
over Infi= niband which mandated the use of Client ID since there was no
MAC addres= s?).

Or are we writing these cases as "we don't care about these edg= e
problems, using the MAC address will solve the vast majority of thecases"?

--
Andre Kostur


------=_Part_30776_366693047.1342105912527-- From Ted.Lemon@nominum.com Thu Jul 12 09:25: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 7C60321F870A for ; Thu, 12 Jul 2012 09:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.571 X-Spam-Level: X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6qLyhCtrPED for ; Thu, 12 Jul 2012 09:25:49 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id AC9D321F86EE for ; Thu, 12 Jul 2012 09:25:43 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKT/76qds2mBaMUh5tTybKgpGDoHOoEmUQ@postini.com; Thu, 12 Jul 2012 09:26: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 77BEF1B82BF for ; Thu, 12 Jul 2012 09:26:16 -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 6D60419005C; Thu, 12 Jul 2012 09:26:16 -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, 12 Jul 2012 09:26:16 -0700 From: Ted Lemon To: Andre Kostur Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNYDkrPoA8vAjQ6kS5Vbap9TjVqZcmSwOA Date: Thu, 12 Jul 2012 16:26:16 +0000 Message-ID: References: <521202936.30106.1342097834494.JavaMail.root@network1.net> 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_C35F21D5C13A4825B4418B737E73F831nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Thu, 12 Jul 2012 16:25:49 -0000 --_000_C35F21D5C13A4825B4418B737E73F831nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jul 12, 2012, at 10:18 AM, Andre Kostur wrote: Changing gears for a second... if the point behind this draft is to correlate DHCPv4 and DHCPv6 leases, is the MAC address sufficient? Consider the case of any device using the DHCPv4 client identifier to distinguish between multiple leases on the same computer. This shouldn't be a problem, because even if the client sends a client-iden= tifier, it still has to send chaddr. --_000_C35F21D5C13A4825B4418B737E73F831nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jul 12, 2012, at 10:18 AM, Andre Kostur wrote:
Changing gears for a second... if the point behind this draft is to
correlate DHCPv4 and DHCPv6 leases, is the MAC address sufficient?
Consider the case of any device using the DHCPv4 client identifier to
distinguish between multiple leases on the same computer.

This shouldn't be a problem, because even if the client sends a client= -identifier, it still has to send chaddr.

--_000_C35F21D5C13A4825B4418B737E73F831nominumcom_-- From akostur@incognito.com Thu Jul 12 09:38: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 55DF621F865C for ; Thu, 12 Jul 2012 09:38:42 -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=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RXPJJxgHFzs for ; Thu, 12 Jul 2012 09:38:41 -0700 (PDT) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by ietfa.amsl.com (Postfix) with SMTP id 5522B21F8656 for ; Thu, 12 Jul 2012 09:38:41 -0700 (PDT) Received: from mail-lb0-f181.google.com ([209.85.217.181]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKT/79spSQSZYlxKnjhnzrOQLOtOcuc21y@postini.com; Thu, 12 Jul 2012 09:39:15 PDT Received: by lbbgk8 with SMTP id gk8so3630990lbb.12 for ; Thu, 12 Jul 2012 09:39:13 -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=ojetZqGAwDmF/sfclvV9FrO+P3wh8ZGPYuXE7+QKOHE=; b=laFZrVPXghb8XD/35Rd1cwnd1v7QkyNFt7pVUVC+HUaal8g54ZJODaD0+p5qGwrIUG 96vMCimq4ffiBDa7dCfXxNTSN4antNWvUTYgeWyHZWx1qPRGc3VM4PgXvhjyWiusXr7a dMzfsbmPpfnc7dOEQuSVK9xJKmkEMDn2D7Y4hdeEIhjA+aa7KapPf0QdpTky+WVhXi94 OIs/AWlLpIWZImsAOoAt0gSn2kBDP/awSRXIfPH2CqR/DfOo9kfuBHZ7mQXKW9shoTgP jtNI2T6j3PVDIXE2QHtZsIV70h/cLbRsjc1LhNhlBD/+Ay6c4X83zLsGYTbJfbJllEb7 X2eA== MIME-Version: 1.0 Received: by 10.112.83.136 with SMTP id q8mr1418731lby.60.1342111153073; Thu, 12 Jul 2012 09:39:13 -0700 (PDT) Received: by 10.112.40.228 with HTTP; Thu, 12 Jul 2012 09:39:12 -0700 (PDT) In-Reply-To: References: <521202936.30106.1342097834494.JavaMail.root@network1.net> Date: Thu, 12 Jul 2012 09:39:12 -0700 Message-ID: From: Andre Kostur To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlEFRmFwsvxg5ccV0aY1/u9ybIC7XRhKfAdp5HevOL3amImePRbN1wm98sf5AjnlxSpFfWu Cc: "" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Thu, 12 Jul 2012 16:38:42 -0000 On Thu, Jul 12, 2012 at 9:26 AM, Ted Lemon wrote: > On Jul 12, 2012, at 10:18 AM, Andre Kostur wrote: > >> Changing gears for a second... if the point behind this draft is to >> correlate DHCPv4 and DHCPv6 leases, is the MAC address sufficient? >> Consider the case of any device using the DHCPv4 client identifier to >> distinguish between multiple leases on the same computer. > > This shouldn't be a problem, because even if the client sends a > client-identifier, it still has to send chaddr. Yes, you'll likely have a chaddr, but you no longer know which DHCPv4 lease that the DHCPv6 transaction corresponds to. You may have dozens of DHCPv4 leases, all with the same CHADDR. -- Andre Kostur From dankney@network1.net Thu Jul 12 11:17: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 A538811E80D3 for ; Thu, 12 Jul 2012 11:17:40 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpomyk+j1jo6 for ; Thu, 12 Jul 2012 11:17:39 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id A58A911E80D1 for ; Thu, 12 Jul 2012 11:17:39 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id A0D775410F4; Thu, 12 Jul 2012 14:18:12 -0400 (EDT) Date: Thu, 12 Jul 2012 14:18:12 -0400 (EDT) From: perl-list To: Andre Kostur Message-ID: <459368309.31749.1342117092540.JavaMail.root@network1.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_31748_1862065720.1342117092539" X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC20 (Mac)/7.2.0_GA_2669) Cc: dhcwg , Ted Lemon Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Thu, 12 Jul 2012 18:17:40 -0000 ------=_Part_31748_1862065720.1342117092539 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Its ok tho - in an ISP situation - you want to associate leases to a customer - you may or may not care how many of them you have. What you do care about is you know who they belong to. ----- Original Message ----- > From: "Andre Kostur" > To: "Ted Lemon" > Cc: "perl-list" , "A. Gregory Rabil" > , "" > Sent: Thursday, July 12, 2012 12:39:12 PM > Subject: Re: [dhcwg] I-D Action: > draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt > On Thu, Jul 12, 2012 at 9:26 AM, Ted Lemon > wrote: > > On Jul 12, 2012, at 10:18 AM, Andre Kostur wrote: > > > >> Changing gears for a second... if the point behind this draft is > >> to > >> correlate DHCPv4 and DHCPv6 leases, is the MAC address sufficient? > >> Consider the case of any device using the DHCPv4 client identifier > >> to > >> distinguish between multiple leases on the same computer. > > > > This shouldn't be a problem, because even if the client sends a > > client-identifier, it still has to send chaddr. > Yes, you'll likely have a chaddr, but you no longer know which DHCPv4 > lease that the DHCPv6 transaction corresponds to. You may have dozens > of DHCPv4 leases, all with the same CHADDR. > -- > Andre Kostur ------=_Part_31748_1862065720.1342117092539 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'>
Its ok tho - in an ISP situation - you want to associate l= eases to a customer - you may or may not care how many of them you have. &n= bsp;What you do care about is you know who they belong to.

From: "Andre Kostur" <akostur@incognito.com>
To: "Ted Lemon" <Ted.Lemon@nominum.com>
Cc: "perl-list" <pe= rl-list@network1.net>, "A. Gregory Rabil" <greg.rabil@jagornet.com>= ;, "<dhcwg@ietf.org>" <dhcwg@ietf.org>
Sent: Thursday= , July 12, 2012 12:39:12 PM
Subject: Re: [dhcwg] I-D Action: draf= t-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt

On Thu, Jul 12, = 2012 at 9:26 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
> On = Jul 12, 2012, at 10:18 AM, Andre Kostur wrote:
>
>> Changing= gears for a second... if the point behind this draft is to
>> cor= relate DHCPv4 and DHCPv6 leases, is the MAC address sufficient?
>>= Consider the case of any device using the DHCPv4 client identifier to
&= gt;> distinguish between multiple leases on the same computer.
>> This shouldn't be a problem, because even if the client sends a
&= gt; client-identifier, it still has to send chaddr.

Yes, you'll like= ly have a chaddr, but you no longer know which DHCPv4
lease that the DHC= Pv6 transaction corresponds to.  You may have dozens
of DHCPv4 leas= es, all with the same CHADDR.


--
Andre Kostur


------=_Part_31748_1862065720.1342117092539-- From marccp@srttel.com Thu Jul 12 12:29: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 1F70F21F855F for ; Thu, 12 Jul 2012 12:29:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsCw1wy1eqXs for ; Thu, 12 Jul 2012 12:29:53 -0700 (PDT) Received: from mail.srttel.com (mail.srttel.com [216.221.96.218]) by ietfa.amsl.com (Postfix) with ESMTP id 494AA21F855A for ; Thu, 12 Jul 2012 12:29:53 -0700 (PDT) Received: from srtdom-MTA by mail.srttel.com with Novell_GroupWise; Thu, 12 Jul 2012 14:30:26 -0500 Message-Id: <4FFEDF70.39E4.004A.0@srttel.com> X-Mailer: Novell GroupWise Internet Agent 7.0.3 Date: Thu, 12 Jul 2012 14:30:17 -0500 From: "Marc Perea" To: References: In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part240A99D9.0__=" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Thu, 12 Jul 2012 19:29:54 -0000 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part240A99D9.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable While true that the primary key of the DHCP server lease would be client = id, in the cases that this draft was intended to support the MAC is a = known indentifier readily printed on the outside of ethernet packaging and = on labels while hardware is powered off and not connected to the network. = That MAC is directly tied to a client/customer in many operator environment= s, whether it sends client-id or not. From the operator perspective, we = don't really care whether the DHCProtocol uses client-id or MAC to index = it's internal database - what we are concerned with is matching a MAC in = existing non-DHCP database to a client/customer so that we can match a v4 = address and a v6 address (or several of each) to an individual client/custo= mer. The solution is intended to have the relay grab the MAC from the v6 = packet and add that as an option (hint) to the DHCP server. Such implementa= tion fills the need of the problem at hand, only requiring changes be made = to relay agents and DHCP servers. WG members represent most of the DHCPv6 = server software and relay hardware/software suppliers. In short, the WG is = both willing and able to effect the changes presented in the draft. =20 It sounds like you're contending that the DHCP server won't be able to = know which v4 =3D=3D which v6 client, and I don't know if that's a = problem. The problem this is intended to solve is that without supporting = the link layer address that is readily available before connecting a = device to a network or even turning it on, there is no way to set the = server in advance to hand out known addresses that are intended for a = specific client. For network access control and some tracking mechanisms, = this is a big problem. By adding MAC to the v6 exchange, operators are = able to match up MAC tracking databases, where MAC is an important index = that they care about. The fact that the DHCP server uses or doesn't use it = is irrelevant. =20 We've presented what use case caused this draft to come into existence, = and I understand the desire to make a protocol robust, but can you present = a use case that relates here so that I can understand what you'd additional= ly like to achieve? --=__Part240A99D9.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML
While true that the primary key of the DHCP server lease would be = client id, in the cases that this draft was intended to support the MAC is = a known indentifier readily printed on the outside of ethernet packaging = and on labels while hardware is powered off and not connected to the = network. That MAC is directly tied to a client/customer in many operator = environments, whether it sends client-id or not. From the operator = perspective, we don't really care whether the DHCProtocol uses client-id = or MAC to index it's internal database - what we are concerned with is = matching a MAC in existing non-DHCP database to a client/cus= tomer so that we can match a v4 address and a v6 address (or several of = each) to an individual client/customer. The solution is intended to have = the relay grab the MAC from the v6 packet and add that as an option (hint) = to the DHCP server. Such implementation fills the need of the problem at = hand, only requiring changes be made to relay agents and DHCP servers. WG = members represent most of the DHCPv6 server software and relay hardware/sof= tware suppliers. In short, the WG is both willing and able to effect the = changes presented in the draft.
 
It sounds like you're contending that the DHCP server won't be able = to know which v4 =3D=3D which v6 client, and I don't know if that's a = problem. The problem this is intended to solve is that without supporting = the link layer address that is readily available before connecting a = device to a network or even turning it on, there is no way to set the = server in advance to hand out known addresses that are intended for a = specific client. For network access control and some tracking mechanisms, = this is a big problem. By adding MAC to the v6 exchange, operators are = able to match up MAC tracking databases, where MAC is an important index = that they care about. The fact that the DHCP server uses or doesn't use it = is irrelevant.
 
We've presented what use case caused this draft to come into = existence, and I understand the desire to make a protocol robust, but can = you present a use case that relates here so that I can understand = what you'd additionally like to achieve?
--=__Part240A99D9.0__=-- From akostur@incognito.com Thu Jul 12 12:39: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 A18D221F85C9 for ; Thu, 12 Jul 2012 12:39:57 -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=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zs6YDoYiIE-j for ; Thu, 12 Jul 2012 12:39:56 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with SMTP id 33DA221F85AE for ; Thu, 12 Jul 2012 12:39:55 -0700 (PDT) Received: from mail-vc0-f176.google.com ([209.85.220.176]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKT/8oKWQMaUN4jXWIbwpYrmMjfKKsom4s@postini.com; Thu, 12 Jul 2012 12:40:30 PDT Received: by vcbfl11 with SMTP id fl11so771395vcb.35 for ; Thu, 12 Jul 2012 12:40:24 -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=2fu7tcOaT8X/ngDDWBdST9f0a7p1voRY2iTukiqGgmQ=; b=JckFbm37ui0FE52klaf7YkZ1IhQwowo7CRmZDTdZS9IJfa/RVLP9AcozCYEAXht/6S 9zHCPYC6dZrZzX3OfqUVIpdOdec37Hn1OqdNX7mfHU8CbBD4SYy/b0bi2RYEpm8WeBCG OKlaVVV0Q8BmeMaJ5PFozATE3ldNg1maiNQ9W53HcL32oxRlC+1uBItCOeb10ps6QqHo SmWLXYGKQ+RpDPokCgtbtx+Nbq0FPW3ARfzheAGcdL0OOwlzVzkFJ3cNRJX2BcHOePtl GkGC/ElUkNuqzmaoT7kazxLgY1xYWi5hEJD6Bcuv599MXschFHDwYM55lwnkwMh4gg5i f6uQ== MIME-Version: 1.0 Received: by 10.220.240.141 with SMTP id la13mr22265261vcb.46.1342122024352; Thu, 12 Jul 2012 12:40:24 -0700 (PDT) Received: by 10.52.34.50 with HTTP; Thu, 12 Jul 2012 12:40:24 -0700 (PDT) In-Reply-To: <4FFEDF70.39E4.004A.0@srttel.com> References: <4FFEDF70.39E4.004A.0@srttel.com> Date: Thu, 12 Jul 2012 12:40:24 -0700 Message-ID: From: Andre Kostur To: Marc Perea Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk7vliC3D5PaWFRUfSyiSTYejXUVhCBjivk4/41sgVod+TM+aa3DiyrChY/bXL1vXDVwPlY Cc: dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Thu, 12 Jul 2012 19:39:57 -0000 On Thu, Jul 12, 2012 at 12:30 PM, Marc Perea wrote: > > While true that the primary key of the DHCP server lease would be client = id, in the cases that this draft was intended to support the MAC is a known= indentifier readily printed on the outside of ethernet packaging and on la= bels while hardware is powered off and not connected to the network. That M= AC is directly tied to a client/customer in many operator environments, whe= ther it sends client-id or not. From the operator perspective, we don't rea= lly care whether the DHCProtocol uses client-id or MAC to index it's intern= al database - what we are concerned with is matching a MAC in existing non-= DHCP database to a client/customer so that we can match a v4 address and a = v6 address (or several of each) to an individual client/customer. The solut= ion is intended to have the relay grab the MAC from the v6 packet and add t= hat as an option (hint) to the DHCP server. Such implementation fills the n= eed of the problem at hand, only requiring changes be made to relay agents = and DHCP servers. WG members represent most of the DHCPv6 server software a= nd relay hardware/software suppliers. In short, the WG is both willing and = able to effect the changes presented in the draft. > > It sounds like you're contending that the DHCP server won't be able to kn= ow which v4 =3D=3D which v6 client, and I don't know if that's a problem. T= he problem this is intended to solve is that without supporting the link la= yer address that is readily available before connecting a device to a netwo= rk or even turning it on, there is no way to set the server in advance to h= and out known addresses that are intended for a specific client. For networ= k access control and some tracking mechanisms, this is a big problem. By ad= ding MAC to the v6 exchange, operators are able to match up MAC tracking da= tabases, where MAC is an important index that they care about. The fact tha= t the DHCP server uses or doesn't use it is irrelevant. > > We've presented what use case caused this draft to come into existence, a= nd I understand the desire to make a protocol robust, but can you present a= use case that relates here so that I can understand what you'd additionall= y like to achieve? Ok, if we're restricting to ISP environments, why not mandate in such environments that they should be using the Remote ID (RFC 4649) to specify the downstream "client". Note that in DOCSIS environments, this is already happening. (Just not in RFC 4649 form... but in an enterprise-specific option 17). -- Andre Kostur From Ted.Lemon@nominum.com Thu Jul 12 12:49: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 EF05411E809B for ; Thu, 12 Jul 2012 12:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGPUd6i6FnQi for ; Thu, 12 Jul 2012 12:49:33 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 149AC11E80CD for ; Thu, 12 Jul 2012 12:49: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 DSNKT/8qbqePGh9t+D3B3C/v4L28FJN6EHAD@postini.com; Thu, 12 Jul 2012 12:50:07 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 467D91B82AF for ; Thu, 12 Jul 2012 12:50:06 -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 3C3E719005C; Thu, 12 Jul 2012 12:50:06 -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, 12 Jul 2012 12:50:00 -0700 From: Ted Lemon To: Andre Kostur Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNYGY2oSSsG0sHhEuKqNLO98w5gJcmg5WA Date: Thu, 12 Jul 2012 19:49:59 +0000 Message-ID: References: <4FFEDF70.39E4.004A.0@srttel.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_BEF0160F9A8C4DF394FC9F69BFB09CAFnominumcom_" MIME-Version: 1.0 Cc: "" , Marc Perea Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Thu, 12 Jul 2012 19:49:34 -0000 --_000_BEF0160F9A8C4DF394FC9F69BFB09CAFnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jul 12, 2012, at 3:40 PM, Andre Kostur wrote: Ok, if we're restricting to ISP environments, why not mandate in such environments that they should be using the Remote ID (RFC 4649) to specify the downstream "client". Note that in DOCSIS environments, this is already happening. (Just not in RFC 4649 form... but in an enterprise-specific option 17). It's my understanding that the main motivator for this draft is use in corp= orate IT departments that inventory machines by MAC address. I guess it w= ould also be useful for ISPs, but that's certainly not the use case that I'= ve heard mentioned most. --_000_BEF0160F9A8C4DF394FC9F69BFB09CAFnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <365E4AD9AEE11F48806CB2277F27605A@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jul 12, 2012, at 3:40 PM, Andre Kostur wrote:
Ok, if we're restricting to ISP environments, why not mandate in such
environments that they should be using the Remote ID (RFC 4649) to
specify the downstream "client".  Note that in DOCSIS enviro= nments,
this is already happening.  (Just not in RFC 4649 form... but in an enterprise-specific option 17).

It's my understanding that the main motivator for this draft is use in= corporate IT departments that inventory machines by MAC address.   I = guess it would also be useful for ISPs, but that's certainly not the use ca= se that I've heard mentioned most.

--_000_BEF0160F9A8C4DF394FC9F69BFB09CAFnominumcom_-- From G.Eustace@massey.ac.nz Thu Jul 12 13:22: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 4BE8411E809C for ; Thu, 12 Jul 2012 13:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLjc2qNpb6YI for ; Thu, 12 Jul 2012 13:22:53 -0700 (PDT) Received: from mu-mail3.massey.ac.nz (mu-mail3.massey.ac.nz [130.123.129.187]) by ietfa.amsl.com (Postfix) with ESMTP id 306FC11E8096 for ; Thu, 12 Jul 2012 13:22:52 -0700 (PDT) Received: from tur-mm5.massey.ac.nz (tur-mm5.massey.ac.nz [130.123.96.133]) by mu-mail3.massey.ac.nz (Postfix) with ESMTP id 5D1571B3182; Fri, 13 Jul 2012 08:23:24 +1200 (NZST) Received: from tur-exch-cas1.massey.ac.nz (Not Verified[10.100.189.3]) by tur-mm5.massey.ac.nz with MailMarshal id ; Fri, 13 Jul 2012 08:23:23 +1200 Received: from TUR-EXCH-NODE2.massey.ac.nz ([fe80::6d90:b430:e061:20ed]) by tur-exch-cas1.massey.ac.nz ([fe80::590d:38a9:56de:47a4%13]) with mapi id 14.02.0298.004; Fri, 13 Jul 2012 08:23:23 +1200 From: "Eustace, Glen" To: Ted Lemon Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNYGwvIo7YZHxtLUu8zFI5r0fWlA== Date: Thu, 12 Jul 2012 20:23:23 +0000 Message-ID: In-Reply-To: Accept-Language: en-NZ, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [10.100.189.3] Content-Type: multipart/alternative; boundary="_000_CC2589A3ADDFGEustacemasseyacnz_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Thu, 12 Jul 2012 20:22:54 -0000 --_000_CC2589A3ADDFGEustacemasseyacnz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As one of these IT departments, I thought that some empirical data might be= useful. We have now got ISC dhcpd running on our main campus and I have just comple= ted adding native IPv6 to the majority of networks. We do NOT yet have DUI= Ds stored in our databases but do have the MAC address for the primary NIC = for all University owned equipment. I have the hardware-ethernet included in each host declaration for both IP= v4 and IPv6. Using the ISC fudge of deconstructing the type 1 DUID, we hav= e 1224 matches out of 1693 active leases. Whilst not perfect, it is actual= ly better than I expected and for us does add value. I have not yet attempted to determine why we failed to match the remaining = leases, could be a number of reasons 1. Private equipment for which we do not have a MAC in the DB 2. The DUID generated used a MAC we don't have in the DB 3. The MAC we have is wrong. 4. etc -- =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D- Glen Eustace, Infrastructure Development Engineer (BC/DR) Information Technology Service, Massey University PN460 Tennent Drive, Palmerston North, New Zealand Ph: +64-6-3569099 x 81005, Fax: +64-6-3505607, Mob: +64-27-4500321 From: "Ted com>" > Date: Thu, 12 Jul 2012 19:49:59 +0000 To: Andre Kostur > Cc: ">" >, Marc Perea > Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-ad= dr-opt-00.txt On Jul 12, 2012, at 3:40 PM, Andre Kostur wrote: Ok, if we're restricting to ISP environments, why not mandate in such environments that they should be using the Remote ID (RFC 4649) to specify the downstream "client". Note that in DOCSIS environments, this is already happening. (Just not in RFC 4649 form... but in an enterprise-specific option 17). It's my understanding that the main motivator for this draft is use in corp= orate IT departments that inventory machines by MAC address. I guess it w= ould also be useful for ISPs, but that's certainly not the use case that I'= ve heard mentioned most. _______________________________________________ dhcwg mailing list dhcwg@ie= tf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_CC2589A3ADDFGEustacemasseyacnz_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
As one of these IT departments, I thought that some empirical data mig= ht be useful.

We have now got ISC dhcpd running on our main campus and I have just c= ompleted adding native IPv6 to the majority of networks.  We do NOT ye= t have DUIDs stored in our databases but do have the MAC address for the pr= imary NIC for all University owned equipment.

I have the  hardware-ethernet included in each host declaration f= or both IPv4 and IPv6.  Using the ISC fudge of deconstructing the type= 1 DUID, we have 1224 matches out of 1693 active leases.  Whilst not p= erfect, it is actually better than I expected and for us does add value.

I have not yet attempted to determine why we failed to match the remai= ning leases, could be a number of reasons
  1. Private equipment for which we do not have a MAC in the DB
  2. The = DUID generated used a MAC we don't have in the DB
  3. The MAC we have i= s wrong.
  4. etc
-- 
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-
Glen Eustace, Infrastructure Development Engineer (BC/DR)
Information Technology Service, Massey University PN460
Tennent Drive, Palmerston North, New Zealand
Ph: +64-6-3569099 x 81005, Fax: +64-6-3505607, Mob: +64-27= -4500321

From: "Ted com>" <<= a href=3D"mailto:Ted.Lemon@nominum.com">Ted.Lemon@nominum.com>
Date: Thu, 12 Jul 2012 19:49:59 = 3;0000
To: Andre Kostur <akostur@incognito.com>
Cc: "<dhcwg@ietf.org>" <dhcwg@ietf.org>, Marc Perea <marccp@srttel.com>
Subject: Re: [dhcwg] I-D Action: dr= aft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt

On Jul 12, 2012, at 3:40 PM, Andre Kostur wrote:
Ok, if we're restricting to ISP envir= onments, why not mandate in such
environments that they should be using the Remote ID (RF= C 4649) to
specify the downstream "client".  Note th= at in DOCSIS environments,
this is already happening.  (Just not in RFC 4649 f= orm... but in an
enterprise-specific option 17).

It's my understanding that the main motivator for this draft is use in= corporate IT departments that inventory machines by MAC address.   I = guess it would also be useful for ISPs, but that's certainly not the use ca= se that I've heard mentioned most.

_______________________________________________ dhcwg mailing list dhcwg@ietf.org = https://www.ietf.org/mailman/listinfo/dhcwg --_000_CC2589A3ADDFGEustacemasseyacnz_-- From marccp@srttel.com Thu Jul 12 14:24: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 62EC811E80DB for ; Thu, 12 Jul 2012 14:24:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axnnUYP28QMc for ; Thu, 12 Jul 2012 14:24:05 -0700 (PDT) Received: from mail.srttel.com (mail.srttel.com [216.221.96.218]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC1411E80CF for ; Thu, 12 Jul 2012 14:24:05 -0700 (PDT) Received: from srtdom-MTA by mail.srttel.com with Novell_GroupWise; Thu, 12 Jul 2012 16:24:39 -0500 Message-Id: <4FFEFA22.39E4.004A.0@srttel.com> X-Mailer: Novell GroupWise Internet Agent 7.0.3 Date: Thu, 12 Jul 2012 16:24:11 -0500 From: "Marc Perea" To: "Andre Kostur" , "Ted Lemon" References: <4FFEDF70.39E4.004A.0@srttel.com> In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartF3DD4E6B.0__=" Cc: "" Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Thu, 12 Jul 2012 21:24:06 -0000 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartF3DD4E6B.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Indeed. Although I work for an ISP, and our intent on v6 is to use option = 82 to identify endpoints, including for the purposes of PD where we won't = care what LL address is presented from the WAN of the device, this work is = useful when I wear the corporate hat, or the educational lab services hat, = or the captive portal for wifi hat. I'm not necessarily interested in = restricting the use of the mechanism we're attempting to push forward here = - I'm trying to understand what real world scenario could exist that = justifies expanding the scope of the draft. I feel that the work and scope = are currently justified and real - I'm not against expanding both, but I'd = like to know it's being done to solve a real problem. Can you elaborate? >>> Ted Lemon 7/12/2012 2:49 PM >>> On Jul 12, 2012, at 3:40 PM, Andre Kostur wrote: Ok, if we're restricting to ISP environments, why not mandate in such environments that they should be using the Remote ID (RFC 4649) to specify the downstream "client". Note that in DOCSIS environments, this is already happening. (Just not in RFC 4649 form... but in an enterprise-specific option 17). It's my understanding that the main motivator for this draft is use in = corporate IT departments that inventory machines by MAC address. I guess = it would also be useful for ISPs, but that's certainly not the use case = that I've heard mentioned most. --=__PartF3DD4E6B.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML Ok, if = we're restricting to ISP environments, why not mandate in such
environme= nts that they should be using the Remote ID (RFC 4649) to
specify the = downstream "client".  Note that in DOCSIS environments,
this is = already happening.  (Just not in RFC 4649 form... but in an
enterpr= ise-specific option 17).

It's my understanding that the main motivator for this draft is use = in corporate IT departments that inventory machines by MAC address.   = I guess it would also be useful for ISPs, but that's certainly not the use = case that I've heard mentioned most.

--=__PartF3DD4E6B.0__=-- From greg.rabil@jagornet.com Thu Jul 12 18:06: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 512D411E80CC for ; Thu, 12 Jul 2012 18:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJB9j4z5RG51 for ; Thu, 12 Jul 2012 18:06:28 -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 B606811E8096 for ; Thu, 12 Jul 2012 18:06:27 -0700 (PDT) Received: by bkty7 with SMTP id y7so2448889bkt.31 for ; Thu, 12 Jul 2012 18:06:57 -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=KrCWVDokIWcBY8nWjPl3eCbgpYMSiV5jXuuvA1YiwHg=; b=CQ3+nyMD9sUyQlQdbOZ8ybiVxy7vdkIC4yHykIQhtiEsQcRl4yQjsu6lvoAxFtDsEQ JU7GhyG0nvpVNgVgFZLC2L3+xiLpLUCzvTWnBs0eWyyVIxUyngesPO//jXZkHrDTrvEp qWB6E5b+hiZDf2y9VZ8ukO99+TBUqBSDfqUljMyNVtvvDDK0/LJiRZpG+oxWAL6cBIFh n3QKPrjLRTr2uI1Vy3gkXuleUlhLANdB6q9Th68XiaIVbPKPv+cdhSz6AWbPuoGkqeK0 OtgyELNYaExeOkaAmeJqTCSQfoNydpDIj+8SO5med9qm2cel1YCNa+LbCNg/MygcnH0p LYXQ== MIME-Version: 1.0 Received: by 10.204.152.199 with SMTP id h7mr178663bkw.39.1342141617045; Thu, 12 Jul 2012 18:06:57 -0700 (PDT) Received: by 10.204.156.133 with HTTP; Thu, 12 Jul 2012 18:06:56 -0700 (PDT) In-Reply-To: References: <521202936.30106.1342097834494.JavaMail.root@network1.net> Date: Thu, 12 Jul 2012 21:06:56 -0400 Message-ID: From: "A. Gregory Rabil" To: Simon Hobson Content-Type: multipart/alternative; boundary=0015175cd9e85280ba04c4abb2ac X-Gm-Message-State: ALoCoQkk90ZQ6XKmB29aFfajfqdYxcwFqsK8sdk+KpQ1XDC5Gdntdpp/6qJJrKo9hQwcqX+juLBW Cc: dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Fri, 13 Jul 2012 01:06:29 -0000 --0015175cd9e85280ba04c4abb2ac Content-Type: text/plain; charset=ISO-8859-1 > While I could see some situations where going further might be useful, I could only see it working in a managed environment (eg ISP supplied routers, I'm thinking something similar to ISP supplied cable modems). Consider the case where both the delegating and requesting router are within an enterprise network, not the current use of PD with home routers. In this case, the downstream interfaces are indeed interesting to the delegating router. On Thu, Jul 12, 2012 at 10:00 AM, Simon Hobson wrote: > perl-list wrote: > > Okay, consider prefix-delegation, for example. ... >>> >> > What you say in theory is interesting and could pose a problem. In >> practice, however, it seems that prefix delegation and WAN configuration >> happen simultaneously in the same exchange within the same packet. Also, >> as this draft is intended to help correlation between DHCPv4 and DHCPv6 >> using the (hardware / link layer / MAC - whatever we are calling it these >> days) address, your argument about downstream interfaces that would not be >> known in DHCPv4 space is irrelevant. >> > > I agree, and what's more I can't really see how it's an upstream server's > job to configure downstream interfaces on a router. In the general case > where PD is likely, it's going to be an ISP delivering a prefix to a > customer's router - what the customer wants to do with that isn't really > anything to do with the ISP. > All the ISP needs to do is a) configure the customer's WAN, and b) provide > them with a PD. > > While I could see some situations where going further might be useful, I > could only see it working in a managed environment (eg ISP supplied > routers, I'm thinking something similar to ISP supplied cable modems). I'd > see that sort of situation managed by 'private' extensions/options which > could be agreed between the client and server - possibly as an industry > segment standard vendor option space. > > > I'm inclined to agree with Ted - keep it simple so it can actually get > passed ! > > > -- > 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. > ______________________________**_________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/**listinfo/dhcwg > --0015175cd9e85280ba04c4abb2ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > While I could see some situations where going further might be useful,= I could only see it working in a managed environment (eg ISP supplied rout= ers, I'm thinking something similar to ISP supplied cable modems).

Consider the case where both the delegating and requesting router are w= ithin an enterprise network, not the current use of PD with home routers. = =A0In this case, the downstream interfaces are indeed interesting to the de= legating router.


On Thu, Jul 12, 2012 at 10:00= AM, Simon Hobson <linux@thehobsons.co.uk> wrote:
perl-list wrote:

Okay, consider prefix-delegation, for example. ...

What you say in theory is interesting and could pose a problem. =A0In pract= ice, however, it seems that prefix delegation and WAN configuration happen = simultaneously in the same exchange within the same packet. =A0Also, as thi= s draft is intended to help correlation between DHCPv4 and DHCPv6 using the= (hardware / link layer / MAC - whatever we are calling it these days) addr= ess, your argument about downstream interfaces that would not be known in D= HCPv4 space is irrelevant.

I agree, and what's more I can't really see how it's an upstrea= m server's job to configure downstream interfaces on a router. In the g= eneral case where PD is likely, it's going to be an ISP delivering a pr= efix to a customer's router - what the customer wants to do with that i= sn't really anything to do with the ISP.
All the ISP needs to do is a) configure the customer's WAN, and b) prov= ide them with a PD.

While I could see some situations where going further might be useful, I co= uld only see it working in a managed environment (eg ISP supplied routers, = I'm thinking something similar to ISP supplied cable modems). I'd s= ee that sort of situation managed by 'private' extensions/options w= hich could be agreed between the client and server - possibly as an industr= y segment standard vendor option space.


I'm inclined to agree with Ted - keep it simple so it can actually get = passed !


--
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed<= br> author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

--0015175cd9e85280ba04c4abb2ac-- From dankney@network1.net Fri Jul 13 06:00: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 6ED4C21F8811 for ; Fri, 13 Jul 2012 06:00:38 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpF+ycCm8MpC for ; Fri, 13 Jul 2012 06:00:37 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8156921F87DB for ; Fri, 13 Jul 2012 06:00:37 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 5DAC5540E44; Fri, 13 Jul 2012 09:01:13 -0400 (EDT) Date: Fri, 13 Jul 2012 09:01:13 -0400 (EDT) From: perl-list To: Marc Perea Message-ID: <59347105.32887.1342184473339.JavaMail.root@network1.net> In-Reply-To: <4FFEFA22.39E4.004A.0@srttel.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_32886_2008086651.1342184473338" X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC20 (Mac)/7.2.0_GA_2669) Cc: dhcwg , Andre Kostur , Ted Lemon Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Fri, 13 Jul 2012 13:00:38 -0000 ------=_Part_32886_2008086651.1342184473338 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit It is useful for ISPs where some of their network types don't have the circuit ID available, or there is no circuit ID (wireless) or the Circuit ID is dynamic. In these cases, they tend to use the Link Layer address for customer identification. ----- Original Message ----- > From: "Marc Perea" > To: "Andre Kostur" , "Ted Lemon" > > Cc: "" > Sent: Thursday, July 12, 2012 5:24:11 PM > Subject: Re: [dhcwg] I-D > Action:draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt > Indeed. Although I work for an ISP, and our intent on v6 is to use > option 82 to identify endpoints, including for the purposes of PD > where we won't care what LL address is presented from the WAN of the > device, this work is useful when I wear the corporate hat, or the > educational lab services hat, or the captive portal for wifi hat. > I'm not necessarily interested in restricting the use of the > mechanism we're attempting to push forward here - I'm trying to > understand what real world scenario could exist that justifies > expanding the scope of the draft. I feel that the work and scope are > currently justified and real - I'm not against expanding both, but > I'd like to know it's being done to solve a real problem. Can you > elaborate? > >>> Ted Lemon 7/12/2012 2:49 PM >>> > On Jul 12, 2012, at 3:40 PM, Andre Kostur wrote: > > Ok, if we're restricting to ISP environments, why not mandate in > > such > > > environments that they should be using the Remote ID (RFC 4649) to > > > specify the downstream "client". Note that in DOCSIS environments, > > > this is already happening. (Just not in RFC 4649 form... but in an > > > enterprise-specific option 17). > > It's my understanding that the main motivator for this draft is use > in corporate IT departments that inventory machines by MAC address. > I guess it would also be useful for ISPs, but that's certainly not > the use case that I've heard mentioned most. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg ------=_Part_32886_2008086651.1342184473338 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'>It is us= eful for ISPs where some of their network types don't have the circuit ID a= vailable, or there is no circuit ID (wireless) or the Circuit ID is dynamic= .  In these cases, they tend to use the Link Layer address for custome= r identification.
From: "Marc Perea" <marccp@= srttel.com>
To: "Andre Kostur" <akostur@incognito.com>, = "Ted Lemon" <Ted.Lemon@nominum.com>
Cc: "<dhcwg@ietf.org= >" <dhcwg@ietf.org>
Sent: Thursday, July 12, 2012 5:24:1= 1 PM
Subject: Re: [dhcwg]      &nbs= p; I-D        Action:draft-iet= f-dhc-dhcpv6-client-link-layer-addr-opt-00.txt

Indeed. Although I work for an ISP, and our intent on v6 is to use option 8= 2 to identify endpoints, including for the purposes of PD where we won't ca= re what LL address is presented from the WAN of the device, this work is us= eful when I wear the corporate hat, or the educational lab services hat, or= the captive portal for wifi hat. I'm not necessarily interested in restric= ting the use of the mechanism we're attempting to push forward here - I'm t= rying to understand what real world scenario could exist that justifies exp= anding the scope of the draft. I feel that the work and scope are currently= justified and real - I'm not against expanding both, but I'd like to know = it's being done to solve a real problem. Can you elaborate?

>>= > Ted Lemon <Ted.Lemon@nominum.com> 7/12/2012 2:49 PM >>>=
On Jul 12, 2012, at 3:40 PM, Andre Kostur wrote:
Ok,= if we're restricting to ISP environments, why not mandate in such
envir= onments that they should be using the Remote ID (RFC 4649) to
specify th= e downstream "client".  Note that in DOCSIS environments,
this is a= lready happening.  (Just not in RFC 4649 form... but in an
enterpri= se-specific option 17).

It's my understanding that the main motivator for this draft is use in= corporate IT departments that inventory machines by MAC address.   I = guess it would also be useful for ISPs, but that's certainly not the use ca= se that I've heard mentioned most.


_______________________________________________
dhcwg mailing listdhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

------=_Part_32886_2008086651.1342184473338-- From dankney@network1.net Fri Jul 13 06:06: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 6767321F87E3 for ; Fri, 13 Jul 2012 06:06:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nir68ajnTfGd for ; Fri, 13 Jul 2012 06:06:32 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id C2EF521F875A for ; Fri, 13 Jul 2012 06:06:32 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id BE856540E44; Fri, 13 Jul 2012 09:07:08 -0400 (EDT) Date: Fri, 13 Jul 2012 09:07:08 -0400 (EDT) From: perl-list To: Glen Eustace Message-ID: <1845045610.32919.1342184828721.JavaMail.root@network1.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_32918_1732330627.1342184828720" X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC20 (Mac)/7.2.0_GA_2669) Cc: dhcwg , Ted Lemon Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Fri, 13 Jul 2012 13:06:33 -0000 ------=_Part_32918_1732330627.1342184828720 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Some equipment doesn't use any mac at all to generate the DUID which is perfectly acceptable in the related RFC. If the DUID always used the mac, then we wouldn't need this draft at all. > I have not yet attempted to determine why we failed to match the > remaining leases, could be a number of reasons > 1. Private equipment for which we do not have a MAC in the DB > 2. The DUID generated used a MAC we don't have in the DB > 3. The MAC we have is wrong. > 4. etc ------=_Part_32918_1732330627.1342184828720 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Some equipment doesn't use any mac at all to generate the DUID which is perfectly acceptable in the related RFC.  If the DUID always used the mac, then we wouldn't need this draft at all.

I have not yet attempted to determine why we failed to match the remaining leases, could be a number of reasons
  1. Private equipment for which we do not have a MAC in the DB
  2. The DUID generated used a MAC we don't have in the DB
  3. The MAC we have is wrong.
  4. etc

------=_Part_32918_1732330627.1342184828720-- From dankney@network1.net Fri Jul 13 06:07: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 E116B21F87E3 for ; Fri, 13 Jul 2012 06:07:59 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpWDWABBcbtz for ; Fri, 13 Jul 2012 06:07:59 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id DB71521F875A for ; Fri, 13 Jul 2012 06:07:58 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id DCC5C540E44; Fri, 13 Jul 2012 09:08:34 -0400 (EDT) Date: Fri, 13 Jul 2012 09:08:34 -0400 (EDT) From: perl-list To: Marc Perea Message-ID: <1133181837.32923.1342184914816.JavaMail.root@network1.net> In-Reply-To: <4FFEDF70.39E4.004A.0@srttel.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_32922_1117571557.1342184914815" X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC20 (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-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: Fri, 13 Jul 2012 13:08:00 -0000 ------=_Part_32922_1117571557.1342184914815 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit This is exactly the ISP case. Administrator doesn't really care how the DHCP server is tracking leases, only that there is some mechanism to correlate between v4 and v6. ----- Original Message ----- > From: "Marc Perea" > To: dhcwg@ietf.org > Sent: Thursday, July 12, 2012 3:30:17 PM > Subject: Re: [dhcwg] I-D Action: > draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt > While true that the primary key of the DHCP server lease would be > client id, in the cases that this draft was intended to support the > MAC is a known indentifier readily printed on the outside of > ethernet packaging and on labels while hardware is powered off and > not connected to the network. That MAC is directly tied to a > client/customer in many operator environments, whether it sends > client-id or not. From the operator perspective, we don't really > care whether the DHCProtocol uses client-id or MAC to index it's > internal database - what we are concerned with is matching a MAC in > existing non-DHCP database to a client/customer so that we can match > a v4 address and a v6 address (or several of each) to an individual > client/customer. The solution is intended to have the relay grab the > MAC from the v6 packet and add that as an option (hint) to the DHCP > server. Such implementation fills the need of the problem at hand, > only requiring changes be made to relay agents and DHCP servers. WG > members represent most of the DHCPv6 server software and relay > hardware/software suppliers. In short, the WG is both willing and > able to effect the changes presented in the draft. > It sounds like you're contending that the DHCP server won't be able > to know which v4 == which v6 client, and I don't know if that's a > problem. The problem this is intended to solve is that without > supporting the link layer address that is readily available before > connecting a device to a network or even turning it on, there is no > way to set the server in advance to hand out known addresses that > are intended for a specific client. For network access control and > some tracking mechanisms, this is a big problem. By adding MAC to > the v6 exchange, operators are able to match up MAC tracking > databases, where MAC is an important index that they care about. The > fact that the DHCP server uses or doesn't use it is irrelevant. > We've presented what use case caused this draft to come into > existence, and I understand the desire to make a protocol robust, > but can you present a use case that relates here so that I can > understand what you'd additionally like to achieve? > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg ------=_Part_32922_1117571557.1342184914815 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'>
This is exactly the ISP case.  Administrator doesn't r= eally care how the DHCP server is tracking leases, only that there is some = mechanism to correlate between v4 and v6.

From: "Ma= rc Perea" <marccp@srttel.com>
To: dhcwg@ietf.org
Sent= : Thursday, July 12, 2012 3:30:17 PM
Subject: Re: [dhcwg] I-D=         Action:   &n= bsp;    draft-ietf-dhc-dhcpv6-client-link-layer-addr-op= t-00.txt

While true that the primary key of the DHCP server lease would be clie= nt id, in the cases that this draft was intended to support the MAC is a kn= own indentifier readily printed on the outside of ethernet packaging and on= labels while hardware is powered off and not connected to the network. Tha= t MAC is directly tied to a client/customer in many operator environments, = whether it sends client-id or not. From the operator perspective, we don't = really care whether the DHCProtocol uses client-id or MAC to index it's int= ernal database - what we are concerned with is matching a MAC in exist= ing non-DHCP database to a client/customer so that we can match a= v4 address and a v6 address (or several of each) to an individual client/c= ustomer. The solution is intended to have the relay grab the MAC from the v= 6 packet and add that as an option (hint) to the DHCP server. Such implemen= tation fills the need of the problem at hand, only requiring changes be mad= e to relay agents and DHCP servers. WG members represent most of the DHCPv6= server software and relay hardware/software suppliers. In short, the WG is= both willing and able to effect the changes presented in the draft.
 
It sounds like you're contending that the DHCP server won't be able to= know which v4 =3D=3D which v6 client, and I don't know if that's a problem= . The problem this is intended to solve is that without supporting the link= layer address that is readily available before connecting a device to a ne= twork or even turning it on, there is no way to set the server in advance t= o hand out known addresses that are intended for a specific client. For net= work access control and some tracking mechanisms, this is a big problem. By= adding MAC to the v6 exchange, operators are able to match up MAC tracking= databases, where MAC is an important index that they care about. The fact = that the DHCP server uses or doesn't use it is irrelevant.
 
We've presented what use case caused this draft to come into existence= , and I understand the desire to make a protocol robust, but can you p= resent a use case that relates here so that I can understand what you'd add= itionally like to achieve?

_______________________________________________
dhcwg mailing listdhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

------=_Part_32922_1117571557.1342184914815-- From dankney@network1.net Fri Jul 13 06:09: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 D8DFC21F8810 for ; Fri, 13 Jul 2012 06:09:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLIMalOCx-tJ for ; Fri, 13 Jul 2012 06:09:39 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1C47C21F880D for ; Fri, 13 Jul 2012 06:09:38 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id E02DC540E44; Fri, 13 Jul 2012 09:10:14 -0400 (EDT) Date: Fri, 13 Jul 2012 09:10:14 -0400 (EDT) From: perl-list To: Andre Kostur Message-ID: <798909694.32949.1342185014808.JavaMail.root@network1.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_32948_133059403.1342185014807" X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC20 (Mac)/7.2.0_GA_2669) Cc: dhcwg@ietf.org, Marc Perea Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Fri, 13 Jul 2012 13:09:41 -0000 ------=_Part_32948_133059403.1342185014807 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Not all downstream equipment supports Remote ID. Not all network setups have a circuit ID either. > Ok, if we're restricting to ISP environments, why not mandate in such > environments that they should be using the Remote ID (RFC 4649) to > specify the downstream "client". Note that in DOCSIS environments, > this is already happening. (Just not in RFC 4649 form... but in an > enterprise-specific option 17). ------=_Part_32948_133059403.1342185014807 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'>
Not all downst= ream equipment supports Remote ID.  Not all network setups have a circ= uit ID either.  


Ok, if we're restricting to ISP environments, why not mandate = in such
environments that they should be using the Remote ID (RFC 4649) = to
specify the downstream "client".  Note that in DOCSIS environmen= ts,
this is already happening.  (Just not in RFC 4649 form... but i= n an
enterprise-specific option 17).

 ------=_Part_32948_133059403.1342185014807-- From volz@cisco.com Fri Jul 13 12:48: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 EEE6E21F8577 for ; Fri, 13 Jul 2012 12:48: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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljSdo7jw5Zwc for ; Fri, 13 Jul 2012 12:48:10 -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 2DAB921F8573 for ; Fri, 13 Jul 2012 12:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3997; q=dns/txt; s=iport; t=1342208927; x=1343418527; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nzXlsYSVmtzbvvDm23gLW/71nmVbRV3WyZ/8fgWc2hU=; b=KQ9ld+S8EwxH6d/+jqqWryasBzYiy2Tq8kl/tKT2r7zqk3eXjFr3IFlD lKgPUloVr8UvV6y3SveH0jlIyvAI2aJWiye93pqWTyVAwb2ECw18TwraC njkHyyHKfaOajQmrW8kApWz8XBJFeWH3yefbxZsSbzvZrtMfaeNNfmMX0 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFt6AFCtJXG9/2dsb2JhbABFuB2BB4IgAQEBBAEBAQ8BJzQLDAQCAQgOAwQBAQEKFAkHJwsUCQgCBAENBQgTB4drC5tXoCIEizyFFmADo1qBZoJf X-IronPort-AV: E=Sophos;i="4.77,580,1336348800"; d="scan'208";a="98735538" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 13 Jul 2012 19:48:46 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6DJmkq5020089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Jul 2012 19:48:46 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Fri, 13 Jul 2012 14:48:46 -0500 From: "Bernie Volz (volz)" To: Andre Kostur , Marc Perea Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNYGY1LkUJv4XiBUiIDfZLQtJcKJcnnvUQ Date: Fri, 13 Jul 2012 19:48:46 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E022DC6@xmb-rcd-x04.cisco.com> References: <4FFEDF70.39E4.004A.0@srttel.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.196] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19038.001 x-tm-as-result: No--37.760600-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] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Fri, 13 Jul 2012 19:48:12 -0000 >Ok, if we're restricting to ISP environments, why not mandate in >such environments that they should be using the Remote ID (RFC >4649) to specify the downstream "client". Note that in DOCSIS >environments, this is already happening. (Just not in RFC 4649 >form... but in an enterprise-specific option 17). And as I pointed out a few days ago, DOCSIS could care less about the CPE m= ac address. The important mac address printed on the box is for the CM, not= the CPE. In DOCSIS, it wants to know the CM's mac address for DHCPv6 CPE r= equests, not the CPE's mac address.=20 So, this draft could be used by DOCSIS only for the CM's DHCPv6 requests an= d something else would still be needed for when the CPE did DHCPv6 to provi= de the CM's mac-address. DOCSIS already solves both issues with its Vendor = Specific Option definitions. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of A= ndre Kostur Sent: Thursday, July 12, 2012 3:40 PM To: Marc Perea Cc: dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-ad= dr-opt-00.txt On Thu, Jul 12, 2012 at 12:30 PM, Marc Perea wrote: > > While true that the primary key of the DHCP server lease would be=20 > client id, in the cases that this draft was intended to support the=20 > MAC is a known indentifier readily printed on the outside of ethernet=20 > packaging and on labels while hardware is powered off and not=20 > connected to the network. That MAC is directly tied to a=20 > client/customer in many operator environments, whether it sends=20 > client-id or not. From the operator perspective, we don't really care=20 > whether the DHCProtocol uses client-id or MAC to index it's internal=20 > database - what we are concerned with is matching a MAC in existing=20 > non-DHCP database to a client/customer so that we can match a v4=20 > address and a v6 address (or several of each) to an individual=20 > client/customer. The solution is intended to have the relay grab the=20 > MAC from the v6 packet and add that as an option (hint) to the DHCP=20 > server. Such implementation fills the need of the problem at hand,=20 > only requiring changes be made to relay agents and DHCP server s. WG members represent most of the DHCPv6 server software and relay hardw= are/software suppliers. In short, the WG is both willing and able to effect= the changes presented in the draft. > > It sounds like you're contending that the DHCP server won't be able to kn= ow which v4 =3D=3D which v6 client, and I don't know if that's a problem. T= he problem this is intended to solve is that without supporting the link la= yer address that is readily available before connecting a device to a netwo= rk or even turning it on, there is no way to set the server in advance to h= and out known addresses that are intended for a specific client. For networ= k access control and some tracking mechanisms, this is a big problem. By ad= ding MAC to the v6 exchange, operators are able to match up MAC tracking da= tabases, where MAC is an important index that they care about. The fact tha= t the DHCP server uses or doesn't use it is irrelevant. > > We've presented what use case caused this draft to come into existence, a= nd I understand the desire to make a protocol robust, but can you present a= use case that relates here so that I can understand what you'd additionall= y like to achieve? Ok, if we're restricting to ISP environments, why not mandate in such envir= onments that they should be using the Remote ID (RFC 4649) to specify the d= ownstream "client". Note that in DOCSIS environments, this is already happ= ening. (Just not in RFC 4649 form... but in an enterprise-specific option = 17). -- Andre Kostur _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Fri Jul 13 12:59: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 C207B11E809B for ; Fri, 13 Jul 2012 12:59:13 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNmH5XeUytxo for ; Fri, 13 Jul 2012 12:59:11 -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 69E6411E80F0 for ; Fri, 13 Jul 2012 12:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14500; q=dns/txt; s=iport; t=1342209588; x=1343419188; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=94ZNNe0oWnF2HcFyzhqrWY3XIE/u5znOP3XCfoIlgns=; b=FyJNmtVY05Win+OCvitT8nJzU2iQkKAObPywZNke4rYSQ1fqb5HAYJaT cuvTEjKB+lrqvAeBw9H0HWt5O5uXs2gvqVavsRlwEKn7ZNC2kGI0vsB4w jo6aGT4koKw6s8BRe2+5o6DBGYgSarf9ooiHYzIZRdnFhVrefb0W5UTs1 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOJ9AFCtJV2Z/2dsb2JhbABFDoI8tVOBB4IgAQEBBBIBGkwQAgEIEQQBAQsdBzIUCQgCBAENBQgah2ubYaAkizyFFmADo1qBZoImOQ X-IronPort-AV: E=Sophos;i="4.77,580,1336348800"; d="scan'208,217";a="98738042" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 13 Jul 2012 19:59:48 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6DJxmBO002164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Jul 2012 19:59:48 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Fri, 13 Jul 2012 14:59:47 -0500 From: "Bernie Volz (volz)" To: "Eustace, Glen" , Ted Lemon Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNYGwvZrBEJQCsAkSClbxFr7Ij65cnoa7w Date: Fri, 13 Jul 2012 19:59:47 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E022DE9@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.244.196] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19038.001 x-tm-as-result: No--35.589000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E022DE9xmbrcdx04ciscocom_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Fri, 13 Jul 2012 19:59:14 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E022DE9xmbrcdx04ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You might repeat this test using the IPv6 source address of the client or R= elay's (closest to client) peer-address field to extract the IPv6 address, = which if a link-local, should contain the EUI-64 identifier which you can t= urn back into a mac-address. I suspect that this technique will be a much more reliable indication of th= e current interface's mac-address. Note: I am not suggesting that we not do this draft because of the above. - Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of E= ustace, Glen Sent: Thursday, July 12, 2012 4:23 PM To: Ted Lemon Cc: Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-ad= dr-opt-00.txt As one of these IT departments, I thought that some empirical data might be= useful. We have now got ISC dhcpd running on our main campus and I have just comple= ted adding native IPv6 to the majority of networks. We do NOT yet have DUI= Ds stored in our databases but do have the MAC address for the primary NIC = for all University owned equipment. I have the hardware-ethernet included in each host declaration for both IP= v4 and IPv6. Using the ISC fudge of deconstructing the type 1 DUID, we hav= e 1224 matches out of 1693 active leases. Whilst not perfect, it is actual= ly better than I expected and for us does add value. I have not yet attempted to determine why we failed to match the remaining = leases, could be a number of reasons 1. Private equipment for which we do not have a MAC in the DB 2. The DUID generated used a MAC we don't have in the DB 3. The MAC we have is wrong. 4. etc -- =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D- Glen Eustace, Infrastructure Development Engineer (BC/DR) Information Technology Service, Massey University PN460 Tennent Drive, Palmerston North, New Zealand Ph: +64-6-3569099 x 81005, Fax: +64-6-3505607, Mob: +64-27-4500321 --_000_489D13FBFA9B3E41812EA89F188F018E022DE9xmbrcdx04ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You might repeat this tes= t using the IPv6 source address of the client or Relay’s (closest to = client) peer-address field to extract the IPv6 address, which if a link-local, should contain the EUI-64 identifier which you can turn b= ack into a mac-address.

 <= /p>

I suspect that this techn= ique will be a much more reliable indication of the current interface’= ;s mac-address.

 <= /p>

Note: I am not suggesting= that we not do this draft because of the above.

 <= /p>

- =          Bernie=

 <= /p>

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Eustace, Glen
Sent: Thursday, July 12, 2012 4:23 PM
To: Ted Lemon
Cc: <dhcwg@ietf.org>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-l= ayer-addr-opt-00.txt

 

As one of these IT departme= nts, I thought that some empirical data might be useful.<= /p>

 

We have now got ISC dhcpd r= unning on our main campus and I have just completed adding native IPv6 to t= he majority of networks.  We do NOT yet have DUIDs stored in our databases but do have the MAC address for the primary NIC for all U= niversity owned equipment.

 

I have the  hardware-e= thernet included in each host declaration for both IPv4 and IPv6.  Usi= ng the ISC fudge of deconstructing the type 1 DUID, we have 1224 matches out of 1693 active leases.  Whilst not perfect, it is actually better= than I expected and for us does add value.

 

I have not yet attempted to= determine why we failed to match the remaining leases, could be a number o= f reasons

  1. Private equipment for which we do not have a MAC in the DB
  2. The DUID generated used a MAC we don't have in the DB
  3. The MAC we have is wrong.
  4. etc

-- <= /p>

=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-

Glen Eustace, Infrastructur= e Development Engineer (BC/DR)

Information Technology Serv= ice, Massey University PN460

Tennent Drive, Palmerston N= orth, New Zealand

Ph: +64-6-3569099 x 810= 05, Fax: +64-6-3505607, Mob: +64-27-4500321

--_000_489D13FBFA9B3E41812EA89F188F018E022DE9xmbrcdx04ciscocom_-- From G.Eustace@massey.ac.nz Sun Jul 15 13:45: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 D7C6F21F852D for ; Sun, 15 Jul 2012 13:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiNXcuyG17zU for ; Sun, 15 Jul 2012 13:45:08 -0700 (PDT) Received: from mu-mail2.massey.ac.nz (mu-mail2.massey.ac.nz [130.123.129.7]) by ietfa.amsl.com (Postfix) with ESMTP id 0A61A21F844C for ; Sun, 15 Jul 2012 13:45:07 -0700 (PDT) Received: from tur-mm4.massey.ac.nz (tur-mm4.massey.ac.nz [130.123.96.132]) by mu-mail2.massey.ac.nz (Postfix) with ESMTP id 6E3C586A5E for ; Mon, 16 Jul 2012 08:45:47 +1200 (NZST) Received: from tur-exch-cas2.massey.ac.nz (Not Verified[10.100.189.3]) by tur-mm4.massey.ac.nz with MailMarshal id ; Mon, 16 Jul 2012 08:45:47 +1200 Received: from TUR-EXCH-NODE2.massey.ac.nz ([fe80::6d90:b430:e061:20ed]) by tur-exch-cas2.massey.ac.nz ([fe80::1868:bfeb:eb89:2%13]) with mapi id 14.02.0298.004; Mon, 16 Jul 2012 08:45:02 +1200 From: "Eustace, Glen" To: dhcwg Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNYGwvIo7YZHxtLUu8zFI5r0fWlJcmZs0AgARtwQA= Date: Sun, 15 Jul 2012 20:45:02 +0000 Message-ID: In-Reply-To: <1845045610.32919.1342184828721.JavaMail.root@network1.net> Accept-Language: en-NZ, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [10.100.189.3] Content-Type: multipart/alternative; boundary="_000_CC298347AE7BGEustacemasseyacnz_" MIME-Version: 1.0 Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Sun, 15 Jul 2012 20:45:09 -0000 --_000_CC298347AE7BGEustacemasseyacnz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Some equipment doesn't use any mac at all to generate the DUID which is p= erfectly acceptable in the related RFC. > If the DUID always used the mac, then we wouldn't need this draft at all. Correct but in an Enterprise environment like ours, the majority of clients= do. I haven't seen any that don't yet. I just thought it might be interes= ting to see in how many cases the MAC used for IPv4 actually was successful= in identifying the client (for back office purposes) --_000_CC298347AE7BGEustacemasseyacnz_ Content-Type: text/html; charset="us-ascii" Content-ID: <5110B327825DBB4AA256E621209B9FC1@local> Content-Transfer-Encoding: quoted-printable

> Some equipme= nt doesn't use any mac at all to generate the DUID which is perfectly = acceptable in the related RFC.
> If= the DUID always used the mac, then we wouldn't need this draft at all.

Correct but = in an Enterprise environment like ours, the majority of clients do. I haven= 't seen any that don't yet.  I just thought it might be interesting to see in how many cases the MAC used for IPv4 act= ually was successful in identifying the client (for back office purposes)


 --_000_CC298347AE7BGEustacemasseyacnz_-- From leaf.y.yeh@huawei.com Mon Jul 16 03:28: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 A7AD821F86DD for ; Mon, 16 Jul 2012 03:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.287 X-Spam-Level: X-Spam-Status: No, score=-6.287 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRAEArsM-KQ4 for ; Mon, 16 Jul 2012 03:28:28 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id EE88721F86CF for ; Mon, 16 Jul 2012 03:28:27 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHU31295; Mon, 16 Jul 2012 06:29:11 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 03:26:39 -0700 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 03:26:40 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Mon, 16 Jul 2012 18:26:35 +0800 From: Leaf yeh To: dhcwg Thread-Topic: New Version Notification for draft-yeh-dhc-dhcpv6-prefix-pool-opt-07.txt Thread-Index: AQHNYzs1ut4jZJ52MEiMcj6ETvi/6Jcrssuw Date: Mon, 16 Jul 2012 10:26:34 +0000 Message-ID: References: <20120716100932.11165.88679.idtracker@ietfa.amsl.com> In-Reply-To: <20120716100932.11165.88679.idtracker@ietfa.amsl.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.160] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] New Version Notification for draft-yeh-dhc-dhcpv6-prefix-pool-opt-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: Mon, 16 Jul 2012 10:28:28 -0000 RGVhciBESEMgZm9sa3MsDQoNClRoZSBuZXdseSB1cGRhdGVkIGluZGl2aWR1YWwgZHJhZnQgb24g dGhlIHByZWZpeCBwb29sIG9wdGlvbiAoT1BUSU9OX1BSRUZJWF9QT09MLCBbVEJEXSkgaXMgcmVh ZHkgdG8gY2FsbCBmb3IgeW91IHJldmlldy4gDQpZb3VyIHZhbHVhYmxlIGNvbW1lbnRzIHdpbGwg YmUgaGlnaGx5IGFwcHJlY2lhdGVkLg0KDQoNCkJlc3QgUmVnYXJkcywNCkxlYWYNCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFtt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgSnVseSAxNiwg MjAxMiA2OjEwIFBNDQpUbzogTGVhZiB5ZWgNCkNjOiBodWpAY3RicmkuY29tLmNuOyBtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LXllaC1kaGMtZGhjcHY2LXByZWZpeC1wb29sLW9wdC0wNy50eHQNCg0KDQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteWVoLWRoYy1kaGNwdjYtcHJlZml4LXBvb2wtb3B0LTA3 LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMZWFmIFkuIFllaCBhbmQg cG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXllaC1k aGMtZGhjcHY2LXByZWZpeC1wb29sLW9wdA0KUmV2aXNpb246CSAwNw0KVGl0bGU6CQkgUHJlZml4 IFBvb2wgT3B0aW9uIGZvciBESENQdjYgUmVsYXkgQWdlbnRzIG9uIFByb3ZpZGVyIEVkZ2UgUm91 dGVycw0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMDctMTYNCldHIElEOgkJIEluZGl2aWR1YWwgU3Vi bWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxMw0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC15ZWgtZGhjLWRoY3B2Ni1wcmVmaXgtcG9v bC1vcHQtMDcudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQteWVoLWRoYy1kaGNwdjYtcHJlZml4LXBvb2wtb3B0DQpIdG1saXplZDogICAg ICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXllaC1kaGMtZGhjcHY2LXByZWZp eC1wb29sLW9wdC0wNw0KRGlmZjogICAgICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LXllaC1kaGMtZGhjcHY2LXByZWZpeC1wb29sLW9wdC0wNw0KDQpBYnN0 cmFjdDoNCiAgIFRoZSBESENQdjYgUHJlZml4IFBvb2wgb3B0aW9uIHByb3ZpZGVzIGEgbWVjaGFu aXNtIGZvciBESENQdjYgUHJlZml4DQogICBEZWxlZ2F0aW9uIChESENQdjYtUEQpLCBhbGxvd2lu ZyB0aGUgREhDUHY2IHNlcnZlciB0byBub3RpZnkgYSBESENQdjYNCiAgIHJlbGF5IGFnZW50IGlt cGxlbWVudGVkIG9uIGEgUHJvdmlkZXIgRWRnZSAoUEUpIHJvdXRlciBhYm91dCBhY3RpdmUNCiAg IHByZWZpeCBwb29scyBhbGxvY2F0ZWQgYnkgdGhlIERIQ1B2NiBzZXJ2ZXIgdG8gdGhlIFBFIHJv dXRlci4gIFRoZQ0KICAgaW5mb3JtYXRpb24gb2YgYWN0aXZlIHByZWZpeCBwb29scyBjYW4gYmUg dXNlZCB0byBlbmZvcmNlIElQdjYgcm91dGUNCiAgIGFnZ3JlZ2F0aW9uIG9uIHRoZSBQRSByb3V0 ZXIgYnkgYWRkaW5nIG9yIHJlbW92aW5nIGFnZ3JlZ2F0ZWQgcm91dGVzDQogICBhY2NvcmRpbmcg dG8gdGhlIHN0YXR1cyBvZiB0aGUgcHJlZml4IHBvb2xzLiAgVGhlIGFkdmVydGlzaW5nIG9mIHRo ZQ0KICAgYWdncmVnYXRlZCByb3V0ZXMgaW4gdGhlIHJvdXRpbmcgcHJvdG9jb2wgZW5hYmxlZCBv biB0aGUgbmV0d29yay0NCiAgIGZhY2luZyBpbnRlcmZhY2Ugb2YgUEUgcm91dGVycyB3aWxsIGRy YW1hdGljYWxseSBkZWNyZWFzZXMgdGhlIG51bWJlcg0KICAgb2YgdGhlIHJvdXRpbmcgdGFibGUg ZW50cmllcyBpbiB0aGUgSVNQIG5ldHdvcmsuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN Cg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From dankney@network1.net Mon Jul 16 05:52: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 897C721F8814 for ; Mon, 16 Jul 2012 05:52:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvRH577QNr8B for ; Mon, 16 Jul 2012 05:52:40 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8AC21F8813 for ; Mon, 16 Jul 2012 05:52:40 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id B3A9A5410F0; Mon, 16 Jul 2012 08:53:23 -0400 (EDT) Date: Mon, 16 Jul 2012 08:53:23 -0400 (EDT) From: perl-list To: Glen Eustace Message-ID: <1979796211.37016.1342443203647.JavaMail.root@network1.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_37015_2069659810.1342443203646" X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC20 (Mac)/7.2.0_GA_2669) Cc: dhcwg Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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, 16 Jul 2012 12:52:41 -0000 ------=_Part_37015_2069659810.1342443203646 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I can't remember which, but it is either Mac OS or windows 7 that use a random mac to generate the link local address and in turn use the link local to generate the DUID (or the reverse - in any case, it wasn't the mac of the interface). D-Link routers use no mac at all and just randomly generate the DUID. Neither of those device's macs can be gotten from the DUID. ----- Original Message ----- > From: "Glen Eustace" > To: "dhcwg" > Sent: Sunday, July 15, 2012 4:45:02 PM > Subject: Re: [dhcwg] I-D Action: > draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt > > Some equipment doesn't use any mac at all to generate the DUID > > which is perfectly acceptable in the related RFC. > > If the DUID always used the mac, then we wouldn't need this draft > > at all. > Correct but in an Enterprise environment like ours, the majority of > clients do. I haven't seen any that don't yet. I just thought it > might be interesting to see in how many cases the MAC used for IPv4 > actually was successful in identifying the client (for back office > purposes) > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg ------=_Part_37015_2069659810.1342443203646 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 can't remember which, but it is either Mac OS or windows 7 th= at use a random mac to generate the link local address and in turn use the = link local to generate the DUID (or the reverse - in any case, it wasn't th= e mac of the interface).  D-Link routers use no mac at all and just ra= ndomly generate the DUID.  Neither of those device's macs can be gotte= n from the DUID.

From: "Glen Eustace" <G= .Eustace@massey.ac.nz>
To: "dhcwg" <dhcwg@ietf.org>
<= b>Sent: Sunday, July 15, 2012 4:45:02 PM
Subject: Re: [dhcwg]= I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt

> Some equipme= nt doesn't use any mac at all to generate the DUID which is perfectly = acceptable in the related RFC.
> If= the DUID always used the mac, then we wouldn't need this draft at all.

Correct but = in an Enterprise environment like ours, the majority of clients do. I haven= 't seen any that don't yet.  I just thought it might be interesting to see in how many cases the MAC used for IPv4 act= ually was successful in identifying the client (for back office purposes)
_______________________________________________
dhcwg mailing listdhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

------=_Part_37015_2069659810.1342443203646-- From tjc@ecs.soton.ac.uk Mon Jul 16 06:23: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 74A9921F87B2 for ; Mon, 16 Jul 2012 06:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.726 X-Spam-Level: X-Spam-Status: No, score=-1.726 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuYh5P4p1dKc for ; Mon, 16 Jul 2012 06:23:40 -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 B211321F878E for ; Mon, 16 Jul 2012 06:23:39 -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 q6GDOG60021203 for ; Mon, 16 Jul 2012 14:24:16 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q6GDOG60021203 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1342445057; bh=n9ZYXuMvMRK7RpHqj4y8+M16gIA=; h=From:Mime-Version:Subject:Date:In-Reply-To:To:References; b=gBQAQ0CIlpj7vjCQc/dWeJqXsbC6C6agfDJkNqCIOPHoznuKIVGmBIJ6HgPIZN5/t lEPF7p+U5pqilCj0oQx3jtxk/rC+zO/RWPkOHGZsqW3WMu2RUi07ZNCSQyW4paomP/ BFjuitOS3Jk+0MyUaLct4dDMxbI1m+HvvwhH9xnY= 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 o6FEOG0430617100kU ret-id none; Mon, 16 Jul 2012 14:24:16 +0100 Received: from ip-205-203.eduroam.soton.ac.uk (ip-205-203.eduroam.soton.ac.uk [152.78.205.203]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q6GDOEZb023505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 16 Jul 2012 14:24:14 +0100 From: Tim Chown Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_2B3BB76A-D667-4950-BFAA-C93D083A1E5D" Date: Mon, 16 Jul 2012 14:24:13 +0100 In-Reply-To: To: dhcwg@ietf.org References: <229DF3CC-E508-4B92-B9F7-EB6D7EA38671@ecs.soton.ac.uk> Message-ID: X-Mailer: Apple Mail (2.1278) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o6FEOG043061710000; tid=o6FEOG0430617100kU; 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: q6GDOG60021203 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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, 16 Jul 2012 13:23:41 -0000 --Apple-Mail=_2B3BB76A-D667-4950-BFAA-C93D083A1E5D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Glen, Does that mean all your devices/OSes are by default using DUID-LL? The = spec says that the client must use *a* MAC address; it may not happen to = pick the one corresponding to the interface that the query comes from.=20= It would be very interesting to see other enterprises who are using = DHCPv6 reporting what they see. And interesting to also note how often = observed DUIDs change over time, e.g. from dual-boot systems. The relay function seems useful to me. In a typical campus environment = that we'd be interested in, all requests would be forwarded by a relay, = thus client support would not be essential in our environment. It would seem very likely the proposed draft would be used by some = enterprise admins to try to perform the same type of "accountability" = that exists for DHCPv4 with DHCPv6. That's a question that frequently = crops up from new sites considering IPv6 deployment. Tim On 12 Jul 2012, at 21:23, Eustace, Glen wrote: > As one of these IT departments, I thought that some empirical data = might be useful. >=20 > We have now got ISC dhcpd running on our main campus and I have just = completed adding native IPv6 to the majority of networks. We do NOT yet = have DUIDs stored in our databases but do have the MAC address for the = primary NIC for all University owned equipment. >=20 > I have the hardware-ethernet included in each host declaration for = both IPv4 and IPv6. Using the ISC fudge of deconstructing the type 1 = DUID, we have 1224 matches out of 1693 active leases. Whilst not = perfect, it is actually better than I expected and for us does add = value. >=20 > I have not yet attempted to determine why we failed to match the = remaining leases, could be a number of reasons > Private equipment for which we do not have a MAC in the DB > The DUID generated used a MAC we don't have in the DB > The MAC we have is wrong. > etc > --=20 > = =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= - > Glen Eustace, Infrastructure Development Engineer (BC/DR) > Information Technology Service, Massey University PN460 > Tennent Drive, Palmerston North, New Zealand > Ph: +64-6-3569099 x 81005, Fax: +64-6-3505607, Mob: +64-27-4500321 >=20 > From: "Ted com>" > Date: Thu, 12 Jul 2012 19:49:59 +0000 > To: Andre Kostur > Cc: "" , Marc Perea = > Subject: Re: [dhcwg] I-D Action: = draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt >=20 > On Jul 12, 2012, at 3:40 PM, Andre Kostur wrote: >> Ok, if we're restricting to ISP environments, why not mandate in such >> environments that they should be using the Remote ID (RFC 4649) to >> specify the downstream "client". Note that in DOCSIS environments, >> this is already happening. (Just not in RFC 4649 form... but in an >> enterprise-specific option 17). >=20 > It's my understanding that the main motivator for this draft is use in = corporate IT departments that inventory machines by MAC address. I = guess it would also be useful for ISPs, but that's certainly not the use = case that I've heard mentioned most. >=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 --Apple-Mail=_2B3BB76A-D667-4950-BFAA-C93D083A1E5D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Glen,

Does that mean all your devices/OSes are by = default using DUID-LL?  The spec says that the client must use *a* = MAC address; it may not happen to pick the one corresponding to the = interface that the query comes from. 

It = would be very interesting to see other enterprises who are using DHCPv6 = reporting what they see. And interesting to also note how often observed = DUIDs change over time, e.g. from dual-boot = systems.

The relay function seems useful to me. = In a typical campus environment that we'd be interested in, all requests = would be forwarded by a relay, thus client support would not be = essential in our environment.

It would seem = very likely the proposed draft would be used by some enterprise admins = to try to perform the same type of "accountability" that exists for = DHCPv4 with DHCPv6.  That's a question that frequently crops up = from new sites considering IPv6 = deployment.

Tim

On 12 = Jul 2012, at 21:23, Eustace, Glen wrote:

As one of these IT departments, I thought that some empirical data = might be useful.

We have now got ISC dhcpd running on our main campus and I have = just completed adding native IPv6 to the majority of networks.  We = do NOT yet have DUIDs stored in our databases but do have the MAC = address for the primary NIC for all University owned equipment.

I have the  hardware-ethernet included in each host = declaration for both IPv4 and IPv6.  Using the ISC fudge of = deconstructing the type 1 DUID, we have 1224 matches out of 1693 active = leases.  Whilst not perfect, it is actually better than I expected = and for us does add value.

I have not yet attempted to determine why we failed to match the = remaining leases, could be a number of reasons
  1. Private equipment for which we do not have a MAC in the = DB
  2. The DUID generated used a MAC we don't have in the = DB
  3. The MAC we have is wrong.
  4. etc
-- 
=
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-
Glen Eustace, Infrastructure Development Engineer (BC/DR)
Information Technology Service, Massey University PN460
Tennent Drive, Palmerston North, New Zealand
Ph: +64-6-3569099 x 81005, Fax: +64-6-3505607, Mob: = +64-27-4500321

From: "Ted com>" <Ted.Lemon@nominum.com>
Date: Thu, 12 Jul 2012 19:49:59 = +0000
To: Andre Kostur <akostur@incognito.com>
Cc: "<dhcwg@ietf.org>" <dhcwg@ietf.org>, Marc Perea <marccp@srttel.com>
Subject: Re: [dhcwg] I-D Action: = draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt

On Jul 12, 2012, at 3:40 PM, Andre Kostur wrote:
Ok, if we're = restricting to ISP environments, why not mandate in such
environments that they should be using the Remote = ID (RFC 4649) to
specify the downstream "client".  Note that in = DOCSIS environments,
this is already happening.  (Just not in RFC = 4649 form... but in an
enterprise-specific option 17).

It's my understanding that the main motivator for this draft is use = in corporate IT departments that inventory machines by MAC address. =   I guess it would also be useful for ISPs, but that's certainly = not the use case that I've heard mentioned most.

_______________________________________________ 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

= --Apple-Mail=_2B3BB76A-D667-4950-BFAA-C93D083A1E5D-- From G.Eustace@massey.ac.nz Mon Jul 16 15:37: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 5F74F11E8336 for ; Mon, 16 Jul 2012 15:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWzunJk6ijUA for ; Mon, 16 Jul 2012 15:37:52 -0700 (PDT) Received: from tur-issmail1.massey.ac.nz (tur-issmail1.massey.ac.nz [130.123.96.135]) by ietfa.amsl.com (Postfix) with ESMTP id 23AEC11E8333 for ; Mon, 16 Jul 2012 15:37:51 -0700 (PDT) Received: from tur-mm5.massey.ac.nz (tur-mm5.massey.ac.nz [130.123.96.133]) by tur-issmail1.massey.ac.nz (Postfix) with ESMTP id 35E7AE99 for ; Tue, 17 Jul 2012 10:38:34 +1200 (NZST) Received: from tur-exch-cas2.massey.ac.nz (Not Verified[10.100.189.3]) by tur-mm5.massey.ac.nz with MailMarshal id ; Tue, 17 Jul 2012 10:38:33 +1200 Received: from TUR-EXCH-NODE2.massey.ac.nz ([fe80::6d90:b430:e061:20ed]) by tur-exch-cas2.massey.ac.nz ([fe80::1868:bfeb:eb89:2%13]) with mapi id 14.02.0298.004; Tue, 17 Jul 2012 10:38:33 +1200 From: "Eustace, Glen" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt Thread-Index: AQHNY6O7uMVE9Uysc0SHS5ylQzAzqA== Date: Mon, 16 Jul 2012 22:38:33 +0000 Message-ID: In-Reply-To: Accept-Language: en-NZ, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [10.100.189.3] Content-Type: multipart/alternative; boundary="_000_CC2AE67BAF0CGEustacemasseyacnz_" MIME-Version: 1.0 Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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, 16 Jul 2012 22:37:53 -0000 --_000_CC2AE67BAF0CGEustacemasseyacnz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tim, > Does that mean all your devices/OSes are by default using DUID-LL? The s= pec says that the client > must use *a* MAC address; it may not happen to pick the one corresponding= to the interface that > the query comes from. No, the vast majority are DUID-LLT, there are some DUID-LLs. The version = of the ISC DHCPv6 code I am running deconstructs the DUID and attempts to m= atch the MAC address with the host hardware-addres if a host DUID isn't spe= cified in the config file, this is a hack but is proving useful as we do no= t have the DUIDs in our database yet still want to try to match the lease t= o the client primarily so that the forward DDNS uses the official name of t= he client. > It would be very interesting to see other enterprises who are using DHCPv= 6 reporting what they see. > And interesting to also note how often observed DUIDs change over time, e= .g. from dual-boot systems. I haven't had a chance to look at anything like this yet. > The relay function seems useful to me. In a typical campus environment th= at we'd be interested in > all requests would be forwarded by a relay, thus client support would not= be essential in our environment. Same here but for the hosts in the same network as the DHCP servers. > It would seem very likely the proposed draft would be used by some enterp= rise admins to try to perform > the same type of "accountability" that exists for DHCPv4 with DHCPv6. Th= at's a question that frequently > crops up from new sites considering IPv6 deployment. I think if is was up to me, I'd be pushing for SLAAC for the majority of ou= r clients but it isn't and the security team wants 'accountability' just li= ke they think they have with IPv4. So I have to do my best to get DHCPv6 do= ing something similar to DHCPv4. Glen. --_000_CC2AE67BAF0CGEustacemasseyacnz_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Tim,

> = ;Does that mean all your devices/OSes are by default using= DUID-LL?  The spec says that the client
> must use *a* MAC address; it may not happen to pick the= one corresponding to the interface that
> the query comes from. 

No, the vast major= ity are DUID-LLT, there are some DUID-LLs.   The version of the ISC DH= CPv6 code I am running deconstructs the DUID and attempts to match the MAC = address with the host hardware-addres if a host DUID isn't specified in the config file, this is a hack but is prov= ing useful as we do not have the DUIDs in our database yet still want to tr= y to match the lease to the client primarily so that the forward DDNS uses = the official name of the client.

> It would be very interesting to see other enterprises who are usi= ng DHCPv6 reporting what they see.
> And interesting to also note how often observed DUIDs change over= time, e.g. from dual-boot systems.

I haven't had a ch= ance to look at anything like this yet.

> The relay fun= ction seems useful to me. In a typical campus environment that we'd be inte= rested in
> all requests would be forwarded by a relay, thus client supp= ort would not be essential in our environment.

Same here but for the hosts in the same network as the DHCP servers.

> It would seem very likely the proposed draft would be used b= y some enterprise admins to try to perform
> the same type of "accountability" that exists for DHCPv= 4 with DHCPv6.  That's a question that frequently
> crops up from new sites considering IPv6 deployment.

I think if is was up to me, I'd be pushing for SLAAC for the majority = of our clients but it isn't and the security team wants 'accountability' ju= st like they think they have with IPv4. So I have to do my best to get DHCP= v6 doing something similar to DHCPv4.

Glen.


 --_000_CC2AE67BAF0CGEustacemasseyacnz_-- From hansliu@gmail.com Mon Jul 16 18:11: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 0955911E8088 for ; Mon, 16 Jul 2012 18:11:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAf6bHiox1DA for ; Mon, 16 Jul 2012 18:11:17 -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 44F8A11E8087 for ; Mon, 16 Jul 2012 18:11:17 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1009326wgb.13 for ; Mon, 16 Jul 2012 18:12:02 -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=+pSpSq/N04K5bA2tL14G4GsyWRHnbQMKWrejTb1xyUQ=; b=XlGJNNHg4PBRe5C7wV+bfpkl9/0Qt/I0bvCA5X69T+iU6UFgI+J8sgNLMp265rmM3e 5GNjcpTG1UOVyGnkAoIGurDaJH0ZGa6wHlPElDuf3vlRDQlOpGtwMOIRTLnsTJNX9xuH gowTbhwpyTwhFC6B8bD9XxuywKlhIohxyPJa7wBkf1ACatxVZMvf8oX1jJXMoRwKMy6J L2nUqtrSK3+zbwm9s1NWsnxIhtzi9gVWHE8Nxxt2++nzj+iCelI+GNVgAw6zvyRaaCWx G+xivwO29++Ptj92vGUm54xQDVoSoYmLGAJBsvTpTEK+Ak0Vd/4mKtW9jU/WIsRJ/jkk 52dw== MIME-Version: 1.0 Received: by 10.180.78.35 with SMTP id y3mr10307918wiw.16.1342487522605; Mon, 16 Jul 2012 18:12:02 -0700 (PDT) Received: by 10.223.143.71 with HTTP; Mon, 16 Jul 2012 18:12:02 -0700 (PDT) In-Reply-To: <1979796211.37016.1342443203647.JavaMail.root@network1.net> References: <1979796211.37016.1342443203647.JavaMail.root@network1.net> Date: Tue, 17 Jul 2012 09:12:02 +0800 Message-ID: From: Hans Liu To: perl-list Content-Type: text/plain; charset=UTF-8 Cc: dhcwg Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-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: Tue, 17 Jul 2012 01:11:18 -0000 D-Link DIR-series routers should use DUID-LL by default. Regards, Hans On Mon, Jul 16, 2012 at 8:53 PM, perl-list wrote: > I can't remember which, but it is either Mac OS or windows 7 that use a > random mac to generate the link local address and in turn use the link local > to generate the DUID (or the reverse - in any case, it wasn't the mac of the > interface). D-Link routers use no mac at all and just randomly generate the > DUID. Neither of those device's macs can be gotten from the DUID. > From dthaler@microsoft.com Wed Jul 18 14:49: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 E2B4411E80A2; Wed, 18 Jul 2012 14:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.414 X-Spam-Level: X-Spam-Status: No, score=-103.414 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68z2BTMPyWNl; Wed, 18 Jul 2012 14:49:42 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id C498111E8087; Wed, 18 Jul 2012 14:49:41 -0700 (PDT) Received: from mail82-db3-R.bigfish.com (10.3.81.245) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 18 Jul 2012 21:50:32 +0000 Received: from mail82-db3 (localhost [127.0.0.1]) by mail82-db3-R.bigfish.com (Postfix) with ESMTP id 7769B44019E; Wed, 18 Jul 2012 21:50:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371I542M1432I4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail82-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail82-db3 (localhost.localdomain [127.0.0.1]) by mail82-db3 (MessageSwitch) id 1342648231662682_30037; Wed, 18 Jul 2012 21:50:31 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.228]) by mail82-db3.bigfish.com (Postfix) with ESMTP id 9F9233A0206; Wed, 18 Jul 2012 21:50:31 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 18 Jul 2012 21:50:31 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.309.3; Wed, 18 Jul 2012 21:50:22 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.309.3; Wed, 18 Jul 2012 14:50:21 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Wed, 18 Jul 2012 14:50:21 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwABZYWw Date: Wed, 18 Jul 2012 21:50:21 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B70B380@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 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, 18 Jul 2012 21:49:43 -0000 Correcting DHC WG email address. > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Dav= e > Thaler > Sent: Wednesday, July 18, 2012 2:21 PM > To: pcp@ietf.org > Cc: dhc@ietf.org > Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 >=20 > As discussed at last IETF, the authors believe that all issues raised so = far have > been addressed. No new issues have been raised since then, so this messa= ge > begins a Working Group Last Call on draft-ietf-pcp-dhcp-03. >=20 > This call would normally conclude in two weeks but that is during IETF we= ek, so > the last call is extended to conclude at the end of IETF (as of the Frida= y PCP > meeting). >=20 > We also agreed in Vancouver that this last call will be cross-posted to t= he DHC > list, hence cc'ing the DHC WG. >=20 > We need at least 5 reviewers. Please send comments to the list. >=20 > Thanks, > -Dave Thaler >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From cuiyang@huawei.com Thu Jul 19 01:22: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 A8F8D21F86D1 for ; Thu, 19 Jul 2012 01:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.337 X-Spam-Level: X-Spam-Status: No, score=-4.337 tagged_above=-999 required=5 tests=[AWL=2.263, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KaFwKP5N5CJ for ; Thu, 19 Jul 2012 01:22:12 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BC6B421F86CB for ; Thu, 19 Jul 2012 01:22:10 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AID72122; Thu, 19 Jul 2012 04:23:02 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 19 Jul 2012 01:21:04 -0700 Received: from SZXEML434-HUB.china.huawei.com (10.72.61.62) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 19 Jul 2012 01:21:02 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.245]) by szxeml434-hub.china.huawei.com ([10.72.61.62]) with mapi id 14.01.0323.003; Thu, 19 Jul 2012 16:20:57 +0800 From: Cuiyang To: dhc WG Thread-Topic: New Version Notification for draft-bi-dhc-sec-option-02.txt Thread-Index: AQHNYzXZoETU98+IrkGaZig9RZMuEJcwRUTA Date: Thu, 19 Jul 2012 08:20:57 +0000 Message-ID: <8CC0CB0BCAE52F46882E17828A9AE2163684D50E@SZXEML508-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.48.119] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [dhcwg] Fwd: New Version Notification for draft-bi-dhc-sec-option-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: Thu, 19 Jul 2012 08:22:14 -0000 SGksIEFsbA0KDQpBY2NvcmRpbmcgdG8gdGhlIGNvbW1lbnRzIGluIHRoZSBsYXN0IG1lZXRpbmcg QFBhcmlzLCB3ZSB1cGRhdGVkIHRoZSBkcmFmdC4NCkNoYW5nZXMgYXJlIG1haW5seSBhcyBmb2xs b3dzOg0KMS4gcmVtb3ZlIHRoZSB1bnVzZWQgYW5kIHNwZWNpZmljIHN1Yi1vcHRpb25zDQoyLiBk ZWZpbmUgYSAiZ2VuZXJhbCIgc2VjdXJpdHkgb3B0aW9uIHRoYXQgcHJvdmlzaW9ucyBjb25maWd1 cmF0aW9uIGluZm9ybWF0aW9uIHRvIERIQ1AgY2xpZW50cy4NCg0KQW55IGNvbW1lbnQgd2lsbCBi ZSBhcHByZWNpYXRlZC4NClRoYW5rcyENCg0KQlIsDQpZYW5nDQo9PT09PT09PT09PT09PT09PT0N CiBZYW5nIEN1aSwgIFBoLkQuDQogSHVhd2VpIFRlY2hub2xvZ2llcw0KIGN1aXlhbmdAaHVhd2Vp LmNvbQ0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQrlj5HpgIHml7bp l7Q6IDIwMTLlubQ35pyIMTbml6UgMTc6MzENCuaUtuS7tuS6ujogQ3VpeWFuZw0K5Li76aKYOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJpLWRoYy1zZWMtb3B0aW9uLTAyLnR4 dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1iaS1kaGMtc2VjLW9wdGlvbi0wMi50 eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWWFuZyBDdWkgYW5kIHBvc3Rl ZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1iaS1kaGMtc2Vj LW9wdGlvbg0KUmV2aXNpb246CSAwMg0KVGl0bGU6CQkgU2VjdXJpdHkgb3B0aW9uIGV4dGVuc2lv bnMgZm9yIERIQ1ANCkNyZWF0aW9uIGRhdGU6CSAyMDEyLTA3LTE2DQpXRyBJRDoJCSBJbmRpdmlk dWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogNw0KVVJMOiAgICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1iaS1kaGMtc2VjLW9wdGlvbi0w Mi50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1iaS1kaGMtc2VjLW9wdGlvbg0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1iaS1kaGMtc2VjLW9wdGlvbi0wMg0KRGlmZjogICAgICAgICAgICBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWJpLWRoYy1zZWMtb3B0aW9u LTAyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IG9wdGlvbiB0 aGF0IGNhbiBiZSB1c2VkIGJ5IERIQ1Agc2VydmVycw0KICAgdG8gcHJvdmlzaW9uIHdpdGggREhD UCBjbGllbnRzIHNwZWNpZmljIHNlY3VyaXR5IGNvbmZpZ3VyYXRpb24NCiAgIGluZm9ybWF0aW9u LiBJdCBoYXMgYmVlbiBrbm93biB0aGF0IERIQ1AgcHJvdG9jb2wgdHlwaWNhbGx5IHdvcmtzIGF0 DQogICB0aGUgdmVyeSBiZWdpbm5pbmcgc3RhZ2Ugb2YgdGhlIGFjY2VzcyB0byBuZXR3b3Jrcywg dGh1cyBsYWNrIG9mDQogICBzZWN1cml0eSBwcm90ZWN0aW9uLiBIb3dldmVyLCBhbHRob3VnaCBp dCBpcyBkaWZmaWN1bHQgdG8gc2V0IHVwIHNvbWUNCiAgIHNlY3VyaXR5IG1lY2hhbmlzbSBmb3Ig REhDUCBwcm90b2NvbCBzb2xlbHksIGl0IGlzIGFibGUgdG8gcGxheSBhIGtleQ0KICAgcm9sZSBm b3IgREhDUCBzZXJ2ZXIgdG8gcHJvdmlkZSBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIHRvIGhl bHANCiAgIGJ1aWxkaW5nIHNlY3VyaXR5IG1lY2hhbmlzbSB3aXRoaW4gdGhvc2UgcHJlLWNvbmZp Z3VyZWQgREhDUCBjbGllbnRzDQogICBhbmQgZGV2aWNlcy4gVGhpcyBuZXcgb3B0aW9uIGRlZmlu ZXMgYSBzaW1wbGUgZXh0ZW5zaW9uIHRvIGN1cnJlbnQNCiAgIHN0YW5kYXJkIGZvcm1hdCBhbmQg YmVuZWZpdHMgdG8gdGhvc2Ugd2hvIG5lZWQgdG8gYWN0aXZhdGUgc2VjdXJpdHkNCiAgIG1lY2hh bmlzbSBpbiBhbiBlYXJseSBzdGFnZSBhbmQgaW50ZXJvcGVyYXRlIHdpdGhpbiBkZXZpY2VzIGZy b20NCiAgIG11bHRpcGxlIHZlbmRvcnMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From volz@cisco.com Thu Jul 19 09:08: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 0EC8521F87BF; Thu, 19 Jul 2012 09:08:00 -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_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTNE7FSlADDc; Thu, 19 Jul 2012 09:07:59 -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 BA66321F87DC; Thu, 19 Jul 2012 09:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=3900; q=dns/txt; s=iport; t=1342714132; x=1343923732; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TZn7Iq93d0RNs/YY9qDESm2XaZdyafxJPSmQoUWPsec=; b=HOY8gWDcb9UUWqs6/7984VjHBneE0TCN5DG/ZjXoM+DEx3oMWtR9EViI AVyC+tvq+10TQ4xoMiRmxiubxqvipn58bsau96pY0Mne/xs/fhmlCb+Bw aVHFmsVQAtsYBCU7ISqVP7VvqtHWgcDQR1hTJIvIEctb1twPcGMIwuC1B c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOovCFCtJXG9/2dsb2JhbABFuUCBB4IgAQEBBAEBAQ8BJzQLDAQCAQgOAwQBAQsUCQcnCxQJCAEBBAENBQgah2sLnkKgBASLTIYwYAOjZ4Fmgl+BXw X-IronPort-AV: E=Sophos;i="4.77,615,1336348800"; d="scan'208";a="103509158" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 19 Jul 2012 16:08:42 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6JG8gGl025295 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jul 2012 16:08:42 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Thu, 19 Jul 2012 11:08:42 -0500 From: "Bernie Volz (volz)" To: Dave Thaler , "pcp@ietf.org" Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwABZYWwACWnwdA= Date: Thu, 19 Jul 2012 16:08:41 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E026F74@xmb-rcd-x04.cisco.com> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B70B380@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B70B380@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.72] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19050.003 x-tm-as-result: No--43.652000-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 on draft-ietf-pcp-dhcp-03 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, 19 Jul 2012 16:08:00 -0000 The document seems OK (reviewing from the DHC WG perspective). Minor nits: 1) 2. Terminology o DHCP refers to both DHCPv4 [RFC2131] and DHCPv6 [RFC3315]. o DHCP client (or client) denotes a node that initiates requests to obtain configuration parameters from one or more DHCP servers [RFC3315]. o DHCP server (or server) refers to a node that responds to requests from DHCP clients [RFC3315]. Why are DHCP client / DHCP server just RFC 3315 and use of "DHCP" here impl= ies RFC 2131 and 3315 from the earlier terminology. 2) 4.1. Format 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_PCP_SERVER | Option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : PCP Server Domain Name : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: PCP Server Name DHCPv6 Option The fields of the option shown in Figure 1 are as follows: o Option-code: OPTION_PCP_SERVER (TBA, see Section 9.1) o Option-length: Length of the 'PCP Server Domain Name' field in octets. o PCP Server Domain Name: The domain name of the PCP Server to be used by the PCP Client. The domain name is encoded as specified in Section 8 of [RFC3315]. The OPTION_PCP_SERVER option can include multiple PCP Server Domain Names; each Name is treated as a separate PCP Server. Would it not be appropriate to change the "PCP Server Domain Name" to be "P= CP Server Domain Name(s)"? And make the description clear that it can be on= e or more rather than adding this later (where it easily might be missed). The same applies to the DHCPv4 option (section 5.1). 3) Be nice if the DHCPv4 domain name encoding clarified that compression was n= ot allowed (though RFC 1035 section 3.1 does not say anything about that to= pic)? Perhaps use the RFC 3315 Section 8 text: A domain name, or list of domain names, in DHCP MUST NOT be stored in c= ompressed form, as described in section 4.1.4 of RFC 1035. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of D= ave Thaler Sent: Wednesday, July 18, 2012 5:50 PM To: pcp@ietf.org Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 Correcting DHC WG email address. > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of=20 > Dave Thaler > Sent: Wednesday, July 18, 2012 2:21 PM > To: pcp@ietf.org > Cc: dhc@ietf.org > Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 >=20 > As discussed at last IETF, the authors believe that all issues raised=20 > so far have been addressed. No new issues have been raised since=20 > then, so this message begins a Working Group Last Call on draft-ietf-pcp-= dhcp-03. >=20 > This call would normally conclude in two weeks but that is during IETF=20 > week, so the last call is extended to conclude at the end of IETF (as=20 > of the Friday PCP meeting). >=20 > We also agreed in Vancouver that this last call will be cross-posted=20 > to the DHC list, hence cc'ing the DHC WG. >=20 > We need at least 5 reviewers. Please send comments to the list. >=20 > Thanks, > -Dave Thaler >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Fri Jul 20 07:57: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 9F1D121F8593 for ; Fri, 20 Jul 2012 07:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.696 X-Spam-Level: X-Spam-Status: No, score=-105.696 tagged_above=-999 required=5 tests=[AWL=-0.851, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-HK+fhT8HYD for ; Fri, 20 Jul 2012 07:57:20 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id EC77A21F858E for ; Fri, 20 Jul 2012 07:57:19 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUAlyBzvSPYZJ9mDJgJqQTxJxSkh14mlU@postini.com; Fri, 20 Jul 2012 07:58: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 9B7C41B8310 for ; Fri, 20 Jul 2012 07:58:14 -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 8E52319005D; Fri, 20 Jul 2012 07:58:14 -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, 20 Jul 2012 07:58:14 -0700 From: Ted Lemon To: yangtianle Thread-Topic: draft-yang-dhc-ipv4-dis-01 Thread-Index: AQHNZmC1evhIu2B8UUi7uy4olciUPJcyuMKA Date: Fri, 20 Jul 2012 14:58:14 +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: multipart/alternative; boundary="_000_F1562890B52E4D48A279E1AA7E68292Enominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] draft-yang-dhc-ipv4-dis-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, 20 Jul 2012 14:57:21 -0000 --_000_F1562890B52E4D48A279E1AA7E68292Enominumcom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 T24gSnVsIDIwLCAyMDEyLCBhdCA2OjE2IEFNLCB5YW5ndGlhbmxlIHdyb3RlOg0KQ291bGQgeW91 IGhlbHAgbWUgc2VuZGluZyB0aGUgbWFpbCB0byB0aGUgV0c/ICBJIGRvbid0IGtub3cgd2h5IG15 IG1haWwgd2FzIHJlamVjdGVkIHR3aWNlLg0KDQpUaGUgbWVzc2FnZSB3YXMgcmVqZWN0ZWQgYmVj YXVzZSBpdCBjb250YWluZWQgamF2YXNjcmlwdCBjb2RlIG1lYW50IHRvIGJlIGV4ZWN1dGVkIGJ5 IHRoZSBlbWFpbCBwcm9ncmFtOyB0aGlzIGlzIG5vdCBhcHByb3ByaWF0ZS4gICBUaGVyZSB3ZXJl IGFsc28gaGVhZGVycyB0aGF0IHRoZSBtYWlsIHByb2dyYW0gZGlkbid0IGxpa2UuDQoNClRoZSBv cHRpb24gdGhhdCB5b3UncmUgcHJvcG9zaW5nIHNvdW5kcyBsaWtlIGEgREhDUHY0IHByb3RvY29s IGV4dGVuc2lvbiBzaW1pbGFyIHRvIHRoZSBTT0xfTUFYX1JUIGV4dGVuc2lvbiBmb3IgREhDUHY2 LiAgIFdoYXQgdGVzdCByZXN1bHRzIGFyZSB5b3UgdGFsa2luZyBhYm91dD8NCg0K --_000_F1562890B52E4D48A279E1AA7E68292Enominumcom_ Content-Type: text/html; charset="gb2312" Content-ID: <68853D315477C741932AEB272B525BEC@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jul 20, 2012, at 6:16 AM, yangtianle wrote:
Could you help me sending the mail to the WG?  I don't know why my mail was= rejected twice.

The message was rejected because it contained javascript code meant to= be executed by the email program; this is not appropriate.   There we= re also headers that the mail program didn't like.

The option that you're proposing sounds like a DHCPv4 protocol extensi= on similar to the SOL_MAX_RT extension for DHCPv6.   What test results= are you talking about?

--_000_F1562890B52E4D48A279E1AA7E68292Enominumcom_-- From wwwrun@rfc-editor.org Fri Jul 20 10:12: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 1972811E8088; Fri, 20 Jul 2012 10:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OFpTFS6qC-T; Fri, 20 Jul 2012 10:12:15 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9D97D11E8085; Fri, 20 Jul 2012 10:12:15 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7B414621A1; Fri, 20 Jul 2012 10:12:29 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120720171229.7B414621A1@rfc-editor.org> Date: Fri, 20 Jul 2012 10:12:29 -0700 (PDT) Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] RFC 6656 on Description of Cisco Systems' Subnet Allocation Option for DHCPv4 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, 20 Jul 2012 17:12:16 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6656 Title: Description of Cisco Systems' Subnet Allocation Option for DHCPv4 Author: R. Johnson, K. Kinnear, M. Stapp Status: Informational Stream: IETF Date: July 2012 Mailbox: raj@cisco.com, kkinnear@cisco.com, mjs@cisco.com Pages: 24 Characters: 54971 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-subnet-alloc-13.txt URL: http://www.rfc-editor.org/rfc/rfc6656.txt This memo documents a DHCPv4 option that currently exists and was previously privately defined for the operation and usage of the Cisco Systems' Subnet Allocation Option for DHCPv4. The option is passed between the DHCPv4 Client and the DHCPv4 Server to request dynamic allocation of a subnet, give specifications of the subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with RFC 3942, which declares that any preexisting usages of option numbers in the range 128-223 should be documented and that the working group will try to officially assign those numbers to those options. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Dynamic Host Configuration Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From leaf.y.yeh@huawei.com Tue Jul 24 21:14:25 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 6F11B11E8080 for ; Tue, 24 Jul 2012 21:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.328 X-Spam-Level: X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcjEt1ujxvjk for ; Tue, 24 Jul 2012 21:14:25 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E688711E807F for ; Tue, 24 Jul 2012 21:14:24 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIH94438; Wed, 25 Jul 2012 00:14:24 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jul 2012 21:12:03 -0700 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jul 2012 21:12:01 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Wed, 25 Jul 2012 12:11:55 +0800 From: Leaf yeh To: dhcwg Thread-Topic: Test++ Thread-Index: AQHNahugS6mB1Tea0UeIilQuJRr2EA== Date: Wed, 25 Jul 2012 04:11:54 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: ACkn AI2p AxO0 BiNe DEGB D4sN Evyl E/rV FmYt F+zm GUn8 GwDD Hl0F H9Fe JBql J7Xr; 1; ZABoAGMAdwBnAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {FC632680-E1F2-48DC-BCBA-3D68894663CF}; bABlAGEAZgAuAHkALgB5AGUAaABAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Wed, 25 Jul 2012 04:11:52 GMT;VABlAHMAdAArACsA x-cr-puzzleid: {FC632680-E1F2-48DC-BCBA-3D68894663CF} 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: [dhcwg] Test++ 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, 25 Jul 2012 04:14:25 -0000 > Pls. ignore this mail. Sorry for the disturbance. Best Regards, Leaf From dthaler@microsoft.com Thu Jul 26 14:59: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 1C30F11E80BD for ; Thu, 26 Jul 2012 14:59:22 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace: References: ...W604.wingroup.windeploy.ntdev.microsoft.com>\n X-Spam-Flag: NO X-Spam-Score: -103.42 X-Spam-Level: X-Spam-Status: No, score=-103.42 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RH5T9js4H17u for ; Thu, 26 Jul 2012 14:59:21 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id E079811E80BB for ; Thu, 26 Jul 2012 14:59:20 -0700 (PDT) Received: from mail51-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 26 Jul 2012 21:59:19 +0000 Received: from mail51-va3 (localhost [127.0.0.1]) by mail51-va3-R.bigfish.com (Postfix) with ESMTP id 990C344013E for ; Thu, 26 Jul 2012 21:59:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371I542M1432I4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail51-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail51-va3 (localhost.localdomain [127.0.0.1]) by mail51-va3 (MessageSwitch) id 1343339957923412_26845; Thu, 26 Jul 2012 21:59:17 +0000 (UTC) Received: from VA3EHSMHS038.bigfish.com (unknown [10.7.14.249]) by mail51-va3.bigfish.com (Postfix) with ESMTP id DE739360051 for ; Thu, 26 Jul 2012 21:59:17 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS038.bigfish.com (10.7.99.48) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 26 Jul 2012 21:59:17 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.298.5; Thu, 26 Jul 2012 21:59:16 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0309.003; Thu, 26 Jul 2012 14:59:16 -0700 From: Dave Thaler To: "dhcwg@ietf.org" Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QAAD2YUAAALuhAA== Date: Thu, 26 Jul 2012 21:59:14 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B7235BF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [dhcwg] FW: WGLC on draft-ietf-pcp-dhcp-03 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, 26 Jul 2012 21:59:22 -0000 I keep mangling the WG mailing list address, so forwarding. -----Original Message----- From: Dave Thaler=20 Sent: Thursday, July 26, 2012 2:58 PM To: 'pcp@ietf.org' Cc: 'dhc@ietf.org' Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 Missed responding to section 7 before sending... 7) Re "A PCP Server configured using OPTION_PCP_SERVER over DHCPv4 is likel= y to be resolved to IPv4 address(es)." I don't think I'd agree with that assumption. If I put a DNS name in = the option, it'll be resolved to whatever records are in DNS of a type the client q= ueries for. The document currently doesn't say what type(s) to query for (A vs AAAA)= . Per my comment on 2, I believe the types to query for should be independ= ent of how the name was obtained (DHCPv4, DHCPv6, manual, SNMP, or whatever els= e). =20 "A PCP Server configured using OPTION_PCP_SERVER over DHCPv6 may be resolved to IPv4-mapped IPv6 address(es) or IPv6 address(es)" By the same reasoning as my previous comment above, it may also be resol= ved to IPv4 addresses. If I have a dual-stack PCP server, I should be able= to put the same DNS name in both a DHCPv4 option and a DHCPv6 option, rather than requiring me to have two separate names for the same server. 8) Pursuant to a discussion I've been having with some folks on draft-iab-identifier-comparison section 3.1.1 and some changes I'll be = making to it as a result, it got me thinking. I'm thinking it would be good to h= ave a short subsection on Guidance to Administrators on what to configure in their = DHCP server to return in these options, or more importantly, what not to con= figure. Specifically, strings like "10.0.258", "0xA000001", and "012.0x102" wou= ld all be a bad idea to configure (unless you specified how they're to be = interpreted which is an option, though probably not the most expedient one). I'm = still strongly in favor of retaining the fact that it's a string that can be passed to= name resolution APIs, but that means it's best to avoid strings that are int= erpreted differently by different such APIs. 9) On the same point, Section 4.2 currently states: "Once each Name conveyed in the OPTION_PCP_SERVER option is validated, each included Name is passed to the name resolution library (e.g., Section 6.1.1 of [RFC1123] or [RFC6055])" The ambiguity of "e.g." and "section 6.1.1 of [RFC1123]" in particular a= re=20 problematic because as worded a client that chose not to support IP lite= rals would be legal, and it would try to resolve "10.11.12.13" in DNS, which = we don't want. Surprising (as draft-iab-identifier-comparison already poi= nts out), even [RFC1123] allows this to be optional (a "SHOULD") in: "The host SH= OULD check the string syntactically for a dotted-decimal number before looking it u= p in=20 the Domain Name System." Instead it's important here to require that the client be able to=20 use IP literals. Most name resolution APIs (gethostbyname, getaddrinfo= , etc.) all meet that criteria. -Dave > -----Original Message----- > From: Dave Thaler > Sent: Thursday, July 26, 2012 2:32 PM > To: pcp@ietf.org > Cc: dhc@ietf.org > Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 >=20 > Here's my personal comments on draft -03... I have a few editorial=20 > nits I'll just send to the authors. >=20 > 1) I agree with the conclusion of the rationale but the sentence > "DHC WG's position is this flexibility have some drawbacks such as i= nducing > errors." > isn't intelligible. What does "inducing errors" mean? Either expla= in or > remove. >=20 > 2) The text on what to do with a name conveyed in an option is duplicated= in > Section 4.2 and 5.2. I'd prefer that this be specified only once, t= o avoid > opportunities for discrepancies. That is, section 4.2's first two p= aragraphs > are > fine, as are the first 1 1/2 paragraphs of 5.2, since those are=20 > about how to get > the name out of the option. The rest isn't DHCPv4 or DHCPv6 specif= ic and > should be in its own subsection. >=20 > 3) Re "It is RECOMMENDED to associate a validity lifetime with any addres= s > resulting from resolving the Name". The text should be more specific= about > what the validity lifetime should be. If the name is resolved in DN= S, I'd > say the validity lifetime should be the TTL of the DNS record. >=20 > 4) Re "When an > application issues a PCP request to a PCP Server, the source addres= s > of the request MUST be among those assigned on the interface to whi= ch > the destination PCP Server is bound. >=20 > This doesn't belong in a DHCP-specific document, it's out of scope. = That's > the job of the pcp-base spec. >=20 > 5) Same as point 4, but for all of section 6. In my view it belongs eith= er in > pcp-base or perhaps more likely in a separate spec that's not DHCP spe= cific. > E.g., if I manually configure one or more names, the same behavior=20 > should apply. >=20 > 6) Section 5.2 says: > "The DHCPv4 client MUST verify that the > option length does not exceed 255 octets [RFC1035])." >=20 > What does this mean? The length field is only 1 byte so cannot conta= in > a value larger than 255 anyway. So what exactly is a client supposed= to > "verify" here? >=20 > -Dave >=20 > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf=20 > > Of Dave Thaler > > Sent: Wednesday, July 18, 2012 2:21 PM > > To: pcp@ietf.org > > Cc: dhc@ietf.org > > Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 > > > > As discussed at last IETF, the authors believe that all issues=20 > > raised so far have been addressed. No new issues have been raised=20 > > since then, so this message begins a Working Group Last Call on=20 > > draft-ietf-pcp- > dhcp-03. > > > > This call would normally conclude in two weeks but that is during=20 > > IETF week, so the last call is extended to conclude at the end of=20 > > IETF (as of the Friday PCP meeting). > > > > We also agreed in Vancouver that this last call will be cross-posted=20 > > to the DHC list, hence cc'ing the DHC WG. > > > > We need at least 5 reviewers. Please send comments to the list. > > > > Thanks, > > -Dave Thaler > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Fri Jul 27 01:25: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 63B3821F849C; Fri, 27 Jul 2012 01:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndYb0iQRCAMh; Fri, 27 Jul 2012 01:25:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6178421F8497; Fri, 27 Jul 2012 01:25:04 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 986703B41E0; Fri, 27 Jul 2012 10:25:03 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 7A974238059; Fri, 27 Jul 2012 10:25:03 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 27 Jul 2012 10:24:57 +0200 From: To: "Bernie Volz (volz)" , Dave Thaler , "pcp@ietf.org" Date: Fri, 27 Jul 2012 10:24:56 +0200 Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwABZYWwACWnwdABgXOiAA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E563@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B70B380@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <489D13FBFA9B3E41812EA89F188F018E026F74@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E026F74@xmb-rcd-x04.cisco.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.7.27.65415 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 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, 27 Jul 2012 08:25:05 -0000 Dear Bernie, Thank you for the review.=20 Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Bernie Volz (volz) >Envoy=E9 : jeudi 19 juillet 2012 18:09 >=C0 : Dave Thaler; pcp@ietf.org >Cc : dhcwg@ietf.org >Objet : Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 > >The document seems OK (reviewing from the DHC WG perspective). > >Minor nits: > >1) > >2. Terminology > o DHCP refers to both DHCPv4 [RFC2131] and DHCPv6 [RFC3315]. > o DHCP client (or client) denotes a node that initiates requests to > obtain configuration parameters from one or more DHCP servers > [RFC3315]. > o DHCP server (or server) refers to a node that responds=20 >to requests > from DHCP clients [RFC3315]. > >Why are DHCP client / DHCP server just RFC 3315 and use of=20 >"DHCP" here implies RFC 2131 and 3315 from the earlier terminology. > Med: Fixed. The new text is:=20 o DHCP client (or client) denotes a node that initiates requests to obtain configuration parameters from one or more DHCP servers. o DHCP server (or server) refers to a node that responds to requests from DHCP clients. >2) > >4.1. Format > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_PCP_SERVER | Option-length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > : PCP Server Domain Name : > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 1: PCP Server Name DHCPv6 Option > > The fields of the option shown in Figure 1 are as follows: > > o Option-code: OPTION_PCP_SERVER (TBA, see Section 9.1) > o Option-length: Length of the 'PCP Server Domain Name' field in > octets. > o PCP Server Domain Name: The domain name of the PCP Server to be > used by the PCP Client. The domain name is encoded as specified > in Section 8 of [RFC3315]. > > The OPTION_PCP_SERVER option can include multiple PCP Server Domain > Names; each Name is treated as a separate PCP Server. > >Would it not be appropriate to change the "PCP Server Domain=20 >Name" to be "PCP Server Domain Name(s)"? And make the=20 >description clear that it can be one or more rather than=20 >adding this later (where it easily might be missed). > >The same applies to the DHCPv4 option (section 5.1). Med: Done. The new text is: o PCP Server Domain Name(s): The domain name s) of the PCP Server to be used by the PCP Client. The OPTION_PCP_SERVER option can include multiple PCP Server Domain Names; each Name is treated as a separate PCP Server. The domain name(s) is encoded as specified in Section 8 of [RFC3315]. And=20 o PCP Server Domain Name(s): The domain name(s) of the PCP Server to be used by the PCP Client when issuing PCP messages. The OPTION_PCP_SERVER option can include multiple PCP Server Domain Names; each Name is treated as a separate PCP Server. The encoding of the domain name(s) is described in Section 3.1 of [RFC1035]. =20 > >3) > >Be nice if the DHCPv4 domain name encoding clarified that=20 >compression was not allowed (though RFC 1035 section 3.1 does=20 >not say anything about that topic)? Perhaps use the RFC 3315=20 >Section 8 text: > > A domain name, or list of domain names, in DHCP MUST NOT=20 >be stored in compressed form, as described in > section 4.1.4 of RFC 1035. Med: I added this sentence to Section 5:=20 "The domain name(s) MUST NOT be stored in compressed form, as described in Section 4.1.4 of [RFC1035]." > > >- Bernie > >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 >On Behalf Of Dave Thaler >Sent: Wednesday, July 18, 2012 5:50 PM >To: pcp@ietf.org >Cc: dhcwg@ietf.org >Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 > >Correcting DHC WG email address. > >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On=20 >Behalf Of=20 >> Dave Thaler >> Sent: Wednesday, July 18, 2012 2:21 PM >> To: pcp@ietf.org >> Cc: dhc@ietf.org >> Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 >>=20 >> As discussed at last IETF, the authors believe that all=20 >issues raised=20 >> so far have been addressed. No new issues have been raised since=20 >> then, so this message begins a Working Group Last Call on=20 >draft-ietf-pcp-dhcp-03. >>=20 >> This call would normally conclude in two weeks but that is=20 >during IETF=20 >> week, so the last call is extended to conclude at the end of=20 >IETF (as=20 >> of the Friday PCP meeting). >>=20 >> We also agreed in Vancouver that this last call will be cross-posted=20 >> to the DHC list, hence cc'ing the DHC WG. >>=20 >> We need at least 5 reviewers. Please send comments to the list. >>=20 >> Thanks, >> -Dave Thaler >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp >= From volz@cisco.com Fri Jul 27 07:47: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 E290D21F87BF; Fri, 27 Jul 2012 07:47:06 -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_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAQeg+Xg6B74; Fri, 27 Jul 2012 07:47:05 -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 8E4B421F87B9; Fri, 27 Jul 2012 07:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=9431; q=dns/txt; s=iport; t=1343400425; x=1344610025; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MLkZ/ShM+/2Wb3p/c59ImJFB3UY3AWoj8BeDVKNXzeo=; b=bVbaJ87OmjpemUggroZkTYOl9y8FCf0ZpJoatrKDDSZmICBQECF6GJAc 6bIxNF4mR1eOhoqQPXTUIFy53b4/cbLAf3USAeIoJ8EbcNPotBL6NIRuX nRUwbnN1dbxDNyeycyVRcUwGeExigbHhVQNyH/eTQS/X2gqAjXw4TgoUN Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGGpElCtJV2c/2dsb2JhbABFuTyBB4IgAQEBAwEBAQEPASc0CwUHBAIBCA4DBAEBCxQJBycLFAkIAQEEAQ0FCBqHZQYLmXugVwSLUAqGCmADkWWSCoFmgl+BWCM X-IronPort-AV: E=Sophos;i="4.77,667,1336348800"; d="scan'208";a="106019554" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 27 Jul 2012 14:47:04 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6REl40E021995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jul 2012 14:47:04 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0298.004; Fri, 27 Jul 2012 09:47:04 -0500 From: "Bernie Volz (volz)" To: Dave Thaler , "dhcwg@ietf.org" Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QAAD2YUAAALuhAAAiadTw Date: Fri, 27 Jul 2012 14:47:04 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E02CD82@xmb-rcd-x04.cisco.com> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B7235BF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B7235BF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.251.222] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19066.004 x-tm-as-result: No--76.412700-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: "pcp@ietf.org" Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 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, 27 Jul 2012 14:47:07 -0000 Dave: As the options as defined contain a domain name (encoded per RFC 1035) are = address literals really appropriate? This also has consequences for configu= ring the option data in the servers. And, it seems rather bad to take an en= coded name, convert it to a string, only to convert it back into an encoded= name. But, alas, that is likely given the common APIs. Also, given that RFC 1035 section 3.1 states:=20 Since every domain name ends with the null label of the root, a domain name is terminated by a length byte of zero. And the option is to accommodate a list of domain names (knowing that each = terminates in the null label makes it possible to separate them), how do yo= u propose that literals (10.1.2.3) be encoded so that it not end up as the = domain name "10.1.2.3.". Perhaps there is a convention used to do this somewhere? (I admit I haven't= looked at draft-iab-identifier-comparison carefully.) When reviewing this and commenting the other day, I originally had thought = about commenting on the rather strict rules as to how the results of DNS qu= eries could be used and was thinking that it might be appropriate to relax = them some. Just doing normal DNS lookups and using the results (AAAA if v6 = is available, A if v4 is available, etc.) would likely make implementing th= is much easier and require less specialized code. > 6) Section 5.2 says: > "The DHCPv4 client MUST verify that the > option length does not exceed 255 octets [RFC1035])." Good catch. This should be removed as we have the ability to support long v= 4 options - see RFC 3396. Note that per section 4 of this RFC: Let us divide all DHCP options into two categories - those that, by definition, require implementation of the mechanisms defined in this document, and those that do not. We will refer to the former as concatenation-requiring options, and the latter as non- concatenation-requiring options. In order for an option to be a concatenation-requiring option, the protocol specification that defines that option must require implementation of option splitting and option concatenation as described in this document, by specifically referencing this document. So the draft should reference RFC 3396 and indicate that this is a concaten= ation-requiring option. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of D= ave Thaler Sent: Thursday, July 26, 2012 5:59 PM To: dhcwg@ietf.org Subject: [dhcwg] FW: WGLC on draft-ietf-pcp-dhcp-03 I keep mangling the WG mailing list address, so forwarding. -----Original Message----- From: Dave Thaler Sent: Thursday, July 26, 2012 2:58 PM To: 'pcp@ietf.org' Cc: 'dhc@ietf.org' Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 Missed responding to section 7 before sending... 7) Re "A PCP Server configured using OPTION_PCP_SERVER over DHCPv4 is likel= y to be resolved to IPv4 address(es)." I don't think I'd agree with that assumption. If I put a DNS name in = the option, it'll be resolved to whatever records are in DNS of a type the client q= ueries for. The document currently doesn't say what type(s) to query for (A vs AAAA)= . Per my comment on 2, I believe the types to query for should be independ= ent of how the name was obtained (DHCPv4, DHCPv6, manual, SNMP, or whatever els= e). =20 "A PCP Server configured using OPTION_PCP_SERVER over DHCPv6 may be resolved to IPv4-mapped IPv6 address(es) or IPv6 address(es)" By the same reasoning as my previous comment above, it may also be resol= ved to IPv4 addresses. If I have a dual-stack PCP server, I should be able= to put the same DNS name in both a DHCPv4 option and a DHCPv6 option, rather than requiring me to have two separate names for the same server. 8) Pursuant to a discussion I've been having with some folks on draft-iab-identifier-comparison section 3.1.1 and some changes I'll be = making to it as a result, it got me thinking. I'm thinking it would be good to h= ave a short subsection on Guidance to Administrators on what to configure in their = DHCP server to return in these options, or more importantly, what not to con= figure. Specifically, strings like "10.0.258", "0xA000001", and "012.0x102" wou= ld all be a bad idea to configure (unless you specified how they're to be = interpreted which is an option, though probably not the most expedient one). I'm = still strongly in favor of retaining the fact that it's a string that can be passed to= name resolution APIs, but that means it's best to avoid strings that are int= erpreted differently by different such APIs. 9) On the same point, Section 4.2 currently states: "Once each Name conveyed in the OPTION_PCP_SERVER option is validated, each included Name is passed to the name resolution library (e.g., Section 6.1.1 of [RFC1123] or [RFC6055])" The ambiguity of "e.g." and "section 6.1.1 of [RFC1123]" in particular a= re=20 problematic because as worded a client that chose not to support IP lite= rals would be legal, and it would try to resolve "10.11.12.13" in DNS, which = we don't want. Surprising (as draft-iab-identifier-comparison already poi= nts out), even [RFC1123] allows this to be optional (a "SHOULD") in: "The host SH= OULD check the string syntactically for a dotted-decimal number before looking it u= p in=20 the Domain Name System." Instead it's important here to require that the client be able to=20 use IP literals. Most name resolution APIs (gethostbyname, getaddrinfo= , etc.) all meet that criteria. -Dave > -----Original Message----- > From: Dave Thaler > Sent: Thursday, July 26, 2012 2:32 PM > To: pcp@ietf.org > Cc: dhc@ietf.org > Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 >=20 > Here's my personal comments on draft -03... I have a few editorial=20 > nits I'll just send to the authors. >=20 > 1) I agree with the conclusion of the rationale but the sentence > "DHC WG's position is this flexibility have some drawbacks such as i= nducing > errors." > isn't intelligible. What does "inducing errors" mean? Either expla= in or > remove. >=20 > 2) The text on what to do with a name conveyed in an option is duplicated= in > Section 4.2 and 5.2. I'd prefer that this be specified only once, t= o avoid > opportunities for discrepancies. That is, section 4.2's first two p= aragraphs > are > fine, as are the first 1 1/2 paragraphs of 5.2, since those are=20 > about how to get > the name out of the option. The rest isn't DHCPv4 or DHCPv6 specif= ic and > should be in its own subsection. >=20 > 3) Re "It is RECOMMENDED to associate a validity lifetime with any addres= s > resulting from resolving the Name". The text should be more specific= about > what the validity lifetime should be. If the name is resolved in DN= S, I'd > say the validity lifetime should be the TTL of the DNS record. >=20 > 4) Re "When an > application issues a PCP request to a PCP Server, the source addres= s > of the request MUST be among those assigned on the interface to whi= ch > the destination PCP Server is bound. >=20 > This doesn't belong in a DHCP-specific document, it's out of scope. = That's > the job of the pcp-base spec. >=20 > 5) Same as point 4, but for all of section 6. In my view it belongs eith= er in > pcp-base or perhaps more likely in a separate spec that's not DHCP spe= cific. > E.g., if I manually configure one or more names, the same behavior=20 > should apply. >=20 > 6) Section 5.2 says: > "The DHCPv4 client MUST verify that the > option length does not exceed 255 octets [RFC1035])." >=20 > What does this mean? The length field is only 1 byte so cannot conta= in > a value larger than 255 anyway. So what exactly is a client supposed= to > "verify" here? >=20 > -Dave >=20 > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf=20 > > Of Dave Thaler > > Sent: Wednesday, July 18, 2012 2:21 PM > > To: pcp@ietf.org > > Cc: dhc@ietf.org > > Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 > > > > As discussed at last IETF, the authors believe that all issues=20 > > raised so far have been addressed. No new issues have been raised=20 > > since then, so this message begins a Working Group Last Call on > > draft-ietf-pcp- > dhcp-03. > > > > This call would normally conclude in two weeks but that is during=20 > > IETF week, so the last call is extended to conclude at the end of=20 > > IETF (as of the Friday PCP meeting). > > > > We also agreed in Vancouver that this last call will be cross-posted=20 > > to the DHC list, hence cc'ing the DHC WG. > > > > We need at least 5 reviewers. Please send comments to the list. > > > > Thanks, > > -Dave Thaler > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From dthaler@microsoft.com Fri Jul 27 12: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 0BB3C21F86DF; Fri, 27 Jul 2012 12:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.415 X-Spam-Level: X-Spam-Status: No, score=-103.415 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAltNseZbBtD; Fri, 27 Jul 2012 12:06:36 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA8421F86E8; Fri, 27 Jul 2012 12:06:36 -0700 (PDT) Received: from mail7-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 27 Jul 2012 19:06:35 +0000 Received: from mail7-am1 (localhost [127.0.0.1]) by mail7-am1-R.bigfish.com (Postfix) with ESMTP id 22D0522021B; Fri, 27 Jul 2012 19:06:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371I542M1432I4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail7-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail7-am1 (localhost.localdomain [127.0.0.1]) by mail7-am1 (MessageSwitch) id 1343415991799264_24655; Fri, 27 Jul 2012 19:06:31 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.242]) by mail7-am1.bigfish.com (Postfix) with ESMTP id C1359320188; Fri, 27 Jul 2012 19:06:31 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 27 Jul 2012 19:06:30 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.309.3; Fri, 27 Jul 2012 19:06:27 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0309.003; Fri, 27 Jul 2012 12:06:27 -0700 From: Dave Thaler To: "Bernie Volz (volz)" , "dhcwg@ietf.org" Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QAAD2YUAAALuhAAAiadTwAAl/+jA= Date: Fri, 27 Jul 2012 19:06:27 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B72551C@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B7235BF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <489D13FBFA9B3E41812EA89F188F018E02CD82@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E02CD82@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "pcp@ietf.org" Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 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, 27 Jul 2012 19:06:38 -0000 > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com] > Sent: Friday, July 27, 2012 7:47 AM > To: Dave Thaler; dhcwg@ietf.org > Cc: pcp@ietf.org > Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 >=20 > Dave: >=20 > As the options as defined contain a domain name (encoded per RFC 1035) ar= e > address literals really appropriate? This also has consequences for confi= guring > the option data in the servers. And, it seems rather bad to take an encod= ed > name, convert it to a string, only to convert it back into an encoded nam= e. But, > alas, that is likely given the common APIs. > > Also, given that RFC 1035 section 3.1 states: >=20 > Since every domain name ends with the null label of > the root, a domain name is terminated by a length byte of zero. >=20 > And the option is to accommodate a list of domain names (knowing that eac= h > terminates in the null label makes it possible to separate them), how do = you > propose that literals (10.1.2.3) be encoded so that it not end up as the = domain > name "10.1.2.3.". >=20 > Perhaps there is a convention used to do this somewhere? (I admit I haven= 't > looked at draft-iab-identifier-comparison carefully.) (draft-iab-identifier-comparison isn't relevant to that particular question= .) The WG goal was to be able to configure a set of strings that can be passed= to an API such as getaddrinfo() where the string can be either an IP literal o= r a domain name. I take your point as saying that using the encoding defined in RFC 1035 section 3.1 isn't sufficient without an additional statement that the trailing dot should be removed. The only other alternative I see would be to not use that encoding but define some other encoding. > When reviewing this and commenting the other day, I originally had though= t > about commenting on the rather strict rules as to how the results of DNS > queries could be used and was thinking that it might be appropriate to re= lax > them some. Just doing normal DNS lookups and using the results (AAAA if v= 6 is > available, A if v4 is available, etc.) would likely make implementing thi= s much > easier and require less specialized code. Right. I think the goal should be to minimize the amount of processing th= e client has to do with the option contents... just pass it to getaddrinfo() = or equivalent was what the WG had discussed. > > 6) Section 5.2 says: > > "The DHCPv4 client MUST verify that the > > option length does not exceed 255 octets [RFC1035])." >=20 > Good catch. This should be removed as we have the ability to support long= v4 > options - see RFC 3396. >=20 > Note that per section 4 of this RFC: >=20 > Let us divide all DHCP options into two categories - those that, by > definition, require implementation of the mechanisms defined in this > document, and those that do not. We will refer to the former as > concatenation-requiring options, and the latter as non- > concatenation-requiring options. In order for an option to be a > concatenation-requiring option, the protocol specification that > defines that option must require implementation of option splitting > and option concatenation as described in this document, by > specifically referencing this document. >=20 > So the draft should reference RFC 3396 and indicate that this is a > concatenation-requiring option. Agree. -Dave >=20 > - Bernie >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of > Dave Thaler > Sent: Thursday, July 26, 2012 5:59 PM > To: dhcwg@ietf.org > Subject: [dhcwg] FW: WGLC on draft-ietf-pcp-dhcp-03 >=20 > I keep mangling the WG mailing list address, so forwarding. >=20 > -----Original Message----- > From: Dave Thaler > Sent: Thursday, July 26, 2012 2:58 PM > To: 'pcp@ietf.org' > Cc: 'dhc@ietf.org' > Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 >=20 > Missed responding to section 7 before sending... >=20 > 7) Re "A PCP Server configured using OPTION_PCP_SERVER over DHCPv4 is > likely > to be resolved to IPv4 address(es)." > I don't think I'd agree with that assumption. If I put a DNS name i= n the > option, > it'll be resolved to whatever records are in DNS of a type the client= queries > for. > The document currently doesn't say what type(s) to query for (A vs AAA= A). > Per my comment on 2, I believe the types to query for should be indepe= ndent > of > how the name was obtained (DHCPv4, DHCPv6, manual, SNMP, or whatever > else). >=20 > "A PCP Server configured using OPTION_PCP_SERVER over DHCPv6 may be > resolved to IPv4-mapped IPv6 address(es) or IPv6 address(es)" > By the same reasoning as my previous comment above, it may also be > resolved > to IPv4 addresses. If I have a dual-stack PCP server, I should be ab= le to put > the same DNS name in both a DHCPv4 option and a DHCPv6 option, rather > than requiring me to have two separate names for the same server. >=20 > 8) Pursuant to a discussion I've been having with some folks on > draft-iab-identifier-comparison section 3.1.1 and some changes I'll b= e > making to > it as a result, it got me thinking. I'm thinking it would be good to= have a > short > subsection on Guidance to Administrators on what to configure in thei= r DHCP > server to return in these options, or more importantly, what not to c= onfigure. > Specifically, strings like "10.0.258", "0xA000001", and "012.0x102" w= ould > all be a bad idea to configure (unless you specified how they're to b= e > interpreted > which is an option, though probably not the most expedient one). I'= m still > strongly > in favor of retaining the fact that it's a string that can be passed = to name > resolution APIs, but that means it's best to avoid strings that are i= nterpreted > differently by different such APIs. >=20 > 9) On the same point, Section 4.2 currently states: > "Once each Name conveyed in the OPTION_PCP_SERVER option is validated, > each included Name is passed to the name resolution library (e.g., > Section 6.1.1 of [RFC1123] or [RFC6055])" > The ambiguity of "e.g." and "section 6.1.1 of [RFC1123]" in particular= are > problematic because as worded a client that chose not to support IP li= terals > would be legal, and it would try to resolve "10.11.12.13" in DNS, whic= h we > don't want. Surprising (as draft-iab-identifier-comparison already p= oints > out), > even [RFC1123] allows this to be optional (a "SHOULD") in: "The host > SHOULD check > the string syntactically for a dotted-decimal number before looking it= up in > the Domain Name System." >=20 > Instead it's important here to require that the client be able to > use IP literals. Most name resolution APIs (gethostbyname, getaddrin= fo, > etc.) all meet that criteria. >=20 > -Dave >=20 > > -----Original Message----- > > From: Dave Thaler > > Sent: Thursday, July 26, 2012 2:32 PM > > To: pcp@ietf.org > > Cc: dhc@ietf.org > > Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 > > > > Here's my personal comments on draft -03... I have a few editorial > > nits I'll just send to the authors. > > > > 1) I agree with the conclusion of the rationale but the sentence > > "DHC WG's position is this flexibility have some drawbacks such as > inducing > > errors." > > isn't intelligible. What does "inducing errors" mean? Either exp= lain or > > remove. > > > > 2) The text on what to do with a name conveyed in an option is duplicat= ed in > > Section 4.2 and 5.2. I'd prefer that this be specified only once,= to avoid > > opportunities for discrepancies. That is, section 4.2's first two= paragraphs > > are > > fine, as are the first 1 1/2 paragraphs of 5.2, since those are > > about how to get > > the name out of the option. The rest isn't DHCPv4 or DHCPv6 spec= ific and > > should be in its own subsection. > > > > 3) Re "It is RECOMMENDED to associate a validity lifetime with any addr= ess > > resulting from resolving the Name". The text should be more specif= ic > about > > what the validity lifetime should be. If the name is resolved in = DNS, I'd > > say the validity lifetime should be the TTL of the DNS record. > > > > 4) Re "When an > > application issues a PCP request to a PCP Server, the source addr= ess > > of the request MUST be among those assigned on the interface to w= hich > > the destination PCP Server is bound. > > > > This doesn't belong in a DHCP-specific document, it's out of scope. = That's > > the job of the pcp-base spec. > > > > 5) Same as point 4, but for all of section 6. In my view it belongs ei= ther in > > pcp-base or perhaps more likely in a separate spec that's not DHCP s= pecific. > > E.g., if I manually configure one or more names, the same behavior > > should apply. > > > > 6) Section 5.2 says: > > "The DHCPv4 client MUST verify that the > > option length does not exceed 255 octets [RFC1035])." > > > > What does this mean? The length field is only 1 byte so cannot con= tain > > a value larger than 255 anyway. So what exactly is a client suppos= ed to > > "verify" here? > > > > -Dave > > > > > -----Original Message----- > > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf > > > Of Dave Thaler > > > Sent: Wednesday, July 18, 2012 2:21 PM > > > To: pcp@ietf.org > > > Cc: dhc@ietf.org > > > Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 > > > > > > As discussed at last IETF, the authors believe that all issues > > > raised so far have been addressed. No new issues have been raised > > > since then, so this message begins a Working Group Last Call on > > > draft-ietf-pcp- > > dhcp-03. > > > > > > This call would normally conclude in two weeks but that is during > > > IETF week, so the last call is extended to conclude at the end of > > > IETF (as of the Friday PCP meeting). > > > > > > We also agreed in Vancouver that this last call will be cross-posted > > > to the DHC list, hence cc'ing the DHC WG. > > > > > > We need at least 5 reviewers. Please send comments to the list. > > > > > > Thanks, > > > -Dave Thaler > > > > > > _______________________________________________ > > > pcp mailing list > > > pcp@ietf.org > > > https://www.ietf.org/mailman/listinfo/pcp >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From dthaler@microsoft.com Fri Jul 27 12:20: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 4AC4721F8636 for ; Fri, 27 Jul 2012 12:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.405 X-Spam-Level: X-Spam-Status: No, score=-103.405 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gy-FhvUAisTZ for ; Fri, 27 Jul 2012 12:20:11 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id EA0D621F8631 for ; Fri, 27 Jul 2012 12:20:10 -0700 (PDT) Received: from mail163-ch1-R.bigfish.com (10.43.68.229) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Fri, 27 Jul 2012 19:20:09 +0000 Received: from mail163-ch1 (localhost [127.0.0.1]) by mail163-ch1-R.bigfish.com (Postfix) with ESMTP id C8C7934074E for ; Fri, 27 Jul 2012 19:20:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -79 X-BigFish: VS-79(zz9371Ic89bh542M1432I15caKJ4015I1447Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail163-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail163-ch1 (localhost.localdomain [127.0.0.1]) by mail163-ch1 (MessageSwitch) id 1343416807818695_26458; Fri, 27 Jul 2012 19:20:07 +0000 (UTC) Received: from CH1EHSMHS019.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail163-ch1.bigfish.com (Postfix) with ESMTP id BC3AA400048 for ; Fri, 27 Jul 2012 19:20:07 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 27 Jul 2012 19:20:07 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.309.3; Fri, 27 Jul 2012 19:20:03 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.309.3; Fri, 27 Jul 2012 12:20:02 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Fri, 27 Jul 2012 12:20:02 -0700 From: Dave Thaler To: "dhcwg@ietf.org" Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QABedF2AAFmkxMAAAaAmw Date: Fri, 27 Jul 2012 19:20:01 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B72565B@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B7234D2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E4A17E586@PUEXCB1B.nanterre.francetelecom.fr> <9B57C850BB53634CACEC56EF4853FF653B725609@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B725609@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 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, 27 Jul 2012 19:20:12 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Dav= e > Thaler > Sent: Friday, July 27, 2012 12:19 PM > To: mohamed.boucadair@orange.com; pcp@ietf.org > Cc: dhc@ietf.org > Subject: Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 >=20 >=20 >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Sent: Friday, July 27, 2012 2:01 AM > > To: Dave Thaler; pcp@ietf.org > > Cc: dhc@ietf.org > > Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 > > > > Dear Dave, > > > > Thank you for the review. > > > > Please see inline. > > > > Cheers, > > Med > > > > >-----Message d'origine----- > > >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de > > >Dave Thaler Envoy=E9 : jeudi 26 juillet 2012 23:32 =C0 : pcp@ietf.org = Cc : > > >dhc@ietf.org Objet : Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 > > > > > >Here's my personal comments on draft -03... I have a few editorial > > >nits I'll just send to the authors. > > > > > >1) I agree with the conclusion of the rationale but the sentence > > > "DHC WG's position is this flexibility have some drawbacks such > > >as inducing > > > errors." > > > isn't intelligible. What does "inducing errors" mean? > > >Either explain or remove. > > > > Med: This is point is discussed in detail here: > > http://tools.ietf.org/html/draft- > > ietf-dhc-option-guidelines-08#section-7. Would you be fine if we add a > reference to that draft? >=20 > Yes, good idea. >=20 > > >2) The text on what to do with a name conveyed in an option is > > >duplicated in > > > Section 4.2 and 5.2. I'd prefer that this be specified > > >only once, to avoid > > > opportunities for discrepancies. That is, section 4.2's > > >first two paragraphs are > > > fine, as are the first 1 1/2 paragraphs of 5.2, since those are > > >about how to get > > > the name out of the option. The rest isn't DHCPv4 or > > >DHCPv6 specific and > > > should be in its own subsection. > > > > Med: There is some duplication there but it does not harm IMHO. I > > prefer to maintain the text as it is. >=20 > I think it does harm. The fact that the text is not identical means tha= t > a reader might interpret them differently, and have different implementat= ions > with different behavior. That would not be correct. So I think it's s= afest > to have only one copy of the text. >=20 > Do others have an opinion on this? >=20 > > >3) Re "It is RECOMMENDED to associate a validity lifetime with any > > >address > > > resulting from resolving the Name". The text should be more > > >specific about > > > what the validity lifetime should be. If the name is > > >resolved in DNS, I'd > > > say the validity lifetime should be the TTL of the DNS record. > > > > > > > Med: I updated the text as follows: > > > > It is RECOMMENDED to associate a validity lifetime (e.g., TTL of DNS > > record if the Name is resolved using DNS) with any address resulting > > from resolving the Name conveyed in a OPTION_PCP_SERVER DHCPv4 > option > > when stored in a local name resolution cache. > > > > Is this better? >=20 > Yes. >=20 > > >4) Re "When an > > > application issues a PCP request to a PCP Server, the source > > >address > > > of the request MUST be among those assigned on the interface to > > >which > > > the destination PCP Server is bound. > > > > > > This doesn't belong in a DHCP-specific document, it's out > > >of scope. That's > > > the job of the pcp-base spec. > > > > Med: I removed that sentence. > > > > >5) Same as point 4, but for all of section 6. In my view it belongs > > >either in > > > pcp-base or perhaps more likely in a separate spec that's not DHCP > > >specific. > > > E.g., if I manually configure one or more names, the same behavior > > >should apply. > > > > Med: Dave, Section 6 is there because you requested it: see > > http://www.ietf.org/mail-archive/web/pcp/current/msg01793.html. Since > > we have the text now, I vote for keeping it. No need to create another > > dependency with another document to come. >=20 > Thanks for the reminder and the pointer. I agree that this spec needs t= o > say something. My preference would be to separate it into something > non-DHCP specific. But you're right about that possibly delaying the do= c. > So I'd suggest the following: >=20 > 1) Introduce a section header called something like "Use of PCP Server Na= mes" > 2) Make the section start with an introductory sentence saying this secti= on > is applicable to any mechanism that configures server names, not just = DHCP. > The first sentence of section 6 is a partial starting point for that. > 3) Move the text I mentioned in point 2 (that I didn't want duplicated) t= o > a subsection of it, since that text isn't necessarily DHCP specific e= ither. > 4) Move section 6 under the "Use of PCP Server Names" section. >=20 > This allows any other future name configuration mechanism (CLI, SNMP, YAN= G, > or whatever else) to reference a single section of this document, which h= as all > the non-DHCP-specific content under it. >=20 > > >6) Section 5.2 says: > > > "The DHCPv4 client MUST verify that the > > > option length does not exceed 255 octets [RFC1035])." > > > > > > What does this mean? The length field is only 1 byte so > > >cannot contain > > > a value larger than 255 anyway. So what exactly is a > > >client supposed to > > > "verify" here? > > > > Med: The text does not talk about the length of the field but the value= it > carries. >=20 > I was talking about the value. > See the exchange between Bernie and I for what this needs to say instead. >=20 > > > > > >-Dave > > > > > >> -----Original Message----- > > >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On > > >Behalf Of Dave > > >> Thaler > > >> Sent: Wednesday, July 18, 2012 2:21 PM > > >> To: pcp@ietf.org > > >> Cc: dhc@ietf.org > > >> Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 > > >> > > >> As discussed at last IETF, the authors believe that all > > >issues raised so far have > > >> been addressed. No new issues have been raised since then, > > >so this message > > >> begins a Working Group Last Call on draft-ietf-pcp-dhcp-03. > > >> > > >> This call would normally conclude in two weeks but that is > > >during IETF week, so > > >> the last call is extended to conclude at the end of IETF (as > > >of the Friday PCP > > >> meeting). > > >> > > >> We also agreed in Vancouver that this last call will be > > >cross-posted to the DHC > > >> list, hence cc'ing the DHC WG. > > >> > > >> We need at least 5 reviewers. Please send comments to the list. > > >> > > >> Thanks, > > >> -Dave Thaler > > >> > > >> _______________________________________________ > > >> pcp mailing list > > >> pcp@ietf.org > > >> https://www.ietf.org/mailman/listinfo/pcp > > > > > > > > >_______________________________________________ > > >pcp mailing list > > >pcp@ietf.org > > >https://www.ietf.org/mailman/listinfo/pcp > > > >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From Ted.Lemon@nominum.com Fri Jul 27 12:34: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 A72C311E80E6; Fri, 27 Jul 2012 12:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxuTLaUCezcB; Fri, 27 Jul 2012 12:34:16 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id BFF2411E80D6; Fri, 27 Jul 2012 12:34:15 -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 DSNKUBLtNMuTGXBlGlsHIJJTdBBjD5qSS6IK@postini.com; Fri, 27 Jul 2012 12:34:15 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 95F3D1B82CD; Fri, 27 Jul 2012 12:34: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 8542719005D; Fri, 27 Jul 2012 12:34: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; Fri, 27 Jul 2012 12:34:11 -0700 From: Ted Lemon To: Dave Thaler Thread-Topic: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QAAD2YUAAALuhAAAiadTwAAl/+jAAD/3vgA== Date: Fri, 27 Jul 2012 19:34:10 +0000 Message-ID: References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B7235BF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <489D13FBFA9B3E41812EA89F188F018E02CD82@xmb-rcd-x04.cisco.com> <9B57C850BB53634CACEC56EF4853FF653B72551C@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B72551C@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.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: multipart/alternative; boundary="_000_D2E362D0DEAB4024BC18A20D98862778nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "pcp@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 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, 27 Jul 2012 19:34:16 -0000 --_000_D2E362D0DEAB4024BC18A20D98862778nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jul 27, 2012, at 3:06 PM, Dave Thaler wrote: Right. I think the goal should be to minimize the amount of processing th= e client has to do with the option contents... just pass it to getaddrinfo() = or equivalent was what the WG had discussed. Remembering that the DHCP server automatically translates names to IP addre= sses in its configuration, why is it necessary to place this burden on the = client? Traditionally DHCP just sends IP addresses, not names, precisely = because it minimizes the burden on the client while maintaining the flexibi= lity of doing name translation on the server. I assume you already consid= ered this, because I'm pretty sure you've seen debates about this go by bef= ore, but I'm curious as to why you decided to send a name rather than an IP= address. --_000_D2E362D0DEAB4024BC18A20D98862778nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jul 27, 2012, at 3:06 PM, Dave Thaler wrote:
Right.   I think the goal should be to minimize the amount of processin= g the
client has to do with the option contents... just pass it to getaddrinfo() = or
equivalent was what the WG had discussed.

Remembering that the DHCP server automatically translates names to IP = addresses in its configuration, why is it necessary to place this burden on= the client?   Traditionally DHCP just sends IP addresses, not names, = precisely because it minimizes the burden on the client while maintaining the flexibility of doing name translation = on the server.   I assume you already considered this, because I'm pre= tty sure you've seen debates about this go by before, but I'm curious as to= why you decided to send a name rather than an IP address.

--_000_D2E362D0DEAB4024BC18A20D98862778nominumcom_-- From volz@cisco.com Fri Jul 27 13:38: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 55F3921F85F3; Fri, 27 Jul 2012 13:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S87UFP-oCm6o; Fri, 27 Jul 2012 13:38:03 -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 8E37421F85F2; Fri, 27 Jul 2012 13:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=16068; q=dns/txt; s=iport; t=1343421483; x=1344631083; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=e12zZGbyi+Z5+u6hid4FO/fTuEJjXIAPyJItlu5b8AI=; b=NbGDrG7lsALLcnUTxL/3T1JI4J/F0aQN4mgBakS12veBruM4jK2z6GuU z+rWeoHqvJZeGqxHjTyToZNvgxEVJDNmYT6yX7E2HEr/b9wgBfdhmHFpg lnpWymI6kDiRC5qh62qbq9ClPuwtJG578DKM0T0/JI6ThBBhQeMEgFlXK Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFANn6ElCtJV2Z/2dsb2JhbABFgkqmIogOAYhXgQeCIAEBAQQSARpMEAIBCBEEAQELHQcyFAkIAgQBDQUIEweHawuaR6Bgi1AVhX9gA5ZcjROBZoJfgVcI X-IronPort-AV: E=Sophos;i="4.77,668,1336348800"; d="scan'208,217";a="106134007" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 27 Jul 2012 20:38:03 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6RKc2Wv001074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jul 2012 20:38:02 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.206]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Fri, 27 Jul 2012 15:36:10 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , Dave Thaler Thread-Topic: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QAAD2YUAAALuhAAAiadTwAAl/+jAAD/3vgAAN07dw Date: Fri, 27 Jul 2012 20:16:53 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E02CE85@xmb-rcd-x04.cisco.com> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B7235BF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <489D13FBFA9B3E41812EA89F188F018E02CD82@xmb-rcd-x04.cisco.com> <9B57C850BB53634CACEC56EF4853FF653B72551C@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.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.251.222] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19068.001 x-tm-as-result: No--46.700100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E02CE85xmbrcdx04ciscocom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "pcp@ietf.org" Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 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, 27 Jul 2012 20:38:06 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E02CE85xmbrcdx04ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ted: I think sending domains names for the client to process is far more dynamic= . Also, the draft specifies use of domain names. When does the DHCP server do this resolution (from domain name to address)? - During configuration (which doesn't allow for any change in the = information) - i.e., when the operator first enters the information. - During startup (i.e., when the server reads the configuration) -= (which would require a reload and might have serious performance issues if= DNS is unavailable when the server is reloaded) - During each client request (which have serious performance issue= s if DNS is unavailable) You can see that these three approaches (and perhaps there are more) are mu= ch less dynamic than having the client get the information when needed and = also don't negatively impact the DHCP server (and thus other clients that m= ight not be relying on DNS) when DNS is unavailable. One might limit the ti= me one waits for the resolution, but what do you send if you can't resolve? This is the grand old debate about whether one should send addresses, domai= n names, or both (in which case we've sometimes defined two options or defi= ned suboptions or an encoding format). And, we sadly have never really solv= ed this issue within the DHC WG. The http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines does s= eem to indicate your solution, but it never specifies "when" this resolutio= n should be done. I think that's likely and issue we need to discuss about = this guidelines draft. (There's a few other oddities in that draft that sho= uld be corrected - why for example is it picking on DHCPv6 - "DHCPv6 stands= for Dynamic Host Configuration Protocol for IPv6. Contrary to its name, i= s many contexts it is not dynamic."; DHCPv4 was no better and actually wors= e since ForceRenew is really not implemented.) But that is likely for anoth= er email thread or for discussion on Monday at the DHC WG meeting. - Bernie From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Friday, July 27, 2012 3:34 PM To: Dave Thaler Cc: Bernie Volz (volz); dhcwg@ietf.org; pcp@ietf.org Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 On Jul 27, 2012, at 3:06 PM, Dave Thaler wrote: Right. I think the goal should be to minimize the amount of processing th= e client has to do with the option contents... just pass it to getaddrinfo() = or equivalent was what the WG had discussed. Remembering that the DHCP server automatically translates names to IP addre= sses in its configuration, why is it necessary to place this burden on the = client? Traditionally DHCP just sends IP addresses, not names, precisely = because it minimizes the burden on the client while maintaining the flexibi= lity of doing name translation on the server. I assume you already consid= ered this, because I'm pretty sure you've seen debates about this go by bef= ore, but I'm curious as to why you decided to send a name rather than an IP= address. --_000_489D13FBFA9B3E41812EA89F188F018E02CE85xmbrcdx04ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ted:

 <= /p>

I think sending domains n= ames for the client to process is far more dynamic. Also, the draft specifi= es use of domain names.

 <= /p>

When does the DHCP server= do this resolution (from domain name to address)?

- =          During configurat= ion (which doesn’t allow for any change in the information) – i= .e., when the operator first enters the information.

- =          During startup (i= .e., when the server reads the configuration) - (which would require a relo= ad and might have serious performance issues if DNS is unavailable when the server is reloaded)

- =          During each clien= t request (which have serious performance issues if DNS is unavailable)

You can see that these th= ree approaches (and perhaps there are more) are much less dynamic than havi= ng the client get the information when needed and also don’t negatively impact the DHCP server (and thus other clients that might not b= e relying on DNS) when DNS is unavailable. One might limit the time one wai= ts for the resolution, but what do you send if you can’t resolve?

 <= /p>

This is the grand old deb= ate about whether one should send addresses, domain names, or both (in whic= h case we’ve sometimes defined two options or defined suboptions or an encoding format). And, we sadly have never really solved this issue = within the DHC WG.

 <= /p>

The http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines does seem to indicate your solution, but it never specifies “when” this resolution should= be done. I think that’s likely and issue we need to discuss about th= is guidelines draft. (There’s a few other oddities in that draft that= should be corrected – why for example is it picking on DHCPv6 - “DHCPv6 stands for Dynamic Host Configuration Protocol for = IPv6.  Contrary to its name, is many contexts it is not dynamic.”= ;; DHCPv4 was no better and actually worse since ForceRenew is really not i= mplemented.) But that is likely for another email thread or for discussion on Monday at the DHC WG meeting.

 <= /p>

- =          Bernie=

 <= /p>

From: Ted Lemo= n [mailto:Ted.Lemon@nominum.com]
Sent: Friday, July 27, 2012 3:34 PM
To: Dave Thaler
Cc: Bernie Volz (volz); dhcwg@ietf.org; pcp@ietf.org
Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03

 

On Jul 27, 2012, at 3:06 PM, Dave Thaler wrote:=

Righ= t.   I think the goal should be to minimize the amount of process= ing the
client has to do with the option contents.= .. just pass it to getaddrinfo() or
equivalent was what the WG had discussed.<= /span>

 

Remembering that the DHCP server automatically trans= lates names to IP addresses in its configuration, why is it necessary to pl= ace this burden on the client?   Traditionally DHCP just sends IP addr= esses, not names, precisely because it minimizes the burden on the client while maintaining the flexibility of do= ing name translation on the server.   I assume you already considered = this, because I'm pretty sure you've seen debates about this go by before, = but I'm curious as to why you decided to send a name rather than an IP address.

 

--_000_489D13FBFA9B3E41812EA89F188F018E02CE85xmbrcdx04ciscocom_-- From Ted.Lemon@nominum.com Fri Jul 27 15:30: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 BE84C11E80F2; Fri, 27 Jul 2012 15:30:51 -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.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8r9NCXReEBx; Fri, 27 Jul 2012 15:30:51 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id C940911E80BA; Fri, 27 Jul 2012 15:30:50 -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 DSNKUBMWmpqs1t58L0ZDtZ8MIgs4hpDTsW8f@postini.com; Fri, 27 Jul 2012 15:30: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 A89221B8312; Fri, 27 Jul 2012 15:30: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 9D92719005D; Fri, 27 Jul 2012 15:30: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; Fri, 27 Jul 2012 15:30:49 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QAAD2YUAAALuhAAAiadTwAAl/+jAAD/3vgAAN07dw///CugA= Date: Fri, 27 Jul 2012 22:30:48 +0000 Message-ID: <37691433-E8ED-4DF8-AFC4-25BF5E8985F2@nominum.com> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B7235BF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <489D13FBFA9B3E41812EA89F188F018E02CD82@xmb-rcd-x04.cisco.com> <9B57C850BB53634CACEC56EF4853FF653B72551C@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <489D13FBFA9B3E41812EA89F188F018E02CE85@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E02CE85@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: multipart/alternative; boundary="_000_37691433E8ED4DF8AFC425BF5E8985F2nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "pcp@ietf.org" Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 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, 27 Jul 2012 22:30:51 -0000 --_000_37691433E8ED4DF8AFC425BF5E8985F2nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jul 27, 2012, at 4:16 PM, Bernie Volz (volz) wrote: The http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines does s= eem to indicate your solution, but it never specifies =93when=94 this resol= ution should be done. I think that=92s likely and issue we need to discuss = about this guidelines draft. That's an implementation issue; the same issue exists on the client. Sinc= e you're setting up a tunnel, obviously the resolution happens when you set= up the tunnel, and if the DNS changes after that, the client doesn't notic= e, tear down the tunnel, and set up a new one, does it? As for how the server handles it, that's left up to the implementation. T= he ISC DHCP server does the resolution when the request comes in, and if th= e DNS is down, it blocks. Nominum's server does the resolution at request= time too, but is a log smarter about not blocking and about responding if = no answer comes from the DNS. But really, if the DNS is down, you're hose= d anyway, no matter who is doing the resolution. You have to have reliabl= e DNS. --_000_37691433E8ED4DF8AFC425BF5E8985F2nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3BB905072B53064888C3EAA0003F8D7E@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jul 27, 2012, at 4:16 PM, Bernie Volz (volz) wrote:
The http://datatracker.ietf.org/= doc/draft-ietf-dhc-option-guidelines does seem to indicate your solution, but it never specifies =93when=94 this res= olution should be done. I think that=92s likely and issue we need to discus= s about this guidelines draft.

That's an implementation issue; the same issue exists on the client. &= nbsp; Since you're setting up a tunnel, obviously the resolution happens wh= en you set up the tunnel, and if the DNS changes after that, the client doe= sn't notice, tear down the tunnel, and set up a new one, does it?

As for how the server handles it, that's left up to the implementation= .   The ISC DHCP server does the resolution when the request comes in,= and if the DNS is down, it blocks.   Nominum's server does the resolu= tion at request time too, but is a log smarter about not blocking and about responding if no answer comes from the DNS. &= nbsp; But really, if the DNS is down, you're hosed anyway, no matter who is= doing the resolution.   You have to have reliable DNS.

--_000_37691433E8ED4DF8AFC425BF5E8985F2nominumcom_-- From volz@cisco.com Sun Jul 29 07:33: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 4113221F86FA for ; Sun, 29 Jul 2012 07:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MJt8SF8hJDW for ; Sun, 29 Jul 2012 07:33:43 -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 3167221F85B8 for ; Sun, 29 Jul 2012 07:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=2653; q=dns/txt; s=iport; t=1343572423; x=1344782023; h=from:to:subject:date:message-id:mime-version; bh=Ilfkh0IufSNiFtgvAO9LeKXNTGroCVdNow0TizHb8gI=; b=GNXmbmHMVxVIk4Yt1S9N7poL2q5h8AJD/B97wW75tAF0KOMvWCSkyhic Qnh5ipZQJyjm8lSRPJ1ry5H8nUkaAI19h80twhYBIhrDlojFRp3A89t2r oFY8rM98xMqe9BM6pDiUo7Sv1tSoHIf2nygYC1v4Fz4S/ykuiEyFrE07o 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABhJFVCtJXG+/2dsb2JhbABFhXOycnqBB4InEgEQaAEMAT0CBDAmAQQ1h2uYPYEojRmRfpEgMmADlUmOJ4Fmgl8 X-IronPort-AV: E=Sophos;i="4.77,674,1336348800"; d="scan'208,217";a="106388557" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 29 Jul 2012 14:33:42 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6TEXf5L003068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 29 Jul 2012 14:33:41 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.162]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0298.004; Sun, 29 Jul 2012 09:33:41 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: draft-cao-dhc-anqp-option-00 Thread-Index: Ac1tlyXw2O9xwNy1QSGiqnzZP73xGw== Date: Sun, 29 Jul 2012 14:33:40 +0000 Message-ID: <9B7D807E-3829-4BFD-9A74-1D31FB9CC2F6@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-19070.004 x-tm-as-result: No--27.134000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_9B7D807E38294BFD9A741D31FB9CC2F6ciscocom_" MIME-Version: 1.0 Subject: [dhcwg] draft-cao-dhc-anqp-option-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, 29 Jul 2012 14:33:44 -0000 --_000_9B7D807E38294BFD9A741D31FB9CC2F6ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2VlbXMgdG8gbWUgdGhlIHY0ICYgdjYgb3B0aW9ucyBjYW4gYmUgc2ltcGxpZWQgdG8gcmVtb3Zl IGxlbmd0aF8yIGFzIHRoZSBvcHRpb24gbGVuZ3RoIGNhbiBqdXN0IGJlIDEgKyAoKCMgb2YgYWRk cmVzc2VzKSAqIChhZGRyZXNzIHNpemUsIGllIDQgb3IgMTYpKS4NCg0KT3IgaXMgdGhlIGludGVu dCB0aGF0IGlmIG1vcmUgdHlwZXMgYXJlIGRlZmluZWQsIHRoYXQgdGhlIGRhdGEgbWlnaHQgYmU6 IHR5cGUtMSwgbGVuZ3RoLTEtMiwgYWRkcmVzcyBsaXN0IGZvciB0eXBlWywgdHlwZS0yLCBsZW5n dGgtMi0yLCBhZGRyZXNzIGxpc3QgZm9yIHR5cGUsIFsuLi5dXT8NCg0KV2Ugc2hvdWxkIGFsc28g ZXhwbG9yZSB3aGV0aGVyIHR5cGUgZmllbGQgaXMgbmVlZGVkOyB3aHkgd291bGRuJ3QgYSBuZXcg c2V0IG9mIG9wdGlvbnMgYmUgZGVmaW5lZCBmb3IgYSBmdXR1cmUgdHlwZT8gVGhpcyBkb2N1bWVu dCBpcyB0aXRsZWQgQU5RUCBzbyB3aGF0IG90aGVyIHR5cGVzIG1pZ2h0IHRoZXJlIGJlIGFuZCB3 b3VsZCB0aGV5IHN0aWxsIGJlIEFOUVA/DQoNCi0gQmVybmUNCg== --_000_9B7D807E38294BFD9A741D31FB9CC2F6ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiNGRkZG RkYiPg0KPGRpdj48L2Rpdj4NCjxkaXY+U2VlbXMgdG8gbWUgdGhlIHY0ICZhbXA7IHY2IG9wdGlv bnMgY2FuIGJlIHNpbXBsaWVkIHRvIHJlbW92ZSBsZW5ndGhfMiBhcyB0aGUgb3B0aW9uIGxlbmd0 aCBjYW4ganVzdCBiZSAxICYjNDM7ICgoIyBvZiBhZGRyZXNzZXMpICogKGFkZHJlc3Mgc2l6ZSwg aWUgNCBvciAxNikpLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+T3IgaXMgdGhlIGlu dGVudCB0aGF0IGlmIG1vcmUgdHlwZXMgYXJlIGRlZmluZWQsIHRoYXQgdGhlIGRhdGEgbWlnaHQg YmU6IHR5cGUtMSwgbGVuZ3RoLTEtMiwgYWRkcmVzcyBsaXN0IGZvciB0eXBlWywgdHlwZS0yLCBs ZW5ndGgtMi0yLCBhZGRyZXNzIGxpc3QgZm9yIHR5cGUsIFsuLi5dXT88L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PldlIHNob3VsZCBhbHNvIGV4cGxvcmUgd2hldGhlciB0eXBlIGZpZWxk IGlzIG5lZWRlZDsgd2h5IHdvdWxkbid0IGEgbmV3IHNldCBvZiBvcHRpb25zIGJlIGRlZmluZWQg Zm9yIGEgZnV0dXJlIHR5cGU/IFRoaXMgZG9jdW1lbnQgaXMgdGl0bGVkIEFOUVAgc28gd2hhdCBv dGhlciB0eXBlcyBtaWdodCB0aGVyZSBiZSBhbmQgd291bGQgdGhleSBzdGlsbCBiZSBBTlFQPzwv ZGl2Pg0KPGRpdj48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iQ291cmllciIg c2l6ZT0iMyI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFj ZTogcHJlOyAtd2Via2l0LXRhcC1oaWdobGlnaHQtY29sb3I6IHJnYmEoMjYsIDI2LCAyNiwgMC4y OTI5NjkpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZpbGwtY29sb3I6IHJnYmEoMTc1LCAxOTIsIDIy NywgMC4yMzA0NjkpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZyYW1lLWNvbG9yOiByZ2JhKDc3LCAx MjgsIDE4MCwgMC4yMzA0NjkpOyI+PGJyPg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+LSBC ZXJuZTwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9B7D807E38294BFD9A741D31FB9CC2F6ciscocom_-- From volz@cisco.com Sun Jul 29 08:01: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 2D1E121F86F5 for ; Sun, 29 Jul 2012 08:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGSdqkSveTwb for ; Sun, 29 Jul 2012 08:01:43 -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 5D2A521F84C4 for ; Sun, 29 Jul 2012 08:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=4017; q=dns/txt; s=iport; t=1343574103; x=1344783703; h=from:to:subject:date:message-id:mime-version; bh=Gg5rl/6szxeD1BbonMm59MclUvkD9NZeaAxI1u91Lnw=; b=RBOAuG4GeULHHIrUHV2A7887fJM2yKdherwEVcKbNNoIdINPVjHZln0Z 47oV5Uf0vHoqWEqbAUxfU5y2H1yF1Mv8UGG6S59KmhV5dQH/j/EX7PE1C j3r/8iCJiPca2i3cvWe7VoiiBajwHWylRUJaNAIaDnnOwMwA/GkoSRtHE 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAF9PFVCtJXG8/2dsb2JhbABFgkqDKbJyeoEHgicSARBoAQw+AgQwJgEENYdrmDmBKI0ZkXyRIDJgA5VJjieBZoJf X-IronPort-AV: E=Sophos;i="4.77,674,1336348800"; d="scan'208,217";a="106393640" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 29 Jul 2012 15:01:43 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6TF1gxE020672 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 29 Jul 2012 15:01:42 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.162]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Sun, 29 Jul 2012 10:01:42 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: draft-lemon-dhc-dns-pd-01.txt Thread-Index: Ac1tmw/2b/R08ZxSRCmQ4FrzUZcKRQ== Date: Sun, 29 Jul 2012 15:01:41 +0000 Message-ID: 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-19070.006 x-tm-as-result: No--23.478200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_ADF7CEDDA8764DAA9EBE06A9078C444Bciscocom_" MIME-Version: 1.0 Subject: [dhcwg] draft-lemon-dhc-dns-pd-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: Sun, 29 Jul 2012 15:01:44 -0000 --_000_ADF7CEDDA8764DAA9EBE06A9078C444Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGVkOg0KDQpJIGxpa2UgdGhpcyB3b3JrLg0KDQpBIGNvdXBsZSBvZiBtaW5vciBuaXRzOg0KDQoi REhDUCBEaXNjb3ZlciIgc2hvdWxkIGJlICJESENQIFNvbGljaXQiLiBNaWdodCBiZSBiZXN0IHRv IGRyb3AgREhDUCBiZWZvcmUgdGhlIERIQ1B2NiBtZXNzYWdlIG5hbWVzIGFzIFJGQyAzMzE1IGFu ZCBvdGhlcnMgaGF2ZW4ndCBnZW5lcmFsbHkgZG9uZSB0aGF0Lg0KDQpJIGFsc28gdGhpbmsgdGhl IGZvbGxvd2luZyBkZXNlcnZlcyBzb21lIGRpc2N1c3Npb246DQoNCiAgICAgVGhlIHJlcXVlc3Rp bmcgcm91dGVyIE1VU1Qgc2lsZW50bHkNCiAgIGRpc2NhcmQgYW55IERIQ1AgQWR2ZXJ0aXNlIG1l c3NhZ2UgY29udGFpbmluZyBhIFBEWk0gb3B0aW9uIHRoYXQNCiAgIGluZGljYXRlcyBhIG1ldGhv ZCB0aGF0IHdhcyBub3QgbGlzdGVkIGluIHRoZSBQRFpQIG9wdGlvbiBzZW50IGluIHRoZQ0KICAg REhDUCBEaXNjb3ZlciBtZXNzYWdlLg0KDQpUaGlzIHNlZW1zIGEgYml0IHNldmVyZSB0byBtZSAt IGVzcGVjaWFsbHkgaWYgYSBzZXJ2ZXIgaXMganVzdCBjb25maWd1cmVkIHRvIHJldHVybiBhIGZp eGVkIHZhbGUgZm9yIHRoaXMgb3B0aW9uLiBJIGNvdWxkIHNlZSBtb3ZlIHRoaXMgdG8gdGhlIGVu ZCBvZiB0aGUgbGlzdCBvZiBBZHZlcnRpc2VzIHRvIGJlIGNvbnNpZGVyZWQsIGJ1dCB0byBkaXNj YXJkIGl0IHNob3VsZCBiZSBhIFNIT1VMRCAtIG5vdCBhIE1VU1QuDQoNClRob3VnaCB0aGlzIHdv dWxkIGxpa2VseSBvbmx5IHdvcmsgaWYgdGhlICJmaXhlZCIgb3B0aW9uIHNwZWNpZmllZCBzcG9v ZmVkLCBzaW5jZSB0aGUgb3RoZXJzIHJlcXVpcmUgZnVydGhlciBjb21tdW5pY2F0aW9uLg0KDQot IEJlcm5pZQ0K --_000_ADF7CEDDA8764DAA9EBE06A9078C444Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <2A762D01F7520C47B6EBC9FAF75B41F6@cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiNGRkZG RkYiPg0KPGRpdj48L2Rpdj4NCjxkaXY+VGVkOjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+SSBsaWtlIHRoaXMgd29yay48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkEgY291 cGxlIG9mIG1pbm9yIG5pdHM6PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mcXVvdDtE SENQIERpc2NvdmVyJnF1b3Q7IHNob3VsZCBiZSAmcXVvdDtESENQIFNvbGljaXQmcXVvdDsuIE1p Z2h0IGJlIGJlc3QgdG8gZHJvcCBESENQIGJlZm9yZSB0aGUgREhDUHY2IG1lc3NhZ2UgbmFtZXMg YXMgUkZDIDMzMTUgYW5kIG90aGVycyBoYXZlbid0IGdlbmVyYWxseSBkb25lIHRoYXQuPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGFsc28gdGhpbmsgdGhlIGZvbGxvd2luZyBkZXNl cnZlcyBzb21lIGRpc2N1c3Npb246PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxl PSJmb250LWZhbWlseTogbW9ub3NwYWNlOyB3aGl0ZS1zcGFjZTogcHJlOyAtd2Via2l0LXRhcC1o aWdobGlnaHQtY29sb3I6IHJnYmEoMjYsIDI2LCAyNiwgMC4yOTY4NzUpOyAtd2Via2l0LWNvbXBv c2l0aW9uLWZpbGwtY29sb3I6IHJnYmEoMTc1LCAxOTIsIDIyNywgMC4yMzA0NjkpOyAtd2Via2l0 LWNvbXBvc2l0aW9uLWZyYW1lLWNvbG9yOiByZ2JhKDc3LCAxMjgsIDE4MCwgMC4yMzA0NjkpOyAi Pg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0icGFnZSIgdGl0bGU9IlBhZ2UgOCI+DQo8ZGl2 IGNsYXNzPSJsYXlvdXRBcmVhIj4NCjxkaXYgY2xhc3M9ImNvbHVtbiI+DQo8cHJlPjxkaXYgY2xh c3M9InBhZ2UiIHRpdGxlPSJQYWdlIDgiPjxkaXYgY2xhc3M9ImxheW91dEFyZWEiPjxkaXYgY2xh c3M9ImNvbHVtbiI+PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC4wMDAwMDBwdDsgZm9u dC1mYW1pbHk6ICdDb3VyaWVyJyI+ICAgICBUaGUgcmVxdWVzdGluZyByb3V0ZXIgTVVTVCBzaWxl bnRseQ0KICAgZGlzY2FyZCBhbnkgREhDUCBBZHZlcnRpc2UgbWVzc2FnZSBjb250YWluaW5nIGEg UERaTSBvcHRpb24gdGhhdA0KICAgaW5kaWNhdGVzIGEgbWV0aG9kIHRoYXQgd2FzIG5vdCBsaXN0 ZWQgaW4gdGhlIFBEWlAgb3B0aW9uIHNlbnQgaW4gdGhlDQogICBESENQIERpc2NvdmVyIG1lc3Nh Z2UuPC9zcGFuPjwvcHJlPjwvZGl2PjwvZGl2PjwvZGl2PjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj5UaGlzIHNlZW1zIGEgYml0IHNldmVyZSB0byBtZSAtIGVzcGVjaWFsbHkg aWYgYSBzZXJ2ZXIgaXMganVzdCBjb25maWd1cmVkIHRvIHJldHVybiBhIGZpeGVkIHZhbGUgZm9y IHRoaXMgb3B0aW9uLiBJIGNvdWxkIHNlZSBtb3ZlIHRoaXMgdG8gdGhlIGVuZCBvZiB0aGUgbGlz dCBvZiBBZHZlcnRpc2VzIHRvIGJlIGNvbnNpZGVyZWQsIGJ1dCB0byBkaXNjYXJkIGl0IHNob3Vs ZCBiZSBhIFNIT1VMRCAtIG5vdCBhIE1VU1QuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5UaG91Z2ggdGhpcyB3b3VsZCBsaWtlbHkgb25seSB3b3JrIGlmIHRoZSAmcXVvdDtmaXhlZCZx dW90OyBvcHRpb24gc3BlY2lmaWVkIHNwb29mZWQsIHNpbmNlIHRoZSBvdGhlcnMgcmVxdWlyZSBm dXJ0aGVyIGNvbW11bmljYXRpb24uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tIEJl cm5pZTwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_ADF7CEDDA8764DAA9EBE06A9078C444Bciscocom_-- From Ted.Lemon@nominum.com Sun Jul 29 08:59: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 4EE6821F8625 for ; Sun, 29 Jul 2012 08:59:05 -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.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zV4TR-GjF5fq for ; Sun, 29 Jul 2012 08:59:04 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 47FC121F85D5 for ; Sun, 29 Jul 2012 08:59:04 -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 DSNKUBVdxwscTQVHgwko1viWOVaEU8VoeXlu@postini.com; Sun, 29 Jul 2012 08:59:04 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 2D6101B8263 for ; Sun, 29 Jul 2012 08:59:03 -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 1616919005D; Sun, 29 Jul 2012 08:59:03 -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, 29 Jul 2012 08:59:03 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] draft-lemon-dhc-dns-pd-01.txt Thread-Index: Ac1tmw/2b/R08ZxSRCmQ4FrzUZcKRQAQq4+A Date: Sun, 29 Jul 2012 15:59:02 +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: multipart/alternative; boundary="_000_CC992AF045944BDE816659D43709B3CCnominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] draft-lemon-dhc-dns-pd-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: Sun, 29 Jul 2012 15:59:05 -0000 --_000_CC992AF045944BDE816659D43709B3CCnominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jul 29, 2012, at 11:01 AM, Bernie Volz (volz) wrote: "DHCP Discover" should be "DHCP Solicit". Might be best to drop DHCP before= the DHCPv6 message names as RFC 3315 and others haven't generally done tha= t. Oops! I also think the following deserves some discussion: The requesting router MUST silently discard any DHCP Advertise message containing a PDZM option that indicates a method that was not listed in the PDZP option sent in the DHCP Discover message. This seems a bit severe to me - especially if a server is just configured t= o return a fixed vale for this option. I could see move this to the end of = the list of Advertises to be considered, but to discard it should be a SHOU= LD - not a MUST. The reason for making this a MUST is that it should never happen. If we m= ake it a should, people won't actually implement this spec=97they'll do wha= t you're suggesting and just make it an option. The goal here was to do a= negotiation, not return a configuration option. I guess that's what the = discussion would be about=97do we want this to be a negotiation, or an opti= on, or both? You can see where I stand on the issue=97that's why I wrote = it this way... :) Though this would likely only work if the "fixed" option specified spoofed,= since the others require further communication. Right. Thanks for the review! I'll be curious to hear if other wg members have r= eactions to the question you've posed! --_000_CC992AF045944BDE816659D43709B3CCnominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jul 29, 2012, at 11:01 AM, Bernie Volz (volz) wrote:
"DHCP Discover" should be "DHCP Solicit". Might be= best to drop DHCP before the DHCPv6 message names as RFC 3315 and others h= aven't generally done that.

Oops!

I also think the following deserves some discussi= on: 
     The requesting router MUST silently
   discard any DHCP Advertise message containing a PDZM option that
   indicates a method that was not listed in the PDZP option sent in the
   DHCP Discover message.
This seems a bit severe to me - especially if a server is just configu= red to return a fixed vale for this option. I could see move this to the en= d of the list of Advertises to be considered, but to discard it should be a= SHOULD - not a MUST.

The reason for making this a MUST is that it should never happen.   If= we make it a should, people won't actually implement this spec=97they'll d= o what you're suggesting and just make it an option.   The goal here w= as to do a negotiation, not return a configuration option.   I guess that's what the discussion would be about=97do we w= ant this to be a negotiation, or an option, or both?   You can see whe= re I stand on the issue=97that's why I wrote it this way... :)

Though this would likely only work if the "f= ixed" option specified spoofed, since the others require further commu= nication.

Right.

Thanks for the review!   I'll be curious to hear if other wg memb= ers have reactions to the question you've posed!

--_000_CC992AF045944BDE816659D43709B3CCnominumcom_-- From zehn.cao@gmail.com Sun Jul 29 15:49: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 E047521F8598 for ; Sun, 29 Jul 2012 15:49:42 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1Nwck+hn2te for ; Sun, 29 Jul 2012 15:49:42 -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 768A221F857E for ; Sun, 29 Jul 2012 15:49:42 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8704197pbc.31 for ; Sun, 29 Jul 2012 15:49:42 -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=BHebE7fhIvpIsV48LcyqNC63o5EgXKCBlew2IW02MLM=; b=TOLFGtMn/mNbvAoe/czahqlJhMtAe4kU33np7bEM8RLJo5fawEPhZvY+7tC5fOsDE0 WKDP7VHzT3+7ywBmD01ZLBtntuokg9Iz3nEfzXg1u7TrpLJq+P8sK8bjvwlRgkyMkBTb lMoID629PtceN0eIZ6G5diauAOgd/nrSf9hzf40RMpkEO95jbUW+R3Eleb1dGSezeSso rWdtqQRMVKZNqENz2Aj9lxvgeCjVXbK6yn1Jc4YvIny68gfGF6cwQGaob2kzOkFLyoxE WoQNH8Tu70dqYGDk9bDtN+e/ZP3rEZEG8cIiPpKAr0f5eN+dlb5ulGst/4Ww1RELv1fE Go9Q== MIME-Version: 1.0 Received: by 10.68.216.72 with SMTP id oo8mr30322905pbc.82.1343602182284; Sun, 29 Jul 2012 15:49:42 -0700 (PDT) Received: by 10.68.1.198 with HTTP; Sun, 29 Jul 2012 15:49:42 -0700 (PDT) In-Reply-To: <9B7D807E-3829-4BFD-9A74-1D31FB9CC2F6@cisco.com> References: <9B7D807E-3829-4BFD-9A74-1D31FB9CC2F6@cisco.com> Date: Sun, 29 Jul 2012 15:49:42 -0700 Message-ID: From: Zhen Cao To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] draft-cao-dhc-anqp-option-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, 29 Jul 2012 22:49:43 -0000 Hi Bernie, Thank you for the comments. See inline below. On Sun, Jul 29, 2012 at 7:33 AM, Bernie Volz (volz) wrote: > Seems to me the v4 & v6 options can be simplied to remove length_2 as the > option length can just be 1 + ((# of addresses) * (address size, ie 4 or > 16)). How to handle the situation that type-1 has two v4 addresses and type-2 has 1 v4 address. And even only one address is contained, how to differentiate the 4 v4 address to 1 v6 address? > > Or is the intent that if more types are defined, that the data might be: > type-1, length-1-2, address list for type[, type-2, length-2-2, address list > for type, [...]]? > > We should also explore whether type field is needed; why wouldn't a new set > of options be defined for a future type? This document is titled ANQP so > what other types might there be and would they still be ANQP? We consider this because the IEEE/WFA people have defined many entities that will need to advertise their address. ANQP is one example in IEEE 802.11-2012, and RLQP is coming in future specs. > > - Berne > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From volz@cisco.com Sun Jul 29 16:11: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 055FF11E80E6 for ; Sun, 29 Jul 2012 16:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UO9qp21WzEyS for ; Sun, 29 Jul 2012 16:11:03 -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 0F63311E8072 for ; Sun, 29 Jul 2012 16:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=1747; q=dns/txt; s=iport; t=1343603463; x=1344813063; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EfMfR2cx9Sn6KF8uAb3tPUIXy4iRdWwYKlhToNO+9Fw=; b=ORbkr+ghMiVEArfHxoHPBgVTalh/jPlYLVM8+4Y4AZp92qXd673W+ypJ 7lPdsvklbCkKLGF+l4hpwmmUMpoegjvZC6xlU5vcXrXuvaWc5UZlWQFPL IUfEHa9COWBNJAQ3b+qP7BAACzlaivFoFcg6uQ4XxtYvaypSL+Lxzitw1 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAK/CFVCtJV2c/2dsb2JhbABFuV6BB4IgAQEBAwEBAQEPASc0CwULAgEIDgoeECEGCyUBAQQOBSKHXAMGBguZU5VMDYlKBIpoaIYCYAOTdYFUiwqDHYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,675,1336348800"; d="scan'208";a="106465843" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 29 Jul 2012 23:10:54 +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 q6TNAsPJ001917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 29 Jul 2012 23:10:54 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.162]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Sun, 29 Jul 2012 18:10:54 -0500 From: "Bernie Volz (volz)" To: Zhen Cao Thread-Topic: [dhcwg] draft-cao-dhc-anqp-option-00 Thread-Index: Ac1tlyXw2O9xwNy1QSGiqnzZP73xGwAbzPoA//+yGVI= Date: Sun, 29 Jul 2012 23:10:52 +0000 Message-ID: References: <9B7D807E-3829-4BFD-9A74-1D31FB9CC2F6@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-19072.001 x-tm-as-result: No--47.247300-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] draft-cao-dhc-anqp-option-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, 29 Jul 2012 23:11:04 -0000 So, you are saying there can be (in the future) multiple types (each follow= ed by data)? Perhaps I missed that but it wasn't clear to me from the draft= .=20 Sent from my iPhone On Jul 29, 2012, at 3:49 PM, "Zhen Cao" wrote: > Hi Bernie, >=20 > Thank you for the comments. See inline below. >=20 > On Sun, Jul 29, 2012 at 7:33 AM, Bernie Volz (volz) wrot= e: >> Seems to me the v4 & v6 options can be simplied to remove length_2 as th= e >> option length can just be 1 + ((# of addresses) * (address size, ie 4 or >> 16)). >=20 > How to handle the situation that type-1 has two v4 addresses and > type-2 has 1 v4 address. >=20 > And even only one address is contained, how to differentiate the 4 v4 > address to 1 v6 address? >=20 >>=20 >> Or is the intent that if more types are defined, that the data might be: >> type-1, length-1-2, address list for type[, type-2, length-2-2, address = list >> for type, [...]]? >>=20 >> We should also explore whether type field is needed; why wouldn't a new = set >> of options be defined for a future type? This document is titled ANQP so >> what other types might there be and would they still be ANQP? >=20 > We consider this because the IEEE/WFA people have defined many > entities that will need to advertise their address. ANQP is one > example in IEEE 802.11-2012, and RLQP is coming in future specs. >=20 >>=20 >> - Berne >>=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 leaf.y.yeh@huawei.com Sun Jul 29 18:36: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 6C4DD21F8686 for ; Sun, 29 Jul 2012 18:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IBfMPuxdgdx for ; Sun, 29 Jul 2012 18:36:53 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BDB9821F860B for ; Sun, 29 Jul 2012 18:36:53 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIE49927; Sun, 29 Jul 2012 21:36:53 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 29 Jul 2012 18:35:08 -0700 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 29 Jul 2012 18:35:08 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Mon, 30 Jul 2012 09:35:03 +0800 From: Leaf yeh To: dhcwg Thread-Topic: New Version Notification for draft-yeh-dhc-dhcpv6-prefix-pool-opt-08.txt Thread-Index: AQHNbfHBvL60uKXnK0SWI9HDwnzpUJdBCLSA Date: Mon, 30 Jul 2012 01:35:02 +0000 Message-ID: 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Bernie Volz \(volz\)" Subject: [dhcwg] FW: New Version Notification for draft-yeh-dhc-dhcpv6-prefix-pool-opt-08.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, 30 Jul 2012 01:36:54 -0000 RGVhciBESEMgZm9sa3MsDQoNClRoZSBkcmFmdCAodmVyLi0wOCkgJiB0aGUgcHJvcG9zZWQgKE9Q VElPTl9QUkVGSVhfUE9PTCkgb24gdGhlIGFnZW5kYSBvZiBJRVRGODQgREhDIHNlc3Npb24gKGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy84NC9hZ2VuZGEvZGhjLyApLCBpcyB3 YWl0aW5nIGZvciB5b3VyIHJldmlldyBhbmQgY29tbWVudHMuDQoNCg0KQmVzdCBSZWdhcmRzLA0K TGVhZg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBN b25kYXksIEp1bHkgMzAsIDIwMTIgOToyMiBBTQ0KVG86IExlYWYgeWVoDQpDYzogaHVqQGN0YnJp LmNvbS5jbjsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgdGVkLmxlbW9uQG5vbWludW0u Y29tDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXllaC1kaGMt ZGhjcHY2LXByZWZpeC1wb29sLW9wdC0wOC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQteWVoLWRoYy1kaGNwdjYtcHJlZml4LXBvb2wtb3B0LTA4LnR4dA0KaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMZWFmIFkuIFllaCBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVU RiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXllaC1kaGMtZGhjcHY2LXByZWZpeC1w b29sLW9wdA0KUmV2aXNpb246CSAwOA0KVGl0bGU6CQkgUHJlZml4IFBvb2wgT3B0aW9uIGZvciBE SENQdjYgUmVsYXkgQWdlbnRzIG9uIFByb3ZpZGVyIEVkZ2UgUm91dGVycw0KQ3JlYXRpb24gZGF0 ZToJIDIwMTItMDctMjgNCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9m IHBhZ2VzOiAxMw0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC15ZWgtZGhjLWRoY3B2Ni1wcmVmaXgtcG9vbC1vcHQtMDgudHh0DQpTdGF0 dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteWVoLWRo Yy1kaGNwdjYtcHJlZml4LXBvb2wtb3B0DQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXllaC1kaGMtZGhjcHY2LXByZWZpeC1wb29sLW9wdC0wOA0KRGlm ZjogICAgICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXll aC1kaGMtZGhjcHY2LXByZWZpeC1wb29sLW9wdC0wOA0KDQpBYnN0cmFjdDoNCiAgIFRoZSBESENQ djYgUHJlZml4IFBvb2wgb3B0aW9uIHByb3ZpZGVzIGEgbWVjaGFuaXNtIGZvciBESENQdjYgUHJl Zml4DQogICBEZWxlZ2F0aW9uIChESENQdjYtUEQpLCBhbGxvd2luZyB0aGUgREhDUHY2IHNlcnZl ciB0byBub3RpZnkgYSBESENQdjYNCiAgIHJlbGF5IGFnZW50IGltcGxlbWVudGVkIG9uIGEgUHJv dmlkZXIgRWRnZSAoUEUpIHJvdXRlciBhYm91dCBhY3RpdmUNCiAgIHByZWZpeCBwb29scyBhbGxv Y2F0ZWQgYnkgdGhlIERIQ1B2NiBzZXJ2ZXIgdG8gdGhlIFBFIHJvdXRlci4gIFRoZQ0KICAgaW5m b3JtYXRpb24gb2YgYWN0aXZlIHByZWZpeCBwb29scyBjYW4gYmUgdXNlZCB0byBlbmZvcmNlIElQ djYgcm91dGUNCiAgIGFnZ3JlZ2F0aW9uIG9uIHRoZSBQRSByb3V0ZXIgYnkgYWRkaW5nIG9yIHJl bW92aW5nIGFnZ3JlZ2F0ZWQgcm91dGVzDQogICBhY2NvcmRpbmcgdG8gdGhlIHN0YXR1cyBvZiB0 aGUgcHJlZml4IHBvb2xzLiAgVGhlIGFkdmVydGlzaW5nIG9mIHRoZQ0KICAgYWdncmVnYXRlZCBy b3V0ZXMgaW4gdGhlIHJvdXRpbmcgcHJvdG9jb2wgZW5hYmxlZCBvbiB0aGUgbmV0d29yay0NCiAg IGZhY2luZyBpbnRlcmZhY2Ugb2YgUEUgcm91dGVycyB3aWxsIGRyYW1hdGljYWxseSBkZWNyZWFz ZXMgdGhlIG51bWJlcg0KICAgb2YgdGhlIHJvdXRpbmcgdGFibGUgZW50cmllcyBpbiB0aGUgSVNQ IG5ldHdvcmsuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNy ZXRhcmlhdA0K From internet-drafts@ietf.org Sun Jul 29 18:58: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 1CF8221F866C; Sun, 29 Jul 2012 18:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLILDH0myTQb; Sun, 29 Jul 2012 18:58:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D86721F8666; Sun, 29 Jul 2012 18:58:14 -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.32 Message-ID: <20120730015814.6142.26392.idtracker@ietfa.amsl.com> Date: Sun, 29 Jul 2012 18:58:14 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-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, 30 Jul 2012 01:58:15 -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 : RADIUS Option for DHCPv6 Relay Agents on Broadband Acces= s Server Author(s) : Leaf Y. Yeh Mohamed Boucadair Ted Lemon Filename : draft-ietf-dhc-dhcpv6-radius-opt-01.txt Pages : 9 Date : 2012-07-29 Abstract: The DHCPv6 RADIUS option provides a communication mechanism between relay agent and the server. This mechanism can help the centralized DHCPv6 server to select the right configuration for the client based on the authorization information received from a separate RADIUS server which is not located at the same place of DHCPv6 server in the cases where the NAS acts as DHCPv6 relay agent and RADIUS client simultaneously. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From leaf.y.yeh@huawei.com Sun Jul 29 20:04: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 7D08911E810E for ; Sun, 29 Jul 2012 20:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrcNbyv5miVV for ; Sun, 29 Jul 2012 20:04:41 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E95CC11E8088 for ; Sun, 29 Jul 2012 20:04:40 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIE55120; Sun, 29 Jul 2012 23:04:40 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 29 Jul 2012 20:02:05 -0700 Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 29 Jul 2012 20:02:05 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Mon, 30 Jul 2012 11:01:58 +0800 From: Leaf yeh To: Ted Lemon , "john_brzozowski@cable.comcast.com" Thread-Topic: Agenda of IETF84 DHC session Thread-Index: Ac1t/65T0qRJCR8kSYSeBl7YvAsRqA== Date: Mon, 30 Jul 2012 03:01:58 +0000 Message-ID: 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 Subject: [dhcwg] Agenda of IETF84 DHC session 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, 30 Jul 2012 03:04:41 -0000 Dear Chairs, The agenda (https://datatracker.ietf.org/meeting/84/agenda/dhc/) might have= a typo in the following text ---------- Draft: RADIUS Option for DHCPv6 Relay Agents on Broadband Access Server URL: http://datatracker.ietf.org/doc/draft-yeh-dhc-dhcpv6-authorization-= opt/ ---------- , the correct draft as a WG item, shall be=20 ---------- Draft: RADIUS Option for DHCPv6 Relay Agents on Broadband Access Server= =20 URL: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt/= =20 ---------- BTW, the draft in https://datatracker.ietf.org/meeting/84/agenda/dhc-drafts= .pdf shall also be corrected as that on the page at https://datatracker.iet= f.org/doc/draft-ietf-dhc-dhcpv6-radius-opt/ . Best Regards, Leaf From leaf.y.yeh@huawei.com Sun Jul 29 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 41B4B21F84CE for ; Sun, 29 Jul 2012 20:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeyE9xYCMVms for ; Sun, 29 Jul 2012 20:05:06 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4048421F84A1 for ; Sun, 29 Jul 2012 20:05:06 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIE55158; Sun, 29 Jul 2012 23:05:06 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 29 Jul 2012 20:02:18 -0700 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 29 Jul 2012 20:02:19 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Mon, 30 Jul 2012 11:02:12 +0800 From: Leaf yeh To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt Thread-Index: AQHNbfbnuo3fiIpzMkKxliaPfKNNi5dBHikg Date: Mon, 30 Jul 2012 03:02:12 +0000 Message-ID: References: <20120730015814.6142.26392.idtracker@ietfa.amsl.com> In-Reply-To: <20120730015814.6142.26392.idtracker@ietfa.amsl.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] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-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, 30 Jul 2012 03:05:07 -0000 Dear DHC folks, The draft-ietf (ver.-01) & the proposed (OPTION_RADIUS) on the agenda of IE= TF84 DHC session, is waiting for your review and comments. Best Regards, Leaf PS. (https://datatracker.ietf.org/meeting/84/agenda/dhc/ ) -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Monday, July 30, 2012 9:58 AM To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.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 : RADIUS Option for DHCPv6 Relay Agents on Broadband Acces= s Server Author(s) : Leaf Y. Yeh Mohamed Boucadair Ted Lemon Filename : draft-ietf-dhc-dhcpv6-radius-opt-01.txt Pages : 9 Date : 2012-07-29 Abstract: The DHCPv6 RADIUS option provides a communication mechanism between relay agent and the server. This mechanism can help the centralized DHCPv6 server to select the right configuration for the client based on the authorization information received from a separate RADIUS server which is not located at the same place of DHCPv6 server in the cases where the NAS acts as DHCPv6 relay agent and RADIUS client simultaneously. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-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 ietf@meetecho.com Mon Jul 30 00:24: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 695B721F844D for ; Mon, 30 Jul 2012 00:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.695 X-Spam-Level: * X-Spam-Status: No, score=1.695 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UkmIAo16Gts for ; Mon, 30 Jul 2012 00:24:13 -0700 (PDT) Received: from smtplq04.aruba.it (smtplq-out6.aruba.it [62.149.158.26]) by ietfa.amsl.com (Postfix) with SMTP id 05C2121F847D for ; Mon, 30 Jul 2012 00:24:12 -0700 (PDT) Received: (qmail 6470 invoked by uid 89); 30 Jul 2012 07:24:09 -0000 Received: from unknown (HELO smtp7.aruba.it) (62.149.158.227) by smtplq04.aruba.it with SMTP; 30 Jul 2012 07:24:09 -0000 Received: (qmail 27679 invoked by uid 89); 30 Jul 2012 07:24:09 -0000 Received: from unknown (HELO ?172.16.1.123?) (alex@meetecho.com@209.82.28.249) by smtp7.ad.aruba.it with ESMTPA; 30 Jul 2012 07:24:09 -0000 Message-ID: <50163687.2090700@meetecho.com> Date: Mon, 30 Jul 2012 09:23:51 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Subject: [dhcwg] Meetecho support for DHC 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, 30 Jul 2012 07:24:14 -0000 Hi all, a virtual room has been reserved on the Meetecho system for Monday's DHC WG meeting session. Access to the on-line session (including audio and video streams) will be available at: http://www.meetecho.com/ietf84/dhc The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. Remote participants might also send their own voice to the room, if they want to, by either calling a landline phone number, or using our embedded VoIP applet (in this last case they are *strongly* advised to use a headset). A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf84 Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From mohamed.boucadair@orange.com Mon Jul 30 04:49: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 77DBE21F874A; Mon, 30 Jul 2012 04:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTAZ1Aob2i6y; Mon, 30 Jul 2012 04:49:05 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5E421F873C; Mon, 30 Jul 2012 04:49:03 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 7BAE118C224; Mon, 30 Jul 2012 13:49:02 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 50EDB238061; Mon, 30 Jul 2012 13:49:02 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Mon, 30 Jul 2012 13:48:54 +0200 From: To: "Bernie Volz (volz)" , Dave Thaler , "dhcwg@ietf.org" Date: Mon, 30 Jul 2012 13:48:53 +0200 Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QAAD2YUAAALuhAAAiadTwAJFlwDA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E910@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B7235BF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <489D13FBFA9B3E41812EA89F188F018E02CD82@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E02CD82@xmb-rcd-x04.cisco.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.6.19.115414 Cc: "pcp@ietf.org" Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 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, 30 Jul 2012 11:49:06 -0000 Dear Bernie, See inline. Cheers, Med =20 >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De=20 >la part de Bernie Volz (volz) >Envoy=E9 : vendredi 27 juillet 2012 16:47 >=C0 : Dave Thaler; dhcwg@ietf.org >Cc : pcp@ietf.org >Objet : Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 > >Dave: > >As the options as defined contain a domain name (encoded per=20 >RFC 1035) are address literals really appropriate? This also=20 >has consequences for configuring the option data in the=20 >servers. And, it seems rather bad to take an encoded name,=20 >convert it to a string, only to convert it back into an=20 >encoded name. But, alas, that is likely given the common APIs. > >Also, given that RFC 1035 section 3.1 states:=20 > > Since every domain name ends with the null label of > the root, a domain name is terminated by a length byte of zero. > >And the option is to accommodate a list of domain names=20 >(knowing that each terminates in the null label makes it=20 >possible to separate them), how do you propose that literals=20 >(10.1.2.3) be encoded so that it not end up as the domain name=20 >"10.1.2.3.". > >Perhaps there is a convention used to do this somewhere? (I=20 >admit I haven't looked at draft-iab-identifier-comparison carefully.) > > >When reviewing this and commenting the other day, I originally=20 >had thought about commenting on the rather strict rules as to=20 >how the results of DNS queries could be used and was thinking=20 >that it might be appropriate to relax them some. Just doing=20 >normal DNS lookups and using the results (AAAA if v6 is=20 >available, A if v4 is available, etc.) would likely make=20 >implementing this much easier and require less specialized code. > > >> 6) Section 5.2 says: >> "The DHCPv4 client MUST verify that the >> option length does not exceed 255 octets [RFC1035])." > >Good catch. This should be removed as we have the ability to=20 >support long v4 options - see RFC 3396. > >Note that per section 4 of this RFC: > > Let us divide all DHCP options into two categories - those that, by > definition, require implementation of the mechanisms defined in this > document, and those that do not. We will refer to the former as > concatenation-requiring options, and the latter as non- > concatenation-requiring options. In order for an option to be a > concatenation-requiring option, the protocol specification that > defines that option must require implementation of option splitting > and option concatenation as described in this document, by > specifically referencing this document. > >So the draft should reference RFC 3396 and indicate that this=20 >is a concatenation-requiring option. Med: I added this text to Section 5.1.=20 The OPTION_PCP_SERVER DHCPv4 option is a concatenation-requiring option. As such, the mechanism specified in [RFC3396] MUST be used if the PCP Server Name option exceeds the maximum DHCPv4 option size of 255 octets. Does this solves your concern?=20 > >- Bernie > >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 >On Behalf Of Dave Thaler >Sent: Thursday, July 26, 2012 5:59 PM >To: dhcwg@ietf.org >Subject: [dhcwg] FW: WGLC on draft-ietf-pcp-dhcp-03 > >I keep mangling the WG mailing list address, so forwarding. > >-----Original Message----- >From: Dave Thaler >Sent: Thursday, July 26, 2012 2:58 PM >To: 'pcp@ietf.org' >Cc: 'dhc@ietf.org' >Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 > >Missed responding to section 7 before sending... > >7) Re "A PCP Server configured using OPTION_PCP_SERVER over=20 >DHCPv4 is likely > to be resolved to IPv4 address(es)." > I don't think I'd agree with that assumption. If I put a=20 >DNS name in the option, > it'll be resolved to whatever records are in DNS of a type=20 >the client queries for. > The document currently doesn't say what type(s) to query=20 >for (A vs AAAA). > Per my comment on 2, I believe the types to query for=20 >should be independent of > how the name was obtained (DHCPv4, DHCPv6, manual, SNMP, or=20 >whatever else). > =20 > "A PCP Server configured using OPTION_PCP_SERVER over DHCPv6 may be > resolved to IPv4-mapped IPv6 address(es) or IPv6 address(es)" > By the same reasoning as my previous comment above, it may=20 >also be resolved > to IPv4 addresses. If I have a dual-stack PCP server, I=20 >should be able to put > the same DNS name in both a DHCPv4 option and a DHCPv6=20 >option, rather > than requiring me to have two separate names for the same server. > >8) Pursuant to a discussion I've been having with some folks on > draft-iab-identifier-comparison section 3.1.1 and some=20 >changes I'll be making to > it as a result, it got me thinking. I'm thinking it would=20 >be good to have a short > subsection on Guidance to Administrators on what to=20 >configure in their DHCP > server to return in these options, or more importantly,=20 >what not to configure. > Specifically, strings like "10.0.258", "0xA000001", and=20 >"012.0x102" would > all be a bad idea to configure (unless you specified how=20 >they're to be interpreted > which is an option, though probably not the most expedient=20 >one). I'm still strongly > in favor of retaining the fact that it's a string that can=20 >be passed to name > resolution APIs, but that means it's best to avoid strings=20 >that are interpreted > differently by different such APIs. > >9) On the same point, Section 4.2 currently states: > "Once each Name conveyed in the OPTION_PCP_SERVER option is=20 >validated, > each included Name is passed to the name resolution library (e.g., > Section 6.1.1 of [RFC1123] or [RFC6055])" > The ambiguity of "e.g." and "section 6.1.1 of [RFC1123]" in=20 >particular are=20 > problematic because as worded a client that chose not to=20 >support IP literals > would be legal, and it would try to resolve "10.11.12.13"=20 >in DNS, which we > don't want. Surprising (as=20 >draft-iab-identifier-comparison already points out), > even [RFC1123] allows this to be optional (a "SHOULD") in: =20 >"The host SHOULD check > the string syntactically for a dotted-decimal number before=20 >looking it up in=20 > the Domain Name System." > > Instead it's important here to require that the client be able to=20 > use IP literals. Most name resolution APIs=20 >(gethostbyname, getaddrinfo, > etc.) all meet that criteria. > >-Dave > >> -----Original Message----- >> From: Dave Thaler >> Sent: Thursday, July 26, 2012 2:32 PM >> To: pcp@ietf.org >> Cc: dhc@ietf.org >> Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 >>=20 >> Here's my personal comments on draft -03... I have a few editorial=20 >> nits I'll just send to the authors. >>=20 >> 1) I agree with the conclusion of the rationale but the sentence >> "DHC WG's position is this flexibility have some=20 >drawbacks such as inducing >> errors." >> isn't intelligible. What does "inducing errors" mean? =20 >Either explain or >> remove. >>=20 >> 2) The text on what to do with a name conveyed in an option=20 >is duplicated in >> Section 4.2 and 5.2. I'd prefer that this be specified=20 >only once, to avoid >> opportunities for discrepancies. That is, section=20 >4.2's first two paragraphs >> are >> fine, as are the first 1 1/2 paragraphs of 5.2, since those are=20 >> about how to get >> the name out of the option. The rest isn't DHCPv4 or=20 >DHCPv6 specific and >> should be in its own subsection. >>=20 >> 3) Re "It is RECOMMENDED to associate a validity lifetime=20 >with any address >> resulting from resolving the Name". The text should be=20 >more specific about >> what the validity lifetime should be. If the name is=20 >resolved in DNS, I'd >> say the validity lifetime should be the TTL of the DNS record. >>=20 >> 4) Re "When an >> application issues a PCP request to a PCP Server, the=20 >source address >> of the request MUST be among those assigned on the=20 >interface to which >> the destination PCP Server is bound. >>=20 >> This doesn't belong in a DHCP-specific document, it's out=20 >of scope. That's >> the job of the pcp-base spec. >>=20 >> 5) Same as point 4, but for all of section 6. In my view it=20 >belongs either in >> pcp-base or perhaps more likely in a separate spec that's=20 >not DHCP specific. >> E.g., if I manually configure one or more names, the same=20 >behavior=20 >> should apply. >>=20 >> 6) Section 5.2 says: >> "The DHCPv4 client MUST verify that the >> option length does not exceed 255 octets [RFC1035])." >>=20 >> What does this mean? The length field is only 1 byte so=20 >cannot contain >> a value larger than 255 anyway. So what exactly is a=20 >client supposed to >> "verify" here? >>=20 >> -Dave >>=20 >> > -----Original Message----- >> > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf=20 >> > Of Dave Thaler >> > Sent: Wednesday, July 18, 2012 2:21 PM >> > To: pcp@ietf.org >> > Cc: dhc@ietf.org >> > Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 >> > >> > As discussed at last IETF, the authors believe that all issues=20 >> > raised so far have been addressed. No new issues have been raised=20 >> > since then, so this message begins a Working Group Last Call on >> > draft-ietf-pcp- >> dhcp-03. >> > >> > This call would normally conclude in two weeks but that is during=20 >> > IETF week, so the last call is extended to conclude at the end of=20 >> > IETF (as of the Friday PCP meeting). >> > >> > We also agreed in Vancouver that this last call will be=20 >cross-posted=20 >> > to the DHC list, hence cc'ing the DHC WG. >> > >> > We need at least 5 reviewers. Please send comments to the list. >> > >> > Thanks, >> > -Dave Thaler >> > >> > _______________________________________________ >> > pcp mailing list >> > pcp@ietf.org >> > https://www.ietf.org/mailman/listinfo/pcp > > >_______________________________________________ >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 Mon Jul 30 06:18: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 3A4AC21F878B; Mon, 30 Jul 2012 06:18:33 -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.240, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHfQzCmzTuO1; Mon, 30 Jul 2012 06:18:32 -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 BBBB621F8786; Mon, 30 Jul 2012 06:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=11169; q=dns/txt; s=iport; t=1343654311; x=1344863911; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DJvMD6H3iXkRN/y36sGZ40OG+R9JuWwuR5NBJvJ86lo=; b=YDdnnVUvr333dhI5OpvREPVcHYYt0IyhG1gQyAIUiuB8PT5VvKYSWn8D SNRfqRKadbhQkQnRKxIHiB/PU2So9QCDmfaHUQHCzn3HeLs7zRzAGPjJj qO8fhP9MsmOOj+7KSCJj9/vrd+9qZ4HzIUnhu568f2sEMcHjKAMYjnvvj M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPaIFlCtJV2a/2dsb2JhbABFuVaBB4IgAQEBAwEBAQEPAVsLBQcEAgEIEQQBASgHJwsUCQgCBA4FIodlBguaVJ9cBItQCoV4YAOIGIlOg2OOJ4Fmgl+BWCM X-IronPort-AV: E=Sophos;i="4.77,679,1336348800"; d="scan'208";a="106630400" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 30 Jul 2012 13:18:31 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6UDIVF5021058 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jul 2012 13:18:31 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.162]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0298.004; Mon, 30 Jul 2012 08:18:30 -0500 From: "Bernie Volz (volz)" To: "mohamed.boucadair@orange.com" Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QAAD2YUAAALuhAAAiadTwAJFlwDAAAy4+fA== Date: Mon, 30 Jul 2012 13:18:29 +0000 Message-ID: <3EDDE74B-8637-4D47-AABD-0226036E9496@cisco.com> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B7235BF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <489D13FBFA9B3E41812EA89F188F018E02CD82@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E4A17E910@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4A17E910@PUEXCB1B.nanterre.francetelecom.fr> 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-19072.005 x-tm-as-result: No--78.520400-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: "dhcwg@ietf.org" , "pcp@ietf.org" Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 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, 30 Jul 2012 13:18:33 -0000 Yes, assuming you removed the text in 5.2 that Dave pointed out. - Bernie On Jul 30, 2012, at 7:49 AM, "mohamed.boucadair@orange.com" wrote: > Dear Bernie, >=20 > See inline. >=20 > Cheers, > Med >=20 >=20 >> -----Message d'origine----- >> De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De=20 >> la part de Bernie Volz (volz) >> Envoy=E9 : vendredi 27 juillet 2012 16:47 >> =C0 : Dave Thaler; dhcwg@ietf.org >> Cc : pcp@ietf.org >> Objet : Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 >>=20 >> Dave: >>=20 >> As the options as defined contain a domain name (encoded per=20 >> RFC 1035) are address literals really appropriate? This also=20 >> has consequences for configuring the option data in the=20 >> servers. And, it seems rather bad to take an encoded name,=20 >> convert it to a string, only to convert it back into an=20 >> encoded name. But, alas, that is likely given the common APIs. >>=20 >> Also, given that RFC 1035 section 3.1 states:=20 >>=20 >> Since every domain name ends with the null label of >> the root, a domain name is terminated by a length byte of zero. >>=20 >> And the option is to accommodate a list of domain names=20 >> (knowing that each terminates in the null label makes it=20 >> possible to separate them), how do you propose that literals=20 >> (10.1.2.3) be encoded so that it not end up as the domain name=20 >> "10.1.2.3.". >>=20 >> Perhaps there is a convention used to do this somewhere? (I=20 >> admit I haven't looked at draft-iab-identifier-comparison carefully.) >>=20 >>=20 >> When reviewing this and commenting the other day, I originally=20 >> had thought about commenting on the rather strict rules as to=20 >> how the results of DNS queries could be used and was thinking=20 >> that it might be appropriate to relax them some. Just doing=20 >> normal DNS lookups and using the results (AAAA if v6 is=20 >> available, A if v4 is available, etc.) would likely make=20 >> implementing this much easier and require less specialized code. >>=20 >>=20 >>> 6) Section 5.2 says: >>> "The DHCPv4 client MUST verify that the >>> option length does not exceed 255 octets [RFC1035])." >>=20 >> Good catch. This should be removed as we have the ability to=20 >> support long v4 options - see RFC 3396. >>=20 >> Note that per section 4 of this RFC: >>=20 >> Let us divide all DHCP options into two categories - those that, by >> definition, require implementation of the mechanisms defined in this >> document, and those that do not. We will refer to the former as >> concatenation-requiring options, and the latter as non- >> concatenation-requiring options. In order for an option to be a >> concatenation-requiring option, the protocol specification that >> defines that option must require implementation of option splitting >> and option concatenation as described in this document, by >> specifically referencing this document. >>=20 >> So the draft should reference RFC 3396 and indicate that this=20 >> is a concatenation-requiring option. >=20 > Med: I added this text to Section 5.1.=20 >=20 > The OPTION_PCP_SERVER DHCPv4 option is a concatenation-requiring > option. As such, the mechanism specified in [RFC3396] MUST be used > if the PCP Server Name option exceeds the maximum DHCPv4 option size > of 255 octets. >=20 > Does this solves your concern?=20 >=20 >=20 >>=20 >> - Bernie >>=20 >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 >> On Behalf Of Dave Thaler >> Sent: Thursday, July 26, 2012 5:59 PM >> To: dhcwg@ietf.org >> Subject: [dhcwg] FW: WGLC on draft-ietf-pcp-dhcp-03 >>=20 >> I keep mangling the WG mailing list address, so forwarding. >>=20 >> -----Original Message----- >> From: Dave Thaler >> Sent: Thursday, July 26, 2012 2:58 PM >> To: 'pcp@ietf.org' >> Cc: 'dhc@ietf.org' >> Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 >>=20 >> Missed responding to section 7 before sending... >>=20 >> 7) Re "A PCP Server configured using OPTION_PCP_SERVER over=20 >> DHCPv4 is likely >> to be resolved to IPv4 address(es)." >> I don't think I'd agree with that assumption. If I put a=20 >> DNS name in the option, >> it'll be resolved to whatever records are in DNS of a type=20 >> the client queries for. >> The document currently doesn't say what type(s) to query=20 >> for (A vs AAAA). >> Per my comment on 2, I believe the types to query for=20 >> should be independent of >> how the name was obtained (DHCPv4, DHCPv6, manual, SNMP, or=20 >> whatever else). >>=20 >> "A PCP Server configured using OPTION_PCP_SERVER over DHCPv6 may be >> resolved to IPv4-mapped IPv6 address(es) or IPv6 address(es)" >> By the same reasoning as my previous comment above, it may=20 >> also be resolved >> to IPv4 addresses. If I have a dual-stack PCP server, I=20 >> should be able to put >> the same DNS name in both a DHCPv4 option and a DHCPv6=20 >> option, rather >> than requiring me to have two separate names for the same server. >>=20 >> 8) Pursuant to a discussion I've been having with some folks on >> draft-iab-identifier-comparison section 3.1.1 and some=20 >> changes I'll be making to >> it as a result, it got me thinking. I'm thinking it would=20 >> be good to have a short >> subsection on Guidance to Administrators on what to=20 >> configure in their DHCP >> server to return in these options, or more importantly,=20 >> what not to configure. >> Specifically, strings like "10.0.258", "0xA000001", and=20 >> "012.0x102" would >> all be a bad idea to configure (unless you specified how=20 >> they're to be interpreted >> which is an option, though probably not the most expedient=20 >> one). I'm still strongly >> in favor of retaining the fact that it's a string that can=20 >> be passed to name >> resolution APIs, but that means it's best to avoid strings=20 >> that are interpreted >> differently by different such APIs. >>=20 >> 9) On the same point, Section 4.2 currently states: >> "Once each Name conveyed in the OPTION_PCP_SERVER option is=20 >> validated, >> each included Name is passed to the name resolution library (e.g., >> Section 6.1.1 of [RFC1123] or [RFC6055])" >> The ambiguity of "e.g." and "section 6.1.1 of [RFC1123]" in=20 >> particular are=20 >> problematic because as worded a client that chose not to=20 >> support IP literals >> would be legal, and it would try to resolve "10.11.12.13"=20 >> in DNS, which we >> don't want. Surprising (as=20 >> draft-iab-identifier-comparison already points out), >> even [RFC1123] allows this to be optional (a "SHOULD") in: =20 >> "The host SHOULD check >> the string syntactically for a dotted-decimal number before=20 >> looking it up in=20 >> the Domain Name System." >>=20 >> Instead it's important here to require that the client be able to=20 >> use IP literals. Most name resolution APIs=20 >> (gethostbyname, getaddrinfo, >> etc.) all meet that criteria. >>=20 >> -Dave >>=20 >>> -----Original Message----- >>> From: Dave Thaler >>> Sent: Thursday, July 26, 2012 2:32 PM >>> To: pcp@ietf.org >>> Cc: dhc@ietf.org >>> Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 >>>=20 >>> Here's my personal comments on draft -03... I have a few editorial=20 >>> nits I'll just send to the authors. >>>=20 >>> 1) I agree with the conclusion of the rationale but the sentence >>> "DHC WG's position is this flexibility have some=20 >> drawbacks such as inducing >>> errors." >>> isn't intelligible. What does "inducing errors" mean? =20 >> Either explain or >>> remove. >>>=20 >>> 2) The text on what to do with a name conveyed in an option=20 >> is duplicated in >>> Section 4.2 and 5.2. I'd prefer that this be specified=20 >> only once, to avoid >>> opportunities for discrepancies. That is, section=20 >> 4.2's first two paragraphs >>> are >>> fine, as are the first 1 1/2 paragraphs of 5.2, since those are=20 >>> about how to get >>> the name out of the option. The rest isn't DHCPv4 or=20 >> DHCPv6 specific and >>> should be in its own subsection. >>>=20 >>> 3) Re "It is RECOMMENDED to associate a validity lifetime=20 >> with any address >>> resulting from resolving the Name". The text should be=20 >> more specific about >>> what the validity lifetime should be. If the name is=20 >> resolved in DNS, I'd >>> say the validity lifetime should be the TTL of the DNS record. >>>=20 >>> 4) Re "When an >>> application issues a PCP request to a PCP Server, the=20 >> source address >>> of the request MUST be among those assigned on the=20 >> interface to which >>> the destination PCP Server is bound. >>>=20 >>> This doesn't belong in a DHCP-specific document, it's out=20 >> of scope. That's >>> the job of the pcp-base spec. >>>=20 >>> 5) Same as point 4, but for all of section 6. In my view it=20 >> belongs either in >>> pcp-base or perhaps more likely in a separate spec that's=20 >> not DHCP specific. >>> E.g., if I manually configure one or more names, the same=20 >> behavior=20 >>> should apply. >>>=20 >>> 6) Section 5.2 says: >>> "The DHCPv4 client MUST verify that the >>> option length does not exceed 255 octets [RFC1035])." >>>=20 >>> What does this mean? The length field is only 1 byte so=20 >> cannot contain >>> a value larger than 255 anyway. So what exactly is a=20 >> client supposed to >>> "verify" here? >>>=20 >>> -Dave >>>=20 >>>> -----Original Message----- >>>> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf=20 >>>> Of Dave Thaler >>>> Sent: Wednesday, July 18, 2012 2:21 PM >>>> To: pcp@ietf.org >>>> Cc: dhc@ietf.org >>>> Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 >>>>=20 >>>> As discussed at last IETF, the authors believe that all issues=20 >>>> raised so far have been addressed. No new issues have been raised=20 >>>> since then, so this message begins a Working Group Last Call on >>>> draft-ietf-pcp- >>> dhcp-03. >>>>=20 >>>> This call would normally conclude in two weeks but that is during=20 >>>> IETF week, so the last call is extended to conclude at the end of=20 >>>> IETF (as of the Friday PCP meeting). >>>>=20 >>>> We also agreed in Vancouver that this last call will be=20 >> cross-posted=20 >>>> to the DHC list, hence cc'ing the DHC WG. >>>>=20 >>>> We need at least 5 reviewers. Please send comments to the list. >>>>=20 >>>> Thanks, >>>> -Dave Thaler >>>>=20 >>>> _______________________________________________ >>>> pcp mailing list >>>> pcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcp >>=20 >>=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 tomasz.mrugalski@gmail.com Mon Jul 30 07:39: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 19AB121F8807 for ; Mon, 30 Jul 2012 07:39: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAE5mHvYZPH0 for ; Mon, 30 Jul 2012 07:39:33 -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 CEC1A21F87EE for ; Mon, 30 Jul 2012 07:39:32 -0700 (PDT) Received: by eekb45 with SMTP id b45so1285792eek.31 for ; Mon, 30 Jul 2012 07:39: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 :x-enigmail-version:content-type:content-transfer-encoding; bh=be4DIDrLxCIVyn8W8iqmmaYYE2xiq+XKmj01ceb1oE4=; b=DKHyHsMAXMaw6dn2hwJ5jtCUbV3iOtrOdC5TzwJeKJmwcnvuiqHMnlnUHCyCWFqD/x vwI2ab8gp8mTXs6AhEuF+8yg05m1pnsArv9c0nCias1uMewrrLVI/p3wbxMlNRh3wEI5 MyLeJKXAI5w6F4k8wXH/od4albNOhdrxRelGVMEpoUSw+PU90XmrLRGYmT61awkH/iub Lzldlw/BYQydc37eZhsTPLy9koW9/MjrNiAa/L01xJzMgDP1FyiyWvJn0vyOXx1o24s0 E9qS5uFeTxe9rpgDoBkutTIoeHqIqLbajwDd/b1fIGlOt5MmWwc9YOw5ZPgqEzwabw0O fFdw== Received: by 10.14.211.196 with SMTP id w44mr435951eeo.19.1343659171894; Mon, 30 Jul 2012 07:39:31 -0700 (PDT) Received: from dhcp-4536.meeting.ietf.org ([2001:df8:0:64:cabc:c8ff:fedf:daff]) by mx.google.com with ESMTPS id g42sm28888988eem.14.2012.07.30.07.39.29 (version=SSLv3 cipher=OTHER); Mon, 30 Jul 2012 07:39:31 -0700 (PDT) Message-ID: <50169CA0.7090500@gmail.com> Date: Mon, 30 Jul 2012 07:39:28 -0700 From: Tomek Mrugalski 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: DHC WG X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Comments on draft-bajko-pripaddrassign-04 and draft-wu-dhc-port-set-option-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, 30 Jul 2012 14:39:34 -0000 Dear group, dear authors, Those 2 drafts are discussing similar approaches. As both are presented by the same person, I suppose there is a likelihood of merge between them. Therefore I'd like to comment on both of them in a single mail. I do not have experience with port-restricted addresses, so please forgive me if some comments are not valid. Sorry for sending those comments so shortly before the meeting. Comments common for both drafts: 1. Well known port assignment problem Here's the generic issue with both proposals. I seems generic to any A+P proposals and the whole class of fixed port protocols, so it is much wider than just "those two drafs and DHCP" problem. Let's assume a simple case of 2 hosts sharing a single IPv4 address. One of them gets 68 port. What would the other host use as source port of its DHCP transmissions? How is server/relay supposed to send back responses to that client? Here's a relevant sentence from RFC2131, section 4.1: "DHCP messages from a server to a client are sent to the 'DHCP client' port (68).". Sure, you can update this to say that a client may use any port and server is supposed to respond to client's source port. That will work for clients directly connected to server. But it will break down when relays are in use. Relay will be able to pass Discover message to the server, the server will be able to pass back the response to the relay, but then relay will not know the client's source port, because relays are stateless and they don't keep information about previously relayed messages. That problem remains to be solved. When proposing a solution, make sure you don't propose that the relay keeps the state. Relay are should remain stateless. Some form along the lines of "relay inserts RAI option that specifies original client's port number and server echoes it back" will probably do the trick. See draft-ietf-dhc-dhcpv4-over-ipv6-02 for an example of similar approach with an IPv6 address. 2. Port allocation options There are many proposals regarding port set allocation options and possibly more may appear. For that purpose, it would be better to define a single container option that contains sub-options with a particular option assignment type (continuous range, non-continus, GMA etc). That approach is used in proposed OPTION-IPv4-PRA option in draft-bajko. It would also simplify interactions. If those options were implemented as separate options, client would be supposed to request all of them and server will respond with those that are reflecting port allocation policy chosen by a network administrator. It doesn't make sense to mix different port-sets in a single deployment IMHO. This would also brings in unfortunate failure modes. What is the server supposed to do, if it is configured to support continuous port-sets, but client requests only non-continuous? I think the better solution would be for a client to simply request IPv4-PRA option, and then deal with whatever sub-options it gets back from the server. 3. Backward compatibility I like the idea of setting yiaddr to 0.0.0.0 mentioned in draft-bajko. Draft-wu does not not have this behavior. If the client does not understand received port set options, it will simply use the whole port range for a given address. Other A+P clients will suffer. 4. ARP and DHCPDECLINE Excuse my ignorance in regards of A+P solutions, but how is ARP supposed to work in that environment? Obviously DHCPDECLINE must not be used and the whole duplicate address detection system must be disable somehow. There should be a section added that discusses that. Comments for draft-wu-dhc-port-set-option: The assumption here is that the ports discussed are TCP and UDP ports, right?. That should be explicitely mentioned. Do clients must support both options or are they allowed to support only one? Section 3.1: Is allocating port 0 allowed? Section 3.2: I-D.mdt-softwire-mapping-address-and-port is now I-D.ietf-softwire-map. Section 7: Security considerations You should discuss allocation stategies somewhere and their impact on allocation. In particular, what should server when handling mix of client do and don't support port-restricted IPs. It doesn't have to be in security considerations section. Perhaps a separate section will be better. But security consideration section must mention that client failing to process received port-set will cause problems. In DHCP, client typically ingores the options that it does not understand or considers for some reason invalid and continues message processing for other options. That is not the case here. If for any reason, the client is not able to use port-set options, it must not continue as conflict with other hosts that share the address will ensue. You should discuss attacks that rely on guessing port numbers here. With the smaller port-range available, guessing becomes easier. Sniffing the DHCP communication will make that attack easier. References: Please remove reference RFC3527, it is not used. Comments for draft-bajko-pripaddrassign-04: Section 1: Introduction > using a newly defined IPv4 DHCP [RFC2131] option Depending on how you read that sentence, someone may think that DHCPv4 is now. Don't call DHCPv4 a newly defined (unless you're a geologist). A simple rewording will do the trick here. Section 3. Suboptions list mentions 3 options, yet only 2 are defined. First sentence on page 6 mentions sub-option type 4 that is not defined. In general, it would be easier to understand, if the IPv4-PRA option description contained just the "sub-options" field and all suboptions started with sub-opt code and length fields. Suboption lengths mentioned in section 3 should be moved to the appropriate subsections that describe particular sub-options. Section 3.1 Since both suboptions (1 and 2) contain IPv4 address, it makes sense to move that field to the parent IPv4-PRA option. Section 6.1 I like the trick with setting yiaddr to 0.0.0.0. It's a clever way to eliminate clients that do not support this extension. This section allows for a client to start another DHCPDISCOVER if it needs additional ports. How is it going to be renewed? Is client expected to maintain 2 separate state machines and send separate REQUEST/Renewing messages? How is it going to be released? Two separate RELEASE messages? What is client supposed to do, if server sends more than one port-set sub-options? Nitpick: How did you generate that draft? Athough its header on the first page shows valid dates, the footer on each page says: "Expires March 27, 2011" and the header shows the date as September 2010. Hope that helps, Tomek From Ted.Lemon@nominum.com Mon Jul 30 08:47: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 C9BCB21F863C for ; Mon, 30 Jul 2012 08:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.55 X-Spam-Level: X-Spam-Status: No, score=-106.55 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1WvpP8KG5pu for ; Mon, 30 Jul 2012 08:47:47 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 7A85921F8639 for ; Mon, 30 Jul 2012 08:47:45 -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 DSNKUBasnI2uffSZVzEmECDBiXixMZaUilwG@postini.com; Mon, 30 Jul 2012 08:47: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 F108B1B8301 for ; Mon, 30 Jul 2012 08:47:39 -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 E398919005D; Mon, 30 Jul 2012 08:47:39 -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, 30 Jul 2012 08:47:39 -0700 From: Ted Lemon To: Tomek Mrugalski Thread-Topic: [dhcwg] Comments on draft-bajko-pripaddrassign-04 and draft-wu-dhc-port-set-option-00 Thread-Index: AQHNbmEm0zGmCzseGkOriWCkNqFILZdCbeGA Date: Mon, 30 Jul 2012 15:47:39 +0000 Message-ID: References: <50169CA0.7090500@gmail.com> In-Reply-To: <50169CA0.7090500@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: multipart/alternative; boundary="_000_B96405CE655B4A9F9A9322CE3D9FD13Anominumcom_" MIME-Version: 1.0 Cc: DHC WG Subject: Re: [dhcwg] Comments on draft-bajko-pripaddrassign-04 and draft-wu-dhc-port-set-option-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, 30 Jul 2012 15:47:47 -0000 --_000_B96405CE655B4A9F9A9322CE3D9FD13Anominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jul 30, 2012, at 7:39 AM, Tomek Mrugalski wrote: I like the idea of setting yiaddr to 0.0.0.0 mentioned in draft-bajko. Draft-wu does not not have this behavior. If the client does not understand received port set options, it will simply use the whole port range for a given address. Other A+P clients will suffer. I think that in the case that the client doesn't support this option, the D= HCP server either has to give it an entire IP address, or not configure it = at all. I agree with your other comments=97thanks for the thorough review! --_000_B96405CE655B4A9F9A9322CE3D9FD13Anominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jul 30, 2012, at 7:39 AM, Tomek Mrugalski wrote:
I like the idea of setting yiaddr to 0.0.0.0 mentioned in draft-bajko.
Draft-wu does not not have this behavior. If the client does not
understand received port set options, it will simply use the whole port
range for a given address. Other A+P clients will suffer.

I think that in the case that the client doesn't support this option, = the DHCP server either has to give it an entire IP address, or not configur= e it at all.

I agree with your other comments=97thanks for the thorough review!

--_000_B96405CE655B4A9F9A9322CE3D9FD13Anominumcom_-- From roberta.maglione@telecomitalia.it Mon Jul 30 10:39: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 02EEA11E808E for ; Mon, 30 Jul 2012 10:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.581 X-Spam-Level: X-Spam-Status: No, score=0.581 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w16uSrJ-aEaY for ; Mon, 30 Jul 2012 10:39:19 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id C3BB011E8193 for ; Mon, 30 Jul 2012 10:39:18 -0700 (PDT) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.245.1; Mon, 30 Jul 2012 19:39:11 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Mon, 30 Jul 2012 19:39:11 +0200 From: Maglione Roberta To: dhc WG , Leaf yeh , 'Ted Lemon' Date: Mon, 30 Jul 2012 19:39:10 +0200 Thread-Topic: draft-ietf-dhc-dhcpv6-radius-opt-01 Thread-Index: Ac1uenz8FGMSnBsdRxyqCofl+okxGw== Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE519702F11C@GRFMBX704BA020.griffon.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-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, 30 Jul 2012 17:39:20 -0000 Hello, I read the draft and I have a comment: you should add DS-Lite-Tunnel-Name (145) defined in RFC 6519 in the list of= the attributes that can be carried in the OPTION_RADIUS. In addition, in my opinion, you should write some text to say that these ar= e the RADIUS attributes currently defined in IETF, but in future new attrib= utes may be defined and there may be the need to add such new attributes in= this list. Thanks Regards Roberta Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From achatz@forthnetgroup.gr Mon Jul 30 12:24: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 73CA511E808D for ; Mon, 30 Jul 2012 12:24:24 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSKX9A6YXJdq for ; Mon, 30 Jul 2012 12:24:22 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id 9467411E81B6 for ; Mon, 30 Jul 2012 12:24:20 -0700 (PDT) Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6UJOEnx003615; Mon, 30 Jul 2012 22:24:14 +0300 Received: from MX-IN-02.forthnet.gr (mx-in-02.forthnet.gr [193.92.150.185]) by mx-av-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id q6UJOEb0010190; Mon, 30 Jul 2012 22:24:14 +0300 Received: from [130.129.71.76] (dhcp-474c.meeting.ietf.org [130.129.71.76]) (authenticated bits=0) by MX-IN-02.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6UJNwqV018159; Mon, 30 Jul 2012 22:24:00 +0300 Authentication-Results: MX-IN-02.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <5016DF55.9040401@forthnetgroup.gr> Date: Mon, 30 Jul 2012 12:24:05 -0700 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Leaf yeh References: <20120730015814.6142.26392.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000301060309070508090809" Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-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, 30 Jul 2012 19:24:24 -0000 This is a multi-part message in MIME format. --------------000301060309070508090809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Just two questions after a quick reading... Is there any particular reason for including Framed-Pool instead of Framed-IPv6-Pool? What about Framed-IPv6-Prefix? Generally, what's the criteria for choosing which attributes to include? Your draft states: > The option-data of OPTION_RADIUS is one or a list of RADIUS > attributes received in the Access-Accept message from the RADIUS > server. As the same method in [RFC4014 ], only the attributes listed > in the table below may be included in the OPTION_RADIUS. RFC 4014 states: > To avoid dependencies between the address allocation and other state > information between the RADIUS server and the DHCP server, the DHCP > relay agent SHOULD include only the attributes in the table below in > an instance of the RADIUS Attributes suboption. The table, based on > the analysis inRFC 3580 [8 ], lists attributes that MAY be included: I'm trying to understand if RFC 4014 refers to DHCPv4 only and if your draft refers to DHCPv6 only, and if yes, why a DHCPv4 server should know about an IPv6 attribute and vice versa. -- Tassos On 29/7/2012 8:02 ??, Leaf yeh wrote: > Dear DHC folks, > > The draft-ietf (ver.-01) & the proposed (OPTION_RADIUS) on the agenda of IETF84 DHC session, is waiting for your review and comments. > > > Best Regards, > Leaf > > PS. (https://datatracker.ietf.org/meeting/84/agenda/dhc/ ) > > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Monday, July 30, 2012 9:58 AM > To: i-d-announce@ietf.org > Cc: dhcwg@ietf.org > Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt > > > 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 : RADIUS Option for DHCPv6 Relay Agents on Broadband Access Server > Author(s) : Leaf Y. Yeh > Mohamed Boucadair > Ted Lemon > Filename : draft-ietf-dhc-dhcpv6-radius-opt-01.txt > Pages : 9 > Date : 2012-07-29 > > Abstract: > The DHCPv6 RADIUS option provides a communication mechanism between > relay agent and the server. This mechanism can help the centralized > DHCPv6 server to select the right configuration for the client based > on the authorization information received from a separate RADIUS > server which is not located at the same place of DHCPv6 server in the > cases where the NAS acts as DHCPv6 relay agent and RADIUS client > simultaneously. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-01 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-radius-opt-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 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --------------000301060309070508090809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Just two questions after a quick reading...

Is there any particular reason for including Framed-Pool instead of Framed-IPv6-Pool?
What about Framed-IPv6-Prefix?
Generally, what's the criteria for choosing which attributes to include?

Your draft states:

   The option-data of OPTION_RADIUS is one or a list of RADIUS
   attributes received in the Access-Accept message from the RADIUS
   server.  As the same method in [RFC4014], only the attributes listed
   in the table below may be included in the OPTION_RADIUS.

RFC 4014 states:

   To avoid dependencies between the address allocation and other state
   information between the RADIUS server and the DHCP server, the DHCP
   relay agent SHOULD include only the attributes in the table below in
   an instance of the RADIUS Attributes suboption.  The table, based on
   the analysis in RFC 3580 [8], lists attributes that MAY be included:


I'm trying to understand if RFC 4014 refers to DHCPv4 only and if your draft refers to DHCPv6 only, and if yes, why a DHCPv4 server should know about an IPv6 attribute and vice versa.

--
Tassos
On 29/7/2012 8:02 μμ, Leaf yeh wrote:
Dear DHC folks,

The draft-ietf (ver.-01) & the proposed (OPTION_RADIUS) on the agenda of IETF84 DHC session, is waiting for your review and comments.


Best Regards,
Leaf

PS. (https://datatracker.ietf.org/meeting/84/agenda/dhc/ )


-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
Sent: Monday, July 30, 2012 9:58 AM
To: i-d-announce@ietf.org
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt


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           : RADIUS Option for DHCPv6 Relay Agents on Broadband Access Server
	Author(s)       : Leaf Y. Yeh
                          Mohamed Boucadair
                          Ted Lemon
	Filename        : draft-ietf-dhc-dhcpv6-radius-opt-01.txt
	Pages           : 9
	Date            : 2012-07-29

Abstract:
   The DHCPv6 RADIUS option provides a communication mechanism between
   relay agent and the server.  This mechanism can help the centralized
   DHCPv6 server to select the right configuration for the client based
   on the authorization information received from a separate RADIUS
   server which is not located at the same place of DHCPv6 server in the
   cases where the NAS acts as DHCPv6 relay agent and RADIUS client
   simultaneously.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-01

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-radius-opt-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
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

--------------000301060309070508090809-- From Ted.Lemon@nominum.com Mon Jul 30 13:14: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 473F621F8600 for ; Mon, 30 Jul 2012 13:14:07 -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.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhMlXx1Hnq+I for ; Mon, 30 Jul 2012 13:14:06 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0ED21F851E for ; Mon, 30 Jul 2012 13:14:06 -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 DSNKUBbrDW/9mnNdaFOobImVxlea+FtDsUew@postini.com; Mon, 30 Jul 2012 13:14: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 51FCF1B8300 for ; Mon, 30 Jul 2012 13:14:04 -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 427F219005D for ; Mon, 30 Jul 2012 13:14:04 -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, 30 Jul 2012 13:14:04 -0700 From: Ted Lemon To: DHC WG Thread-Topic: Need volunteers for the NomCom Thread-Index: AQHNbnHJM3GEq1l72EKj1ND+xKkiyw== Date: Mon, 30 Jul 2012 20:14:04 +0000 Message-ID: References: <20120730032233.17770.35790.idtracker@ietfa.amsl.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: multipart/alternative; boundary="_000_FE34C5DE7F4148FEB7E053A547C61371nominumcom_" MIME-Version: 1.0 Subject: [dhcwg] Need volunteers for the NomCom 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, 30 Jul 2012 20:14:07 -0000 --_000_FE34C5DE7F4148FEB7E053A547C61371nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: NomCom Chair > Subject: Need volunteers for the NomCom Date: July 29, 2012 8:22:33 PM PDT To: Working Group Chairs > We are currently looking for volunteers to serve on the 2012-2013 NomCom. As you know, the success of the NomCom process depends crucially on having a large pool of volunteers from throughout the IETF community. In particular, it is valuable for the pool of volunteers to have strong representation from all of the technical areas within the IETF. The NomCom 2012-2013 Call for Volunteers is open until this Sunday, August 5. Details can be found at: https://datatracker.ietf.org/ann/nomcom/= 49851/ Thank you for your help, - Matt Lepinski mlepinski.ietf@gmail.com nomcom-chair@ietf.org --_000_FE34C5DE7F4148FEB7E053A547C61371nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6C4A29D58E37DD4A877F4723B2E0ED9F@nominum.com> Content-Transfer-Encoding: quoted-printable
--_000_FE34C5DE7F4148FEB7E053A547C61371nominumcom_-- From leaf.y.yeh@huawei.com Mon Jul 30 20:46: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 B91A211E80E5 for ; Mon, 30 Jul 2012 20:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.376 X-Spam-Level: X-Spam-Status: No, score=-6.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqoFNelf0iIZ for ; Mon, 30 Jul 2012 20:46:12 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9608811E80E2 for ; Mon, 30 Jul 2012 20:46:12 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIM32358; Mon, 30 Jul 2012 23:46:12 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Jul 2012 20:42:59 -0700 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Jul 2012 20:43:01 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Tue, 31 Jul 2012 11:42:57 +0800 From: Leaf yeh To: Tassos Chatzithomaoglou Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt Thread-Index: AQHNbfbnuo3fiIpzMkKxliaPfKNNi5dBHikggACRkICAAOZ4kA== Date: Tue, 31 Jul 2012 03:42:56 +0000 Message-ID: References: <20120730015814.6142.26392.idtracker@ietfa.amsl.com> <5016DF55.9040401@forthnetgroup.gr> In-Reply-To: <5016DF55.9040401@forthnetgroup.gr> 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-7" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-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, 31 Jul 2012 03:46:13 -0000 Tassos - Is there any particular reason for including Framed-Pool instead o= f Framed-IPv6-Pool?=20 Good question.=20 a. Framed-IPv6-Pool is defined in section 2.6 of RFC3162 (http://tools.ietf= .org/html/rfc3162 ) , and This Attribute contains the name of an as= signed pool that SHOULD be used to assign an IPv6 prefix for the user. RFC3162 was published in 2001, at that time, we don't have DHCPv6 (RFC= 3315) published in 2003. So I guess Framed-IPv6-Pool is designed for SLAAC = (Stateless Address Autoconfiguration). But we need something for DHCPv6. b. When we look into the definition of Framed-IPv6-Pool (88), the format of= it is exactly the same as Framed-Pool (100). The content of these 2 attrib= utes are the name of pool in string. I suppose it will be fine for the usag= e whether it is IPv4 pool or IPv6 pool, or whether it is address pool name = or prefix pool name. Agree? c. When we read section 2.4 of draft-ietf-radext-ipv6-access (http://datatr= acker.ietf.org/doc/draft-ietf-radext-ipv6-access/?include_text=3D1 ), To avoid ambiguity in this scenario, use of the Delegated-IPv6-Prefix-Poo= l attribute should be restricted to authorization and accounting of prefix= pools used in DHCPv6 Prefix Delegation and the Framed-IPv6-Pool attribute = should be used for authorization and accounting of prefix pools used in SLA= AC. . So it is also not recommended to use Framed-IPv6-Pool (100) f= or DHCPv6. d. The alternative options for DHCPv6 address/ prefix pool might be : 1. Fr= amed-IPv6-Pool (88); 2. Stateful-IPv6-Address-Pool + Delegated-IPv6-Prefix-= Pool defined in draft-ietf-radext-ipv6-access. Which one do you prefer in y= our implementation or suggestion? Or would you like both of them? Tassos - What about Framed-IPv6-Prefix? Again. Framed-IPv6-Prefix(97) is design for SLAAC, not for DHCPv6. Pls. ref= er to section 2.2 of draft-ietf-radext-ipv6-access , To avoid ambigu= ity, the Framed-IPv6-Address attribute is only used for authorization and a= ccounting of DHCPv6-assigned addresses and the Framed-IPv6-Prefix and Frame= d-Interface-Id attributes are used for authorization and accounting of addr= esses assigned via SLAAC. Tassos - Generally, what's the criteria for choosing which attributes to in= clude? The original though was to design OPTION_RADIUS to convey the AAA-authorize= d pool/address/prefix for the right selection of the configuration paramete= r at DHCPv6 server, but I suppose each of the attributes, which is associa= ted with IPv6 and might be used by DHCPv6 server, could be the candidate. B= ut I guess we will not reuse the analysis in RFC3580 here, which is only de= signed for IEEE 802.1x. The scenarios mentioned in this draft are focused o= n the broadband access, including IPoE and PPPoE. Agree? Best Regards, Leaf From: Tassos Chatzithomaoglou [mailto:achatz@forthnetgroup.gr]=20 Sent: Tuesday, July 31, 2012 3:24 AM To: Leaf yeh Cc: dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt Just two questions after a quick reading... Is there any particular reason for including Framed-Pool instead of Framed-= IPv6-Pool? What about Framed-IPv6-Prefix? Generally, what's the criteria for choosing which attributes to include? Your draft states: The option-data of OPTION_RADIUS is one or a list of RADIUS attributes received in the Access-Accept message from the RADIUS server. As the same method in [RFC4014], only the attributes listed in the table below may be included in the OPTION_RADIUS. RFC 4014 states: To avoid dependencies between the address allocation and other state information between the RADIUS server and the DHCP server, the DHCP relay agent SHOULD include only the attributes in the table below in an instance of the RADIUS Attributes suboption. The table, based on the analysis in RFC 3580 [8], lists attributes that MAY be included: I'm trying to understand if RFC 4014 refers to DHCPv4 only and if your draf= t refers to DHCPv6 only, and if yes, why a DHCPv4 server should know about = an IPv6 attribute and vice versa. -- Tassos On 29/7/2012 8:02 =EC=EC, Leaf yeh wrote: Dear DHC folks, The draft-ietf (ver.-01) & the proposed (OPTION_RADIUS) on the agenda of IE= TF84 DHC session, is waiting for your review and comments. Best Regards, Leaf PS. (https://datatracker.ietf.org/meeting/84/agenda/dhc/ ) -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Monday, July 30, 2012 9:58 AM To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.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 : RADIUS Option for DHCPv6 Relay Agents on Broadband Acces= s Server Author(s) : Leaf Y. Yeh Mohamed Boucadair Ted Lemon Filename : draft-ietf-dhc-dhcpv6-radius-opt-01.txt Pages : 9 Date : 2012-07-29 Abstract: The DHCPv6 RADIUS option provides a communication mechanism between relay agent and the server. This mechanism can help the centralized DHCPv6 server to select the right configuration for the client based on the authorization information received from a separate RADIUS server which is not located at the same place of DHCPv6 server in the cases where the NAS acts as DHCPv6 relay agent and RADIUS client simultaneously. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From leaf.y.yeh@huawei.com Tue Jul 31 00:29: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 8059621F854D for ; Tue, 31 Jul 2012 00:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmSEZYuU7AyY for ; Tue, 31 Jul 2012 00:29:54 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3088E21F852C for ; Tue, 31 Jul 2012 00:29:54 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIM46150; Tue, 31 Jul 2012 03:29:53 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 31 Jul 2012 00:26:52 -0700 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 31 Jul 2012 00:26:51 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 31 Jul 2012 15:26:48 +0800 From: Leaf yeh To: Maglione Roberta Thread-Topic: draft-ietf-dhc-dhcpv6-radius-opt-01 Thread-Index: Ac1uenz8FGMSnBsdRxyqCofl+okxGwAVGMKg Date: Tue, 31 Jul 2012 07:26:48 +0000 Message-ID: References: <282BBE8A501E1F4DA9C775F964BB21FE519702F11C@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE519702F11C@GRFMBX704BA020.griffon.local> 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: dhc WG , 'Ted Lemon' Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-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: Tue, 31 Jul 2012 07:29:55 -0000 Roberta - you should add DS-Lite-Tunnel-Name (145) defined in RFC 6519 in t= he list of the attributes that can be carried in the OPTION_RADIUS. I am fine with to add DS-Lite-Tunnel-Name (144) to join the list, which hel= ps DHCPv6 server to get the stateless parameter of AFTR FQDN in OPTION_AFTR= _NAME (64) for CE to support DS-Lite.=20 Roberta - In addition, in my opinion, you should write some text to say tha= t these are the RADIUS attributes currently defined in IETF, but in future = new attributes may be defined and there may be the need to add such new att= ributes in this list. The draft (OPTION_RADIUS) has some text in section 4. Note: The abov= e table might have more attributes in the future. I guess it might = meet your concern mentioned above. I can also expect more attribute related= to IPv6 transition tech. including MAP, and etc., which are under definiti= on, might join the list in the future. Best Regards, Leaf -----Original Message----- From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]=20 Sent: Tuesday, July 31, 2012 1:39 AM To: dhc WG; Leaf yeh; 'Ted Lemon' Subject: draft-ietf-dhc-dhcpv6-radius-opt-01 Hello, I read the draft and I have a comment: you should add DS-Lite-Tunnel-Name (145) defined in RFC 6519 in the list of= the attributes that can be carried in the OPTION_RADIUS. In addition, in my opinion, you should write some text to say that these ar= e the RADIUS attributes currently defined in IETF, but in future new attrib= utes may be defined and there may be the need to add such new attributes in= this list. Thanks Regards Roberta Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From achatz@forthnetgroup.gr Tue Jul 31 10:17: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 CF68421F8742 for ; Tue, 31 Jul 2012 10:17:26 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e49PkBgsGwyQ for ; Tue, 31 Jul 2012 10:17:25 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id 3E90E21F871D for ; Tue, 31 Jul 2012 10:17:25 -0700 (PDT) Received: from mx-av-06.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6VHHJ8H028181; Tue, 31 Jul 2012 20:17:19 +0300 Received: from MX-IN-11.forthnet.gr (mx-in-11.forthnet.gr [193.92.150.31]) by mx-av-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6VHHJwm031476; Tue, 31 Jul 2012 20:17:19 +0300 Received: from [130.129.20.221] (dhcp-14dd.meeting.ietf.org [130.129.20.221]) (authenticated bits=0) by MX-IN-11.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6VHH9sa006186; Tue, 31 Jul 2012 20:17:12 +0300 Authentication-Results: MX-IN-11.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <5018131B.4090605@forthnetgroup.gr> Date: Tue, 31 Jul 2012 10:17:15 -0700 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Leaf yeh References: <20120730015814.6142.26392.idtracker@ietfa.amsl.com> <5016DF55.9040401@forthnetgroup.gr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 8bit Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-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, 31 Jul 2012 17:17:27 -0000 Thank you for the detailed answer Leaf, I was under the impression that this draft covered also attributes that could be passed to the DHCPv6 server as a hint. So it wasn't necessarily a strict path for the DHCPv6 server to use these attributes to the replies it sends back. Maybe you could separate the attributes, to the ones clearly defined for dhcp usage (replies) and to others which are defined for passing to the dhcp server as a guidance or hint or whatever. Regarding the pool options, i would give light a preference to Stateful-IPv6-Address-Pool + Delegated-IPv6-Prefix-Pool. Tassos On 30/7/2012 8:42 μμ, Leaf yeh wrote: > Tassos - Is there any particular reason for including Framed-Pool instead of Framed-IPv6-Pool? > > Good question. > > a. Framed-IPv6-Pool is defined in section 2.6 of RFC3162 (http://tools.ietf.org/html/rfc3162 ) , and This Attribute contains the name of an assigned pool that SHOULD be used to assign an IPv6 prefix for the user. RFC3162 was published in 2001, at that time, we don't have DHCPv6 (RFC3315) published in 2003. So I guess Framed-IPv6-Pool is designed for SLAAC (Stateless Address Autoconfiguration). But we need something for DHCPv6. > > b. When we look into the definition of Framed-IPv6-Pool (88), the format of it is exactly the same as Framed-Pool (100). The content of these 2 attributes are the name of pool in string. I suppose it will be fine for the usage whether it is IPv4 pool or IPv6 pool, or whether it is address pool name or prefix pool name. Agree? > > c. When we read section 2.4 of draft-ietf-radext-ipv6-access (http://datatracker.ietf.org/doc/draft-ietf-radext-ipv6-access/?include_text=1 ), To avoid ambiguity in this scenario, use of the Delegated-IPv6-Prefix-Pool attribute should be restricted to authorization and accounting of prefix pools used in DHCPv6 Prefix Delegation and the Framed-IPv6-Pool attribute should be used for authorization and accounting of prefix pools used in SLAAC. . So it is also not recommended to use Framed-IPv6-Pool (100) for DHCPv6. > > d. The alternative options for DHCPv6 address/ prefix pool might be : 1. Framed-IPv6-Pool (88); 2. Stateful-IPv6-Address-Pool + Delegated-IPv6-Prefix-Pool defined in draft-ietf-radext-ipv6-access. Which one do you prefer in your implementation or suggestion? Or would you like both of them? > > Tassos - What about Framed-IPv6-Prefix? > > Again. Framed-IPv6-Prefix(97) is design for SLAAC, not for DHCPv6. Pls. refer to section 2.2 of draft-ietf-radext-ipv6-access , To avoid ambiguity, the Framed-IPv6-Address attribute is only used for authorization and accounting of DHCPv6-assigned addresses and the Framed-IPv6-Prefix and Framed-Interface-Id attributes are used for authorization and accounting of addresses assigned via SLAAC. > > Tassos - Generally, what's the criteria for choosing which attributes to include? > > The original though was to design OPTION_RADIUS to convey the AAA-authorized pool/address/prefix for the right selection of the configuration parameter at DHCPv6 server, but I suppose each of the attributes, which is associated with IPv6 and might be used by DHCPv6 server, could be the candidate. But I guess we will not reuse the analysis in RFC3580 here, which is only designed for IEEE 802.1x. The scenarios mentioned in this draft are focused on the broadband access, including IPoE and PPPoE. Agree? > > > Best Regards, > Leaf > > > > From: Tassos Chatzithomaoglou [mailto:achatz@forthnetgroup.gr] > Sent: Tuesday, July 31, 2012 3:24 AM > To: Leaf yeh > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt > > Just two questions after a quick reading... > > Is there any particular reason for including Framed-Pool instead of Framed-IPv6-Pool? > What about Framed-IPv6-Prefix? > Generally, what's the criteria for choosing which attributes to include? > > Your draft states: > > > The option-data of OPTION_RADIUS is one or a list of RADIUS > attributes received in the Access-Accept message from the RADIUS > server. As the same method in [RFC4014], only the attributes listed > in the table below may be included in the OPTION_RADIUS. > > RFC 4014 states: > > > To avoid dependencies between the address allocation and other state > information between the RADIUS server and the DHCP server, the DHCP > relay agent SHOULD include only the attributes in the table below in > an instance of the RADIUS Attributes suboption. The table, based on > the analysis in RFC 3580 [8], lists attributes that MAY be included: > > > I'm trying to understand if RFC 4014 refers to DHCPv4 only and if your draft refers to DHCPv6 only, and if yes, why a DHCPv4 server should know about an IPv6 attribute and vice versa. > > > -- > Tassos > On 29/7/2012 8:02 μμ, Leaf yeh wrote: > Dear DHC folks, > > The draft-ietf (ver.-01) & the proposed (OPTION_RADIUS) on the agenda of IETF84 DHC session, is waiting for your review and comments. > > > Best Regards, > Leaf > > PS. (https://datatracker.ietf.org/meeting/84/agenda/dhc/ ) > > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Monday, July 30, 2012 9:58 AM > To: i-d-announce@ietf.org > Cc: dhcwg@ietf.org > Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt > > > 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 : RADIUS Option for DHCPv6 Relay Agents on Broadband Access Server > Author(s) : Leaf Y. Yeh > Mohamed Boucadair > Ted Lemon > Filename : draft-ietf-dhc-dhcpv6-radius-opt-01.txt > Pages : 9 > Date : 2012-07-29 > > Abstract: > The DHCPv6 RADIUS option provides a communication mechanism between > relay agent and the server. This mechanism can help the centralized > DHCPv6 server to select the right configuration for the client based > on the authorization information received from a separate RADIUS > server which is not located at the same place of DHCPv6 server in the > cases where the NAS acts as DHCPv6 relay agent and RADIUS client > simultaneously. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-01 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-radius-opt-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 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > > > From leaf.y.yeh@huawei.com Tue Jul 31 19:42: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 3AB9711E8097 for ; Tue, 31 Jul 2012 19:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.391 X-Spam-Level: X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWqT7Wp2qfml for ; Tue, 31 Jul 2012 19:42:56 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2A10D11E8072 for ; Tue, 31 Jul 2012 19:42:56 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIG25390; Tue, 31 Jul 2012 22:42:55 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 31 Jul 2012 19:41:06 -0700 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 31 Jul 2012 19:41:10 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Wed, 1 Aug 2012 10:41:05 +0800 From: Leaf yeh To: Tassos Chatzithomaoglou , Maglione Roberta Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt Thread-Index: AQHNbfbnuo3fiIpzMkKxliaPfKNNi5dBHikggACRkICAAOZ4kIAAiG2AgAEgNbA= Date: Wed, 1 Aug 2012 02:41:04 +0000 Message-ID: References: <20120730015814.6142.26392.idtracker@ietfa.amsl.com> <5016DF55.9040401@forthnetgroup.gr> <5018131B.4090605@forthnetgroup.gr> In-Reply-To: <5018131B.4090605@forthnetgroup.gr> 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-7" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-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, 01 Aug 2012 02:42:57 -0000 Tassos - Maybe you could separate the attributes, to the ones clearly defin= ed for=20 dhcp usage (replies) and to others which are defined for passing to the=20 dhcp server as a guidance or hint or whatever. I prefer OPTION_RADIUS only carried those attributes that sounds useful to = DHCPv6 server, whether it is hint or not. Tassos - Regarding the pool options, i would give light a preference to=20 Stateful-IPv6-Address-Pool + Delegated-IPv6-Prefix-Pool. I could delete Framed-Pool (88) from the list if you all believe it is only= for IPv4 address pool.=20 Maglione, your opinion? Best Regards, Leaf -----Original Message----- From: Tassos Chatzithomaoglou [mailto:achatz@forthnetgroup.gr]=20 Sent: Wednesday, August 01, 2012 1:17 AM To: Leaf yeh Cc: dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt Thank you for the detailed answer Leaf, I was under the impression that this draft covered also attributes that=20 could be passed to the DHCPv6 server as a hint. So it wasn't necessarily a strict path for the DHCPv6 server to use=20 these attributes to the replies it sends back. Maybe you could separate the attributes, to the ones clearly defined for=20 dhcp usage (replies) and to others which are defined for passing to the=20 dhcp server as a guidance or hint or whatever. Regarding the pool options, i would give light a preference to=20 Stateful-IPv6-Address-Pool + Delegated-IPv6-Prefix-Pool. Tassos On 30/7/2012 8:42 =EC=EC, Leaf yeh wrote: > Tassos - Is there any particular reason for including Framed-Pool instead= of Framed-IPv6-Pool? > > Good question. > > a. Framed-IPv6-Pool is defined in section 2.6 of RFC3162 (http://tools.ie= tf.org/html/rfc3162 ) , and This Attribute contains the name of an = assigned pool that SHOULD be used to assign an IPv6 prefix for the user. RFC3162 was published in 2001, at that time, we don't have DHCPv6 (R= FC3315) published in 2003. So I guess Framed-IPv6-Pool is designed for SLAA= C (Stateless Address Autoconfiguration). But we need something for DHCPv6. > > b. When we look into the definition of Framed-Pool (88), the format of it= is exactly the same as Framed-IPv6-Pool (100). The content of these 2 attr= ibutes are the name of pool in string. I suppose it will be fine for the us= age whether it is IPv4 pool or IPv6 pool, or whether it is address pool nam= e or prefix pool name. Agree? > > c. When we read section 2.4 of draft-ietf-radext-ipv6-access (http://data= tracker.ietf.org/doc/draft-ietf-radext-ipv6-access/?include_text=3D1 ), To avoid ambiguity in this scenario, use of the Delegated-IPv6-Prefix-P= ool attribute should be restricted to authorization and accounting of pref= ix pools used in DHCPv6 Prefix Delegation and the Framed-IPv6-Pool attribut= e should be used for authorization and accounting of prefix pools used in S= LAAC. . So it is also not recommended to use Framed-IPv6-Pool (100)= for DHCPv6. > > d. The alternative options for DHCPv6 address/ prefix pool might be : 1. = Framed-Pool (88); 2. Stateful-IPv6-Address-Pool + Delegated-IPv6-Prefix-Poo= l defined in draft-ietf-radext-ipv6-access. Which one do you prefer in your= implementation or suggestion? Or would you like both of them? > > Tassos - What about Framed-IPv6-Prefix? > > Again. Framed-IPv6-Prefix(97) is design for SLAAC, not for DHCPv6. Pls. r= efer to section 2.2 of draft-ietf-radext-ipv6-access , To avoid ambi= guity, the Framed-IPv6-Address attribute is only used for authorization and= accounting of DHCPv6-assigned addresses and the Framed-IPv6-Prefix and Fra= med-Interface-Id attributes are used for authorization and accounting of ad= dresses assigned via SLAAC. > > Tassos - Generally, what's the criteria for choosing which attributes to = include? > > The original though was to design OPTION_RADIUS to convey the AAA-authori= zed pool/address/prefix for the right selection of the configuration parame= ter at DHCPv6 server, but I suppose each of the attributes, which is assoc= iated with IPv6 and might be used by DHCPv6 server, could be the candidate.= But I guess we will not reuse the analysis in RFC3580 here, which is only = designed for IEEE 802.1x. The scenarios mentioned in this draft are focused= on the broadband access, including IPoE and PPPoE. Agree? > > > Best Regards, > Leaf > > > > From: Tassos Chatzithomaoglou [mailto:achatz@forthnetgroup.gr] > Sent: Tuesday, July 31, 2012 3:24 AM > To: Leaf yeh > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt > > Just two questions after a quick reading... > > Is there any particular reason for including Framed-Pool instead of Frame= d-IPv6-Pool? > What about Framed-IPv6-Prefix? > Generally, what's the criteria for choosing which attributes to include? > > Your draft states: > > > The option-data of OPTION_RADIUS is one or a list of RADIUS > attributes received in the Access-Accept message from the RADIUS > server. As the same method in [RFC4014], only the attributes listed > in the table below may be included in the OPTION_RADIUS. > > RFC 4014 states: > > > To avoid dependencies between the address allocation and other state > information between the RADIUS server and the DHCP server, the DHCP > relay agent SHOULD include only the attributes in the table below in > an instance of the RADIUS Attributes suboption. The table, based on > the analysis in RFC 3580 [8], lists attributes that MAY be included: > > > I'm trying to understand if RFC 4014 refers to DHCPv4 only and if your dr= aft refers to DHCPv6 only, and if yes, why a DHCPv4 server should know abou= t an IPv6 attribute and vice versa. > > > -- > Tassos > On 29/7/2012 8:02 =EC=EC, Leaf yeh wrote: > Dear DHC folks, > > The draft-ietf (ver.-01) & the proposed (OPTION_RADIUS) on the agenda of = IETF84 DHC session, is waiting for your review and comments. > > > Best Regards, > Leaf > > PS. (https://datatracker.ietf.org/meeting/84/agenda/dhc/ ) > > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of= internet-drafts@ietf.org > Sent: Monday, July 30, 2012 9:58 AM > To: i-d-announce@ietf.org > Cc: dhcwg@ietf.org > Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt > > > 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 Gro= up of the IETF. > > Title : RADIUS Option for DHCPv6 Relay Agents on Broadband Acc= ess Server > Author(s) : Leaf Y. Yeh > Mohamed Boucadair > Ted Lemon > Filename : draft-ietf-dhc-dhcpv6-radius-opt-01.txt > Pages : 9 > Date : 2012-07-29 > > Abstract: > The DHCPv6 RADIUS option provides a communication mechanism between > relay agent and the server. This mechanism can help the centralized > DHCPv6 server to select the right configuration for the client based > on the authorization information received from a separate RADIUS > server which is not located at the same place of DHCPv6 server in the > cases where the NAS acts as DHCPv6 relay agent and RADIUS client > simultaneously. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-01 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-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 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > > > From roberta.maglione@telecomitalia.it Tue Jul 31 23:21: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 CFE6A21F86D4; Tue, 31 Jul 2012 23:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.425 X-Spam-Level: * X-Spam-Status: No, score=1.425 tagged_above=-999 required=5 tests=[AWL=-1.059, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fH7iZ2vytFP; Tue, 31 Jul 2012 23:21:39 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 2C78321F86CB; Tue, 31 Jul 2012 23:21:38 -0700 (PDT) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.245.1; Wed, 1 Aug 2012 08:21:32 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Wed, 1 Aug 2012 08:21:32 +0200 From: Maglione Roberta To: 'Leaf yeh' , Tassos Chatzithomaoglou Date: Wed, 1 Aug 2012 08:21:31 +0200 Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt Thread-Index: AQHNbfbnuo3fiIpzMkKxliaPfKNNi5dBHikggACRkICAAOZ4kIAAiG2AgAEgNbCAAECDsA== Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE519702F127@GRFMBX704BA020.griffon.local> References: <20120730015814.6142.26392.idtracker@ietfa.amsl.com> <5016DF55.9040401@forthnetgroup.gr> <5018131B.4090605@forthnetgroup.gr> In-Reply-To: Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "radext@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-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, 01 Aug 2012 06:21:40 -0000 SGVsbG8sDQoNCj4gSSBjb3VsZCBkZWxldGUgRnJhbWVkLVBvb2wgKDg4KSBmcm9tIHRoZSBsaXN0 IGlmIHlvdSBhbGwgYmVsaWV2ZSBpdCBpcw0KPiBvbmx5IGZvciBJUHY0IGFkZHJlc3MgcG9vbC4N Cg0KPiBNYWdsaW9uZSwgeW91ciBvcGluaW9uPw0KDQpJbiBteSBvcGluaW9uIHlvdSBzaG91bGQg cmVtb3ZlIEZyYW1lZC1Qb29sIGJlY2F1c2UgdGhpcyBhdHRyaWJ1dGUgaXMgdXNlZCBmb3IgSVB2 NCBvbmx5IHBvb2wsIHNvIGl0IGRvZXMgbm90IGFwcGx5IGhlcmUuDQoNCkknbSBjYy1pbmcgYWxz byByYWRleHQgbWFpbGluZyBsaXN0Lg0KDQpCZXN0IFJlZ2FyZHMsDQpSb2JlcnRhDQoNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExlYWYgeWVoIFttYWlsdG86bGVhZi55Lnll aEBodWF3ZWkuY29tXQ0KU2VudDogbWVyY29sZWSorCAxIGFnb3N0byAyMDEyIDQuNDENClRvOiBU YXNzb3MgQ2hhdHppdGhvbWFvZ2xvdTsgTWFnbGlvbmUgUm9iZXJ0YQ0KQ2M6IGRoY3dnQGlldGYu b3JnDQpTdWJqZWN0OiBSRTogW2RoY3dnXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRoYy1kaGNw djYtcmFkaXVzLW9wdC0wMS50eHQNCg0KVGFzc29zIC0gTWF5YmUgeW91IGNvdWxkIHNlcGFyYXRl IHRoZSBhdHRyaWJ1dGVzLCB0byB0aGUgb25lcyBjbGVhcmx5IGRlZmluZWQgZm9yDQpkaGNwIHVz YWdlIChyZXBsaWVzKSBhbmQgdG8gb3RoZXJzIHdoaWNoIGFyZSBkZWZpbmVkIGZvciBwYXNzaW5n IHRvIHRoZQ0KZGhjcCBzZXJ2ZXIgYXMgYSBndWlkYW5jZSBvciBoaW50IG9yIHdoYXRldmVyLg0K DQpJIHByZWZlciBPUFRJT05fUkFESVVTIG9ubHkgY2FycmllZCB0aG9zZSBhdHRyaWJ1dGVzIHRo YXQgc291bmRzIHVzZWZ1bCB0byBESENQdjYgc2VydmVyLCB3aGV0aGVyIGl0IGlzIGhpbnQgb3Ig bm90Lg0KDQoNClRhc3NvcyAtIFJlZ2FyZGluZyB0aGUgcG9vbCBvcHRpb25zLCBpIHdvdWxkIGdp dmUgbGlnaHQgYSBwcmVmZXJlbmNlIHRvDQpTdGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbCArIERl bGVnYXRlZC1JUHY2LVByZWZpeC1Qb29sLg0KDQpJIGNvdWxkIGRlbGV0ZSBGcmFtZWQtUG9vbCAo ODgpIGZyb20gdGhlIGxpc3QgaWYgeW91IGFsbCBiZWxpZXZlIGl0IGlzIG9ubHkgZm9yIElQdjQg YWRkcmVzcyBwb29sLg0KDQpNYWdsaW9uZSwgeW91ciBvcGluaW9uPw0KDQoNCkJlc3QgUmVnYXJk cywNCkxlYWYNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVGFzc29zIENo YXR6aXRob21hb2dsb3UgW21haWx0bzphY2hhdHpAZm9ydGhuZXRncm91cC5ncl0NClNlbnQ6IFdl ZG5lc2RheSwgQXVndXN0IDAxLCAyMDEyIDE6MTcgQU0NClRvOiBMZWFmIHllaA0KQ2M6IGRoY3dn QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2RoY3dnXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRo Yy1kaGNwdjYtcmFkaXVzLW9wdC0wMS50eHQNCg0KVGhhbmsgeW91IGZvciB0aGUgZGV0YWlsZWQg YW5zd2VyIExlYWYsDQoNCkkgd2FzIHVuZGVyIHRoZSBpbXByZXNzaW9uIHRoYXQgdGhpcyBkcmFm dCBjb3ZlcmVkIGFsc28gYXR0cmlidXRlcyB0aGF0DQpjb3VsZCBiZSBwYXNzZWQgdG8gdGhlIERI Q1B2NiBzZXJ2ZXIgYXMgYSBoaW50Lg0KU28gaXQgd2Fzbid0IG5lY2Vzc2FyaWx5IGEgc3RyaWN0 IHBhdGggZm9yIHRoZSBESENQdjYgc2VydmVyIHRvIHVzZQ0KdGhlc2UgYXR0cmlidXRlcyB0byB0 aGUgcmVwbGllcyBpdCBzZW5kcyBiYWNrLg0KDQpNYXliZSB5b3UgY291bGQgc2VwYXJhdGUgdGhl IGF0dHJpYnV0ZXMsIHRvIHRoZSBvbmVzIGNsZWFybHkgZGVmaW5lZCBmb3INCmRoY3AgdXNhZ2Ug KHJlcGxpZXMpIGFuZCB0byBvdGhlcnMgd2hpY2ggYXJlIGRlZmluZWQgZm9yIHBhc3NpbmcgdG8g dGhlDQpkaGNwIHNlcnZlciBhcyBhIGd1aWRhbmNlIG9yIGhpbnQgb3Igd2hhdGV2ZXIuDQoNClJl Z2FyZGluZyB0aGUgcG9vbCBvcHRpb25zLCBpIHdvdWxkIGdpdmUgbGlnaHQgYSBwcmVmZXJlbmNl IHRvDQpTdGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbCArIERlbGVnYXRlZC1JUHY2LVByZWZpeC1Q b29sLg0KDQpUYXNzb3MNCg0KT24gMzAvNy8yMDEyIDg6NDIgpsymzCwgTGVhZiB5ZWggd3JvdGU6 DQo+IFRhc3NvcyAtIElzIHRoZXJlIGFueSBwYXJ0aWN1bGFyIHJlYXNvbiBmb3IgaW5jbHVkaW5n IEZyYW1lZC1Qb29sIGluc3RlYWQgb2YgRnJhbWVkLUlQdjYtUG9vbD8NCj4NCj4gR29vZCBxdWVz dGlvbi4NCj4NCj4gYS4gRnJhbWVkLUlQdjYtUG9vbCBpcyBkZWZpbmVkIGluIHNlY3Rpb24gMi42 IG9mIFJGQzMxNjIgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMxNjIgKSAsIGFuZCAg PHF1b3RlPlRoaXMgQXR0cmlidXRlIGNvbnRhaW5zIHRoZSBuYW1lIG9mIGFuIGFzc2lnbmVkIHBv b2wgdGhhdCBTSE9VTEQgYmUgdXNlZCB0byBhc3NpZ24gYW4gSVB2NiBwcmVmaXggZm9yIHRoZSB1 c2VyLjwvcXVvdGU+ICBSRkMzMTYyIHdhcyBwdWJsaXNoZWQgaW4gMjAwMSwgYXQgdGhhdCB0aW1l LCB3ZSBkb24ndCBoYXZlIERIQ1B2NiAoUkZDMzMxNSkgcHVibGlzaGVkIGluIDIwMDMuIFNvIEkg Z3Vlc3MgRnJhbWVkLUlQdjYtUG9vbCBpcyBkZXNpZ25lZCBmb3IgU0xBQUMgKFN0YXRlbGVzcyBB ZGRyZXNzIEF1dG9jb25maWd1cmF0aW9uKS4gQnV0IHdlIG5lZWQgc29tZXRoaW5nIGZvciBESENQ djYuDQo+DQo+IGIuIFdoZW4gd2UgbG9vayBpbnRvIHRoZSBkZWZpbml0aW9uIG9mIEZyYW1lZC1Q b29sICg4OCksIHRoZSBmb3JtYXQgb2YgaXQgaXMgZXhhY3RseSB0aGUgc2FtZSBhcyBGcmFtZWQt SVB2Ni1Qb29sICgxMDApLiBUaGUgY29udGVudCBvZiB0aGVzZSAyIGF0dHJpYnV0ZXMgYXJlIHRo ZSBuYW1lIG9mIHBvb2wgaW4gc3RyaW5nLiBJIHN1cHBvc2UgaXQgd2lsbCBiZSBmaW5lIGZvciB0 aGUgdXNhZ2Ugd2hldGhlciBpdCBpcyBJUHY0IHBvb2wgb3IgSVB2NiBwb29sLCBvciB3aGV0aGVy IGl0IGlzIGFkZHJlc3MgcG9vbCBuYW1lIG9yIHByZWZpeCBwb29sIG5hbWUuIEFncmVlPw0KPg0K PiBjLiBXaGVuIHdlIHJlYWQgc2VjdGlvbiAyLjQgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1h Y2Nlc3MgKGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1yYWRleHQt aXB2Ni1hY2Nlc3MvP2luY2x1ZGVfdGV4dD0xICksIDxxdW90ZT5UbyBhdm9pZCBhbWJpZ3VpdHkg aW4gdGhpcyBzY2VuYXJpbywgdXNlIG9mIHRoZSBEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCBh dHRyaWJ1dGUgc2hvdWxkIGJlIHJlc3RyaWN0ZWQgdG8gYXV0aG9yaXphdGlvbiBhbmQgIGFjY291 bnRpbmcgb2YgcHJlZml4IHBvb2xzIHVzZWQgaW4gREhDUHY2IFByZWZpeCBEZWxlZ2F0aW9uIGFu ZCB0aGUgRnJhbWVkLUlQdjYtUG9vbCBhdHRyaWJ1dGUgc2hvdWxkIGJlIHVzZWQgZm9yIGF1dGhv cml6YXRpb24gYW5kIGFjY291bnRpbmcgb2YgcHJlZml4IHBvb2xzIHVzZWQgaW4gU0xBQUMuIDwv cXVvdGU+LiBTbyBpdCBpcyBhbHNvIG5vdCByZWNvbW1lbmRlZCB0byB1c2UgRnJhbWVkLUlQdjYt UG9vbCAoMTAwKSBmb3IgREhDUHY2Lg0KPg0KPiBkLiBUaGUgYWx0ZXJuYXRpdmUgb3B0aW9ucyBm b3IgREhDUHY2IGFkZHJlc3MvIHByZWZpeCBwb29sIG1pZ2h0IGJlIDogMS4gRnJhbWVkLVBvb2wg KDg4KTsgMi4gU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wgKyBEZWxlZ2F0ZWQtSVB2Ni1QcmVm aXgtUG9vbCBkZWZpbmVkIGluIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzLiBXaGljaCBv bmUgZG8geW91IHByZWZlciBpbiB5b3VyIGltcGxlbWVudGF0aW9uIG9yIHN1Z2dlc3Rpb24/IE9y IHdvdWxkIHlvdSBsaWtlIGJvdGggb2YgdGhlbT8NCj4NCj4gVGFzc29zIC0gV2hhdCBhYm91dCBG cmFtZWQtSVB2Ni1QcmVmaXg/DQo+DQo+IEFnYWluLiBGcmFtZWQtSVB2Ni1QcmVmaXgoOTcpIGlz IGRlc2lnbiBmb3IgU0xBQUMsIG5vdCBmb3IgREhDUHY2LiBQbHMuIHJlZmVyIHRvIHNlY3Rpb24g Mi4yIG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzICwgPHF1b3RlPlRvIGF2b2lkIGFt YmlndWl0eSwgdGhlIEZyYW1lZC1JUHY2LUFkZHJlc3MgYXR0cmlidXRlIGlzIG9ubHkgdXNlZCBm b3IgYXV0aG9yaXphdGlvbiBhbmQgYWNjb3VudGluZyBvZiBESENQdjYtYXNzaWduZWQgYWRkcmVz c2VzIGFuZCB0aGUgRnJhbWVkLUlQdjYtUHJlZml4IGFuZCBGcmFtZWQtSW50ZXJmYWNlLUlkIGF0 dHJpYnV0ZXMgYXJlIHVzZWQgZm9yIGF1dGhvcml6YXRpb24gYW5kIGFjY291bnRpbmcgb2YgYWRk cmVzc2VzIGFzc2lnbmVkIHZpYSBTTEFBQy4gPC9xdW90ZT4NCj4NCj4gVGFzc29zIC0gR2VuZXJh bGx5LCB3aGF0J3MgdGhlIGNyaXRlcmlhIGZvciBjaG9vc2luZyB3aGljaCBhdHRyaWJ1dGVzIHRv IGluY2x1ZGU/DQo+DQo+IFRoZSBvcmlnaW5hbCB0aG91Z2ggd2FzIHRvIGRlc2lnbiBPUFRJT05f UkFESVVTIHRvIGNvbnZleSB0aGUgQUFBLWF1dGhvcml6ZWQgcG9vbC9hZGRyZXNzL3ByZWZpeCBm b3IgdGhlIHJpZ2h0IHNlbGVjdGlvbiBvZiB0aGUgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXIgYXQg REhDUHY2IHNlcnZlciwgYnV0ICBJIHN1cHBvc2UgZWFjaCBvZiB0aGUgYXR0cmlidXRlcywgd2hp Y2ggaXMgYXNzb2NpYXRlZCB3aXRoIElQdjYgYW5kIG1pZ2h0IGJlIHVzZWQgYnkgREhDUHY2IHNl cnZlciwgY291bGQgYmUgdGhlIGNhbmRpZGF0ZS4gQnV0IEkgZ3Vlc3Mgd2Ugd2lsbCBub3QgcmV1 c2UgdGhlIGFuYWx5c2lzIGluIFJGQzM1ODAgaGVyZSwgd2hpY2ggaXMgb25seSBkZXNpZ25lZCBm b3IgSUVFRSA4MDIuMXguIFRoZSBzY2VuYXJpb3MgbWVudGlvbmVkIGluIHRoaXMgZHJhZnQgYXJl IGZvY3VzZWQgb24gdGhlIGJyb2FkYmFuZCBhY2Nlc3MsIGluY2x1ZGluZyBJUG9FIGFuZCBQUFBv RS4gQWdyZWU/DQo+DQo+DQo+IEJlc3QgUmVnYXJkcywNCj4gTGVhZg0KPg0KPg0KPg0KPiBGcm9t OiBUYXNzb3MgQ2hhdHppdGhvbWFvZ2xvdSBbbWFpbHRvOmFjaGF0ekBmb3J0aG5ldGdyb3VwLmdy XQ0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDMxLCAyMDEyIDM6MjQgQU0NCj4gVG86IExlYWYgeWVo DQo+IENjOiBkaGN3Z0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2RoY3dnXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcmFkaXVzLW9wdC0wMS50eHQNCj4NCj4gSnVzdCB0d28g cXVlc3Rpb25zIGFmdGVyIGEgcXVpY2sgcmVhZGluZy4uLg0KPg0KPiBJcyB0aGVyZSBhbnkgcGFy dGljdWxhciByZWFzb24gZm9yIGluY2x1ZGluZyBGcmFtZWQtUG9vbCBpbnN0ZWFkIG9mIEZyYW1l ZC1JUHY2LVBvb2w/DQo+IFdoYXQgYWJvdXQgRnJhbWVkLUlQdjYtUHJlZml4Pw0KPiBHZW5lcmFs bHksIHdoYXQncyB0aGUgY3JpdGVyaWEgZm9yIGNob29zaW5nIHdoaWNoIGF0dHJpYnV0ZXMgdG8g aW5jbHVkZT8NCj4NCj4gWW91ciBkcmFmdCBzdGF0ZXM6DQo+DQo+DQo+ICAgICBUaGUgb3B0aW9u LWRhdGEgb2YgT1BUSU9OX1JBRElVUyBpcyBvbmUgb3IgYSBsaXN0IG9mIFJBRElVUw0KPiAgICAg YXR0cmlidXRlcyByZWNlaXZlZCBpbiB0aGUgQWNjZXNzLUFjY2VwdCBtZXNzYWdlIGZyb20gdGhl IFJBRElVUw0KPiAgICAgc2VydmVyLiAgQXMgdGhlIHNhbWUgbWV0aG9kIGluIFtSRkM0MDE0XSwg b25seSB0aGUgYXR0cmlidXRlcyBsaXN0ZWQNCj4gICAgIGluIHRoZSB0YWJsZSBiZWxvdyBtYXkg YmUgaW5jbHVkZWQgaW4gdGhlIE9QVElPTl9SQURJVVMuDQo+DQo+IFJGQyA0MDE0IHN0YXRlczoN Cj4NCj4NCj4gICAgIFRvIGF2b2lkIGRlcGVuZGVuY2llcyBiZXR3ZWVuIHRoZSBhZGRyZXNzIGFs bG9jYXRpb24gYW5kIG90aGVyIHN0YXRlDQo+ICAgICBpbmZvcm1hdGlvbiBiZXR3ZWVuIHRoZSBS QURJVVMgc2VydmVyIGFuZCB0aGUgREhDUCBzZXJ2ZXIsIHRoZSBESENQDQo+ICAgICByZWxheSBh Z2VudCBTSE9VTEQgaW5jbHVkZSBvbmx5IHRoZSBhdHRyaWJ1dGVzIGluIHRoZSB0YWJsZSBiZWxv dyBpbg0KPiAgICAgYW4gaW5zdGFuY2Ugb2YgdGhlIFJBRElVUyBBdHRyaWJ1dGVzIHN1Ym9wdGlv bi4gIFRoZSB0YWJsZSwgYmFzZWQgb24NCj4gICAgIHRoZSBhbmFseXNpcyBpbiBSRkMgMzU4MCBb OF0sIGxpc3RzIGF0dHJpYnV0ZXMgdGhhdCBNQVkgYmUgaW5jbHVkZWQ6DQo+DQo+DQo+IEknbSB0 cnlpbmcgdG8gdW5kZXJzdGFuZCBpZiBSRkMgNDAxNCByZWZlcnMgdG8gREhDUHY0IG9ubHkgYW5k IGlmIHlvdXIgZHJhZnQgcmVmZXJzIHRvIERIQ1B2NiBvbmx5LCBhbmQgaWYgeWVzLCB3aHkgYSBE SENQdjQgc2VydmVyIHNob3VsZCBrbm93IGFib3V0IGFuIElQdjYgYXR0cmlidXRlIGFuZCB2aWNl IHZlcnNhLg0KPg0KPg0KPiAtLQ0KPiBUYXNzb3MNCj4gT24gMjkvNy8yMDEyIDg6MDIgpsymzCwg TGVhZiB5ZWggd3JvdGU6DQo+IERlYXIgREhDIGZvbGtzLA0KPg0KPiBUaGUgZHJhZnQtaWV0ZiAo dmVyLi0wMSkgJiB0aGUgcHJvcG9zZWQgKE9QVElPTl9SQURJVVMpIG9uIHRoZSBhZ2VuZGEgb2Yg SUVURjg0IERIQyBzZXNzaW9uLCBpcyB3YWl0aW5nIGZvciB5b3VyIHJldmlldyBhbmQgY29tbWVu dHMuDQo+DQo+DQo+IEJlc3QgUmVnYXJkcywNCj4gTGVhZg0KPg0KPiBQUy4gKGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy84NC9hZ2VuZGEvZGhjLyApDQo+DQo+DQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnDQo+IFNlbnQ6IE1vbmRheSwgSnVseSAzMCwgMjAxMiA5OjU4IEFNDQo+IFRvOiBp LWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4gQ2M6IGRoY3dnQGlldGYub3JnDQo+IFN1YmplY3Q6IFtk aGN3Z10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LXJhZGl1cy1vcHQtMDEudHh0 DQo+DQo+DQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s aW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4gICBUaGlzIGRyYWZ0IGlzIGEgd29y ayBpdGVtIG9mIHRoZSBEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBXb3JraW5nIEdyb3VwIG9m IHRoZSBJRVRGLg0KPg0KPiAgICAgICBUaXRsZSAgICAgICAgICAgOiBSQURJVVMgT3B0aW9uIGZv ciBESENQdjYgUmVsYXkgQWdlbnRzIG9uIEJyb2FkYmFuZCBBY2Nlc3MgU2VydmVyDQo+ICAgICAg IEF1dGhvcihzKSAgICAgICA6IExlYWYgWS4gWWVoDQo+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgIE1vaGFtZWQgQm91Y2FkYWlyDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRlZCBM ZW1vbg0KPiAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcmFk aXVzLW9wdC0wMS50eHQNCj4gICAgICAgUGFnZXMgICAgICAgICAgIDogOQ0KPiAgICAgICBEYXRl ICAgICAgICAgICAgOiAyMDEyLTA3LTI5DQo+DQo+IEFic3RyYWN0Og0KPiAgICAgVGhlIERIQ1B2 NiBSQURJVVMgb3B0aW9uIHByb3ZpZGVzIGEgY29tbXVuaWNhdGlvbiBtZWNoYW5pc20gYmV0d2Vl bg0KPiAgICAgcmVsYXkgYWdlbnQgYW5kIHRoZSBzZXJ2ZXIuICBUaGlzIG1lY2hhbmlzbSBjYW4g aGVscCB0aGUgY2VudHJhbGl6ZWQNCj4gICAgIERIQ1B2NiBzZXJ2ZXIgdG8gc2VsZWN0IHRoZSBy aWdodCBjb25maWd1cmF0aW9uIGZvciB0aGUgY2xpZW50IGJhc2VkDQo+ICAgICBvbiB0aGUgYXV0 aG9yaXphdGlvbiBpbmZvcm1hdGlvbiByZWNlaXZlZCBmcm9tIGEgc2VwYXJhdGUgUkFESVVTDQo+ ICAgICBzZXJ2ZXIgd2hpY2ggaXMgbm90IGxvY2F0ZWQgYXQgdGhlIHNhbWUgcGxhY2Ugb2YgREhD UHY2IHNlcnZlciBpbiB0aGUNCj4gICAgIGNhc2VzIHdoZXJlIHRoZSBOQVMgYWN0cyBhcyBESENQ djYgcmVsYXkgYWdlbnQgYW5kIFJBRElVUyBjbGllbnQNCj4gICAgIHNpbXVsdGFuZW91c2x5Lg0K Pg0KPg0KPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBp czoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaGMtZGhj cHY2LXJhZGl1cy1vcHQNCj4NCj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFp bGFibGUgYXQ6DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGhjLWRo Y3B2Ni1yYWRpdXMtb3B0LTAxDQo+DQo+IEEgZGlmZiBmcm9tIHByZXZpb3VzIHZlcnNpb24gaXMg YXZhaWxhYmxlIGF0Og0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWlldGYtZGhjLWRoY3B2Ni1yYWRpdXMtb3B0LTAxDQo+DQo+DQo+IEludGVybmV0LURyYWZ0cyBh cmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gZGhjd2cgbWFpbGluZyBsaXN0DQo+IGRoY3dnQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZGhjd2cgbWFpbGlu ZyBsaXN0DQo+IGRoY3dnQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGhjd2cNCj4NCj4NCj4NCj4NCg0KDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9p IGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGlu ZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVy aXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29y b3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVu dG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlh dGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlz dHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBj b25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5k ZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJp bnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWws IFRoYW5rcy4NCg0K